How to Actually Scale Engineering Teams

Every time scaling went sideways for me, it was never because I was short on people. It was because the team had outgrown the way it was organized, and I kept trying to fix an org-chart problem by hiring.

And more often than not, the real bottleneck was me.

When something broke, my instinct was to jump in and be the hero who fixed it. That instinct feels productive, and it’s the exact thing that keeps a team from growing.

Scaling is really about learning to scale beyond yourself, and that starts with the person reading this.

That is the part most advice on scaling engineering teams gets backwards. The question isn’t “how do I add more engineers faster.” It’s “what has to change about how this team is built before more engineers actually help.” As a four-time founder and CTO, I’ve scaled engineering at three companies now. I bootstrapped VinSolutions to $35 million in annual recurring revenue before we sold it, I built and exited Stackify, and I run Full Scale, where I’ve helped over 200 companies grow their teams. The pattern is the same every time. A big part of that is rethinking hiring software engineers as you scale, not just adding headcount.

Scaling an engineering team is an org-design problem, not a hiring problem.

Get the structure and the leadership right, and adding people multiplies what the team can do. Get it wrong, and every new hire makes the team slower. Part of getting the structure right is a shared leveling framework so everyone knows what each role is accountable for. Here’s how to tell the difference, and what to fix first. It also means measuring engineering productivity by outcomes instead of activity, so adding people compounds the work instead of just adding motion.

Are you the problem?

Before you touch the org chart, sit with an uncomfortable question. Are you the thing holding your team back?

For most leaders, the honest answer is yes, at least some of the time. When something breaks, our instinct is to jump in and fix it ourselves, because we know the system best and it feels good to be the one who saves the day. It also teaches the whole team that the important calls run through us. That’s the exact moment scaling stops.

I know this trap because I lived in it. At Stackify I was doing everything: strategy, product, sales, marketing, and engineering. I thought that was the job. Then my COO, Craig, asked to talk, and my first thought was that he was quitting. Instead he told me, as kindly as he could, that I was the problem. Then he handed me a copy of Rocket Fuel by Gino Wickman, which argues that a company needs both a visionary and an integrator to work. I was the visionary trying to force myself into the integrator’s job, and it was draining me and blocking everyone else.

That moment changed how I lead, and it’s a big part of why I wrote Product Driven. The book is built on five pillars: vision, focus, clarity, ownership, and courage. The one that decides whether you can scale past yourself is ownership.

You can’t scale if every decision still runs through you.

Ownership is how you fix that, and not the fake kind where you hand off a task but keep all the real decisions. The real kind is when you transfer responsibility along with the context, the clarity, and the support people need to run with it. You don’t scale by doing less yourself. You scale by building people who can do more without you in the room.

This was the hardest lesson of my career, and I wrote it in the book as plainly as I could: the most productive thing I could do was make other people more productive. I stopped measuring myself by how much I could carry, and started measuring what the team could do when I wasn’t there. I’m not the hero anymore. I’m the leader.

If you lead engineers, that shift is your first step. Everything else here, the team structure, the leadership layers, the hiring, only works once you’ve decided to scale beyond yourself.

Hiring faster is not the same as scaling

There’s a rule every engineering leader should have tattooed somewhere they’ll see it. It’s called Brooks’s Law, and it says adding people to a late software project makes it later.

It sounds wrong until you’ve lived it. The reason it’s true is communication. When you have five engineers, there are ten ways for them to talk to each other. At fifteen engineers, there are over a hundred, and that explosion of communication breakdowns on software teams is what slows everything down. The work of keeping everyone aligned grows faster than the headcount does, so at some point each new person you add spends more time getting up to speed and staying in sync than they spend shipping.

I learned this the expensive way. At one point I tried to speed up a behind-schedule project by throwing more developers at it. We didn’t get faster. We got a bigger group of people stepping on each other, asking the same questions, and waiting on the same overloaded senior engineer to unblock them. The lesson was about the engineering roles you actually need to hire, not the raw headcount.

The headcount went up and the output went flat.

