software solutions / project leadership / agile coaching and training

Are software teams inherently inefficient?

Posted on July 8, 2013

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.


  1. 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 :)

    Seth Petry-Johnson — July 8, 2013 @ 10:42 am

  2. 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.

    Ray Trask — September 6, 2013 @ 8:48 am

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010