The Russian software development outsourcing industry is known for its ability to deal with complex and unique software development projects. I, for one, like to quote Steven Chase, the President of Intel/Russia:
If you have something tough, give it to the Americans. If you have something difficult, give it to the Indians. If you have something impossible, give it to the Russians.
So it comes as no surprise that we, as a software R&D services provider with development centers in Russia, are regularly contacted by potential clients who say, “Build me an elite team of senior professionals to work on our product.”
And then I have to go and convince them to avoid going down that road and to 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 just 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 key word here is “small.” And the crucial parameter that I haven’t revealed until now is that the potential clients not only ask me to build them an elite team but also expect that team to consist of between 10 and 50 people.
My rule of thumb is if you need a team of more than five to seven engineers, you need a balanced team structure. And it’s probably not a coincidence that many people suggest similar numbers when talking about the maximum size for an agile team. Why is the balanced team better than a team consisting of the same number of elite engineers? The short answer is 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.
What we have seen in our rich corporate history is that if you build a team consisting entirely of senior guys, for the first half-year, everything is great. 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 and that their skills are becoming less and less sharp and 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. But there are no less experienced engineers in the elite team consisting of seniors only. 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. It would be good to let them spend 20% on fun, creative, and challenging side projects. 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 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 that 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 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 on the labor 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 some senior engineers. By doing this, you achieve several advantages compared to the original situation.
First, you can distribute the tasks so that more routine and tedious tasks are assigned to junior team members, 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, again, 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. And all you need to do after that on the labor market is to hire another junior, which is much easier. And isn’t it good to add, “We rely on internal promotion” to the corporate values?
Lastly, with the increased loyalty of the engineers who came to the company as juniors and then grew internally through standard to senior positions comes a lower resulting compensation that you pay to them for doing the same job compared to the 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.