That’s the trap. More engineers is the easiest thing to ask for and the easiest thing to approve, so it’s the lever everyone reaches for. But raw headcount only pays off when the structure around it can absorb the people. If you add five engineers to a team that already can’t make a decision without three meetings, you now have a slower team that costs more.

The signs you’ve outgrown your structure, not your headcount

Most teams notice they’re struggling and conclude they need to hire. Usually the real signal is that the current structure has hit its ceiling. The tells are about people and communication, not about your codebase.

What you’re seeing	What it’s actually telling you
The same senior person is in every decision	Authority is too centralized to scale
Onboarding takes longer with each new hire	Knowledge lives in people’s heads, not in writing
One engineer is the only one who understands a system	You have single points of failure, not a team
Simple choices need three meetings	Nobody knows who owns the decision
Communication breaks down past ~15 people	You’ve outgrown a single flat team

When a team pushes past about fifteen people, the flat structure that felt fast and friendly starts to choke. Nobody can hold the whole picture in their head anymore. Decisions that used to happen over a desk now need a meeting, and the meeting needs a follow-up.

None of that is fixed by hiring. It’s fixed by changing how the team is shaped, who owns what, and how decisions move. If you’ve already got more than a handful of these symptoms, the answer isn’t a job posting. It’s a look at your software engineering team structure.

Fix the team structure before you add people

This is the part of team scaling that actually moves the needle, and it’s the part almost nobody does first.

The best book I know on the subject is Team Topologies by Matthew Skelton and Manuel Pais. The core idea is that you should design your teams on purpose instead of letting them sprawl. The book lays out four kinds of teams: stream-aligned teams that own a product or a slice of the business end to end, platform teams that build the internal tools everyone else stands on, enabling teams that help other teams level up, and complicated-subsystem teams that own the one gnarly part that needs deep specialists.

Most growing companies have exactly one kind of team: a big pile of engineers all reporting up through the same funnel. That works at ten people. It falls apart at forty. The architecture is no different, and it holds up far longer than people fear, which is why I tell teams most scalability work can wait.

The fix is to break that pile into small teams that each own something real. Keep them small, because a team you can feed with two pizzas can still move fast, and a team of twelve cannot. Give each team a clear mission and the authority to make its own calls. The goal is to lower the amount any one person has to carry in their head, so they can go deep on their piece instead of staying shallow on everything.

There’s a second reason team boundaries matter, and it’s worth knowing even if you only file it away. Conway’s Law says your software ends up looking like your org chart, because the way your teams communicate shapes the way your systems connect. So when you draw team boundaries, you’re also drawing the seams in your architecture whether you mean to or not. Design the teams well and the system tends to follow. Let the teams sprawl and the codebase sprawls with them.

Small and owned does not mean every team runs off on its own. Randy Silver, a product and leadership consultant, made a point on my podcast that stuck with me: autonomous teams don’t mean people do whatever they want. They work inside a tightly defined box of clear goals and outcomes, and they communicate constantly with everyone their work touches. That’s the difference between small teams that move fast and small teams that quietly fall out of sync, which is exactly how he says teams lose their way as they scale.

You don’t need to copy the book chapter and verse. You need to stop treating “the engineering team” as one giant unit and start treating it as a set of small, owned teams with clear edges. Do that before you hire, and the people you add land inside a structure that can hold them.

The only way to scale a team is to scale ownership

Good structure gives you boxes on a chart. It doesn’t make anyone care. What actually makes scaling work is teams that take ownership of outcomes, not teams that just execute tickets. That is the real goal, and it’s the hardest one to reach.

The only way to scale a team is to scale ownership.

This is one of the five pillars in Product Driven for a reason. Shared ownership is what makes scale possible. Teams that own their outcomes move faster, solve better problems, and care more, because the result is theirs. A team that only owns its scope ships what it was told to ship and then stops thinking. A team that owns the problem keeps going until the customer actually gets value.

Here’s the catch. You can’t order people to take ownership, and you can’t hire for it like it’s a personality trait. Ownership grows in systems, not in individuals. You build it into how the team works, and you build it with three things the book calls vision, focus, and clarity.

