I have noticed that as SV companies get larger they tend to adopt the more "old school" approach. Not that it's a binary - it's a spectrum, and depending on management chain/how an org runs, people can have different experiences. I think it's caused by 1. When you have very deep management chains you start to have lots of people with opinions on what you should do, how you should do it, who you should do it with. Eve…
The "SV style" runs into scaling problems. Engineers making product decisions requires that they have a solid grasp on everything the business cares about, which gets harder as the business gets bigger. Direct engineer -> engineer communication between teams is O(N^2) to organize things between N engineers. As you grow I think reducing engineer autonomy is unavoidable, and the goal is merely to stick to reducing it a…
This isn't true in my experience. I'd say it's more like a binary search than a fully-connected network. I talk to my immediate team first. If they can't help, I dig through the company-wide documentation and codebase, then message people who have done or considered something similar to what I'm trying to do; they either give me the information I need, or direct me to someone more likely to have it. Each hop gets me closer to an answer, and I typically end up having to talk to 1-3 engineers rather than the O(500) who work in my organization.
Part of the reason this works is because there are a handful of very senior engineers who have a good sense of what's going on across a big part of the company. Complex requests often get routed through one of these people, and they always seem to know who to talk to. I guess that's a form of hierarchy, but without the "command-and-control" aspect. I see it as an occasional escape hatch rather than a primary means of problem-solving.