The software development outsourcing industry is known for its ability to deal with complex and unique software development projects.
So it comes as no surprise that we, as a software R&D services provider with development centers in Eastern Europe, are regularly contacted by potential clients who say, “Build me an elite team of senior professionals to work on our product.” Then, I have to convince them to avoid that path and build a balanced team consisting of comparable numbers of senior, standard, and junior engineers instead.
Please don’t get me wrong. I spent about 10 years working as a software engineer and then about the same amount of time in various management roles in the software industry. I love working in small teams of seasoned, highly qualified professionals, and fortunately, I was lucky to be a part of such teams on multiple occasions. But one of the keywords here is “small.” The crucial parameter that I haven’t revealed until now is that potential clients not only ask me to build an elite team but also expect that team to consist of between 10 and 50 people.
My rule is that if you need a team of more than five to seven engineers, you need a balanced team structure. It’s probably not a coincidence that many people suggest similar numbers when discussing the maximum size for an agile team. Why is a balanced team better than a team consisting of the same number of elite engineers? The short answer is that it is too unstable on several levels. It’s like putting a pyramid upside down on its tip and hoping that it will stay like that for centuries.
In our rich corporate history, we have seen that everything is great if you build a team consisting entirely of senior guys for the first half-year. The problems become obvious after 6–12 months. Merely developing a ground-shaking, record-breaking software product (not to mention maintaining a cash-cow product in its sunset days) involves a lot of routine and often boring tasks. Initially, the newly assembled team is excited with the product; it dives into technology and domain specifics and learns something new in the narrow area. But then the excitement lowers a notch or two, all the new things are learned, and the fact that there are a lot of dull integration and bug-fixing tasks around becomes more obvious.
That’s the point when the senior team members start complaining that they are doing the job that a much less experienced person could do instead of them, that their skills are becoming less and less sharp, and that they see no professional challenges in their work. That’s the point when they start looking elsewhere for a new job.
To deal with that, it would be good to offload those tasks that can be done by less experienced engineers to… yes, less experienced engineers. However, there are no less experienced engineers in the elite team, consisting of only seniors. It would be good to offer some career progression opportunities to at least alleviate the pain of dealing with the less challenging tasks. But in the flat structure, there’s no room for promotion. Letting them spend 20% on fun, creative, and challenging side projects would be good. But not every company is Google (and imagine the additional political difficulties of allowing your engineers to spend paid work time on side projects when they are employees of an offshore outsourcing provider who invoices you monthly for their time).
So the senior engineers start leaving. And here, another problem is discovered. Senior guys tend to develop a natural specialization. They are self-sufficient and can cover important tasks or subsystems of your product without requesting assistance from other team members. So, every engineer who leaves is a serious blow to the collective knowledge of your team and your ability to keep up with the current deadlines. Yes, other senior engineers learn quickly, and in a couple of months, they will relearn what was lost after the previous team members left and recover all the dropped balls. But for that important release planned for the next week, that’s too late.
Besides, looking for a replacement senior engineer in the labour market takes time and is not cheap. The list of skills and experience is long; you need to find the right candidate, and you need to convince your internal team that the new candidate is as good as the existing elite engineers and then convince the candidate to quit his/her current job and come to your company. And don’t forget, while you’re dealing with that replacement, another person quits since nothing has changed in the situation that caused the attrition in the first place.
So, for a long-term mid-to-large-size team, it’s better to build a balanced structure from the very beginning. It is also good to break the team into separate sub-teams led by senior engineers. This approach achieves several advantages compared to the original situation.
First, you can distribute the tasks so that junior team members are assigned more routine and tedious tasks while the senior guys get more complex and interesting tasks.
Second, you build an internal career ladder inside the team.
Third, if a senior guy still leaves the team (some attrition is inevitable and even healthy), it is much easier to pick up the tasks that he or she was dealing with for the upcoming release since the entire sub-team was working on them.
Fourth, if a senior engineer leaves the team, you promote a standard engineer to fill the hole in the structure and then promote a junior to fill the place of the promoted standard. After that, all you need to do on the labor market is hire another junior, which is much easier. And isn’t it good to add, “We rely on internal promotion” to the corporate values?
Lastly, the increased loyalty of the engineers who came to the company as juniors and then grew internally through standard to senior positions results in lower compensation for doing the same job compared to cases when you head-hunt senior guys from the open market. You win on all fronts. There are more financial aspects related to building a balanced team, but I’ll leave that for a separate post.
Hopefully, I’ve convinced you that to achieve long-term success with your engineering team, you need to build a balanced team structure. And note that I’m not saying something revolutionary or contradicting the experts’ opinions here. If we look at the classics, The Mythical Man-Month describes the ideal team as consisting of the “surgeon” (senior engineer) who deals with the most critical issues and leads the rest of the team that deals with other tasks. So let’s listen to the wise and avoid one of the common outsourcing pitfalls—demanding that the provider builds an elite-only team.
