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 team throughput, instead of hiring based on abstract and often wishy-washy criteria, where you can only hope for the best.
“Moneyball” economics?
A pathological losing Baseball team in California was dealt a death-blow: the loss of their star player. A 2011 film called “Moneyball” documents the revenue-poor team entirely change their hiring strategy and started winning games again, so much so they’ve permanently changed how all team managers think about hiring strategies.
Oakland's team budget was $44 million, and regularly against teams spending over $100 million. That's getting the same job done with only a fraction of the resources. The secret-sauce? They applied some incredibly basic math skills and started winning.
The movie is more about math and business management, and not really about sports, and I highly recommend it for some entertainment in your down time if the topic interests you.
The goal of hiring
Once upon a time the ambitions of your company were beyond what your development teams could do, and you were forced to hire. The ultimate goal of hiring is: to help your team match the ambitions of your business.
At first glance hiring the best may sound like 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 sync with your teams’ capabilities. More work will enter the system without the possibility of it being completed (input is faster than output). However, if you reduce business ambitions to match team throughput you're less likely to grow the product in your market, and less likely to innovate if you’re only playing catch-up.
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” (a outdated concept) 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"), despite the “open-secret” (common knowledge selectively ignored) 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 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 not simply increment throughput, but maximise the total business throughput. The goal is not simply increasing “lines of code per day”, tickets completed per week, or some sub-task inside the business. The goal is so big that business processes themselves must be able to change to fit the goal.
Presumably you have teams of Frontend/Backend ("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 with 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 or picked up within a week of training. 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
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. You should pick a set meaningful to your organization.
The final touch is to match these against levels of mastery. A lower skill level could be due to a person being simply uninformed of the subject, a middle level may be someone who can constantly use that skill well, and a high level could be someone who is a mentor and thought-leader.
With your new chart you are well prepared to decide where to make an investment. Should your next hire help cover a specific team weakness? Which team members get what training? Can we run focused peer mentorship programs? Do I have unchallenged experts who have no room to grow? Your next tasks for team growth become clearer as you explore the details.
It's about focus
Think about a typical brainstorming session. We've all sat through unstructured brainstorms before. What a mess! Often someone (usually 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 in the first four hours the consensus often tends to be limited to the obvious or undesirable options (and many brainstorms stop here).
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 intellectual focus into specific modes which 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, his book is available for cheap). When applying the hats, a team full of average people can quickly get amazing 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.
If you've read this far you should also think about other options to improve your team performance without hiring more developers. The demand for talent that is marketed as "the top x%" is highly competitive (and therefore: time consuming, and expensive).
It's time to look for lateral solutions — it’s time to scale horizontally, not vertically.