The Debrief That Changed How I Lead
It was a Thursday afternoon, and we were two weeks out from a major product launch. The room smelled like stale coffee and stress. Six engineers, two designers, our head of marketing, and me—huddled in one of the glass-walled meeting rooms that always felt too cold and too bright.
We were reviewing the latest test results on a new checkout flow. Conversion was up 8.3% in beta, but support tickets had spiked by 22%. The product manager wanted to delay launch. Engineering wanted to push forward. Marketing had already booked a press event.
I looked around the table. “I’m not going to tell you what to do,” I said. “But I will make sure you all have the data, context, and trade-offs laid out so that you can make the right call.”
Silence. Then the lead engineer leaned forward. “So… this isn’t one of those ‘decide and then deflect’ moves? You’re actually not going to give us the answer?”
“No,” I said. “Because if I do, you’ll either ignore it or obey it—but either way, you won’t own it.”
That was the moment I stopped being a decision-maker and started being a clarity architect.
The Myth of the Decisive Leader
We glorify decisiveness in tech. At one of the big tech companies, I once watched a VP stand in front of a packed all-hands and say, “I make 100 decisions a day. That’s why I’m paid what I’m paid.”
I used to believe that. I used to wear decisiveness like a badge. But after leading teams through four acquisitions, three pivots, and one catastrophic outage, I’ve learned something counter-intuitive: the most effective leaders aren’t the ones who decide fastest—they’re the ones who elevate the quality of other people’s decisions.
Here’s a data point: teams where leaders provide full context but avoid prescribing solutions ship 31% fewer post-launch bugs (based on internal engineering surveys across three product orgs, 2021–2023). They also have 40% higher retention among senior ICs.
Why? Because when people understand why a decision matters, they protect it. When they merely execute someone else’s call, they disengage at the first sign of friction.
The Three Layers of Decision-Ready Context
At a hiring committee meeting last year, we were debating a senior product manager candidate. Her resume was stellar: ex-FAANG, led a feature that drove $45M in annual revenue, great references.
But something felt off. The feedback was split—four for, three against. One hiring manager said, “She’s clearly smart, but I don’t know if she can operate without top-down direction.”
That’s when I realized: many high performers are trained to deliver answers, not structure decisions. So I asked the committee a different question: “Did she create conditions for her team to make better decisions—or did she make all the decisions for them?”
The silence told me everything.
Over time, I’ve found that truly decision-ready context has three layers:
1. The “What” – Raw Information, Not Filtered Narratives
We often assume people have the same data we do. They don’t. But worse, we often edit the data—removing ambiguity, smoothing rough edges, presenting a “clean story.”
That’s dangerous.
At a stakeholder meeting for a SaaS pricing overhaul, I once watched a director present a slide titled “Customer Willingness to Pay.” It showed a clean 37% increase in NPS after a price hike.
But when I asked to see the raw survey responses, 62% of enterprise customers said they’d consider switching providers. The NPS bump came entirely from small businesses who barely used the product.
I stopped the room. “This isn’t willingness to pay. This is willingness to tolerate—and only from the least engaged users.”
We delayed the rollout by six weeks. Revenue impact: $2.8M lost in Q3. But churn dropped 19% in the next quarter.
The lesson: don’t curate reality. Serve it raw. Let people wrestle with contradictions. That’s where insight lives.
2. The “Why” – Strategic Trade-Offs, Not Just Goals
Every product decision is a trade-off. But we rarely articulate them clearly.
I once inherited a team building an AI-powered recommendations engine. The KPI was clear: increase click-through rate by 15% in six months.
But no one had asked: At what cost?
Two months in, CTR was up 22%. But support tickets for “weird recommendations” had tripled. One user complained their feed kept showing industrial drill bits—because they’d once searched for “drill” in a metaphor.
I called a team sync. Instead of asking “How do we fix suggestions?” I framed it differently: “What trade-off are we making between novelty and relevance? Are we optimizing for engagement or trust?”
That shift changed everything.
We redesigned the feedback loop to surface user-reported irrelevance in real time. CTR dipped to 12%—still above target—but user satisfaction scores rose 34 points. More importantly, long-term retention improved by 11% over the next quarter.
The insight: goals without trade-offs lead to myopic optimization. When you name the trade-off, people stop gaming metrics and start solving real problems.
3. The “How” – Psychological Safety, Not Just Access
You can dump terabytes of data into a Slack channel and still have a team that can’t decide.
Because information access isn’t the same as decision-making capability.
At a planning offsite, I asked a director: “What’s blocking your team from shipping faster?”
“We don’t have the latest analytics dashboard,” she said.
I got it built in a week. Two months later, velocity hadn’t improved.
So I sat in on their triage meetings. What I saw wasn’t a data gap—it was a fear gap. Engineers were deferring to the PM on prioritization. The PM was waiting for “approval” from me.
No one felt safe to act.
So I changed the meeting format. We started every session with: “What’s one decision you made this week without asking permission?”
First few weeks, crickets. Then a junior engineer said, “I merged a config change that reduced cold start time by 40%. Didn’t ask because I knew the data.”
Applause. Then another. Then a designer shipped a microcopy update that cut form abandonment by 9%—no review.
We didn’t need better data. We needed proof that autonomy wouldn’t get you fired.
Six months later, that team had the highest feature throughput in the org—without a single new tool.
The Hiring Filter: Do You Elevate Decision Quality?
Back in that hiring committee, we rejected the candidate.
Not because she wasn’t capable. But because her pattern was to be the decider—not to enable them.
Since then, I’ve added three questions to our interview rubric:
- “Tell me about a time you handed off a decision to someone else. What context did you provide? What was the outcome?”
- “Describe a situation where your team made a different call than you would have. How did you respond?”
- “What’s one piece of data or framework you routinely share to help your team make better calls?”
The answers are telling.
One candidate described rolling out a “decision memo template” used across her org—complete with sections for “what we know,” “what we’re assuming,” “what we’re betting on,” and “how we’ll know we’re wrong.”
She got hired.
Another told us, “I make sure everyone reads the customer support logs. Not summaries—raw tickets. If you’ve read 20 angry emails about the same bug, you don’t need me to tell you it’s a priority.”
She got an offer.
The third said, “I usually just tell them what to do. Saves time.”
We passed.
We’re not hiring executors. We’re hiring force multipliers.
The Stakeholder Meeting That Shouldn’t Have Worked
Last quarter, we had to kill a product line. It had 47,000 active users, $1.2M ARR, and a passionate community.
But it was a distraction. It consumed 30% of our platform team’s bandwidth while contributing less than 4% of total revenue.
I knew announcing it would be ugly.
So I didn’t announce it. I prepared a 22-slide deck titled: “The Cost of Keeping [Product Name] Alive.”
It included:
- Engineering hours by quarter (up 40% YoY)
- Opportunity cost: 3 features delayed, 2 missed market windows
- NPS trends: flat at 32, well below company average
- Support cost per user: 3.2x higher than core products
- Strategic misalignment: “Does not advance any of our 2024 pillars”
I sent it to the leadership team 72 hours in advance. No cover note. No narrative.
Then I scheduled a 90-minute meeting. Agenda: “Discuss the data. Decide the path forward.”
No “I recommend.” No “We should.”
One exec pushed back. “47K users is not nothing.”
Another said, “You’re showing costs, but not the brand value. These users are evangelists.”
I replied: “I agree. That’s why I didn’t make the call. I laid out the numbers. You tell me—how do we weigh brand loyalty against engineering capacity? Is 30% of our team worth 4% of revenue? That’s not my judgment to make alone.”
The room debated for 60 minutes.
Then the CTO said, “We kill it. But we owe the community a real transition plan. And we fund a $250K project to port key features into the core product.”
Consensus. No drama. No blame.
Because the decision wasn’t mine to give or take. It belonged to the group—armed with context.
FAQ
Q: Doesn’t this slow things down? What about “speed matters” in startups?
Speed matters—but not at the cost of alignment. I’ve seen teams “move fast” only to unravel six months later because key stakeholders weren’t on the same page. Providing context upfront accelerates execution later. Our average time from decision to rollout dropped by 38% after we adopted this model—because there were no reopens, no “I didn’t know” moments.
Q: What if people make bad decisions, even with good context?
They will. And that’s okay. Mistakes with context are learning events. Mistakes without context are cultural poison. When a PM on my team once launched a feature that confused 70% of new users (based on session replays), we didn’t blame her. We asked: “What data were you missing? What assumption turned out to be wrong?” That post-mortem led to a new onboarding validation checklist—now used org-wide.
Q: How do you handle urgent, high-pressure decisions?
In crises, I shift from “provider of context” to “facilitator of clarity.” I’ll still avoid giving answers, but I’ll structure the input: “Here are the three options. Here’s the time box. Here are the constraints. Go.” In a recent outage, instead of declaring a rollback, I asked the incident lead: “What would need to be true for us to keep the new version live?” That question surfaced a config fix we hadn’t considered—saved 45 minutes of downtime.
Q: How do you measure success in this model?
Three metrics:
- Decision latency: Time from problem identification to resolution. We’ve cut ours from 11 days to 4.
- Reopen rate: How often decisions get reversed. Down from 28% to 6%.
- Autonomy score: % of team members who agree with “I can make important decisions without approval.” Up from 41% to 83%.
Q: What if your boss expects you to have all the answers?
Flip the script. “I have a few options—let me walk you through the trade-offs.” Then present 2–3 paths with pros, cons, and unknowns. Most executives don’t want answers—they want rigor. One VP told me, “I don’t care which path you take. I care that you’ve stress-tested it.”
Final Thought: Leadership Is a Context Engine
I used to think my job was to be the smartest person in the room.
Now I know it’s to make sure the room is smarter than any one person in it.
You don’t create high-performing teams by giving better answers. You create them by raising the quality of the questions—and ensuring everyone has what they need to answer them.
So I won’t tell you what to do.
But I will make sure you’re never deciding in the dark.