> I work at a company (Google) where the prevailing assumption is that if a team is not getting enough done it should ask for more engineers. What I'm finding

> I work at a company (Google) where the prevailing assumption is that if a team is not getting enough done it should ask for more engineers. What I'm finding at Google is that whenever a team takes longer than 2 quarters to do pretty much anything, that's considered some kind of "problem" that needs to be "fixed." Sometimes the problem is that the technical challenge really needs more than 2 quarters to be adequately addressed. And yes, the first instinct is to ask for more headcount. But often times the problem is also with the headcount you have, not the headcount you don't have. What is usually needed is to get rid of the TLM who got into a management position through the IC track because of the collective delusion that someone who has worked their way up to Senior or Staff SWE by writing dank design docs and uber code (often in vast quantities) has also acquired senior engineering management competency. Once you've hired somebody who has significant education and/or experience with engineering management is managing the team, the next thing for that person to do is figure out how to increase the health and effectiveness of the team they have. You might even need to reorg to get the team size down to 7-10. In the process you need to give the team a couple more quarters to cut their MVP down to the bone and deliver on it. Then, and only then, should you think about throwing more headcount in the team's general direction. And it needs to be done with the goal of adding a layer of management hierarchy, making sure than no more than 7-10 people are in the daily standups.