One of the hottest terms among tech leaders nowadays seems to be the “scale-up.” You’re no longer a mere startup. They’re relatively easy to identify, as these are companies where all managers are occupied with maintaining the breakneck hiring pace. There’s nothing necessarily bad about achieving this phase. In fact, many times, that’s the right course of action.
Nevertheless, I have had to help several companies that entered this stage prematurely. When kicking up a massive growth spurt at the wrong time, e.g., when the team hasn’t achieved product-market fit, it can lead to the establishment of precisely the habits and culture that you’d want to avoid.
Veering Off Course
The main issue I have with mistimed scale-ups is the rapid dilution of impact per engineer. In the newborn phase of a startup, the first couple of engineers are center stage. Any second where they perform low-impact tasks is painfully obvious. After all, not much else can progress. When they return to the right path, things seem to explode, and the product can be propelled forward.
Poor scale-ups often dilute impact in a way where engineers tackle issues that are smaller and smaller. Product tends to spread itself too thin to keep “feeding the beast.” After all, Jira isn’t going to populate itself with tasks! Features of lesser importance are implemented. Maintaining capabilities that no one genuinely cares about is not weighted heavily as the team has the working hands to account for it.
When I worked at an enterprise division on a product that went through a similar phase, it was clear within several weeks that we could let go a couple of dozen of engineers without any real downside to the clients and company. We were sweating the details of obscure integrations, edge cases that would never happen in the real world, and features that wouldn’t even be used as selling points in a presentation.
This is the point where many engineering organizations take the wrong turn towards tech for tech’s sake. Not seeing the importance of their tasks and lacking the impact that comes with achievements, engineers will gravitate around the new shiny things. We spend hundreds of hours refining tech debt, evaluating new solutions, and lose interest in the business. That’s not the path to engineering excellence.
The best teams I’ve worked with were those that retained the startup mentality and team size until unlocking the right business cases.
Making the Decision Wisely
The Tech Executive Operating System stems from a few leadership axioms. One of them is that great teams are made of layers of force-multipliers. When piling on more working hands doesn’t result in a non-linear jump in effectiveness, you might be going into scale-up prematurely.
When I’m working with CEOs and tech executives to finalize roadmaps and the commensurate hiring plans and budgets, these are the things we consider:
Flywheels: Squads and efforts that are clearly gaining momentum and where product-market fit has been achieved or seems nearby often require rapid growth. When the team is busy turning the flywheel faster and faster, and you can vividly see how more hands turning the wheel would help, scaling up makes sense.
Impact wellsprings: Most successful companies uncover areas where it seems like everything they look they turn up gold. For example, there are markets where creating integrations even for the long-tail of vendors makes sense clearly, as every integration widens the company’s moat and increases its competitive advantage. As opposed to flywheels, where we need to iterate faster to learn faster, these impact founts are areas where value is certain. If increasing the team is guaranteed to result in more impact, it would be malpractice not to do so.
Innovation wiggle room: Lastly, your growth plans should always take the proper buffers into account. Being too prudent with hiring means that you don’t take into account things like natural churn. Moreover, teams cannot innovate, experiment, and try new things out when the team’s size is tailored precisely to your roadmap. When you want to ensure that the team has the capacity to amass tech capital and try things out, you have to scale the organization more than anticipated.