Many companies have too many engineers (and some not enough). This is mainly due to #engineers = f1(revenue || vc money) while it should be #engineers = f2(prob

Many companies have too many engineers (and some not enough). This is mainly due to #engineers = f1(revenue || vc money) while it should be #engineers = f2(problem). Mostly because our industry has no clue about f2 and so falls back to f1. But this also works with business thinking, e.g. CEO thinking techbudget = 0.1 * revenue With the law of the used budget (all people always use up their budget of fear to not get the budget next year when they might need it), CTOs use the whole budget #engineers = techbudget/salary so f1 is often #engineers = f1(revenue) = (revenue * 0.X - hosting - laptops - licenses)/ salary and with salary >> hosting, salary >> laptops, licenses -> 0 due to open source usage, f1(revenue) = revenue * 0.X / engineer salary (the 0.X is determined by VC experience/push, negotiation between CEO and CTO, how much of a tech company the CEO sees his company or from his previous experience, most probably on a wholly different tech business model). with no need to understand the tech challenge at hand. For startups and high margin tech business, there is often a large tech budget, so many engineers are hired (also other forces like capability building, war of talents etc. - some startup CEO tell me their VC said they need to hire 100 engineers until the end of the year - this is without knowing anything about the tech problem at hand). Coming to your point: If there are too many engineers for the essential complexity they create accidental complexity.