Rockstar Engineers Aren’t a Long Term Strategy for Success
I’ve been fortunate to travel and speak a lot about my experience leading teams that successfully adopted XP. In my talks I share my approach for hiring and retaining great talent. The approach I follow now is the exact opposite of the approach I had 15 years ago.
I used to believe that I needed engineers fueled by caffeine, the ones that worked through the night and committed large amounts of code. The true rockstars. We all know those people, zero empathy. If you stopped them in the hallway to ask what they were working on they’d tell you you’re not smart enough to comprehend what they’re doing. This is exactly the kind of person I go out of my way NOT to hire now.
Why Not Hire Rockstars?
I’ve said this at least a million times but I’ll say it again,
The best outcomes are the confluence of everyone’s opinion
Following that statement to logical conclusion, if I had two choices to get work done:
1.Complete a story in 30 minutes with a rock star working alone OR
2. Pair 2 developers together take 3 hours and up-level the knowledge of the team
I’d choose option #2 every time.
Together we are Strong, Together we will Go Far
Two heads are better than one. I’ve seen it time and again, two developers working to solve a problem will ultimately lead to a better outcome. The confluence of their experience and effort …
There are other benefits though. Pairing is context sharing. When we work together to solve a problem we don’t ‘feel’ included we are ‘included’. We’re part of the solution. Perhaps more important when there’s a problem we feel a sense of shared ownership to fix it. The code becomes everyone’s problem and not just one person’s. That sense of ownership may seem odd especially to leaders who look for ‘one neck to choke’ when there’s a problem. The syndrome, “if it’s everyone’s problem, then it’s no one’s problem” is true for leadership. But that’s a whole other blog post.
Through pairing we boost efficiency through collaboration. Programming really can be a collaborative endeavor. When we pair we knowledge share and skill transfer. We prevent
little silos of knowledge from forming. Everyone knows the code base and we’re all familiar with each other.
Conclusion
At Cognizant Labs we’re fueling our innovation with teams that lift each other up. We employ XP, retros, standups and other agile methods at all levels. Yes even my leadership team attends a standup, a retro and we have a backlog of work we call action items instead of stories. But we write our action items like stories. They have a consumer, goals … definition of success. Why? So anyone can pick that action item from the backlog when they’re free and resolve it.
Influencing change throughout an organization isn’t just about asking developers to change, it’s about change at all levels. The most successful teams are the ones that realize the enemy/competition isn’t inside our walls but outside. We need to work together, lift each other up and remove roadblocks to achieve greatness.