>Another aspect is your changes often have to be approved by a lot of people, which is not the case on small projects.
So you need more engineers because you hired more middle managers?
That's a little absurd in my opinion but I am likely wrong in this assumption.
It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more engineers to increase velocity.
It sounds wasteful until you've been with a company that outgrew its management structure. I spent many years at a place that grew from 200 to 800 people in about 3 years. We prided ourselves on the flat org and high level of responsibility. But as we approached the 500 mark, the cracks really started to show:
- Things truly requiring management handling (like raises, big expenses, hiring, etc.) took FOREVER in the best case because of the bottleneck at the top. More commonly, they got lost/dropped without explanation.
- Flow of sensitive information was slow and inconsistent because the only way to communicate with a flat org is all-or-nothing.
- Specialist engineers found themselves trying to track too many projects before they realized the overload was a problem (this was me)
- The president (and effective sole owner) was still deeply involved in all projects and regularly exercised veto rights. As the project load increased, the vetos landed later and later - some times after we'd already spent 50% of the budget! This left our customers up a creek and our reputation suffered.
It's not just approvals from managers, sometimes you need approval from a group of peer engineers just to create new routes in an (internal) API, or to launch a new cron job that will upload an Excel spreadsheet in marketing once a day with data from Google Forms.
Also, UX wants to see the final result on their screen before they approve your build, so before deploy you have to push into a test cluster, but there are only 10 of those, and you need to wait until one of them is free.
And of course your Jenkins server takes 2h to build and fails sometimes, so pushing small changes takes 2h because you have to babysit the build. The testing cluster above also takes 2h to build. CTO believes in engineers taking care of their code, so SRE is not allowed to handle the builds.
And then there's an average of 2h of meetings per day (I'm not including the 40 minute daily scrum because your squad has 15 people). Half of them to discuss the production incident you had because you didn't see the Slack alerts when you were in another meeting. The other half is chapter and guild meetings where you don't talk, but participation is mandatory. On Mondays you have sprint planning, so forget about coding.
Engineering fact: A 300 watt amplifier is only twice as loud (+10 dB) as a 30 watt amplifier. The same math works for engineering teams.
The best way I’ve ever heard this explained is to imagine a software business as a machine. Early on, it’s easy to trust - the machine is small, there aren’t many working parts and dependencies are all manageable. Making things even easier, the founders generally have control over hiring and they’re often still at the hiring friends/colleagues stage of their evolution.
Then, the machine gets bigger and the dependency graph gets more complicated. Suddenly, if you change one small part of your module, you run a very real chance of ruining something someone in a faraway department relies upon. So, the machine evolves to have things like coding standards and more formalized review processes. Unfortunately, the machine is composed of humans and humans aren’t as simple as just pulling it all apart, greasing it up and putting it back into service. So every single time you add a review step, there’s a chance it genuinely adds to quality (or removes risk). But, there’s also a chance that that change was about ego and organizational power. Then, in five to ten years, they hire MBAs to come in and lay people off.
I think you need as many approvals as your risk tolerance allows for... they're not pointless. If they are pointless then sure, get rid of them. But I don't know how you'd guess that number without deep knowledge of the business.
It is sometimes better to go slower than you could and be more confident that the product is acceptable. Approvals can but don't necessarily help with that.
You start out with a very light process. Then you have outages, or you discover that not every part of the system with appropriate care, etc. Then you put some process into place. That slows everyone down a bit... your business keeps growing, though, so "more slightly less efficient people" can capture more of the market than "fewer more efficient people" can because you have a calculation where something like 1000.4 is still greater than 101.0, so if that additional stuff getting done is worth the cost of more people, you keep doing it!
And you can cycle through this a few times. And yes, people will also cycle through "we need to reduce bottlenecks" and such, but at this point, you've been successful, you've got a bunch of money coming in, and pissing off your clients is something to be avoided, since individual efficiency is not the end goal by itself.
> So you need more engineers because you hired more middle managers?
Companies often implement more process for good reason.
The antithesis of old Facebook's Move Fast And Break Things is to have policies that ensure good security, stability, accessibility, privacy, internationalization, meeting legal requirements, etc. and that usually means processes to ensure that eager engineers and product managers actually meet those policies, instead of rushing to launch.
It's easy to scoff at process when you're a small company or startup whose mistakes will go largely unnoticed unless you suddenly go viral. If you're a Big Tech Company, accidentally messing up security or privacy somewhat means getting a front page article on The Verge detailing your crimes.
Working at Google now, there's plenty of process involves in developing and launching a thing, but I can't really say any of the pieces are without merit.
You're not hiring more middle managers because you want too, no large companies have to promote engineers to senior engineering managers to handle the complexities of approvals required by compliance such as SOC2,SOC3,ISO27001,FedRAMP, GDPR, etc.
I've worked at companies were every line of code has to be reviewed and approved by a lawyer. Yes a lawyer (usually a former engineer that the company paid to go to law school) is reviewing some dumb little javascript or python script for license and legal compliance.
> I've worked at companies were every line of code has to be reviewed and approved by a lawyer. Yes a lawyer (usually a former engineer that the company paid to go to law school) is reviewing some dumb little javascript or python script for license and legal compliance.
Jesus, what company was that? And how about libraries included... Will this lawyer now also need to go through that?
The approvals usually come from other engineers. It stems from having to modify highly-sensitive code which usually has an owner you need to work with to get an approval.
The approvals often exist for valid reasons. You can't just get rid of them. You can try to streamline the approval process but that only gets you so far.
So you need more engineers because you hired more middle managers?
That's a little absurd in my opinion but I am likely wrong in this assumption.
It just seems like the reaction to "We have lots of approvals" should be figuring out how to reduce the amount of approvals needed, not hiring more engineers to increase velocity.