Leading at Different Scales

Effectively leading teams from 2 to 50+ people

As a leader, your leadership style should change based on various factors for your team: the mix of seniority levels (a largely-senior or largely-junior team), functional composition (for example, engineers only versus other functions like product management), and the stage of the product or platform you are building (for example, “zero-to-one” products versus products in steady state or growth). An important additional factor that I’ll focus on in this post is the size of your team: teams at different sizes call for you to lead them in different ways.

This post talks about some of the factors I’ve considered as I’ve led teams at different sizes. It’s focused on engineering leadership, though some principles may apply to teams in other functions. It’s also focused on a “typical” software development team that works on a mix of new and sustaining product development, without a heavy research component. These are the sorts of teams that I am most familiar with.

A note on terminology below: I use "leadership" in this article to mean direct management of a team. People can be leaders without being managers, but this article is focused specifically on leadership via management.

You’ll likely start your management career managing a small team, say 2 to 4 people (it is usually an organizational red flag to have a manager managing a single person, so 2 people is probably the smallest size of team you should be managing). At this size, you should know in detail what everyone on the team is working on. You’re likely writing code and design documents yourself, and otherwise making direct technical contributions, serving as the official or de facto tech lead on the team.

You should aim to have a detailed technical understanding of the systems your team is responsible for, as well as an idea of how those systems fit into the bigger picture of your company’s overall architecture. Your team is likely all early or mid-career individual contributors, and you should aim to help them develop both their technical skills and their understanding of the big picture through 1:1 coaching, technical reviews, and training.

At a startup I founded in 2009, I was the de facto technical architect and overall manager for the small engineering team. My days were spent helping people with day to day tasks, monitoring progress and writing code myself, though as founder I was also involved in selling and business development activities that are not typical for managers of teams at this size.

At team sizes between 5 and 10 people, you may be managing a single large team or multiple smaller teams; at some companies, this is the “Senior Engineering Manager” level. At this size, you will typically start to delegate some of the responsibilities that you took on yourself at the previous stage. For example, you’ll likely have one or more tech leads, and (toward the larger end) maybe a manager, who will help you run the team effectively. You’re not a technical expert in all of the areas your team covers, and you are likely not writing code on a daily basis. You should still expect to know in detail all the projects your team is working on.

I’ve found that the primary skills that you need to be successful in this stage are delegation, prioritization, and articulating the “why” to your team. Delegation helps free you up to focus on more strategic work, and to work with cross-functional partners (product management, design, other engineering teams) to understand what matters to the company. You can then use that understanding to make sure your team is working on the highest-impact things (prioritization), and to help your team understand how their work fits into the big picture (the “why”).

In my experience, you can’t directly manage more than around 7 or 8 people effectively, so as your team grows beyond this size you will likely need a manager to manage a sub-team within your broader team. An effective pattern I’ve seen is for a manager with around 10 people to directly manage one sub-team with a few individual contributors, and to have a manager manage another sub-team. This structure is shown in the image below.

The manager here is likely a mix of a tech lead and a manager, as described for the previous stage. Some companies have an explicit “Tech Lead/Manager”, or “TL/M”, title for this purpose.

This structure is likely the first time you will have to think about organizational design; it’s worth considering how you will split your team in this way. Generally, it’s helpful if you can organize things so that the team the manager runs (sub-team 2) has some sort of coherence in its scope, distinct from the team that you yourself manage (sub-team 1). This is generally possible with some creative thinking.

This structure needs to be handled thoughtfully: it can create an imbalance where the people in the sub-team you directly manage (sub-team 1) are considered hierarchically “above” the people in the indirectly managed sub-team (sub-team 2), and you need to actively work to counteract this effect.

