Once a well-defined program of work has been established, we assess the internal resources at our disposal and build teams that can execute the program in an efficient and reliable manner.
This is an area most businesses struggle with but not for the reasons one might assume. Rather than lacking developers or analysts, most businesses have teams that are simply too large. Others have too many senior developers or too many developers, period.
The best teams are small and balanced, with the right level of experience to get work done efficiently and cost-effectively.
The Right Size
Smaller teams are almost always better. They’re far more agile with significantly lower overheads. How small is small? We aim for teams with as few as three people.
This is our preference and although there is no definitive right or wrong answer, many researchers have tried to come up with one.
“Weighing the pros and the cons, researchers have conducted numerous studies to determine the approximate team size at which the benefits of putting more heads together are maximized and the costs in terms of coordination and motivation loss are minimized,” writes Jaime Potter, director of executive recruitment at Core Staffing. “Across these studies, the exact answer varies depending on the exact task, but the modal answer is 3-5 people.”
While some projects require large teams, productivity tends to be inversely proportional to team size, says Ryan Trout, cofounder and COO at lean project management system Leantime. That’s why keeping teams as small as possible is usually the best strategy. “When a team becomes too large, fitting in and agreeing become more important to team members than standing out and offering a practical and project-driven assessment of team needs. On a large team, team members may become lost in the system or left out of the conversation, and these factors may lead to a decline in the team’s overall productivity.”
We’ve seen this in the past when we’ve worked with clients that favor large teams. Because of their size, they were almost always inefficient. In fact, we’ve seen teams with almost 20 people doing one-quarter of the work that our smaller teams can accomplish.
The Right Roles at the Right Ratio
Large teams can be a problem. But unbalanced teams are an even bigger one. It’s common practice to have as many as seven or eight developers to one analyst, and this kind of ratio simply doesn’t work.
Our teams can be as small as three people, we strive for a 2:1 ratio of developers to analysts. That may seem unusual, but our analysts cover many different roles (business analysis, technical analysis and quality assurance); we’ve found this ratio leads to timely, well-executed successes.
Conversely, if you have a team of ten but only one of those people is an analyst, that person has to provide all of the requirements for nine developers, manage them and test their work. It creates a substantial bottleneck that slows the rate at which developers can deliver updates. Worse still, the analyst won’t be able to provide the level of detail needed for successful implementation, which means engineers could execute a task in any number of ineffective ways. That leads to more time being wasted rewriting that code.
Our preferred ratio of developers to analysts is even slightly smaller than the typical number found in agile and waterfall development teams. These sit at around 4:1 or 3:1 for agile and 8:1 in waterfall, writes Ajay Badri, a business solutions architect at Seilevel. The problem with these standard ratios, he says, is the strain they place on testing. Badri proposes two solutions: longer sprints and dedicated testing teams.
Another frequent solution is to employ a more junior analyst to handle quality assurance but we don’t think this is a good approach. Junior analysts typically don’t have the business acumen needed to qualify and sign-off work from engineers. It’s not something that can be learned from a standard operating procedure document, either. Senior analysts absorb so much information during conversations with clients that can’t be translated without slowing down projects. If you want to move fast, then the best — and the only —people to test whether development meets business goals are those who spend all of their time working with business executives.
The Right Experience
Effective development teams require the right mix of experience. It’s a Goldilocks scenario where you can’t have too many senior people or too many junior people; you have to get the balance just right.
Rather than stacking a team with highly experienced developers, Cliff White, vice president of engineering at mobile insurance technology company Cover, recommends aiming for a pyramid structure whereby a few senior developers sit at the top, several mid-level developers are underneath them and more junior developers are underneath them. “A pyramidal structure ensures the right proportion between these three layers,” he explains.
It may seem counterintuitive but you can have too many experienced and talented people on a job. When developing software, there are tasks that do require the attention and experience of senior people, but there will also be tasks that even the most junior developer can accomplish. Senior developers drive strategy and provide oversight, while junior devs execute.
Junior and mid-level employees need to work with more senior staff in order to learn and graduate to a senior position in the future. This kind of structure creates “healthy team dynamics,” writes Luca Rossi, head of engineering at Translated. “In the long run it leads to a better outcome than an all-senior team, while also being cheaper.”
Most companies build teams the wrong way. Throwing resources and people at a problem is rarely the best way to solve it. Smaller teams are more effective and balanced, and teams with a range of senior and junior employees are more productive.
Images by: Tim van der Kuip, Christina@wocintechchat.com, Leon