Lean Hiring: time to outgrow the Unicorn Ninja Rockstar

If you’re in any leadership or HR position a startup or scaleup, odds are you’re struggling to get new people in. What if I told you this is not the market’s fault, but rather, mostly because you’re doing it wrong?

In my last 4 jobs, I was involved with technical hiring in different capacities, in startups of different sizes. I learned a lot of dos and don’ts, and while I wouldn’t consider myself an authority, this is what I picked up.

Go anywhere startup jobs are advertised, and you’ll see ambitious postings, often referring to their dream hires by hyperboles like “rockstar”, “ninja”, and worse. They describe in detail all technologies (and sometimes market segment) the company is working with, over all of which the candidate is of course expected to have mastery. There’s no such thing as a “junior” position in such organisations: everyone is an ace. And the salaries are, of course, entry-level at best. After all, it’s a startup. We can’t afford market salaries.

And then when the applications do trickle in, a lot of effort goes into making sure they are, in fact, geniuses fit for your elite, unique team. Most of the time, that leads to weeks of consideration and interviews, and sometimes even internal meetings — after which a good number of the candidates have already moved on to another offer.

When someone is finally hired, almost without fail, they’re either thrown in the sea to sink or swim, or instead micromanaged down to the smallest detail. All promises of ping-pong or kicker tables, endless free coffee, cool-looking offices, and fresh fruit are delivered; as for of a vibrant environment, self-management, creative freedom, and valuing their opinions, those are completely forgotten. Which is kind of ok from the candidate’s point of view, since they never believed any of that anyway.

Technical and market experience

Let’s start from your list of requirements and selection criteria.

Learning to be proficient in a position, be it coding, UI, product management, agile process management, QA, UX, sales, support — is difficult and time-consuming. It typically takes years.

However, I’ll let you in on a secret: a good developer will take two or three days to learn a framework, about two weeks to learn a language to a productive level of proficiency. A medium-good developer might take twice as much, at most. If it takes longer, it’s probably because the company is actually getting in the way of learning, probably by trying to teach them all the wrong things. In fact, if you have a properly designed, reasonably competent onboarding process, it can take even less time!

And I started with developers because that’s the focus of most recruiting talk. But the same is true for all other areas a startup or scaleup will be interested in. PM never worked with JIRA, Pivotal, or whatever you’re using? No sweat! (In fact, I find JIRA experience completely irrelevant, since every setup is completely different.) Never worked with Kanban? They’ll learn. UI designer is a web veteran and never did mobile? That’s great, you’ll have a fresh perspective. Sales candidate never did fintech? Who cares.

On top of that, there’s another reason why it’s counterproductive to select for specific skills or experience. And I’m going to bold it because it’s important: all that may and probably will change. There’s no reason to believe you’ll be using the same frameworks, language, platform, UI design language, process, etc in a year; there’s even no guarantee you’ll be in the same business. Steve Blank famously defined a startup like so:

A startup is a temporary organization formed to search for a repeatable and scalable business model.

That means, if you’re any good at it, you’ll iterate and steer. And if your technical team is any good, they’ll adapt to what’s best to the task at hand, and maybe even keep up with the trends in the field.

What you should be focusing on is finding a candidate that:

• Is a quick study, and ideally loves learning.
• Is a team player. A mediocre team player produces more value in a startup than a genius hermit.
• Takes professional satisfaction in seeing problems solved and/or value added. Beautiful code, difficult technical challenges, aesthetic pleasing UIs, burned story points, etc, are all as desirable as ice cream; but they’re not what will make or fail your startup.
• Readily adapts to change, and ideally, enjoys it.
• Understands that prototypes will be thrown away, and doesn’t see a problem with that.

Your startup is not an unique snowflake

The next point of interest is your ad. I prefer to call it an ad, because the term stresses an important point: you’re trying to “sell” the position. Qualified people, and especially the experienced ones, don’t apply to everything they see; an ad that doesn’t make the sell will be ignored by the people you’re trying to catch.

First lesson: forget the kicker table and other stereotypical startup perks. Ultimately, a good candidate doesn’t care. They are “nice to haves”, but No One Ever™ (probably) applied for a job because the company has a ping-pong table or an unlimited supply of free Club Mate/Mountain Dew/Jolt.

Browse a few job ads and take note of what most of them have in common. “Vibrant environment”, “rockstar team”, and “disruptive product” are common offenders. These statements are, (a) not a differentiator, since everybody else will be claiming the same; and (b), not credible — any candidate who’s not completely new to the startup world knows 9.99 times out of 10 those turn out to be untrue. And by the way — if you’re a founder, it’s very unlikely you’d notice whether or not they’re true.

Strike all of those out of your draft, and replace them with some variation of, “All the usual startup perks, plus:”. And then get real.

Next, find the place in your draft where you wrote “are you passionate about creating (whatever your idea is)?” I know you have it. Save yourself the embarrassment and strike that one out as well. Let me be blunt: pretty much nobody does. If they did, they’d be your competitors. Having this on the ad makes you sound naïve, and invites the candidate to lie in their application or interview. (Exception: you may or may not leave that in when searching for a cofounder.)

In the business you’re trying to build, you’re competing against companies in the same field, or alternative solutions for the problem you’re trying to disrupt/innovate. When you post a job ad, on the other hand, you’re competing against everybody else. And I hope you’re aware that nowadays, if one picks up a rock, there will be three startups there underneath angling for funding and staff.