Make sure not to treat sub-team 2 as higher distance from you in any way than sub-team 1 — that is more a division of convenience than one meant to indicate that one sub-team is more important than another. For example, while you cannot meet 1:1 with people in sub-team 2 as often as people you manage directly (that would defeat some of the purpose of the division), you should still meet with your entire team regularly, making no distinction between your directly managed and indirectly managed sub-teams. Make sure especially that everyone has equal access to contextual information: information asymmetry is one of the primary ways in which power within companies is expressed, so you want to make sure that everyone on your broader team feels that they have the same level of access to information regardless of whether they report to you directly or not.

The next level of complexity is running teams between 10 and 25 people. Effectively leading teams at this size requires growing increasingly strong leaders under you. You may have multiple managers, some with their own managers, reporting to you, and your primary way to add value is to help them run their teams most effectively. Given the rule of thumb above of roughly 1 manager for a team of 7 or 8 people, at the higher end of this scale (a team of 25 people), you will need at least 3 managers. You won’t typically be directly managing individual contributors at this size, though a common structure is to have a “staff” or “principal” engineer reporting to you to support multiple projects and teams across your organization.

At this size, you typically won’t know the details of all the projects your team is working on, though you should still aim to have a general sense of everything going on.

To lead effectively at this size, you will need to templatize and scale your management techniques. You should think of your role from the perspectives of both execution (progress against commitments) and people management, and aim to develop techniques that help you be effective in both areas.

On the execution axis, you won’t be able to dive deep into every project your team is doing, but you’ll need to be aware of how things are going in general. Aim to have “pull” techniques to regularly gather information on work across your team, while also digging (in more of a “push” fashion) into particularly important projects or areas as needed.

An effective “pull” technique I’ve used is to have different teams present progress against OKRs or other targets periodically to me, perhaps once every two weeks. For an organization of this size, it should be feasible to have execution reviews of every team multiple times a quarter. Aim to really understand the details, including the technical details, at these reviews — your time is well spent by understanding not just the project management aspects of the work (what percentage is complete, is the work slipping relative to commitments) but also whether it is being done to the right level of quality, how the work impacts overall system architecture, etc.

The other axis that you want to focus on is connection to people. You should aim to have regular 1:1s with everyone on your team who does not report directly to you at roughly the same frequency (biweekly or once a month). At the higher end of this size range, this may be challenging, but aim to maintain this level of connection for as long as you can: I’ve found that nothing can replace direct connection with people for really helping you understand what’s going well and poorly across your team.

At this size, you should also establish some forums for your organization: design review sessions, demos, tech talks, etc. Some of these may be redundant with forums in the broader organization within which your team sits, and you should evaluate where it makes sense to pay the costs of the redundancy. For example, if your team is building a single cohesive part of a larger system, it may make sense to have regular demo meetings within your team, even if the broader organization outside your team also has a cadence of demos: demos within your team can help give everyone in your team a sense of the cohesive whole of what your team does.

For organizations between 25 and 50 people, effective leadership requires building on the techniques you’ve used at smaller sizes. Typically you will rely heavily on your leaders at this stage, focusing on growing your direct reports (and their reports) into leaders of leaders. There’s probably too much going on across your organization for the synchronous “pull” technique described previously to be effective; you will simply have too many status update meetings to attend. Instead, what I’ve found works well is to have your direct reports send you a structured progress report periodically (say once a week) listing progress across their area; they can in turn delegate the updates for specific sub-areas within their area to their own leaders. I find these reports very valuable in understanding both the state of various projects, but also the relative rates of progress in different teams across the organization. You can complement these written status updates with periodic live deep dives into a limited number of strategically important areas.

Direct people connection is more important than ever, but you will need to scale that as well; at this size, you likely will not be able to keep up a cadence of regular meetings with everyone in your team. I’ve found it useful to have regular “skip level” meetings with tech leads or senior people in the team, and ad hoc 1:1s with new hires or high performers within the team. You may also find it useful at this stage to set up regular “office hours” where people can book time with you, though I have found these challenging to manage logistically (and often after an initial burst of activity when the office hours are announced, engagement has tended to drop off). Regardless, this is an area in which to keep investing: it is worth it to find ways to connect with people at all levels in your organization, both for team motivation and because it can help you spot problems early. I have also found value in more structured ways of getting a pulse of your organization such as satisfaction surveys, though the highest fidelity information you will get will still be from direct conversations.

