The most difficult challenge in scaling a tech company is finding the right people. It’s harder than raising capital, finding or winning customers, or finding product-market fit.
I’ve been fortunate to have been hired at Microsoft, eBay and Google, and I’ve interviewed a few thousand people in my jobs at those companies.
One of my roles today is as a venture partner with Rampersand VC and that gives me the opportunity to work with some of Australia’s fastest-growing companies.
If you’re facing the challenges of building out your team, here are a few thoughts that may be worth considering.
One of the many things that Microsoft taught me is to hire for competencies.
Everyone has fundamental characteristics or competencies such as their sense of humour, integrity, smarts, creativity and drive.
These are broader and more fundamental than the skills that they learn along the way such as SQL, public speaking, Python, Excel, blockchain, or project management.
In some cases, such as intellectual horsepower, people either have it or they don’t. It’s arguably impossible to coach or develop intelligence.
In other cases, such as the ability to plan, competence can be developed over time, though it’s unlikely you can create a world-class planner from a disorganised person.
I believe that you should hire for the competencies that you need in a role.
If you hire people who are strong at the fundamentals that you need in a role, your employees will adapt, grow and stretch as your company evolves. It won’t matter whether augmented reality becomes a thing, or whether you pivot your company, or whether you go from mobile- to voice-first.
If you focus only on hiring for the skills you need right now, there’s a higher chance that you will hire a candidate that can’t adapt as their skills become less relevant over time.
I’d never create a job ad for a React developer. I’d hire a front-end software engineer with a demonstrated track record of shipping user-facing software who is smart, passionate, and wants to get things built that users love. If they’ve never used the React framework (or even JavaScript), they’ll figure it out. If you hire right, they’ll learn in parallel as they build their first important milestone.
What are the competencies you should hire for?
The Lominger Competencies is a useful list of 67 business-focused competencies.
My recommendation is you make a shortlist of four to six that are exceptionally important in the role you’re hiring for. Once you have a list, make sure your hiring practices help you evaluate candidates against those competencies; we’ll return to that topic later.
When hiring software engineers or engineering managers, I believe you will generally make great hires if you focus on these four competencies:
Each role likely has a different top four to six competencies. If you’re hiring a user experience designer, perhaps you’d decide to remove problem-solving and add in creativity and customer focus into a top five.
These are the competencies that you want to be exceptionally great.
Of course, you likely also want at least a passing grade in most of the other competencies.
In my experience, good Microsoft, Google, Amazon, and Facebook software engineering interviews are about discovering the level of competency across the four competencies I’ve shared.
When I’m hiring the first few folks in a team, I’m less likely to take risks in the hiring decisions. I’m concerned about how well the few people that I have will work together from day one.
You have to hit the ground running with your first few hires: this probably isn’t the time to take a risk, add a twist, or add an eccentric to the group.
It’s also probably not the time to hire someone who is a longer-term project, and might be ineffective for the first year or so.
When a team has a critical mass — let’s say four or five folks — it’s time to increase the diversity of strength across competencies.
Perhaps you need someone who also has exceptional business acumen or innovation management or planning competency.
Perhaps you might hire for experience in a particular business sector, so your team doesn’t have to learn everything from scratch. There are times when competency should be supplemented with experience.
As you’re doing that, you should also be keeping your eye on diversity areas such as gender, age, ethnicity and disability.
If you focus on building a balanced and broad team as it grows, it will likely outperform a homogeneous one. That’s been my observation across my career.
Figuring this all out requires several interviewers who can evaluate a candidate. A day or so of interviews is called a ‘hiring loop’ or just a ‘loop’.
I’ve been an interview candidate at Facebook, Google and Microsoft. I had at least seven or eight interviews in the loop at Google and Facebook in one day, and about fifteen over two days at Microsoft. That’s fairly typical of US tech companies. I think seven or so interviews in a loop is about right.
There are different philosophies on how to run a loop. Here are a few things to think about.
Here are a few answers to those questions I’ve come to like. You can agree or disagree — the main thing is that you have answers.
I build custom loops for each candidate that begin with less experienced interviewers and work up towards the most experienced folks.
Experienced interviewers are in demand to do more loops, and junior interviewers need the practice.
I build diverse loops, and I always include people from other functions and outside the team this is hiring.
I prefer to cut a loop short if the first three interviewers are confident the candidate is a ‘no hire’ — that is, is not right for the role.
I dislike consensus decisions on hiring candidates. I prefer the most experienced and senior interviewer to make the decision after reading feedback and meeting the interviewers.
Why? It’s hard to believe you can create an interesting and diverse team with a consensus approach. I believe the right question for the senior person who makes the decision is: ‘Is this candidate great for our company?’
If the answer is yes, hire them if you can find a role, even if it’s not the role you’re hiring for.
If the answer is no, don’t hire them.
I believe long-form written interview write-ups are terrific. There’s nothing like writing down what questions you asked, what answers you heard, and how you reason about the competencies.
It’s great for less experienced interviewers to read more experienced interviewers’ write-ups.
I also believe written decisions should be ‘binary’. You should have a conviction to hire or not hire the candidate. I particularly dislike ‘no hire for my team, but might be great for a different role’.
If you’re a small startup, this is where your network is important. You can call in favours from investors, advisors, and folks in other small startups.
You should avoid running a small loop because you only have a couple of people.
I’ve shared thoughts on what to hire for, and how to go about making decisions using a group of interviewers.
There’s more to hiring: writing job ads, screening resumes, working with recruiters, letting candidates know your decision, selling a successful candidate on taking the role, getting the compensation and levelling right, and onboarding a new employee.
If there’s interest, I’ll pick those up in a future post.
Good luck with your hiring. Getting the right folks on your team is the most important and challenging thing you’ll do!
This article was first published on Medium and has been republished with permission.
Hugh is a venture partner at Rampersand, a professor, and a board member at the State Library of Victoria. He is the co-founder and CEO of CS in Schools, and has previously worked at Google, eBay and Microsoft.
