Moneyball teams
If you run a quick search on "We only hire the best" you'll quickly discover that literally everyone only hires the best. How can it be that 100% of businesses hire 5% of the pool? What happens to the other 95% of developers? Well I can tell you. It's nonsense, that's all there is to it. Nobody hires exclusively the best, nor should they! Frankly, we don't even have an obvious industry-wide set of objective metrics to measure developers by.
This post will discuss how to build strong teams focused on total throughput, instead of hiring based on abstract and often disconnected criteria and hoping for the best.
Baseball economics
There's a 2011 film that documents how an Oakland baseball team that was on a losing streak had just lost their superstar player. The team decided to start hiring players based on statistical Return On Investment per hire and the shortcomings of their existing teams. It's more about math and business than sports, and I highly recommend it for some entertainment in your down time if the topic interests you.
Oakland's team budget was $44 million, and won against teams spending over $100 million. That's doing the same work a fraction of the resources.
The goal of hiring
Once upon a time the ambitions of your company were exceeding the throughput capacity of your development teams, and you needed to hire. The ultimate goal of hiring is: to help match the ambitions of your business.
At first glance hiring the best may be the obvious answer. However, careful attention will reveal two hidden traps:
The first trap: If ambition growth is constant, it will surely be out of lock-step with your teams. More work will enter the system without the possibility of it being completed. However, if you match ambitions to throughput you will reduce ambitions, now you're hard-pressed to increase on the product and market innovation side.
The second trap: Throughput fluctuates often. This may be related to any number of factors such as: up-stream product specs being revisited many times, clarity over direction, new technical challenges, technical debt, development process, and even dilution of team focus. Hiring a new smart team member may be able to resolve these problems, however, with a new hire's focus on shipping software it is unlikely these previous challenges will be addressed, which means your new 10x developer could have productivity divided by 10 when placed on your team.
It is very traditional to look at developers as interchangeable units with different capability levels ("Senior" or "Junior"), and yet it is an open-secret that one Senior Developer may be capable of wildly different things than that of another. If you view a team this way, it implies your individual contributors act as teams of one, and are likely to be less productive than a team where all members strive to set each other up for success every day.
How to hire
Business is governed by positive Return on Investment over time. If the goal of hiring is to increase throughput, the correct investment should be addressing the decrease in throughput. By doing this, a business can do more with less.
Presumably you have teams of Web-stack ("Fullstack") developers. Turning high-level business needs into software is traditionally seen as increasing a role specialization in the team mixture. There are however non-discipline-specific skills needed to make a team healthy, and sometimes this comes out in culture interviews, but I think we can do better and have a stronger focus.
When used correctly, one of my favorite tools is a skills matrix. However, if used incorrectly it becomes little more than a status contest to measure trivia about algorithms, data structures, syntax, and things easily read in manuals. A skills matrix on your team should focus on things that need to be done on a regular basis:
- Technical discussions
- Reviewing code
- Architecture
- Scaling
- Testing
- Code Quality
- Mentoring others
- Pragmatism
- Collaboration and motivation
- Etc... (you should pick a set meaningful for your team)
Not all of those are technical skills, and that's a side-effect of real life: Software Development is often about human factors as much as it is the code.
The final touch is to match these against levels of mastery. A lower level of skill may be someone who is largely uninformed of the subject, a middle level may be someone who can constantly use that skill well, and a high level is someone who is a mentor and thought-leader. (By the way, be cautious that your thought leaders are challenged frequently, I've seen thought-leaders who operate in isolation and it can generate a negative impact from unchallenged ideas).
With your new chart you are well prepared to decide where to make an investment. Should you hire for a specific weakness? Which team members get what training? Can we run peer mentorship? Do I have unchallenged experts who have no room to grow? Your answers are straight-forward now.
Lets talk about this concept of skills focused approaches in an analogous situation: Brainstorming. We've all sat through unstructured brainstorms. What a mess! Often someone (the boss) will stand in front of a board with a marker and ask for random ideas that pop into the heads of the team, make an on-the-spot judgement, and often pick something that was obvious and undesirable after an hour or four.
Edward de Bono invented a system to address this exact problem called "Six Thinking Hats". He has made a career out of this system of focusing on balancing out intellectual focus into specific modes, to ensure multiple perspectives are accounted for. Users of the system have discovered they can come up with more innovative solutions, faster, and they know exactly what balance of skills is required for various tasks. By the way, the book has been around forever, so it's quite inexpensive now. They can get great results without having a room full of 150 IQs.
Really what I'm advocating for is that you take some of that focused specialized goodness and put that into how you build your teams.
I hope that if you've read this far you are thinking about other options on how to hack your team performance without hiring more developers. The demand for talent that is marketable as "the top" is highly competitive. It's time to look for lateral solutions.