Vision is the why. A team that sees the reason behind the work makes good calls on its own, because it knows what it’s aiming at. A team that’s only handed tasks waits around to be told the next one.

Focus means saying no, including no to your own ideas. A team buried under every urgent request can’t own anything, because it’s too busy reacting to take a breath. Protecting a team’s focus is how you give it the room to carry something real.

Clarity is the daily work of making the product, the scope, and the technical direction unambiguous. It isn’t a one-time kickoff doc. It’s the constant practice of making sure everyone knows what “done” means and why it matters. Without it, ownership just turns into people confidently building the wrong thing.

Give a team vision, focus, and clarity, and you’ve handed it enough to own its outcomes without you in the loop. That’s what scaling a team actually means. Not more people reporting up to you, but more teams that can run without you.

Your leadership has to scale before your team does

Here’s the thing nobody tells you when you’re the technical founder or the first VP of Engineering: If you’re sorting out that next layer, it helps to understand the director of engineering vs. VP of engineering question before you pick a title. It’s the same foundation behind what makes a 10x engineer, since the best ones are produced by the environment, not recruited into it.

In a small team, the leader does the work and makes most of the calls. That’s fine at ten engineers. At fifty, a leader who’s still in every decision is the bottleneck the whole company is waiting on. The role has to change from doing the work to designing the org that does the work. Most CTOs fall into that shift by accident and figure it out late. The good ones make the shift on purpose. This is the real shift behind what a 10x developer actually is: the best ones make the whole team faster instead of becoming the bottleneck themselves.

Part of making it on purpose is knowing when to add a layer. The first time you need engineering managers is usually right around the point where one leader can no longer have a real one-on-one with everyone, somewhere in the fifteen-to-twenty-five range. Add that layer too late and your best people burn out or leave because nobody is paying attention to them. Add it too early and you’ve built middle management for a team that didn’t need it yet, which just slows decisions down. A big part of scaling well is deciding which engineering levels you actually need instead of copying a giant company’s ladder.

You also have to separate two ladders that companies love to mash together. Being a great engineer and being a great manager are different jobs that need different skills. Your strongest developer is not automatically your best manager, and forcing that move often costs you a great engineer and gets you a miserable manager. Build a path where someone can grow in technical leadership without being pushed into managing people, and a separate path for the ones who genuinely want to lead people. The same split shows up at the top, which is why it helps to settle the head of engineering vs. CTO question before you write the job description.

Where do those leaders come from? Grow them. Engineers who already know your product and your people make stronger leaders than someone you hired last month off a resume. Engineers who think like owners outperform the ones who wait for tickets, and ownership is exactly the trait you want to spot early and develop. That mindset is the heart of what I wrote about in Product Driven: a team that sees the why behind the work will lead itself far more than a team that’s just executing orders.

Light process beats heavy process

When a team starts to strain, the instinct is to add process. More meetings, more approvals, more rules. It almost always makes things worse.

You can’t fix broken engineering with more process.

The process that actually helps a growing team is the kind that lets people make good decisions without asking. Write things down, so the answer to a question lives in a doc instead of in one person’s memory. Push authority down to the teams that own the work, so decisions don’t pile up on one desk. Lean on async communication, especially once your team spans time zones, so progress doesn’t stall every time someone’s offline.

David Mitchell, the CTO of VML and one of the largest creative agencies in the world, made this point on my podcast: creativity gets buried in big companies when rigid process piles up over the years. The same thing happens to speed. Every gate you add is one more place where good work sits and waits for permission.

That’s it. The aim is to remove the need for permission, not to add more gates. A heavy process is usually a sign that you didn’t get the team structure right and you’re trying to patch it with rules. Fix the structure and most of the process you thought you needed disappears.

The most underrated way to add capacity is offshore

Once your structure is sound and your leadership can scale, then it’s time to talk about adding people. And the most underrated way to add real capacity, especially on a budget, is to hire globally.

I say underrated because most people get it wrong, and the ones who get burned conclude offshore doesn’t work. I learned both sides of that firsthand. At Stackify I ran what I now think of as a four-country experiment. I hired developers in Russia, in Uruguay, in Colombia, and finally in the Philippines.

