Scaling an engineering team in as requirements pile up is a challenging feat. With a hockey-stick user growth, engineering managers feel like drowning trying to balance non-stop requests for new features. But every feature adds to the towering technical debt that quickly takes up half the developer’s time. And amidst all this, users of a live app are constantly reporting new bugs daily that need attention.
In a situation like that, a scrappy team of developers can barely keep up. They would work nights and weekends to make at least some visible progress. Morale would plummet along with productivity. Managers must make a tough call: gradually scale up over a year or hire more engineers ASAP.
The Struggle of Competing Priorities
Maria gulped her third coffee, staring desperately at the sprint burn-down chart. There were only 2 days left, and her team had completed just one of the five planned big features.
As an engineering manager, she managed a scrappy team of developers supporting a telecom app growing exponentially. This quarter alone, they were expected to deliver new features, including new tech like AI.
But her team barely kept pace for the past 6 months, treading water. Of the hundreds of tasks completed last quarter, two-thirds were technical debt, bugs, and user requests instead of new features.
Morale was plummeting along with productivity. Her team stayed late every night, backs aching from tension, trying to hit impossible deadlines. Lately, engineers have started calling in sick from stress.
The growing mountain of technical debt would soon crush all advancement at their current velocity. Forget any out-of-the-box solutions to deliver new features — even maintaining the service was becoming unbearable.
Maria’s stomach churned, imagining the catastrophic impact of any significant outage. Support requests were already piling up unanswered as the team struggled with competing priorities.
Their set of features all users were waiting for this year, scheduled to roll out next month, now seemed woefully in jeopardy. Maria mentally calculated how many all-nighters it would take just to keep their heads above water. Something needed to change soon, or the team wouldn’t survive the year.
Too Much Work, Too Little Time
Mary was the engineering manager at a team building a product whose codebase grew 4x yearly. But her squad remained stagnant at just a dozen developers. The widening gap between what users needed and resources was becoming unmanageable.
Mary felt like she was drowning in juggling all the competing priorities. There were non-stop feature requests from the product team as they tried to grow. But every new feature added to their technical debt. The team spent half her time maintaining their creaky infrastructure, which became a legacy over the years. And users reported new bugs daily that needed squashing.
With such a small team, meeting even the modest goals set on the product roadmap was impossible. Mary knew she needed to urgently scale up the engineering team to have a sustainable process. Only dramatically higher headcount could match their user growth.
Scaling Slowly vs Scaling Quickly
Initially, the shareholders were reluctant to approve massively increasing engineering headcount. They worried about costs spiraling out of control. The CTO suggested a compromise — they would scale up gradually with 1–2 new hires per quarter.
Mary pushed back hard. Their growth of demands wouldn’t wait. At the current trajectory, their small team would implode from exhaustion soon. Their technical debt would accumulate so high that building new features would halt entirely.
The gradual scaling plan would take multiple years to fully staff the team appropriately. Mary argued they needed to scale dramatically within months to meet demands and save the team and the product.
Scaling the Team Quickly
To scale quickly, Mary would need to focus on hiring backend, frontend, and DevOps engineers to build out a full-stack team. Finding great talent rapidly was a challenge. But with everyone now aligned on the urgency, they can bring on board top engineers by offering perks like remote work options, equity, and learning budgets.
With more engineers, they could assign dedicated specialists for ongoing big sub-projects. This will increase focus and velocity. Knowledge will also become less siloed as major initiatives will have shared ownership.
Increased Focus, Productivity, and Morale
The rapid scaling of Maria’s engineering team would pay dividends quickly. Engineers could make meaningful progress on roadmap features instead of just reacting to fires. The features they committed to delivering at the beginning of the year that are valuable to the end users would be rolled out successfully and on time.
There will be a steady decrease in technical debt as the team will allocate resources to address it. Users and customers will for sure notice fewer bugs and faster resolution of issues. Morale will jump up as engineers will feel empowered by autonomy and purpose.
With the foundations for scalable processes built, true engineering innovation and creativity missing in stressed-out environments will flourish. Rapid scaling will unlock the team’s potential, setting them up for sustainable long-term success.
Originally posted on Medium.com
