Over the years, growing software teams have moved from functional silos to small, autonomous cross-functional teams, but not everyone has made that transition.
This is sad to see.
Once you’ve worked in a cross-functional team, you can’t imagine any other way of working. When a small team with a clear remit is put on a problem, it’s more fun, results are easier to deliver, and generally speaking things are a bit less confusing. So how exactly do you get there?
Letting go
So what's the hold-up? The big reason we don’t embrace this structure is in the end, it boils down to a really big problem. A reluctance to give up control over lots of people. Some feel that knowing what people are working on and signing off on every task, or at least being able to see those tasks clearly, is how you maintain order in an organization.
When you reflect on that, this has been a universal management problem since Peter Druckers time, who often wrote about how autonomy contributed to higher levels of productivity output.
Despite what people say in meetings, the reality is managers often have a hard time delegating authority, what if someone doesn’t do as good of a job as I need them to! And so a team structure that tackles that head-on would obviously be tricky for some to embrace.
When you boil down this big transition, moving to smaller teams requires someone to let go and have a little courage that everything will be okay. They must give teams the ability to run more independently, and that, for some, is scary to sanction. There is some foundational growing-up to do in order to move to autonomous teams, and I’m becoming more aware of this as time goes on.
Over the last few years, given the amount of work I’ve done on OKRs, I’ve been asked by a few startups to come in, chat to them about goal setting and team structures, and I thought I’d talk about one problem that comes up all the time.
“We have a team with 15 people in it and everything is a mess.”
So how many pizzas?
The two-pizza rule. This term comes up a lot these days (thanks to Amazon) when talking about how large software teams should be. It says you should be able to feed your teams (like factory-farmed chickens, one assumes) about two pizzas, and that will keep them full.
But this phrase is more than that. When we start out as little crews in a garage, building software with a few friends, no managers, no rules, things seem to move quickly, its all very fun. But as we grow, those feelings and observations rot away, something changes and it’s hard to know how or why it changed. It just doesn’t feel the same and you realize it takes forever to do anything.
The Ringelmann Effect
As team sizes get larger, a few things start to change. This isn’t just my gut feeling, or the reasons software companies around the world have embraced the model, there is a term for it called the Ringelmann effect.
The Ringelmann Effect is the tendency for individual members of a group to become increasingly less productive as the size of their group increases.
Ringelmanns study had groups and individuals pull on a rope, and measure their output. What he found was that as more individuals were added to the group, individuals effort would decline.
More people per team = less effort.
1. Priorities bounce around
When teams get too big, developers and designers bounce from crisis to crisis, following whatever major project happens to be urgent this week from a large list of equally important sounding priorities.
In reality, if you had a team using something like Scrum by the letter, planning sprints and being very focused, this can mitigate this problem, but from what I’ve observed, even the most disciplined scrum teams, for whatever reason as they grow, face a bouncing priority problem. You could also argue OKRs solve this problem, but what I see in practice, is that the larger the teams get, the more OKRs they have, which seem so widely varied, it may as well be an enormous to-do list and it’s unclear what the focus really is.
I think this is because when a team remit is broad, giving any particular piece of work to anyone on the team seems to make sense because there are no clear boundaries of what that team should be doing. We don’t ask electricians to fix our toilet because we know thats not what their team is for.
2. It’s hard to know who is working on what
The second thing that comes up with large teams is it’s unclear who is working on what, but not because the tickets are unclear in JIRA or whatever. It is because most of us don’t care — we have our own shit to deal with.
If our focus is to build a new website, for instance, that’s all we think about. And when you see, in the same team, someone is working on a new mobile app, the details of that don’t interest you, and second, because they don’t interest you, you pay no real attention to why, how, or what that person is doing because it simply doesn’t impact your day to day life - and this is fine. So the real question is, why create more noise for someone who isn’t working on that mobile app in the first place?
You could argue having everyone together is good because you want to make sure everyone is aligned, but in practice, people will usually just tune out, start working on something on their laptop while someone goes deep on their mobile app project that has nothing to do with your objectives.
3. The team is unsure what its purpose is.
We know there is substantial evidence pointing to a teams purpose as being one of the three important drivers for motivation. So when a team works on seemingly unrelated projects or ideas, their orientation becomes very muddy.
https://www.youtube.com/watch?v=u6XAPnuFjJc
OKRs can be good to fix this, for a period, but a general purposeful direction can be wildly calming for a team whos world is already pretty chaotic.
“If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. “ — Antoine de Saint-Exupery
4. Ceremonies become ceremonial, not useful.
If you’ve ever sat in a standup or retro and listened to other members of a team talk about things you know nothing about, your team is probably too big.
The best way to see this play out is to observe a team on Zoom, and if you can sense that some of the team members are all talking about the same thing, and talking in the same language, those people are really their own team. The rest, are just tuning in to watch (tune out and work on their laptops while others talk.)
Then velocity slows down.
With all of these forces coming into play, what you end up with is a team that is just not as fast or productive as it could be. If you still don’t think these smaller, autonomous teams are worth considering, that’s fine, but one thing should keep you up at night.
A competitor who might do something similar to you, if the only change they make is a move to smaller, more productive team structures, this could be the difference-maker that starts to swallow up your market share.
The common objection. “But we don’t have enough XYZ senior roles?”
If you feel people on your teams simply couldn’t do the job, such as the case where you might have lots of junior roles and only one senior role, I hear you.
In this case, putting a team of junior people together might fill you with dread. In my experience, I’ve found this to not really matter anyway, but to help put things at ease, the best solution to this is to really manage and coach those resources and upskill them on gaps.
Put together real coaching and development plans to help them get the skills required to do a great job. I’ve used this team competency matrix on a wall before which can be a fun way for teams to track their upskilling over the year. The colours represent three things.
- I can teach it
- I can do it
- I know about it.
So when do you crack one team in half?
If any of the above signs are happening, it might be time to think about splitting your teams up. How you split teams or what kind of remit you give them I won’t cover here, because those topics are large in themselves.
The one factor I don’t think matters is how many pizzas your team can eat. Some teams will make sense to have 10 people in them, some, having 1 or 2 people in a team will be fine. But I would suggest that all teams (most of the time at least) have the following roles exercised.
- Someone to build it (usually an engineer)
- Someone to design it (usually a product designer)
- And someone to prioritize the work, and fill other gaps (usually a product manager)
Ideally, I also think having two engineers per team is best. This would mean my ideal team size, at the baseline is 4 people.
Now, this doesn’t mean you can’t have someone on a team who can do two of those roles together, but think of this as a more rule of thumb.
Your second team
If you want to try moving to a two-team system but aren’t sure what to put your teams on, the following questions may inspire some answers.
- What are the biggest problems, stopping us reaching our goals, that we face?
- What jobs are our users hiring us to do for them? (JTBD)
- Which of the startup pirate metrics do we care most about right now?
- Does the product we make have a clear line down the middle perhaps (mobile vs web)
- Even, as Valve might have us all believe, what do our teams actually want to work on?
Moving to two teams
So then, really, all you need to do is the following.
- Create the teams.
- Put people in those teams.
- Give those teams clear objectives,
- give them some space to focus,
- and get out of their way.
You’ll find in a very short amount of time, the results you once had when you started out, will flood back in.