When someone decides to join a startup, they know there’s a reasonable chance the company will have disappeared and they’ll be unemployed again in a year or two. There are three things that they really care about, and the first doesn’t count:

First, money. A startup that pays well is attractive because, well, people need money, but also because it demonstrates a level of stability. However, most likely that’s not an option for you, so let’s get to the rest of the list.

The most important one is assurance. Demonstrate that you know what you’re doing. That means there’s a much better chance the company will survive and prosper, as well as actually put out a valuable product. Are you already funded? Is your product out? Do you have traction? Revenue? Make that clear. Include a link to your website (which, I hope, already looks professional).

The other one is that you’re looking out for them. A lot of startups treat hires as grain for the grind, and to some extent that’s understandable, since you’re busy trying to build a viable business. But if someone is putting a lot of work into it, usually for lower-than-average pay and with few guarantees, they expect to get something out of it. And that’s not only the stock options that may be worth a lot of money if the company goes big, because that’s basically playing the lottery. Typically, someone joining a startup wants to learn a lot, build up their network, feed their résumés, feel the satisfaction of creating something of real value, or (usually) a combination of those. In order to catch the best, it’s important that you’re aware of this, hint of it in the job ad, and make it more explicit in the interview. Make them feel you’ve got their back, that their personal development matters to you, that you’re aware their growth will contribute to your growth and that, if you’re not able to pay them as much as they could make elsewhere, you’ll make an effort to see them compensated in other ways.

Have a real, explicit recruiting process

Processes are good. They save you a lot of flailing and figuring out what to do each time a task comes up. In the Kanban book, David J. Anderson gives us a very useful definition of process:

It is important to think of a process as a set of policies that govern behavior.

The title of the chapter in question is “Make Process Policies Explicit”. Anderson strongly recommends you write down your policies somewhere everybody who needs to follow them has access to, typically the company’s internal knowledge management repository (that may sound fancy, but even a super-early-stage startup typically has a shared Dropbox or Google Drive folder that serves this purpose).

So, think of all the policies involved in the hiring process. Discuss them with the relevant stakeholders. Write them down. What’s the format of our job ads? Where do we post them? How do we respond to applicants? How do we filter off the obvious no-fits? Then what? Test? Interview? In what order?

And then, don’t let anyone treat them as if they’re set in stone, including yourself. They’re not bureaucracy: they’re guidelines and they should be mostly followed, but as you go, you’ll learn more, and find ways to improve them.

When you do, don’t forget to update the documentation.

Use probation periods

Here in Germany, nobody gets hired without a probation period of 3 to 6 months, for anything. And yet, startups and scaleups waste 90% of their best candidates by being too cautious, often selecting by the wrong criteria, or simply taking so long that the candidate goes elsewhere.

Much of the reason for that is the perceived cost of hiring. Common wisdom is the cost of onboarding will be roughly equivalent to two months of salary, and a new employee will take weeks to become productive.

People, seriously, this is 2015. (As of this writing, at least; when you’re reading, there’s a good chance it’s even later.) I’ve had new hires productive in 3 days, with negligible onboarding cost overhead. Take that effort you were going to put into the first onboarding, “two months worth of salary”, and invest it instead on developing a serious onboarding plan. Keep reasonable process and system documentation, brief, well-organized, and up-to-date. (Those three things go hand in hand, but I’ll revisit the topic in a future article.) Maybe you won’t get it down to 3 days, but you can bring the cost down so much, it stops being a chimera.

And then hire boldly. Don’t hire those clearly unqualified, and neither the ones who don’t fit your company culture; but if you’re not sure, hire them. Make the probation terms very clear. Typically, during probation, the notice time is lower, sometimes only a week. You might even want a “double probation”: in the first two weeks there’s no notice period at all, then for the remainder it’s one or two weeks. Or call it a “test project”.

Then put the tentative hire through their paces. Skip the lengthy training and put them to work from day one, on something that will help pick up the knowledge (often, that means helping someone else, who will then act as a mentor). But make sure they know where the docs are, and who to ask for help; and make sure these people are available.

We all know about “learn by doing”, and yet we rarely put that in practice; spending days reading docs and being explicitly “shown around” is boring, and almost everybody will learn much faster by having an actual project to work on, something that will force them to go through the documentation, ask other people, and figure things out (while at the same time developing a bond with the colleagues). And at the same time, you’re (maybe) getting actual value created!

After a few days, take a good look, see what they produced, talk to the people who worked with them. If they didn’t fit, let them go. If you’re lucky, both your team and the candidate got a fresh perspective and some useful experience.

Be careful how you frame this, though. If people are coming and going all the time, there’s a number of ways that could hurt morale — it could look like your team members can’t expect security, or it could look like you’re unable to find good people, or it could simply tire the team with too many interruptions. Instead, frame it as a policy of temporary contributors that may become employees. And, of course, don’t treat that as a lie ;-) because that’s exactly what this is, and it can be a healthy policy; that’s how most Open Source projects operate, after all.

Some experts even recommend hiring people for pre-determined “tours of duty”. Depending on your business, that might make sense, although for a startup that would typically be less than the 2 to 4 years recommended in the article. A 6-month probation period is, in the end, essentially a 6-month “tour of duty”, after which both parties get together again and decide how to proceed.

And finally: Don’t buy a kicker table

Just don’t.