If there is a single thing I can point to as the key to creating a successful engineering organization, it’s the extreme focus on recruiting the best people in the world who share common values, and are passionate about working together to achieve a mission. Attracting the best talent is hard, and it’s always my number one focus and priority.
Hiring for Product Needs
Hiring great engineers is a long game with no short term wins.
It’s common to hire people based on product needs, primarily because it’s easy to reason about it and to explain needs to non-technical people. Need a dynamic website? Hire a Ruby-on-Rails engineer. Develop an iPhone app? You need an iOS engineer. This is an effective, short term approach, that works for those specific purposes. If you think of engineering as your hands and the product people as your brain, this works very well. When thinking this way I suggest you work with an agency, where you pay a premium for getting individuals that are up and running immediately, do what you tell them to do and are able to scale resources up and down depending on how your needs change with time. Furthermore, all hired guns are paid for their technical skills, not to think. They rarely care about your domain and seek interesting technical challenges. This is a good thing, you’re paying them to do more than to think.
Hiring for needs can work for full time roles in a product organization as well. However it creates very high and unnecessary risk for product development. Product needs are very specific, skills are rarely a perfect match, and there are a lot of variables in hiring someone multiplied by the incredible scarcity of software engineers. It takes on average 21 days to get an individual through an interview, references, and offer process, assuming such candidate exists, so it’s not uncommon to see positions unfilled for months. Furthermore there’s a really big risk that the new hire doesn’t work out, jeopardizing your entire new product or feature. That’s the reason why I believe there are no short term wins in hiring great engineers and why I believe so many companies complain that hiring is their biggest limiting factor - they either can’t find that perfect matching candidate or see new hires under-deliver.
Hiring Multipliers
Taking a step back, what do we want a product development organization to actually do?
In order to sustain any reasonable growth we definitely want engineers that think, understand the domain, work effectively with product managers and business stakeholders and ultimately write as little code as possible that can last for a very long time and be iterated upon in order to answer today’s and tomorrow’s business goals. We don’t want hired guns because we want to maximize medium and long term outcomes, we want engineers to have real skin in the game through the lifecycle of every line of code. This takes deliberate investment and conviction that people are paramount. This also ensures great short term outcomes, continuously.
I always try to create teams where individual skills are multiplied, not added. Consider an engineer running into a blocking issue - a colleague helping them move forward can save an unproductive day worth of frustration. I therefore seek individuals that complete each-other or expand the breadth of a team, not ones that are needed by a specific product direction or feature. Furthermore, good engineers learn quickly, and specific and narrow missing skills can always be acquired on the job.
Instead of hiring engineers to satisfy product needs, look for engineers to satisfy team needs. Hire teams, not individuals.
This is somewhat similar to Spotify Squads, although my preference is to staff technology verticals (eg. Web or Mobile) and then redistribute these resources across product teams regularly, something that will likely have to be revisited at different team sizes.
A Roadmap for Hiring Engineering Teams
My hiring roadmap has two types of positions:
- Individuals with skills that don’t exist or lack across a team. This is where more experienced engineers often come in, increasing the team skill multiplying factor.
- Individuals who mirror skills of existing team members. This is where juniors often come in, which helps build capacity and strengthen the base.
I think about how much headcount is needed based on what the existing teams tell me within this framework, aim for a sustainable pace, and am very careful about not adding too many people too quickly. For a team of 20 this means adding 10 engineers over the course of a year.
Finally, you’ll rarely hear me say that we don’t have the resources to build a feature, therefore we need to hire someone. My engineering team will work on everything starting with the highest priority items, and we continue growing capacity under the hood at a steady rate to get more things done faster.