The obvious and completely correct answer is that it depends on what you’re building; who your users are; and a whole host of other factors. The less obvious factor is who cares? If you have the wrong number of testers, what does that cost?
There are certainly costs involved – monetary, costs in the product, and costs in the team. We can have too many testers and we will end up with many bugs logged, including some that aren’t important, and no one to fix them. We can also have too few testers. The consequences are long gaps between when development is finished and when we’re ready to release the software, or we end up releasing software without a good idea of what it will do in the field. The same applies across an engineering team: too many developers and we get overengineered code; too few and we just don’t hit our release dates.
An engineering team typically has several components: developers who work on the front-end; developers who work on the back-end; testers of various types; perhaps a designer or two; maybe a database architect; maybe a systems architect; and sometimes operations people. When these components are in balance – when we have the right number of each type of engineer – then the team is as efficient as possible. When the components are out of balance – too few testers, for example, or too many designers – then we’ve got misappropriated spending. Our costs are higher than they should be for what we’re getting.
Unbalanced Costs
Let’s take a simple example of a team that has two developers, one tester, one designer, and an operations engineer who handles a production environment. This team costs us roughly this:
- Developer 1: $90K / year, or about $45/hour
- Developer 2: $110K / year, or about $55/hour
- Tester: $95K / year, or about $47.50/hour
- Designer: $85K / year, or about $42.50/hour
- Operations Engineer: $90K / year, or about $45/hour
The trouble is our product has a lot of third-party dependencies and runs on many different platforms. It’s driving our tester nuts. He works a lot of nights and weekends, but we still wind up with the development team waiting for bugs to be found before they can fix them and then ship to production. Our designer often helps with testing, too, since we don’t have much of a user interface, and we really only need a new design element once a month or so.
In the end our developers are averaging about 30-35 hour weeks and our designer is really only working about 20 hours per week. Our tester is easily doing 50 hour weeks. There is time spent on self-improvement, refactoring, reviewing requirements and working up stories, going to meetings, attending training, etc., but we’ll assume for purposes of this article that’s all included in working, and that it all counts toward helping the product – even if helping in this case is a bit longer term. In the end, it comes down to one simple conclusion: our team is unbalanced. Some people are more bored than they should be, and others are overworked consistently.
We have some waste. We’re paying our developers for time that they’re not actually helping the product. We’re paying the designer to not help the product. We’re not paying the tester and expecting him to help the product more than normal. It’s not their fault; the developers and designers aren’t slackers. We’ve simply got a team that is unbalanced.
Let’s look at how much we’re wasting:
- Developer 1: 10 hours/week wasted at $45/hour = $450/ week = $22,500/year
- Developer 2: 10 hours/week wasted at $55/hour = $550/ week = $27,500/year
-
Tester: -10 hours/week wasted at $47.50/hour = -$475/ week = (saving)
$23,750/year - Designer: 20 hours/week wasted at $42.50/hour = $850/ week = $42,500/year
- Operations Engineer: 0 hours/ week wasted at $45/hour = $0/week = $0/year
It adds up. Even with the bonus we’re getting from overworking the tester, we’re losing $68,750 a year by not having the right team for the work we need to do. That’s the cost of an unbalanced team, in dollars. We are likely to eventually have to pay that cost; if the tester leaves, a new one will probably want to be paid according to the actual amount of work he’s doing. Similarly, the developers and designer might get bored and leave.
There are other consequences as well. Morale declines as the team notices who works hard and who doesn’t. Resentment between the people working hard and the people who don’t work as much builds up, and the team doesn’t work as well together. The developers can’t get any time from the testers because they’re so busy and the designer is probably taking very long lunches and is getting hard to find. Process fights break out, because there’s plenty of time to overthink how we develop the code we do write. This is a recipe for an unhappy engineering team, which decreases output even more.
Balancing Teams
Once we have identified that we have a team out of balance, we can reduce our waste by bringing the team into balance. This does not always mean firing people; often it means changing some things about how we work, or adding resources to increase overall output while improving team balance.
In our example, we can:
- Hire two testers and one developer. Assuming we want the increased output, that would give us a rough balance of developers, testers, and designers. We might need some help in operations, too, since our output could increase by over one and a half times.
- Give some testing tasks to the developers. Test automation or testing with more of the third-party components before it reaches the tester would both ease the burden on the tester and give the developers something more to do.
- Share the designer’s time with marketing, or shift that to a part-time position.
- Unleash the designer’s nascent testing skills, and get some help for the tester. The designer would probably be both willing and able to do some cross-browser testing, and that could speed up delivery enough to increase our throughput and better use the time of our developers.
As we seek to balance an unbalanced team, there are three factors we can affect: the number of people in each function; the total output; and what each person does. Of course, none of these comes for free. Changing the number of people in each function involves hiring, firing, or both. Changing the total output generally costs more overall; we’re just getting more, so our cost per unit goes down. Changing what each person does runs into problems with skills and willingness. Before you start making changes, decide how you want to achieve balance, and what factors you will attempt to affect. It’s completely reasonable to change more than one factor, and frequently the fastest way to balance is tweaks in several areas rather than massive change.
Conclusion
First and foremost, an unbalanced team is a management problem. It’s a consequence of the engineering team makeup, development methodology, type of software, users’ expectations, and overall culture. An unbalanced team costs the company money, and is usually populated by people who are slowly getting unhappier from either boredom or overwork. Balancing an engineering team saves money, improves morale, and might even give you a better product. Why wait?
About the Author
Catherine Powell I specialize in tactical QA – preventing, finding and fixing software problems no matter what the circumstances. No excuses, no problem.
She (blog.abakas.com) writes about what she knows: teams, testing, and the everyday adventures of shipping software.