Never Staff to the Peak

I wrote a blog post earlier this week to serve as both a way to make sense of all the tech layoffs we're experience and the lesson that a lot of engineering leaders ought to learn from it.

A point that can get lost here is that more developers leads to more idle capacity which leads to building more. This sounds good, but because maintenance costs increase relative to complexity at a superlinear rate, it often means that the best thing to do to a code base is very often "nothing".

Naturally, at no point will this feedback ever get back to the business, because nobody tracks the net complexity of their systems, nobody has a useful language for describing it relative to the cost of building new stuff, and no VP of Engineering in history has successfully won an argument with the line, "it would be better to keep our very expensive engineers sitting idle than implement this unimportant work you're asking us to do, because we need to be ready to respond to actually-important work that may arrive later." (There's a reason I'm not a VP of Engineering, if you're wondering.)

Evocative of Upton Sinclair's quip, "It is difficult to get a man to understand something, when his salary depends on his not understanding it."