Span sanity—ideal feature teams

 As I described in Too much of a good thing?, there are sane ways to appropriately size feature teams for a fixed amount of work and timeframe. You want the fewest number of people in each role that still ensures work flows smoothly and is completed on time. But what about services that continuously deliver ever-changing value? The strong sense of scope for a specific release is diminished, since whatever doesn’t ship today, this week, or this month, can ship tomorrow, next week, or next month. How do you determine the ideal feature team size for continuous delivery?

Idealistic ignoramuses and theoretical theologians would say that the perfect feature team is a pool of interchangeable engineers who are assigned as needed to whatever feature is next, returning to the pool upon feature completion. These large pools of people would report to a tiny number of HR-savvy managers, minimizing useless management overhead. If it weren’t for reality, this would be genius.

However, in the real world, people aren’t instantly interchangeable, team dynamics matter, and leads who know, understand, and care about you turn out to be desirable (as rare as they may seem to be). The real world demands real feature teams that develop a rapport as well as software. Executives and HR folks might wish to set team size based on some span of control number (the ratio of employees to managers) in order to flatten organizations, but surely there’s a sane way to set that value—a way that balances the needs of the business with the effectiveness of the feature teams. It turns out there is, and the value may surprise you.

That would be ideal

What does the ideal feature team look like? Let’s make a few assumptions.

• The team owns a cohesive app, service, or component. Staying small and focused, with clear ownership and control, is important for any effective team.
• The team delivers value to customers continuously. The days of year-long ship cycles are over. Now even Windows aspires to be a service and flight new code to preview audiences constantly.
• The team tests and supports what it delivers. When you deliver value constantly, quality must be there from the start, and the only people who already know the code well enough to support it are the people who built it. DevOps is the new normal.

Based on these assumptions, the ideal feature team should include program management (PM), development, and service engineer roles. You need a PM to manage relationships with other teams, be the point person for customer engagement, and help keep the team organized and focused (one per feature team is probably enough). You need developers to design, build, and maintain the code and tests. You need service engineers to design, construct, and support the environment that hosts the code (components and apps may need less of this role). Together, these roles plan, build, deploy, and operate their app, service, or component.

These three roles may be dedicated or interchangeable, depending on the team’s capabilities and preferences. How many people you need in each role depends on business requirements.

Eric Aside

I left out user experience designers and technical writers from the feature team, since they are usually shared across teams. I left out testers because test writing falls increasingly on developers and testing in production. However, all of these roles could be added to the feature team as needed.

Show me the money

To design the ideal feature team, we must consider some realities of team dynamics and business constraints.

• PM desires conflict with other roles. PMs want to deliver everything tomorrow. Developers and service engineers want to occasionally eat and sleep. Historically, it’s best if PMs don’t report to the other roles and vice-versa. Ideally, they are equal peers.
• Manager experience and quality counts. Good team leads make a huge difference. Pure people-managers who oversee 20–50 reports lack the technical context and direct exposure to provide engineers with the career guidance and personal feedback they need to grow and be successful. Instead, for the ideal feature team, we need leads who are technical enough to provide strong design guidance and experienced enough to provide strong career guidance.
• Engineers are expensive, and experienced engineers are really expensive. The fully burdened cost of an engineer is roughly $250K per year. (That includes salary, benefits, bonus, stock, morale, travel, conferences and training, machines, power, networking, floor space, furniture, heating, cooling, etc.) The fully burdened cost of a lead in the principal band is roughly $350K per year.

Ideally, you want the biggest impact for the lowest cost. Good leads are quite expensive and in limited supply. You also need clear feature team direction and leadership. For the ideal feature team, we’ll want just one PM and one dev lead as peers. With those positions set, we only need to determine the number of developers and service engineers that report to the dev lead. There is an ideal number, and it hinges on the dev lead’s role.

Less is more

Principal band leads who have no reports can contribute more than average engineers—that’s what you’d expect for the principal band. As leads add reports, they have less time for individual contribution. But the give and take of feedback with just a few reports improves the lead’s contribution and the contribution of team members—the whole is greater than the sum of its parts.

However, once leads have five direct reports that require monitoring, they’ve reached their limit. (You can read a nice summary of the phenomenon here.) At that point, there are enough daily interruptions that reliable focus time is gone. Leads can still make a contribution over time, but not reliably each week. Keep adding reports, and eventually leads do nothing but deal with that day’s crisis, stifling the give and take of feedback and causing the whole team to suffer. (I’ve seen this happen consistently when there are 10 to 15 reports, depending on the lead.)

