Just yesterday, your development team was just a handful of eager engineers working long hours to build an MVP from duct tape and dreams. The sleepy startup became a hiring frenzy after finding your product market fit. What was once a tight-knit team is now a few engineering teams and growing.
While you used to join the coders for the hack sessions, you now spend days in management meetings. You find yourself longing for the scrappy startup days when decisions were fast, and titles didn’t matter.
Things that used to move at lightning speed have slowed down. Where simple product experiments once took days, they now get stuck in multi-week research and approval cycles. Code that engineers hacked together overnight now goes through labored multi-team review and QA processes.
You dread reading the latest monthly velocity charts showing downward team productivity trends. Engineers complain of too many meetings, context switching, and waiting for other teams. Some even consider giving notice in frustration.
You recall the enterprise companies you swore you’d never become — bureaucratic dinosaurs where the org chart matters more than the product and people. But it suddenly feels like you are becoming just that — an innovation-stifling monster of process will soon replace passion and creativity.
The reality is your scaling startup sits in a precarious grey area, no longer a fly-by-night startup yet far from the comforts and constraints of the enterprise. How do you continue to expand complexity without collapsing under weight? When is the right time to stop blindly growing and focus on getting your house in order? Can you avoid swinging the pendulum too far towards red tape or chaos?
You used to have all the answers when it was just you and a whiteboard full of dreams. But now the problems span org charts, budgets, and competing priorities across multiple teams. If only you could return to those simpler times, but the genie of growth has left the bottle, and there are no magic answers for managing this in between stage.
Your Startup Days
In those early wild west days as a scrappy startup, your tiny band of engineers must wear many different hats. When it’s just a handful of people, everybody has to pitch in on everything — dreaming up ideas, scoping out plans, banging out code, squashing bugs, you name it. The potential upside down the road is huge, driving everyone to work long hours. Formal processes slow things down when you need to move incredibly fast, so you don’t sweat the structure too much.
The key people you bring on board are likely those mad scientist types who thrive under pressure and don’t mind navigating ambiguity. You need builders and innovators who can MacGyver creative solutions out of nothing. You work closely with the engineers to swiftly piece together minimally viable versions of features, pivoting as needed until you find that sweet spot of product-market fit. Initially, it’s more about progress over perfection when tradeoffs need to be made.
Once you prove that traction and bring in some funding, it becomes a race to scale up that engineering team to crank out features at warp speed. Keeping that scrappy startup mojo as some structure starts solidifying becomes tough. You must focus on keeping your engineering team in flow rather than locking things down tightly with strict rules too early. It gets trickier to strike that balance as complexity grows, but heavy bureaucracy can bog down delivering value.
Why Big Company Playbooks Fall Short
As your scrappy group of developers grows into a larger development team, you may be tempted to raid the dusty management playbooks of mature enterprises for tips on engineering management. But those big company methodologies usually don’t apply well when you’re building creative things that would make typical risk-averse enterprise management anxious. Plus, you want to keep your talented people around for the long haul, not churn through bodies like some huge corporation. And let’s be honest — those rigid processes designed for large engineering teams tend to suck the life out of getting amazing things done quickly.
The whole enterprise approach revolves around complexity, size, and replacing parts like a machine. It does make sense for a big company. They run projects through specialized teams and defined procedures so they can efficiently slot new people in when others burn out and quit. But in a smaller organization, you want every person to matter. Uniquely gifted builders who have been with you for a while need to keep challenged and excited about their work for years to come.
On top of that, the marathon multi-year enterprise initiatives with utterly complex architectures often crawl along at a snail’s pace to launch. Your fast-moving team slinging out customer-focused features just can’t afford that.
Maturing engineering teams absolutely need more structure to level up. However, applying heavyweight enterprise processes and structures will likely slug output velocity. The art is finding the path in the middle that adds only the minimal processes to enable quality and coordination while keeping that scrappy startup soul alive.
When to Stop Growing?
There’s this uncomfortable zone between running wild with no rules and being smothered by bureaucracy. You need more structure so things don’t spiral into chaos as you add engineers to the team. However, too many rigid processes will leech away the agility. Stay vigilant about still keeping delivering value to customers. Business outcomes should continue improving amidst growth.
Also, keep a sharp watch for signs that scaling headcount is actually decreasing overall output as complexity compounds. Velocity metrics like features shipped slowing down can signal a bloated organization losing its edge. Be ready to stop expanding before morale, quality, and momentum erode too far.
Also, look for cultural symptoms like rising friction between groups or individual productivity plateauing. Are your original rockstar engineers getting drowned out by a swarm of average newbies? Big red flags your organization is bloating uncomfortably include complaints about “too many meetings” or people waiting around on other teams.
Before diseconomies of scale totally sap performance, explore what lightweight process upgrades could help tame the chaos. For example, breaking into semi-autonomous sub-teams can keep coordination needs in check so things don’t spiral. But, as Conway’s law suggests, the organization structure is tightly coupled with software architecture, so if your app is a monolith, you may be up to some serious refactoring.
Trying to pinpoint peak efficient engineering team scale is part art, part science. Having buffer capacity beyond immediate needs is good for stability and attrition. But stay vigilant that you aren’t overstuffing the clown car past the point of diminishing returns. Stop cramming in more people when the output gains no longer justify the input costs.
Originally published on Medium.com
