Be the Rabbit

I read a lot of picture books to my kids, and a surprising number of them are parenting books in disguise. One of my favorites is The Rabbit Listened by Cori Doerrfeld, and I’ve come to think it works as a management book too. When someone on your team is frustrated, the reflex is to fix the problem, or hand them advice, or tell them about the time it happened to you. The better first move, most of the time, is to sit down next to them and listen.

Every animal has a fix

The plot fits in a paragraph. A kid named Taylor builds a tower out of blocks, and it gets knocked down. Then the animals start showing up, one at a time, each with a suggestion. One wants to talk it over, another wants Taylor to get angry, and one suggests going and knocking down somebody else’s tower. Taylor doesn’t want any of it.

Then the rabbit arrives and doesn’t suggest anything. It sits close and listens. Taylor works through it, at Taylor’s own pace, and eventually decides to build the tower again.

None of the animals mean any harm. Each one offers a reasonable way to cope. Their problem is timing: they show up with an answer before Taylor is ready for one, and the answer belongs to them.

The rabbit never says “you should rebuild.” That idea comes from Taylor.

Engineers are the animals

Most of us got into this work because we like fixing things. A bug report comes in, we reproduce it, we ship a patch. So when a teammate shows up frustrated, we treat it like a ticket.

You can hear the animals in any engineering org:

• “Have you tried splitting the PR up?”
• “Ugh, the same thing happened to me on my last team.”
• “That reviewer is like that with everyone.”
• “Honestly, the platform team should have caught that.”

Every one of those moves the conversation away from what the person is dealing with and toward what you think about it. The last two are the angry animal and the one who wants to knock down someone else’s tower, wearing a hoodie.

The fix is rarely what they’re missing anyway. An engineer whose design doc got rejected can usually tell you exactly what the reviewers objected to. Someone whose launch slipped already knows which dependency was late. What they want first is a few minutes to be upset about it with someone who isn’t trying to hurry them along.

In 1:1s and mentoring

A 1:1 belongs to the report. When they come in hot about something, ask what happened, then stop talking. Let the silence go on longer than feels comfortable. Most people fill it with the part that actually matters.

If you can’t tell what they want from you, ask: “Do you want help with this, or do you want to vent for a bit?” It sounds awkward the first time you say it. It also saves you from solving a problem they didn’t bring you.

Mentoring is harder, because mentors tend to think advice is the job. A mentee shows up with a design that got shot down, and the mentor starts marking up the doc. Sometimes that’s useful. Often the design isn’t the sore spot. Maybe they spent three weeks on it before anyone mentioned the direction had changed, or the criticism landed in a meeting with their whole team watching. You only find that out if you give them room to get there.

After incidents and in code review

After a bad incident, the engineer who shipped the change usually feels worse than anyone else in the room. The retro wants to jump straight to action items. Before it does, let the people closest to the incident walk through what happened from where they sat, without someone cutting in with “well, the real problem was.” You get a more honest timeline. You also get an engineer who’s still willing to take the pager next week, which is a big part of why blameless postmortems work at all.

Code review conversations go the same way. Someone puts a week into a pull request and gets back thirty comments and a “request changes.” They come find you. The tempting move is to open the PR and start ruling on each comment: this one’s fair, this one’s a nitpick, that reviewer always does this. Hold off. Ask what they think the reviewer was worried about. Once they’ve cooled down, most people can sort the fair comments from the nitpicks on their own, and they’ll go back to the reviewer calmer than if you’d handed them ammunition.

Then help them rebuild

Taylor does rebuild the tower. Listening is the first move, and there’s still work after it.

I’ve written before that a retro where nobody follows up on last time’s action items turns into a recurring venting session, which is why you should start your retro by reviewing the last one. I still believe that. Listening first is how you find out which action items are worth writing down, and the teammate who felt heard is the one most likely to own the follow-up.

Once they’ve had their say, ask what they want to do next, and offer help if they want it. The plan they land on will often look a lot like what you would have suggested twenty minutes earlier. It’s theirs now, though, and people follow through on plans they own.

There are exceptions. In the middle of an outage, nobody needs you to sit quietly. They need you to roll back. Listening is for the hour after.

Next time someone sits down across from you with a knocked-over tower, keep your fix to yourself for a few minutes. Be the rabbit.