What changes when the person approving your work wasn’t there when it started, and 5 moves for bringing a new decision-maker along without stopping the work.
New leaders inherit decisions they never watched get made. That’s obvious when you say it, and it’s easy to forget when you’re the one presenting, because from your seat the problem was settled months ago. You did the discovery, you walked through the data, you got the sign-off, and now you’re showing the plan. The person across the table is seeing the plan with none of that behind it.
I watched this happen across a week of planning reviews, where teams walked a leader who is newer to their areas through next year’s work. Some sessions went well and some ran out of time on background questions. Afterward, someone on my team asked me if we need to improve our skills on making business cases clearer. It was a spicy question, and my answer was no. The cases were made, and they landed with the audience they were made for. Then the audience changed, and that’s a change management problem that falls on me, more than a skills problem.
I also think the scrutiny is fair. Anyone asked to run something deserves a deeper understanding of it, and I’d probably ask the same questions in their shoes. So the work falls to us, and here’s what I saw work this week.
Re-sell the problem. One of our senior designers said it best in our 1:1. His team had skipped the problem statement because it was already signed off, and with a new decision-maker, “we have to reintroduce the problem, re-sell it.” It feels like going backwards, and it takes 5 minutes.
Carry the context before the room. The teams that did well had sent a pre-read or grabbed 30 minutes ahead of time. I’ve started sending presenters a short cheat sheet of what came up in the other reviews, and I plan to keep doing it. If the first time a leader hears the background is in the meeting where you need a decision, you’ve spent your decision time on the background.
If the first time a leader hears the background is in the meeting where you need a decision, you’ve spent your decision time on the background.
Park the tangent, kindly. Two of my partners did this well. When a question pulled toward history, they said, in effect, “That’s a great question. We have that context and can walk you through it, and let’s get through the plan first.” Then they booked the time. Nodding along and staying silent isn’t the smart move here. The goal is for the leader to feel they’re getting educated, on a schedule that still lets you finish.
Say what your anchor was. A designer offered a framing I loved: “I don’t know if this anchor is still true, but here’s what we were basing it on.” It lets a new leader see the reasoning without anyone having to defend it as permanent.
Frame iteration as learning. “We’ll iterate” can sound like “we’re not sure.” What landed better was describing the same plan as learning in the product, from people using it, with a decision at the end that the data supports.
I’m not exempt from any of this. A designer told me this week that a demo I’d asked him for felt rushed, because nobody knew where the ask came from. It was on me. I’d been in a thread where an exec asked what the full workflow looked like, I didn’t have an answer, and I went to him with “can you stitch this together?” and none of the context. I was the person the context was supposed to travel through, and I dropped it. I’m sharing screenshots and the “why” from those threads now, every time.
To be fair, there’s a cost to all this. One of our lead designers pointed out that a business case for everything slows down the small, low-risk things we could just start and learn from. She’s right, and I don’t have a tidy answer yet. My hope is that a leader with the context will be faster to say “just try it,” and getting them the context is the part we control.