What Actually Breaks When You Scale an Engineering Team Fast

Scaling fast doesn't necessarily break your technology. It breaks your ability to focus.

I joined a Series A startup as its first engineering leader. There were four people on the engineering team when I got there. We were building a platform to take on the residential house flipping market when the housing market was red hot. Eighteen months later we had about seventy people in engineering. Thirty FTEs including engineers, QA, and managers, plus nearshore vendors and two outsourced partners spread across six product teams. We were building fast.

I thought technical constraints would be my biggest challenge as we built in a hurry. Our deployment pipeline would collapse, or we’d hit some architectural ceiling. That’s not what happened. What broke was focus.

Product was hiring faster than engineering could absorb

Our VP of Product kept hiring product managers, one for each vertical. Each PM needed a team to build their vision. This seemed reasonable until I found myself trying to staff all of them at once.

We couldn’t hire fast enough. We brought in two outsourced vendors, seemingly the fastest way to get new teams running. One vendor basically owned their vertical’s roadmap. The separation created a lack of awareness more than anything. The associated PM was happy working with that team and iterating on their own. They didn’t need anything from us, and I had no visibility into their day to day.

The other vendor just misunderstood their role. They thought they were building a whole platform, not focusing on a particular vertical. This happened for multiple reasons: Philosophical differences between the product leader and me about how to scale. A lack of trust. And mostly us moving too fast to get alignment right.

The shape of the engineering org was being dictated by product’s hiring, not by our capacity to absorb. Every new PM created pressure for a new team, and we kept saying yes because the business needed it. Or we thought it did. Our VP of Product had more influence with the CEO than I did. The CEO believed more people would solve everything. He wanted all six verticals built at once and wasn’t willing to tie-break. I pushed back, but saying no doesn’t work when the person above you won’t prioritize. You need a framework, not just a strong opinion. I didn’t have one.

Teams without managers, managers without context

I was scaling up teams before I had managers for them. Sometimes I was managing those teams myself, juggling too many things to give any real attention. Other times I’d bring in a manager, but the team they inherited had two engineers. Their first job was hiring, and they were hiring into a product and codebase they didn’t know. They couldn’t evaluate candidates against the work because they didn’t understand the work. Some teams had experienced engineers who could figure things out on their own. Others had junior people who needed daily guidance and weren’t getting it because their manager was still finding the bathroom.

You might think I should have slowed down, hired managers first, and given them time to help shape the team they’d take on. Easier said than done. Hiring takes time. We were in a competitive landscape. I also wanted local candidates for managerial roles, which narrowed the pool. Every week without a team on a vertical felt like falling behind.

Trying to build everything at once

The biggest mistake was distributing resources across every team instead of focusing on one or two things before expanding.

The business needed a platform and didn’t have one. They were surviving on manual processes, spreadsheets, and a menagerie of third-party software. Every part of the business had a legitimate need for a legitimate software platform. So we tried to build all of it at once. Made sense at the time.

What we should have done, and what I wanted to do, was pick the two highest-leverage problems, solve them well, and then expand. Instead we had teams spread across every vertical making incremental progress, and nothing was far enough along to matter.

We shipped. It wasn’t enough.

We weren’t just sitting around. We shipped a working iOS app for inspectors to use in the field. We built software actively collecting deal information from house flippers. We made real progress digitizing the renovation process. People were using what we built.

But shipping despite chaos isn’t scaling well. We were delivering product across every vertical and none were complete enough to fully replace the manual processes the business was already using. The business side kept doing things the old way. Sales kept selling, deals kept closing, operations kept running on patchwork and third-party tools. Each time they found a solution that didn’t involve our software, the urgency to adopt what we were building dropped a little.

That created a vicious cycle. The business moves on without you, which makes leadership nervous, which creates more pressure to build everything at once, which spreads your teams thinner, which means nothing ships fast enough to change how the company actually operates. Repeat.

If we’d focused and shipped one thing that actually replaced a manual process or an expensive vendor, we’d have bought real credibility instead of just promising it. The company eventually failed. Not entirely because of this, but this didn’t help.

What I’d do differently

If I had it to do over again, I’d hire managers before teams, not after. I don’t care if a manager only has two reports for the first month. They need time to learn the product vision and the codebase before they start hiring and leading. A team that’s half-staffed with mixed seniority and no dedicated manager isn’t a team. It’s a group of people who share a Slack channel.

I’d focus on two things built well over six things built halfway. Every time.

And I’d change how we used vendors. We treated them like real teams building production software. That was wrong. If I did it again, I’d reposition them as rapid prototyping support. A PM with vendor support can prototype fast enough to prove out a business case without burning core engineering resources. The PMs who can’t make the case don’t get a dedicated team. Their project gets starved. That sounds harsh, but it takes the prioritization decision out of the CEO’s hands and makes it earn-based. The alternative is what I lived through. Six teams, all underfunded, all making incremental progress, none of them shipping anything complete enough to matter.

The tricky part is that a high-fidelity prototype looks like working software to a CEO who isn’t technical. You blur the line between “we proved this is worth building” and “we already built it, why can’t we ship it.” You have to manage that expectation explicitly, or you’ve just created a new version of the same problem.

Scaling fast is a focusing problem. Everything feels urgent. Almost none of it is sequenced. The companies that get this right are the ones where someone has the authority to pick two things and let the other four hurt for a while.