> * 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.