The Uruguay setup is the one that taught me the most, because it failed.

We worked with a firm there that put a proxy product owner between us and the developers. Every requirement, every question, every bit of feedback went through that one person. The developers never talked to us directly and never really understood our product. We ended up with a team we couldn’t communicate with and a middleman in the way of every decision. That’s not an offshore problem. That’s a structure problem, the same one this whole article is about, just stretched across an ocean.

The Philippines is where it worked, and it worked because we structured it right. By 2018 I had a team of more than twenty Filipino developers who worked directly for us, on our product, as part of our company. There was no middleman and no proxy in the way, so they cared about what we were building the same way the in-house engineers did. That team was a real contributor to the exit when we sold Stackify in 2021. It worked so well that other founders started asking me to set them up the same way, and that’s literally how Full Scale got started. Full Scale now staffs engineering teams across every role, including infrastructure, and if you need to hire dedicated DevOps engineers alongside your product team, the same direct-hire model applies.

Here’s the principle I took away, and it’s the one rule I’d give anyone considering this: offshore works much better when you hire people to work directly for you, long term, as your own team. Hand a pile of requirements to an outsourcing firm and wait for a finished project, and it almost always falls apart. There are smart people all over the world. The thing that decides whether they succeed is whether they’re built into your team or walled off behind a vendor.

The economics are hard to argue with once the structure is right. You can hire strong global talent for 50 to 80 percent less than US rates. A senior engineer who’d cost you $80 to $150 an hour in the States runs more like $30 to $40 an hour through an offshore engagement. That’s not a small saving you reinvest in a nicer office. That’s the difference between affording four engineers and affording ten.

The best proof I have isn’t my own company. It’s AMC Theatres, who run the largest movie-theatre ticketing platform in the world. Their CIO, Derrick Leggett, put it better than I could:

“It’s a fully integrated team. It’s just some of the people happen to be living in the Philippines.”

That’s the whole game. The Filipino engineers join AMC’s standups, use AMC’s tools, and work off AMC’s roadmap, with no parallel vendor layer skimming overhead and getting in the way. They’re treated as AMC engineers, because that’s what they are. It’s the same lesson as the Uruguay story, just from the company that got it right.

If you want the longer version of how to structure this, I wrote a full development team extension guide and a breakdown of staff augmentation that go deeper than I can here. The short version: you always need technical leadership in-house, and the offshore team works best as a long-term extension of it, not a project you toss over a wall.

It’s also worth saying this isn’t a fragile setup that falls apart the moment someone leaves. Full Scale keeps 93 percent of its developers year over year, and we’re Great Place to Work Certified in the Philippines two years running, with 95 percent of employees calling it a great place to work versus 65 percent at a typical company there. A stable team is the whole point, because a team that turns over every nine months can’t scale anything. We wrote up what our Great Place to Work certification means for the team.

The mistakes that quietly break scaling teams

After enough cycles of scaling engineering teams, the same failures show up again and again. Watch for these.

The first is adding process too early. A five-person team that adopts the ceremonies of a fifty-person team just buried itself in meetings for no reason. Add structure when the pain is real, not before.

The second is building management layers you don’t need. Every layer you add is another stop a decision has to make. Add managers when one leader genuinely can’t keep up, and not as a reward for tenure.

The third is hiring for speed instead of fit. Hiring great engineers takes patience, and when you’re behind, the temptation is to fill seats fast. A bad senior hire who fights the team is far more expensive than the empty seat would have been. Slow down enough to hire people who’ll actually work well on your team.

The fourth is centralizing every decision. If everything routes through one person, that person is your ceiling. The whole point of good structure is to let teams decide without asking. If you’ve planned your team capacity but every call still lands on one desk, you haven’t actually scaled, you’ve just added spectators.

Scale your engineering team the right way

The companies that scale well aren’t the ones that hire the fastest. They’re the ones that fix their structure and their leadership first, then add the right people into a team that can hold them. If you want help to scale your development team, whether that’s adding senior engineers in the Philippines or extending the team you already have, let’s talk about what your team actually needs.