The key to optimizing the number of reports is paying attention to the transition point.

• With no reports, we have one contributor (the lead).
• Each report we add also adds a contributor, up to four reports (five contributors).
• At five reports, we add a new contributor, but subtract the lead as a steady contributor. This is the transition point. We’re paying another $250K, yet losing the most capable contributor at a cost of $350K. Adding the fifth report actually subtracts $100K in steady individual contribution. Although the lead still contributes in other ways, we’d have been better off staying with four reports.
• Having six reports is an improvement over five, but things get worse again around 10 reports, when the lead can no longer effectively lead. You’d be much better off with two teams of five (each with a lead and four reports) than one team with a lead and nine reports.There you have it. The ideal feature team is six people: a PM, a lead, and four engineers reporting to the lead. For services, the four reports might be two developers and two service engineers. For apps and components, the four reports might be four developers or three developers and one service engineer.

  I’ve been using six-person teams with a PM, a dev lead, two developers, and two service engineers to run my services for the nearly four years. They sit together. They communicate all the time. They support their own live services. And they are uniformly the best performing teams I’ve ever had, and I’ve had some great teams.

Eric Aside

It’s far easier for a lead to manage five senior and principal engineers than five entry-level engineers due to the amount of monitoring and oversight required. Typically, leads manage a mix of experienced and entry-level engineers.

Tell me what I say

Let’s cover some rude questions.

• “Can’t the lead still contribute with five or more reports?” Yes, a good lead will find time here and there to contribute, but that time won’t be reliable. If the time isn’t reliable, the lead’s individual contribution isn’t reliable. That means either the lead isn’t contributing effectively or is only contributing inconsequential work. Either way, his or her individual contribution is diminished.
• “How can a PM and five engineers deliver what’s committed?” Quite well. We’re assuming continuous delivery, so the team is constantly delivering value to customers in priority order. Since the team is small, communication and coordination are clear. Everyone on the team is contributing important work, including the lead. The approach is actually amazingly efficient and productive.
• “But how can a feature team of six people scale to the needs of the division?” By having a bunch of six-person feature teams, each owning a cohesive app, service, or component. If your cohesive apps, services, or components are far too big for a six-person team to manage, and are such a tangled mess that there’s no way for separate teams to work on them together, then you’ve got bigger problems than finding the ideal team size.
• “Why waste some of the six people on service engineering?” If you’re not deploying a service, then you likely don’t need service engineers. But for a service, the design, construction, and support of the environment that hosts the service is just as important, complex, and dynamic as the design, building, and testing of the code. By being on the same small team, the service engineers and developers can create robust, scalable, and performant services that run as reliably and efficiently as the team.
• “But who will support the live site?” The six-person feature team supports the live site—they are a DevOps team (read Bogeyman buddy—DevOps).
• “But how will this small team have time for delivering new value?” A DevOps team constantly upgrades its services so that live site issues are minimized. Every time there’s a problem, the DevOps team does a root cause analysis to determine what failed, how it failed, and why the failure wasn’t automatically detected and rectified. Then it improves the monitoring, recovery, and robustness of the services it owns so that the issue doesn’t recur. In time, live site issues become as rare as customers rightfully expect, and the feature team has plenty of bandwidth for delivering new value.
• “But what if my division has service engineers sitting in a different org?” Ideally, you’d move your team’s service engineers to your group and save the extra management overhead. But virtual teams can also work well, so long as they work together daily, preferably sitting together in the same hall or space (see Collaboration cache—colocation).

The times they are a-changin’

Are you on an ideal feature team? I’m guessing you aren’t. Maybe your team has more than six members. Maybe your lead doesn’t have enough reliable time to make an individual contribution, even though she’s one of the best people on the team. Maybe not everyone on your team is doing equally important work. Maybe your PM and service engineers serve multiple teams, don’t attend your daily standup, and don’t sit together with you. Maybe you don’t deliver value continuously, spending as much of your time planning and coordinating as you do coding. Maybe you rely on others to clean up your live-site issues, while your technical debt builds and your customers suffer. Maybe my ideal feature teams run circles around yours.

We live in a competitive world and a competitive workplace. You can sit back comfortably, rest on what you know, and let the world pass you by. Or you can understand what makes the best teams the best and get on board. The train is leaving the station. Better hop on.