In a true startup, you have an early phase of experimentation. You ship fast, the rules are loose, and you break things. The cost of mistakes slowly increases, until one day you realize that mistakes are no longer worth the fast & rule-free iteration. Maybe it’s lost revenue, maybe it’s unhappy customers, or maybe it’s something else. The point is: Feedback has been received and rules were made. It is in that moment I believe you stop being a startup. You now have inherent value and it can be risked.

If you have experienced engineering leaders, what happens next is fairly straightforward. You start iteratively adopting bits of process, bits of pipelines & tooling, orderly hiring — your leaders reach into their toolbox and suggest fixes that slowly grow into something cohesive that lets humans keep moving at speed without running into each other so much.

If you don’t have that experience, what happens next is fairly predictable: arbitrary rules & gatekeeping. “We only can release if X, Y, Z sign off personally” is a classic. “No one can touch A without person X reviewing it” is another. The common theme is they are often individual-based (as opposed to role- or team-based) and designed as hurdles to slow things down to a “safe speed”. From there, your culture gets a bit weird. You hire new folks who are afraid to touch anything they weren’t explicitly assigned. Your knowledge is in the heads of a few key veterans. And your releases slowly grind to a halt as everyone follows “the rules” and aren’t empowered to change them. Your entire department is in lock-step with the founder or first technical lead and the boot gets heavier and heavier by the day.

Now you have a second problem: You can’t hire super senior developers to come in and help fix it. They can smell the problem a mile away and don’t want anything to do with it. You don’t have a team, really, you have someone setting the rules and bunch of developers following the rules, and they’ve seen this movie and it doesn’t end well for them if they agree to tackle it. They will come in with tools and ideas but quickly find that no one has the authority to make changes and so things continue to stall. The power rests somewhere upstream and is inaccessible, no matter how much experience they bring to bear.

If you don’t invest in engineering leadership early and prioritize good management as its own discipline, you end up in a spiral of trying to find the most-clever but green developers available, releasing them into your org, and watching them flounder and bounce. It’s very tempting to skip the investment because you’re not doing the math right.

Say I have five engineers today. If I have enough revenue for a new hire, I’m likely to think in terms of productivity per dollar. So maybe I could A) hire one senior dev now, or I could B) hire a junior and MUCH SOONER have money for a second junior, or I could C) wait and hire no one so that after a bit longer I could afford a very senior engineering lead or manager. Here’s how a novice approaches this: A new senior dev is 20% more productivity (5 become 6)! Or I could hire juniors and OFFLOAD tasks from my other more experienced devs and maybe get a 40% gain!! Or, I could hire a manager/super senior and get… some squishy value, maybe.

I cannot adequately convey how myopic and inexperienced this view is. Good leadership is a force multiplier. Like, double. Like, triple. Finding a leader your engineers trust is worth its weight in gold. It’s incredibly hard, but the idea of it being some sort of dollar-based “trade-off” with more bodies-in-chairs sooner is ludicrous. Figuring this out early in the lifecycle of your company is a bigger competitive advantage than any feature you’ll ever dream up.