> At very large software companies, programming ability, technical expertise, and raw resources are not the limiting factors. Coordination is.

If coordination is your limiting factor I'd argue that it shouldn't be, and you're not investing enough in removing it as a factor. Companies can use various tools to do this, for example:

* Defining directly responsible individuals / single-threaded leaders so that every choice doesn't involve massive coordination

* Putting people who work together in the office sitting next to each other most days of the week

* Or, for remote work, having a strong culture of async communication that is visible to the broader group by default, for example with Slack

> * Defining directly responsible individuals / single-threaded leaders so that every choice doesn't involve massive coordination

Obviously doing this makes sense when possible, but in cases where you see it, it's usually due to a fair amount of work to have made this possible.

To give a simple example, I work on a class of problems that require a VP level approval for new instances of $thing. I've gotten this down to a pretty straightforward process where I can work with folks who are proposing a new instance, get things working, and then the VP usually is happy to stamp the work we've already done. Though in some cases they aren't, and they have (good, probing) questions or changes they'd like us to make. But that's only possible because I have a longstanding relationship with the set of folks who ultimately approve this kind of thing, I have worked with them on a process that they like, and I have the experience to shepherd things effectively, and their trust and buy-in. And I'd argue that my case is pretty simple, because while there are a handful of responsible people that I could go to, there's rarely any individual concerned.

Consider a different, relatively common case, of a client and a server that are owned by different teams. The client wants a feature in the server, and perhaps is willing to do some development and loan headcount to implement the feature. Who is the single responsible party here?

It should probably be either the manager of the client server team or the mutual manager of both if the teams are fairly close in the wider org, but then you have multiple indirect layers between the people doing the work (client team members) and the accountable person (server team manager), and that's the state you get to after you've done a bunch of coordination work and gotten everyone to agree to that division of labor and accountability.