[joshuamorton]

This is far less true than you make it seem, I think. I can think of executives who are very clear decision makers in particular contexts.

But for most engineers, most of the time, you're working well below the level of those executives, and especially if you're engaging with shared infrastructure, the executive who is the final decision maker is Sundar.

For example, I am involved in an issue where 3 ICs whose levels are between 4 and 6 (really this is a simplification), are engaged in dealing with solving a problem. These three ICs are in 3 different PAs, reporting indirectly to 3 different SVPs, who join up at Sundar. It isn't worth it to have the CEO spend time refereeing this decision.

Ultimately this was resolved at the director level, by consensus building, because it would reflect badly on every one of those directors if they failed to resolve it and had to escalate to SVPs or CEOs about something that is, on the company scale, trivial (to be clear this is still a thing that is multiple engineer-years of work, but it's still Google-trivial).

I expect the same is true at Amazon or Apple. Cook and Bezos aren't making every decision. VPs and Directors deal with small potatoes, and most things are small potatoes. The difference may be organizationally that those companies are more siloed and so leaves from different trees interact less often. But this friction also is often intentional and has value (SRE explicitly not reporting up through normal product eng ladders, for example).

[cobookman]

The executives are still beholden to supporting teams. Want to launch a new feature that depends on GFE. Looks like the current GFE is end-of-life, but the the new one still isn't ready yet. Let's connect with GFE team on if they'll support the older GFE and accept our CL to launch...<GFE has power to delay your launch right here>

Next up is the documentation. That requires the doc team's approval. Oh they require IL8n, lets go to that team and see where in their queue we are <Doc team has power to delay your launch>.

This same flow occurs across all supporting teams. And it can get complex with Service A depends on Service B, which depends on Service C...and Service C can reject the quota increase delaying your launch...etc.

> I expect the same is true at Amazon or Apple

At amazon you would connect to who everyone reports up to, or whoever has clear decision making authority. You would then provide a written document going over the facts and suggested decisions, and ask they make the call. After that its "disagree and commit".

[joshuamorton]

> The executives are still beholden to supporting teams. Want to launch a new feature that depends on GFE. Looks like the current GFE is end-of-life, but the the new one still isn't ready yet. Let's connect with GFE team on if they'll support the older GFE and accept our CL to launch...<GFE has power to delay your launch right here>

I don't see how this is distinct from what I said, except perhaps that for many teams, the GFE team reports up to a different SVP than you, so the person who you'd connect up via is the CEO, which like I said, doesn't scale for every launch.

If you want to try and escalate your launch up to the CEO, nothing is stopping you, except perhaps your director or VP. But that is itself a signal that perhaps this isn't worth escalating about and that the status quo is acceptable.