I recently stumbled upon the presentation by Bryan Cantrill on software engineering management, and I must say I completely agree with his thoughts—not with every single detail, probably, but with the overall picture that he has painted.
Of course, I was shocked to learn that I belong to the most dangerous group of managers—“formerly technical” managers. But I hope I dodged the bullet since I continue writing software code in my spare time, and that makes me tolerable, according to what Bryan writes. But more important is his emphasis on attracting primarily (in his version, exclusively) top performers and the reasons why organizations fail to do that.
Now, if you are that single person who reads all my posts in this blog, you’d be utterly surprised by now because earlier this year, I wrote here:
…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.” 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…
But the contradiction here is imaginary. In fact, a big part of the reason why I don’t recommend our clients to use the teams of top performers is exactly what Bryan says in his presentation: They are not ready to deal with an elite team of top performers.
What often happens is, for example, a team of automated testing experts is given a task to perform manual testing of the product “just this last time so that we can make a final push to deployment for this release and then work on creating a long-anticipated automated framework.” Then, a new release comes, and the deadline is tight as always, and there’s no time to be “lost” on improving the development environment, so they have to work on small bits and do manual testing again. And again. After a couple more releases, the elite team starts fleeing the ship because their skills are not utilized, they have no hard problems to tackle, they are not learning anything new, and they justly think that the same task could be done by a group of yesterday’s school graduates under proper supervision.
Consider another example: A group of system-level developers is hired to re-engineer a respected-but-getting-old product that was originally created in the 1990s by three genius engineers who are no longer with the company. A new product version is supposed to become a market leader full of unique features. But first, there is a sales deadline to meet, by which the team needs to make a number of long-requested fixes. Forget about refactoring at the design level and turning spaghetti code into something more attractive; patch it for key clients in their respective branches. Then there’s another marketing deadline and a new key client comes on board, and a new set of spaghetti branches is created because it “takes too long” to refactor first, and we need the new small feature “tomorrow.” So, eventually, all the design decisions are made for that team by product management, and the original idea of a product re-engineering is forgotten, while those top performers are deep in small patching, which they hate because it’s just obviously wrong from their point of view. Guess what happens with that team pretty soon?
I assume it’s just more obvious when there is an explicit client-provider relationship between the engineering team and the business/product management. If you don’t plan to trust your elite team to make the right decisions, or you don’t plan to utilize their top skills, you’d better forget the idea of putting together a team of top performers and creating a balanced team, as I described in my post. The sad reality is that this is true in 80% of the cases (yes, this 80% is one of those 92.63% statistics that are made on the spot, but you get the point; besides, it just sounds right to everybody who spent their better years doing project management and applying a good old Pareto principle).
If you are one of those lucky few who know how and why to use an elite team, just be strong and stay on that course. You’ll be rewarded eventually. And we’ll be happy to help you put together that kind of team if you need it.
