As the CTO of a growing software development team, I was starting to feel anxious. Our engineering team grew from a handful to almost 30 people in the last few years. Don’t get me wrong — I was thrilled that the product we were building was taking off and we were able to expand. But, I felt the growing pains as our once tight-knit team struggled to maintain alignment.
Early morning debates over architecture started to be replaced with rigid processes. Releases slowed down as more approvals and coordination were needed across teams. When it became apparent that to achieve everything we wanted, we had to double our engineering headcount again this upcoming year, my first reaction was sheer panic.
Were we ready to level up? Could we capture the innovative magic of our early days on a larger scale? That’s when it became clear that it was time to evolve. But we had to do it thoughtfully, not reactively. We needed to intentionally build the management capacity and structures to fully unlock the team.
Easier said than done, I thought. Thankfully, Will Larson’s book “An Elegant Puzzle: Systems of Engineering Management” convinced me it was the right path. I dug into the text, hoping for insights from Larson’s experiences leading high-scaling engineering organizations. His candid, pragmatic advice around scaling teams, avoiding bottlenecks, and focusing on finishing projects gave me hope.
I ended up with pages of notes. This was the wisdom I needed to guide my team through growth while preserving our agility. My panic was replaced by excitement as I looked forward to applying Larson’s lessons to level up as an engineering leader. Plenty of work was ahead, but I was confident we could navigate this puzzle elegantly after all.
Here are some of the notes I took. Hopefully, they’ll be useful to you too.
Expand the Team to Unlock Innovation
If there are not enough people, the team falls behind, treads water, or repays debt.
We were excited when we started one of our current five-year projects. But our tiny dev team spent every day treading water, trying not to drown in support tickets. Big ideas shrank into triage. Overworked and overwhelmed, we had no capacity for innovation or new features. It was death by a thousand cuts.
Finally, we realized that it was time to expand the team. With more engineers sharing the load, we could start swimming instead of sinking. Morale began to soar as we started to ship some of the long-promised features. Turns out you need a tribe to build something great.
Watch Manager-Employee Ratios
Make sure managers only manage a few people.
Maria was promoted to engineering manager with high hopes. But with fifteen direct, she was utterly overwhelmed. Priorities slipped through the cracks. There was no time for one-on-ones. Maria was barely sleeping as inboxes and bugs piled up.
At one point, an engineer almost quit over lack of guidance. It was the last straw. No one can develop, coach, and support a whole pack of people single-handedly. Watch for manager burnout and split teams before it’s too late. Your people are everything.
Scale Up Rapidly After While the Team Gels
It is better to scale rapidly to start progressing sooner after the gelling period ends.
After deciding to expand the team, we took a slow approach, hiring only a handful of people over six months. We were afraid of the gelling period affecting the productivity of the core team. Guess what? We still struggled after a long period of six months because we needed to expand further.
Then, we tried hiring more rapidly, and our bloated ship finally started sailing towards the horizon. With a whole crew cooperating, we could navigate rough waters. Next time, we’ll be staffing up front to set sail sooner.
Add Management Layers
You need to add a management layer for every additional order of magnitude of engineers.
After about 25 team members, the flat structure isn’t cutting it anymore. Every decision gets funneled up to someone for approval. Smothered by process, progress slowly down to a crawl.
The solution is to hire managers as well, not just individual contributors. Once the engineering managers can breathe again, the engineers get empowered with more autonomy. Keep the management sandwich in mind — scale your leaders and your doers.
Plan Ahead for System Migrations
You have to rewrite systems once in a while, but migrating to them is the real productivity killer.
Our monolithic legacy app was creaking at the stitchings. Every tweak required days of debugging whack-a-mole. We had to kill this beast before it killed us. But we couldn’t afford a complete rewrite, hoping for a gradual migration instead. We were still straddling two complex systems a year later, wasting countless dev hours.
Sometimes, you must toss the old car and buy a new one. Legacy migrations are a black hole, so plan for them accordingly. Set a deadline to force the rebirth your team needs. Of course, that’s easier said than done.
Focus on Finishing
To make progress, you must finish what you’ve started.
Shiny new feature smell lures our team like cats to catnip. We get obsessed with building something innovative. But when its fresh glow fades, off we dart to the next bright idea, often leaving wreckage behind. Half-baked prototypes start to litter our landscape.
But these abandoned ideas have zero value to everyone. As an experiment, try to say no to starting new work until you’ve finished something. Try it — the momentum of shipping is intoxicating. Your team will thrive.
Minimize Interruptions
Interruptions are the main time killer.
Interruptions are the bane of an engineer’s existence. You are just starting to sink into coding zen than… ping! The slightest distraction shatters your mental flow into fragments. A question from the project manager. Follow-ups regarding yesterday’s code review. Your brain feels like a jittery hamster on a wheel, constantly scooped up and dropped in a new maze.
When you treasure developer flow states, you unlock their superpowers. We adopted async communication a while ago, and the whole team blossomed. You can optimize humans just like code.
Larson’s insights have given me concrete ideas to experiment with as I aim to optimize my engineering team’s organizational design. I can’t recommend “An Elegant Puzzle” more to any engineering manager looking for thought-provoking perspectives on building great teams. Implementing even a fraction of Larson’s suggestions will significantly improve your team’s effectiveness.
Originally published on Medium.com
