Scaling teams is one of my favourite things to do – probably because it’s where people meet systems, with ever-changing questions about what makes teams effective and how to balance now versus next.

Sometimes this gets presented in a pure numbers way, but I like to come at it from a systems perspective: Engineering teams have three primary components: people, projects, and process.

Strong teams of people who are individually doing well, deliver business value, predictably and efficiently.

I don’t include process in that statement deliberately – good teams are not defined by their processes, good teams use and evolve process effectively in order to meet the organizational need. My hot take: engineers often love process, but when they love it, they call it culture.

This post builds on a previous one about what makes a good team. This is about how to scale one. Scaling teams requires attention to all three of these components, identifying and addressing bottlenecks as (or ideally before) they emerge.

People

Having enough people (hiring) – As you scale, your hiring process needs to be effective – can it be improved? Should it be improved?

The process needs to be efficient without sacrificing quality. It’s not enough to just hire people – you also need to make them effective. Good onboarding is predictable.

Note that whether the hiring process is working well isn’t impacted only by the stage and needs of the team, but also by the market. The market has been a wild ride the past few years, and AI has presented additional special challenges. It’s worth thinking regularly about whether your hiring process is a good predictor of success, and if you have concerns about that, what you can do about them.

Ensuring people are properly supported (managers/leadership) – in an ideal world, everyone gets a good manager. Sometimes “good enough” has to do.

As teams scale, you need to grow your management layer thoughtfully. What blend of hiring and growing internally makes most sense for you? Both of these take time and have their own associated risks.

Feedback loops/culture – feedback loops need to be solid. Under-performers are addressed (up or out), high performers get developed. As teams grow, individuals can be lost sight of, and when there’s pressure often high performers get taken for granted rather than developed further.

If you want to build teams where high performers can thrive, you need to make sure that good work gets rewarded and poor work gets addressed. Feedback loops are foundational for this (more on that in this post on 1:1 structure).

Team alignment and values – larger teams need more deliberate alignment. What are the shared values and principles that guide how the team operates?

A team is formed based on what they share. Is that some shared ownership (like a codebase), or a mission (like a flow or feature). What metrics is the team responsible for? As teams scale, the scope of what they can cover adjusts, so you need to come back to the shared purpose and figure out how that needs to evolve, too.

Projects

What is being worked on and why – clarity of purpose becomes even more critical as teams grow. Everyone should understand the portfolio of work and how it connects to business value.

With more people, what used to be obvious starts to be less obvious over time. You need to get more explicit about metrics, mission, and goals, and more structured about prioritization and decision-making.

Work allocation becomes critical. For small teams, there’s often a ‘goto person’ who gets pinged for everything, but the more people you have, the more important it is to create transparency, equity, and accountability in work allocation.

Effective project management – it’s not enough to pick the right work, you also need to deliver that work, and to continue to deliver consistently over time.

This means thinking about the project life cycle:

• Set projects up for success – clear goals, well defined scope, and the right people involved from the start.
• Keep projects on track – larger teams need better visibility into project health. Set up warning signs and mechanisms for course correction before problems compound. As teams scale, decide what you’ll actively monitor versus what gets surfaced to you through people or process.
• End projects well – close projects cleanly, capturing learnings, and celebrating success often gets lost in the push to start the next thing.

Process

Process should be driven in support of the above. Good process is like an oil that keeps a team moving, bad process is like glue that favours performance over progress.

How do we communicate – meeting structures, standups, documentation practices all need to evolve. What worked for 5 people won’t work for 50.

How do we work together – collaboration practices like PR review, design review, and pairing need to scale without becoming bottlenecks.

How do we escalate effectively – as teams grow, escalation paths get longer and more complex. Clear escalation mechanisms prevent small problems from becoming crises.

How do we build a mindset of continuous improvement – all process has a purpose. Easy things are easy. Hard things are possible. Processes evolve as problems change.

Identifying Bottlenecks

The key to scaling is identifying where the bottlenecks are and addressing them before they constrain growth. Is it hiring? Is it unclear prioritization? Is it communication overhead? Is it feedback loops breaking down?

Good scaling isn’t about implementing every process or even doing every process perfectly. It’s about thoughtfully addressing the specific constraints your team is facing, evolving your approach as the team and organization changes, and always keeping the focus on people delivering value effectively.