At this size, you will need to actively manage the design of your organization. For example, you will likely want to make sure that all teams are roughly equally strong, so that you don’t end up with “hotspots” where some teams are exceptionally strong or exceptionally weak. You’ll want some scope coherence between adjacent teams, so that teams grouped under a manager (or manager of managers) have things in common. You’ll probably want most teams to have a mix of seniority levels, to provide mentoring opportunities between more senior and more junior people. And you may start to develop a location strategy, deciding to home specific teams in specific geographies, or do the reverse, where you explicitly have geographically distributed teams for a “follow the sun” development model. In a previous company, we homed product development-focused teams in one location, infrastructure teams in another location, and innovation-focused AI teams in a third location. This sort of location coherence can help ensure that people working in similar areas have a lot of work hours overlap; it has the disadvantage that on-call support requires people to work outside regular business hours in their timezone. In that previous company, we partially solved this by having common on-call groups across multiple teams in the US and Europe, giving us 24-hour on-call hour support with most people working roughly within regular business hours.

You also need to guard against organizational entropy, where structures that were appropriate in the past persist through inertia even after they stop making sense. It’s helpful to look regularly (say once a quarter) at your organization and decide if the current team structures make sense, and if the right people are on the right teams. Be open to moving people between teams to give them exposure to new areas and “shake things up”; good ideas often come from people immersed in one area seeing connections to another area they might not have worked in before.

At team sizes over 50 people, you should operate the sub-teams under your overall team using the techniques that worked for you at smaller sizes. In this way, leadership at larger sizes can be fairly fractal. For example, you may have leaders who each run teams of 20–30 people, who in turn use the techniques for that size of team. Continue to be proactive about seeking out information about how things are going across your organization, both by talking with people within and outside your organization, and through written updates from your leaders. You will likely start leaning more on formal mechanisms of evaluation at this stage: satisfaction surveys, formal performance reviews and calibration results, productivity tracking software etc, but make sure not to use these tools as substitutes for direct experience. In my experience, the highest fidelity data is gathered via face to face conversations, and you should aim to maintain that level of direct insight into your organization as much as you can.

At this level (and really starting at team sizes of 35+ or so), it’s worth also putting together groups of people who can serve as horizontal experts in specific areas (for example, data design, security, or infrastructure) across your organization. These groups can then advise teams across your organization in those areas, helping set the technical quality bar and ensuring cohesiveness in architecture and design across disparate projects. You should aim to develop strong relationships with these experts, even if they don’t report to you directly, and lean on their insights about the organization.

You may find that your work at this level is driven by business metrics that are at least partially outside your control (they depend on product or business factors in addition to engineering factors); make efforts to tie the work your team does to the business metrics that matter to the overall division or company. If you cannot see a direct connection, you should resolve the misalignment; either the work fits under a new metric or goal that should be bubbled up to a higher level, or work on the project should stop. You should avoid having “orphan” projects that are unconnected to things that have been stated to matter to your broader organization; sometimes this value is in terms of platform improvements or tech debt reduction, but must be explicitly stated and agreed to. You should see your job at this level to be a good steward of the company’s resources, and a primary way in which you do that is to be relentless about justifying how everything within your organization contributes to the broader goals of your division or company.

I’ll write more about leading large teams in a follow-up post.

Effectively leading teams at different sizes requires a varying mix of skills. I’ve found developing these skills a rewarding experience; it has helped me (I think) create more positive change in the teams I’ve worked on, and has helped me build deeper connections with the people I work with. I hope some of these techniques help you on your own leadership journey.

This article was also published on my blog.