Trust a New Hire One Decision at a Time

Your new hire is presenting their plan at the quarterly review. Somebody asks how they picked the number on their second slide, and before your hire gets through the first sentence of an answer, you've answered it for them. In the moment it feels like helping. What the room takes away is that the plan is still yours to defend, and the next time that question comes up, people will bring it straight to you.

You answered because you had to decide, on the spot, whether your hire was ready for that question, and you had nothing to decide with. "Is your hire ready?" has no answer as asked. "Is your hire ready to make this decision, and with how much supervision?" does, and medicine has been writing that second answer down since 2005. A head of product making a first hire can borrow it on a single page.

Competence belongs to a problem

Marcus Castenfors, a product coach, defines competence as whether someone can solve the problem you just handed them. That's a test of one person against one problem, and a new hire can pass it on one problem and fail it on the next.

The tools I found for judging product managers measure the person instead. The most-watched video on the subject walks through the technical, business and design skills every product manager needs. A product management firm called the 280 Group sells a 70-question self-assessment. Marty Cagan, whose firm sells coaching and transformation work, publishes a gap analysis: rate how important each skill is for the team from one to ten, rate your product manager against it, and coach the biggest gaps first. Cagan's tool is sound, and it will tell you where to spend your coaching. It won't tell you which of your decisions you can hand your new hire on Monday, or how much of each one.

When nothing on paper says which decisions are handed over, delegation swings between two settings, leaving a decision with them and checking everything they do, and which one you choose depends on your week. When you're busy, they're on their own. In a review, with the room watching, you take the decision back.

Medicine writes the decision down

Medicine had the same problem with new doctors. In 2005 Olle ten Cate, a Dutch medical educator, looked at the competency frameworks spreading through medical schools, which are lists of the qualities a good doctor should have, and warned that unless somebody tied those lists to daily work, a competency would turn out to be nothing but a label. "Every day," he wrote, "supervisors consider whether or not to delegate professional activities to trainees." The information guiding those decisions, he added, is often implicit.

His answer was to grant trust one activity at a time. Some of his examples are procedures, and others are ordinary work, like presenting the overnight patients the next morning or chairing a meeting of several departments. For each activity, a supervisor decides how much supervision the trainee still needs, on a scale with five levels. At the first, the trainee only watches. At the second, they do it with the supervisor right there, and at the third, with the supervisor nearby and ready when called. At the fourth they do it unsupervised, and at the fifth they supervise someone else doing it. In 2014 the Association of American Medical Colleges named 13 such activities that every new resident should be able to do on their first day without direct supervision: the third level.

Supervisors weigh more than skill. A 2017 paper of practical tips for supervisors, led by Carrie Chen, lists what has to sit alongside competence: integrity, reliability and humility. It defines humility as recognizing your own limitations and being willing "to ask for help if needed." A supervising doctor is weighing whether a resident will call for help. A head of product is weighing whether a new hire will report a miss before somebody else finds it, and that question belongs on the page.

One page

The levels come from medicine. Using them on product decisions is my idea, and I haven't found anyone who has tested it on product teams. Here is the page I'd write for a new hire.

One page for a new hire Down the left side: the four decisions every product function makes. Which problems we solve, and for whom. What evidence justifies solving them. What we decline. What outcome we expect, and how we'd know. Beside each one you hand over: what they'd have to show you, written as something you could watch them do and then judge. Where they are today: 1. They watch you do it. 2. They do it with you there. 3. They do it, and you check it before it goes out. 4. They do it alone, and tell you when it misses. 5. They teach it. At the top: your company's strategy, which they read before anything else. At the bottom: a weekly one-on-one, and a date a few months out when the decisions you've handed over should be at level four.

For the evidence decision, what they'd have to show you is two things. Before a customer call, they write down how many customers would need to have the problem before it's worth building. After the call, they can tell you what the customer has done about it, kept apart from the customer's promises.

The strategy goes at the top so your hire knows what the company has already decided, like which customers it focuses on and what it declines. Netflix's 2009 culture deck made the phrase "context, not control" famous, and the same deck lists exceptions to it. One is a person who's still learning their area. At level one that's your new hire, who reads the strategy and still watches you make the decision.

The page has to be written down because of the date at the bottom. Ben Horowitz, who ran product management at Netscape, asks a question about letting someone go: "When you fired the person, how did you know with certainty that the employee both understood the expectations of the job and were missing them?" His answer is that the manager set those expectations while training them. On Andy Grove's advice, Horowitz wrote his own down, in a short training document called Good Product Manager/Bad Product Manager. When the date on your page arrives, the page is how you answer his question.

Coaching changes with the level

