Are software teams inherently inefficient?
I recently went through a big change in my role at work. I went from being a tech lead on a team of 15 people to working on a project all by myself.
Anytime you go from one extreme to the other, you see some stark differences between the two environments, and in my case, it caused me to think about the way we do things in teams.
The most obvious change was a huge decrease in meetings. I went from an average of 4-5 meetings a day (not counting standups) to an average of 1 meeting a day. When you’re a team lead of a large team, I suppose that comes with the territory. But when you have close to 7 hours a day of time to work with minimal interruptions, you get a LOT of work done.
Meetings are a common complaint from people who work in a team environment. And even though you can read hundreds of articles about how meetings are pointless and you should skip them, the fact is that most meetings exist for a good reason, and while skipping all your meetings may seem like a good short term decision, you can’t realistically do that all the time.
I think that the problem isn’t necessarily the meetings, it’s the fact that the meetings are needed in the first place. Every time you add a person to a team, you’re introducing more inefficiency to the team because now there is one more person that you need to communicate with, that you have to share information with, that you have to invite to a meeting.
Now, even though this inefficiency exists, typically you are adding someone to the team because the benefits of having them there outweigh the negatives. But to what extent? Is there a point where you get diminishing returns from adding new people?
Managers exist for a good reason – to coordinate team activities, make sure everyone is on the same page, communicate with other teams, and go to lots of meetings so that the rest of the team doesn’t have to. When your team gets really large, you start needing more management. Then what happens is one of two things – the manager becomes overworked and can’t keep up with everything, or you end up having your tech leads go to more meetings and become more like managers. The problem there is that tech leads are tech leads because they’re good at tech, not necessarily because they’re good at management, and now you’ve essentially taken your best technical person and removed them from the role where they can provide the most value. Then your tech leads get frustrated because they feel that they don’t get anything done because they spend all of their time on meetings.
If you’re hiring a bunch if people and creating a big team, it’s probably because you have a lot of important work that needs to be done, so I’m not saying to not hire those people. But I would encourage you to find a way to split them up into smaller teams. You may have multiple teams working on the same project or even in the same codebase, and that’s fine, we just want to decrease the amount of communication that is needed in order to get things done.
Our IT department has done a lot of this lately, trying to take large teams and divide them up into smaller sub-teams of around 4-5 people. Now those communication inefficiencies are diminished because you only have to communicate with a few people (who ideally sit in the same area as you). Not only that, planning is so much easier. It’s much easier to accurately predict what you can do with 4 people than it is with 15 people, not to mention that if things go off the rails for an iteration, it’s a lot less expensive.
I think the ideal team size would be 3-5 people, where you don’t have more than 2 people in each discipline (BA, QA, dev). It would be even better if those people were somewhat cross-functional so that they can help each other out when someone gets behind.
While splitting into smaller teams may make those teams more efficient, you still will need coordination across teams and more meetings and management. But I think having smaller teams helps you to see the need for management and enables you to put the right people in those roles instead of just pulling your tech leads in to fill those roles.
There are no hard and fast rules for this sort of thing, and the results may be different for you than it was for me. The important things is that we constantly evaluate how we are doing things and find ways that we can increase our efficiency and reliability of our software teams.
My current team is pretty close to your ideal: we have two senior dev/architect types, two QA people [one lead, one junior], and a BA that fills a PM role too. It feels really productive, though I think one more dev would be ideal.
I find that doing the occasional short-term solo project makes me very aware of inefficiencies on larger teams, which is both a blessing and a curse. It’s a blessing because it keeps me focused on being “lean and mean”, but a curse because after getting used to coding for 7.5 hours of an 8 hour day, it can be hard to sit through -ANY- meeting, no matter how necessary or important to the big picture :)
Reminds me when I was asked to become the tech lead for a troubled project. It had 15 people on it. First thing I did, was break it up into three teams of five with the most senior person providing direction on each team. What a difference that made.
Some interesting side points on team size:
By the way as study was done over 30 years ago (by I think GE). The ideal number of people to directly manage was 7. Another manager told me he calculated it takes him one hour per day per person he manages.