The Hiring Pool

When you first embark on building a hiring journey, at least for those that are trying to build high performing teams, the most common two pieces of feedback you'll probably received are "your standards are too high" and "your process is too long".

Both right and wrong.

You see you can go to a local bustling high street, stop people, ask them if they're a developer, and offer them top paying jobs without any process, and I'm pretty sure you'll fill your quota by the end of the day.

And you won't do that, because that's stupid.

The 3 month interview

Several years ago I did one of those FAANG loops. The process took over 3 months and contained no less than 15 calls. At the end I was "successful" but there was no more budget that year and had to wait until some vaguely defined period before I'd get my offer.

Stuck in limbo, I took a CTO role where the interview consisted of talking to the owner primarily about video games for around 45 minutes. Unsurprisingly, given the hiring rigor was close to the aforementioned high street, the entire thing was a bit of a misadventure.

True to their word big-tech came back to me with an offer. It was a tough decision.

Why Big Tech

• For many having to do entry interviews, a full-loop, and a bunch of auxiliary calls is an egregious experience. For me I was excited at the prospect of working with the caliber of engineer who could pass the loop. Removing the issue of competency means when someone presents an unorthodox opinion, you should probably listen. This is a cultural stake in the ground that defines how you grow. It helps you be the best you can be.
• They pay top of the market. There's no real question about it. With few exceptions, if you work for big tech, you'll be better off financially. It's one of the reason everyone you interview with has been there going on a decade, and it removes a lot of the need to hop roles every couple of years, which is otherwise a borderline hard requirement for career progression.
• Big tech opens doors. At the very least it's an pivot point to other big tech, but their stamp of approval is usually the stamp of competency. And in a world where newer startups may not yet know how to qualify competency, that stamp is extremely valuable.
• The problems are more interesting. There's a large pool of people who can write a CRUD app and get it working. Over time, you add more data, and the design that doesn't consider peaks, hot spots, indexes, and other architectural considerations starts to creak and fail. Wouldn't it be fun to skip to the end and just work on a scaled system without a bunch of average developers sabotaging as you go?

Holding the centre ground

So this post isn't really about me. I mean it is, because I'm awesome, but it isn't really. It's about using your empathy, desires, skills and a little bit of wit to build your own hiring journey.

You're not big tech

You've not got the prestige, the money, nor the competency, so why would anyone undertake a three month process with you? And you won't ask them to, because that's also stupid.

So what do?

Introspect

So in the end, I passed on the big tech role many of us dream of. These were my reasons:

• There was a bait and switch; The role was no longer remote. I was living in Norfolk because a family member had cancer. Moving was a non-option and the prospect of a 3 hour commute, even only a couple of days a week was pretty daunting.
• I was in a role I was enjoying and whilst I wasn't growing from a technical point of view, I was growing in others areas such as leadership, management and an overall business acumen.
• Being a cog in a machine was maybe not that interesting, and whilst the competency arguments hold a lot of sway with me, I've worked with competent people in the past, and I am pretty competent myself, so whilst I'm sure it would have been a learning experience, maybe it's not something I specifically need at this stage of my career.

I declined and the world kept spinning.

Be what you want

So here I am in charge of a budding tech unicorn that's literally on fire and I need to hire competent people. People a bit like me, so I put a stake in the ground.

• We'll hire for competency. We need to figure out how to streamline the process to be as short as possible, but we'll qualify competency and offer our colleagues the same assurances that we were looking for. This was my process.
• We'll hire anywhere we can get them. A hop skip and a jump later, we're using remote.com as our PEO service and I've hired a #2 that had recently left big tech, but had similar location constraints due to his own family problems.
• We'll progress you. I've created structure, progression plans, performance management processes that are designed to progress people and bring them closer to the business. Since we hired for skills, the more senior roles are mentors, and are there to help the team grow.

This was a combination of building a team I'd want to join, but also the team the business needed.

Implementation

So it's usually at this point you get a lot of push back.

Complaints

1. By setting standards you've likely just tanked your recruiters income. And even with all the best intentions, why would good developers join your org when they can join orgs that don't test them?
2. Folks will argue that your test is somehow invalid. You don't need those skills to be a good developer, because they're a good developer and they don't have those skills.
3. We can't just hire from anywhere. People are lazy, and if you don't manage them you don't know what they're doing. You need to walk the floor.

Counters

1. The talent pool is actually larger because you're no longer filtering on trivia or pet technologies. At this point your recruiter probably doesn't know that and they don't know how to sell the engineering culture to candidates. You need to own this part of the process; you need to own the spiel and provide literature. There's an investment, for sure, but one that pays dividends.
2. You'll note that these are low quality arguments as the process has had a fair amount of thought put into it, but the push back is almost immediate. The worry is, of course, their roles and positions are in jeopardy if they themselves don't pass the bar. If you react defensive, the conversation gets away from you. You need to change the narrative from one of fear to one of personal growth, to positive outcomes for those that go on the journey.
3. This, or similar arguments, isn't what they are on the face of it. There is a fear that you won't work on business value, which is all too common with tech driven engineering teams. The secret isn't to bridge the gap between the business and engineering, it's that they're the same thing. The need, rather than micromanagement, is to expose your people to the business, help them understand business decisions, and help them be credible to the business.

Final points

There's a lot to unpack there, but there's some key arguments that I hope we can take away.

• Empathy will take you a long way in leadership. It helps you build structures and teams that are motivated, and it helps you figure out where things are going wrong. This is why, in most circumstances, it's not appropriate to give the technical leadership roles to non-practitioners or those that are not technically credible.
• Challenging for competency is a good thing, but you need to think about how you filter and why. Filtering a strong candidate because you've randomly asked them a trivia in the interview, or because of where they live, despite the fact they're otherwise a strong candidate, is tanking your process without much of an upside. You're looking for reasons to say yes, not reasons to say no.
• Investing in people has positive outcomes. The industry has grown increasingly lazy as it's matured. There's no training, mentorship, no progression without leaving. This is a gap which you can use to your advantage. By pushing competency and progression, you're offering higher levels of discourse that'll help Engineers grow into mature decision makes that consider pros and cons, rather than shilling silver bullets.
• We are the business. If your developers never communicate with customers, or are never exposed to business financials in a meaningful way, can you really expect them to make decisions that benefit the customer and / or the business. This is another gap, because it's yet another set of skills that engineers are not being mentored in, in fact the entire concept has been outsourced to other departments in many orgs. This is both bad for the individual and the business.

This is what strong technical leadership can offer. Casting a wide net looking for competency with a hard sell on personal growth will differentiate you from your competitors. Your teams will build better technology that better meets the need of its users.

By making tech skills table stakes, you'll waste less time having redundant conversations or mentoring people who aren't competent, people can be given more autonomy and their output will have less downsides, required less remediation, and create less debt.

It's at this level where you can essentially cut the bullshit and start to refocus on the business need, because you're no longer trying to build a functioning delivery team, they deliver, because they're competent.