Hire Late

You’ve heard the phrase “hire when it becomes painful”, but did anyone ever tell you what that means in practice? In this article, I’ll break it down as best as I can.

Define the problem

You don’t understand the solution until you can define the problem. And it’s not fully defined until you see how it’s a problem to begin with. Take the following example:

• Problem → “My car isn’t working”
• Why is it a problem? → “I can’t run any errands”
• Solution → “Pay someone to fix the car”

Unless you are capable of fixing your car, this is a good solution, as anything you learn by attempting it yourself only tells you about how cars work, and not much else. Relatedly, in hiring a mechanic you aren’t hiring them to solve all your transportation needs, nor are you hiring them to someday upgrade you to an EV. As complex as cars are, it’s a task. You’re hiring someone to complete a task for you.

Most full-time roles (and with product & engineering, all roles) are not as simple as paying someone to complete tasks for you. The potential risks and opportunities for product/engineering should be measured as multiples when compared to the broken car problem above.

An Example

Let’s take a more real-world example:

• Problem → “Customers are getting invoices late”
• Why is it a problem? → “Late invoices means late payments, hits revenue”
• Solution → “Hire someone in accounting to mail invoices on time”

Maybe there is already someone who can do this for you. Maybe sending invoices isn’t a full-time job, but tracking down lost invoices, while rare, is a whole-day problem. Maybe physical invoices aren’t the future anyway. The point here is, hiring early based just on the above situation means closing yourself off to learning all the facets involved.

Another example

• Problem → “We have too many user-facing requests"
• Why is it a problem? → “Not enough bandwidth & team morale is low”
• Solution → “Hire a senior front end developer to pick up the slack”

What’s the nature of these “too many user-facing” requests? Do they require senior-level talent? Or is it that people feel there’s just so many requests that a “senior” person would finish faster than a junior person?

To the hiring manager who lacks time to understand the problem entirely, but approaches it like a Lego set (ie “this puzzle needs a piece, my job is to find the piece”), they are likely missing higher-order problems: what’s the nature of the work and how repetitive are these requests? Is this a sign the team needs to “re-instrument” such that these requests can be solved another way?

Don’t hire too early

Hire too early, and you miss out on the real problem. And how this role could be made into a strategic advantage for the team (or company).

Hire too early, and you may inadvertently increase the odds you may need to fire this person, or that the person will eventually quit.

Hire too early, and you create inertia for the category of problem that person was meant to solve.

Know thy self

Getting out of this means incurring a bit of pain, which means do the job before you hire the job.

The common theme here is understanding the problem by doing it for a while, which means being ready for some repetitiveness. This can be painful for managers who feel they don’t have time to do this level of discovery or feel they’ve “graduated” from lower-level work. But it shouldn’t be.

When to delegate

If there is someone to delegate this decision, that’s fine. But the right person to delegate is not necessarily the person closest to the problem (and not necessarily the most senior person either!).

If you delegate the hiring decision, it should be someone who understands that the point of this exercise is not to experience the pain of extra work just for the hell of it. Nor is the point to save the company a few bucks.

The point of doing the job before hiring the job is to ensure the role is needed, and to define all the success criteria for the role.

Final note

To paraphrase: (what? how does that work?)

Hiring early creates inertia for categories of problems the person was hired to solve.

Something like Parkinson’s law applies to problems people are hired to solve. Misunderstanding the problem a role is intended to solve can expand that problem in unintended ways.

If you hire a DBA, you’ll get a person who will find ways a database can solve things for the company. That sounds fine, and it’s mostly fine, but if you don’t know the reason why they were hired, you better hope you never run out of problems in which database expertise is the defining factor.

Now apply the above logic to other roles like “Data Analyst”, or “Project Manager”, or “Senior React Developer”. Is the answer as obvious? Will there always be such needs? Is the project manager compensating for lack of communication on a team? Is the data analyst filling a gap that could be filled by light training on marketing? Is the new developer filling a gap no one else was asked to own?