The most-watched coaching video I found teaches coaching as asking questions, and its best tip is that "does that make sense?" gets a yes almost every time, so you should ask how they'd apply it instead. Cagan argues against coaching by questions alone: it fails when the person has never done the work, because they can't find an answer they've never seen.

Both are right, at different levels on the page. At levels one and two, while your hire is watching you or doing the work with you there, you show them. At level three, once they've done it on their own, you ask the questions, because now they have an answer to find. At level four the decision is theirs, and your job is to stop answering for them, including when the hard question comes in a review. Thirty years of building and hiring, and my worst calls came from not wanting to let go of work I liked doing. Answering the hard question is work you like doing, and your new hire was hired to do it.

Cagan's written rule for the cadence is a one-on-one of at least 30 minutes every week, never cancelled. For a new product manager who isn't competent yet, he says it may be "2-3 times per week, or even daily." "The primary purpose of the 1:1," he writes, "is to help the product manager develop and improve." The page sets the agenda for that hour. Each time you meet, pick one decision and work on moving it up one level.

When a decision moves up a level, say so to everyone who sends that kind of work. A handed-over decision only becomes your hire's when the rest of the company treats it that way, and the company takes its cue from what you announce, and from what you do the next time somebody tries to go around your hire.

What it looks like at Meridian

Meridian is the fictional composite company I've carried through The Operator's Guide to Product Leadership, the video series this essay accompanies: a 40-person company, run by its founder, that sells shift scheduling software to logistics operators. Every product decision goes through its head of product. She picks the problems Meridian takes on, writes down what it declines, and before anything ships writes a one-page scoreboard with the number that would mean the work did its job. The series calls that number the bar.

Last quarter she reported a miss. She had written down that four of the quarter's six new customers would publish a first schedule within a day without calling support, and three did. The other three got stuck setting up overtime rules, so the next piece of work is a set of templates for the common ones, and with every decision running through her, the templates wait for her calendar. Meridian needs its first product manager, reporting to her: somebody who can write the bar, read the result and report a miss.

She thinks about hiring from outside first. When Meridian hired her, the search took about four months. Then there's the person who runs support, who talks to more Meridian customers in a week than anyone else in the building; all three of last quarter's stuck customers called him. I like that kind of person for a company this size, because somebody who talks to customers all day knows where they get stuck and what they ask for long before a specialist from outside would. But he has never written down, before a customer call, how much evidence would be enough, or written a scoreboard before a build, so promoting him would be hiring on potential, and Cagan's rule allows that only if the person hiring is willing and able to coach him to competence. When a manager has coached sincerely for months and a product manager still can't do the job, Cagan writes, it's usually someone "simply re-assigned from a different role at the company," often because they knew the customers or the product.

The head of product promotes the support lead anyway, knowing the cost is months of her own coaching with no guarantee it works, and she writes him a page. All four decisions are on it, and she hands over two. She keeps which problems Meridian solves and what it declines, and any request from a single customer still goes to her.

The first decision she hands him is the evidence. Before a customer call he writes down what would count as enough, like three of the operators Meridian focuses on who are already working around the problem, and on day one he does it with her there, at level two. The second is the scoreboard for the overtime templates, and for that one he has to show her three things: he writes the bar before the build, reads the result against that bar, and reports a miss himself. On day one he's at level one, watching her write it while she talks him through why last quarter's bar was four and what four was supposed to mean. They meet three times a week at first. Once he has written a scoreboard on his own, she switches to questions: what would make you lower that bar, and what else could explain a miss?

Six weeks in, he writes the templates' scoreboard on his own, and she checks it before the build starts. That decision is at level three now, and she tells the engineers and the founder that the scoreboard is his. His bar is five of the next six new customers publishing a first schedule within a day, without calling support.

At the next product review he puts the scoreboard up, and the founder asks the hard question: last quarter's bar was four and we got three, so why is this one five? The head of product knows the answer, and she lets the new product manager give it. All three customers who called support last quarter got stuck setting up overtime rules, he says, and if the templates fix that step, he expects five; six would mean nothing else gets in a new customer's way, and he doesn't believe that yet. The founder's next question goes to the new product manager as well.

When it doesn't work

Sometimes the date at the bottom of the page arrives and your hire isn't at level four. Then the next step is a different role, and somebody promoted from inside, like Meridian's support lead, has a job to go back to that they were good at.

There's one more time you'll take a decision back: an emergency, like an outage or a big customer about to leave. Netflix's deck lists emergencies as an exception too. When you take one back, say so out loud, and say when it goes back.

I haven't looked into whether medicine's levels make better doctors. What I'm borrowing is the habit of writing the decision down.

At your next review, when a hard question comes up about a decision you've already handed over, let the silence run until your new hire answers it.

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →