We need someone who has done “it” before

We need someone who has done “it” before

My professor says this plugin is very elegant.
Have you (or your company) tried repeatedly to hire for Role X? And failed?

Do you have a revolving door situation at your company?

The SituationDoes this situation sound familiar?

Company leadership looks to hire someone who has “done it”, but they (leadership) don’t really understand “it”. Or they understand it, but can’t explain it.

They eventually hire someone highly qualified with stellar recommendations and a great track record doing “it” (but remember we don’t really understand “it”). One of two things happens. Either the new hire tries to apply a playbook that is not a good fit for the current context. No one really gave them the lay of the land, and they were rushed into executing.

They inevitably fail. 

Or, the new hire identifies the complexity in the situation, maps it to their speciality, but proposes a way forward that doesn’t match expectations. Leader: “Wait, I didn’t know things were that broken” or “this isn’t actually what we hired you to fix!” 

Tension mounts, and that approach inevitably fails as well.

A wicked cycle develops where the ante keeps getting upped for people who have “done it”, yet those people are ultimately not set up for success. As failures mount, skepticism and distrust mount. It gets harder and harder. And you get a revolving door effect with multiple failed hires.

It’s easy to point fingers. But it’s not that simple (is it ever?)

What’s Going OnThere’s a lot going on here, so let’s break it down a bit. 

Who knows what?

New hire knows a lot about their domain, but not a lot about the company. 

Existing leaders know about their company, but not a lot about the new hire’s domain.

Both parties take for granted what they know! In fact, much of it falls under the category of the “unknown knowns”. And both parties have blindspots (things we think we know, but don’t know).

So we’re dealing with implicit knowledge, or lack thereof. 

There’s also fundamental attribution at play. When things work, we tend to talk about how unique we are. It’s us! 

When things don’t work, we tend to talk about:

How someone else screwed up

How similar our problems are to other people’s problems (“that’s just the way it is, it is hard for everyone”)

If we’re being directly blamed, either how it is out of our hands, or how it is an incredibly rare problem that is very difficult to solve!

What a mess! Humans are weird.

When it comes to hiring, company leaders tend to want company opportunities to be unique, but company problems to be common. No one wants to have a “rare problem” (unless they doing #3 above). But everyone wants to have a rare opportunity. So they hope the new hire will be able to use their playbook to fix the common problem (“someone who has done it”). While at the same time hoping the new hire will provide unique value! 

PlaybooksWhich brings us to the core issue. My theory is that the real issue here is making sense of the situation. How do we determine when we—or someone we hire—should:

Use old playbooks (copy and paste)

Combine playbooks (mix and match)

Adapt and customize playbooks (adapt and customize)

Create new playbooks (invent)

Answering this question involves answering “playbooks for what?” And this is the crux.

Say that your company is growing like crazy. You need people who have experience growing a functional team from dozens of people to hundreds of people. I’ll use product for our example.

You can copy and paste AND mix and match playbooks for many of the problems you will encounter. There’s no need to reinvent the wheel for many things. Two examples here might be some basic meeting hygiene (A), and maybe employee onboarding (B).

But say there’s a situation where you need to lightly tweak and combine existing ways.  Or some quirks in the culture that require extra navigation. Example: a company culture that is highly collaborative and collectivist. You might need to modify approaches to goal setting, roadmapping, etc. But not by much. Category C.

Now throw in something very unique and challenging about the domain. Say, for example, there’s a twist with your target customers. Regulation. Something puzzling. A less common sales motion with some extra twists. You will need to invent new approaches. You need to hire people who can invent whole new playbooks. Category D.

This is meta, but not only do you have the individual problems and their playbooks, but you also have the cumulative package. Only doing A, is very different from having to juggle A, A, B, B, C, D, D.

Map It OutWardley Mapping is a great technique for unraveling these types of problems. This post is not about Wardley Mapping (see here for a great intro course), and it is OK if this visualization makes no sense.

Using Wardley Mapping, the above situation might look something like this:

Note how we put Ds over on the left. And As over on the right. Oversimplified, but for our discussion the x-axis describes what type of playbook you might use. Genesis maps to invent. Custom maps to adapt and customize. Product(+rental) maps to mix and match. And commodity maps to copy and paste. A neat thing about Wardley Mapping is that there are a bunch of different X-axis labels you can use.

Also note how problems are related and impact each other. We connect things with lines. Disregard the Y-axis for now. It mostly describes where things sit in the value chain.

What is Wardley Mapping doing for us here? It is letting us explore a more nuanced view of the problem space. Instead of treating things as one problem, we break the problem apart into a bunch of capabilities. When we do this exercise we typically find:

Not everything is an existing playbook. Not everything is a new playbook.

To solve new problems, we need a foundation of stable playbooks. For example, to solve that crazy new problem, the team might need a foundation of trustworthy data.

Yes, you can break things apart to see them better. But you’re also dealing with the whole thing.

So What?Let’s go back to the team trying to hire someone who has “done it”. When we think about “it”, we often think about a list of skills or areas of experience. Which makes sense. That is how job ads look. And that is how resumes look! 

But as we saw in our Wardley Map, it isn’t really a flat list. It is a network of problems/potential playbooks. 

Notice how in most hiring discussions, the conversations goes a bit like:

P1: “So have they done X?”

P2: “Yes”

P1: “Have they done Y?”

P2: “No, but they can figure it out! That’s a nice-to-have.”

But it could go like this:

P1: “It looks like there’s no real playbook for X?”

P2: “I’d agree there. So they are going to need to invent one.”

P1: “Do they have experience adapting Y given this emergent context over here?”

P2: “Hmmm. Not sure. But not many people do.”

P1: “It seems like we’ll need to support them in that effort.”

Now this doesn’t mean you have all the answers. And it doesn’t mean everyone agrees where to put every piece of the puzzle. People can be wrong. But at least it gets the conversation going. 

It also means that you can invite new people into the conversation and develop more shared understanding (vs. swoop in advice).

Back to our hiring dilemma. An interesting job interview activity might be to do a mapping activity with a candidate! How do they see the world? What do they perceive as solved problems? Where would they apply the different types of playbook? How does this all compared to what you see?

What you tend to find is that seemingly “simple” problems are an amalgam of mostly copy and paste, and mix and match. But…when you layer in adapt and customize, and create new playbooks things get much more nuanced.

You have to resist either seeing everything as solved, or everything up in the air. It’s a mix. That’s….”it”.

Read More
Share this on knowasiak.com to discuss with people on this topicSign up on Knowasiak.com now if you’re not registered yet.

Related Articles

Create your crypto business with Stripe

The crypto ecosystem and its regulatory outlook continue to evolve rapidly, and our feature availability varies by region and use case. Please see our crypto supportability page for more details on our current product availability. Fill out the form to tell us more about what you’re building so we can better understand how to support…

Stripe Crypto

The crypto ecosystem and its regulatory outlook continue to evolve rapidly, and our feature availability varies by region and use case. Please see our crypto supportability page for more details on our current product availability. Fill out the form to tell us more about what you’re building so we can better understand how to support…

Disaster Planning for Regular Folks

Written by lcamtuf@coredump.cx, Dec 2015, minor updates Jul 2021. Twitter: @lcamtuf. Buy the book! Practical Doomsday is an in-depth, data-packed guide to rational emergency preparedness. Compared to the original content hosted on this page, the book strikes a far more mature tone, and provides much deeper insights on many key topics. For example, it dedicates…


Your email address will not be published. Required fields are marked *