Whether you're outsourcing software development or building it in-house, you're going to need the right team. That includes:
- The right configuration of expertise
- The right size team
- The right metrics to measure their success
Building an engineering team, like many challenges in software development, is a numbers game. Expertise and experience come at a high cost. The more people you hire, the more overhead you carry – which means you expect more return on your investment. And when it comes to ensuring you’re getting what you pay for, it’s about time the industry took a fresh perspective on showcasing development efficiency.
How do you avoid paying too much, hiring the wrong people, and stalling a project? It’s about right-sizing and focus. Here’s how to build a development team that’s set up for success.
The best engineering teams have a project manager (PM), at least one developer, and at least one quality assurance (QA) tester.
It’s tempting to consider just hiring a dev, who theoretically has all the knowledge needed to build your project and costs less than a whole team. But that’s a bad idea for a few reasons:
1. Technical resources need a technical leader—a PM who can not only keep the team on budget and on schedule, but also act as an advisor for developers and even work as an additional resource if required. Even if you have an engineering background, you’ve got your own job to do; leave the project management to someone else. You’ll be glad you did.
2. Software development is a team sport. It requires creativity, critical thinking, and compliance with strict criteria in an industry that is constantly changing. One person can’t possibly have the full breadth of knowledge needed to make your project output the best it can be.
3. No one catches all their own mistakes. That’s why authors go through editors before their work reaches the public. No matter how good your dev is, and while they should certainly self-test their code, they’ll inevitably miss a few bugs that another pair of eyes would catch.
When you build a software development team, you solve each of those problems. Now it’s a matter of right-sizing that team.
Over years and years of working on software development projects, we’ve found that the best sizes for software development teams comprise 3, 5, or 8 people.
Have you ever driven by a construction site and seen one person digging a hole while 10 other people stand around and watch? Yikes. But software projects run the same risk of stalling if your team has too many people—and engineers are too expensive to allow that to happen.
On a software development project, there’s a bell curve of number of people vs. return on investment, and research shows that high performance teams are smaller than you might expect. At first, each person you add is vital. PM, dev, QA—each plays a large and necessary role, and that’s why 3 people is our minimum suggested pod size.
Often, though, you want to move at a faster pace than three people can provide. Adding another dev, QA, or even another two devs to your software development team can result in amazing economy of scale. A team of 5-6 people is versatile while staying hyperfocused and agile. Psychologist and World War II veteran Ivan Dale Steiner, who literally wrote the book on Group Process and Productivity, came to the same conclusion.
In our experience, 8 people is the maximum number you can have on an engineering team while still yielding high performance. Remember Jeff Bezos’s “two pizza rule,” which states that no meeting should include more people than two pizzas can feed? After that point, the team is too big to maintain the kind of focus required for efficiency and efficacy. Productivity diminishes, people feel siloed, and leadership has a harder time staying up to date on each contributor’s work.
Plus, when it comes to software development, at some point there are simply too many irons in the same fire. That’s when you start getting into budget-wasting, mismanaged-construction-site territory.
You might wonder what happens if you have a large project that requires more than eight people to build it. The solution: bring on multiple teams and split your backlog across them. Especially at that kind of scale, you’ll need the tight structure and focus that only comes with these smaller teams.
This is where the metrics come in. A high performance team should be measured not on story points or number of bugs, but on stats that enforce both tempo + quality:
- Deployment frequency
- Lead time
- Change fail rate
- Mean time to restore
The keywords for a successful high performance software development team: continuous delivery + continuous improvement. If deployment frequency is low and lead time is high, you probably need more people on your engineering team. If change fail rate is high and time to restore is also high, you aren’t getting your developers’ and QAs’ best work. The good news is, these metrics allow you to identify needs and gaps much faster than by conventional metrics, so you can adjust your team as necessary and yield return on your investment sooner.
Like we said, it’s a numbers game. Knowing how to staff a software development team that yields high performance and amazing results is as much about number of people and how you measure success as it is about cost. Use this guide to help you build the right team—so they can build your next great thing.