When every decision still needs you

For too long I was the single interface between my team and the executives. It was efficient in the moment, and it was gratifying: every important conversation ran through me. It also kept the context in my head, held the team back, and meant their work reached the room secondhand. I wrote that up as a mistake in Data in the boardroom, and it is the one I would warn a new data manager about first.

So if every recommendation on your team still needs your approval, ask a less comfortable question than whether the team lacks judgment. Ask whether you have kept the information and the authority they would need to exercise it.

I have managed and mentored people across data engineering and analytics. Part of that work was making technical judgment something to teach and review, through code review, deployment standards and data quality practices that outlasted any one project, rather than something only the lead could supply. What follows is how I would hand over the harder kind: judgment about decisions.

Diagnose the dependency before delegating

A capable analyst may keep asking you for decisions because the stakeholder’s actual priority was discussed in a meeting they did not attend. Another may understand the context and need help weighing alternatives. A third may have the judgment but no clear permission to act. Those situations need different support.

What is missing?	What the leader needs to provide
Context	Access to the stakeholder, the decision, and the constraints
Skill	A worked example, practice, and feedback on the reasoning
Authority	Explicit boundaries on what the person can decide
Capacity	Time, and a reduction in competing work
Confidence	A bounded opportunity to act, with a reliable route to help

Calling all five a confidence problem is the easy mistake. It offers encouragement where the person needs a structural change. The last of the six questions in What would this work change? asks which of the first four is missing for one decision, and its review keeps the fixes apart.

Hand over a decision with a boundary

Start with something consequential enough to teach judgment and contained enough that a mistake is recoverable. Agree on the decision, who it affects, the deadline, and when to escalate. Say which constraints are fixed and which are open to challenge.

Say the decision is whether to reduce a dashboard’s refresh frequency. The analyst needs to understand its consumers, the freshness each of their decisions requires, and the operating cost. The learning comes from defending the tradeoff, not from guessing which schedule the manager prefers.

The first analyst I brought into the rooms where decisions got made was a product analyst. The product managers made most of their calls from experience and instinct, with some data alongside. Putting the analyst in the room helped both sides. The analyst learned how product decisions actually get made, and the product managers learned to use data to back a call and to read their experiments with more statistical care. If I were starting over, that is where I would begin again: one bounded decision, prepared together, with a part of the meeting the analyst owns. Attending a meeting is exposure. Owning part of the decision is development.

For higher-consequence work, keep the approval where it belongs. Developing someone does not mean making them carry a risk they cannot control.

Review the reasoning before supplying your answer

Ask for a recommendation, an alternative, and the evidence that would change their view. Listen for the missing context before correcting the conclusion. The questions I use:

• Which decision are you helping someone make?
• What have you assumed about what matters to them?
• Which alternative did you reject, and what did it offer?
• What would make your recommendation unsafe or no longer useful?
• What do you need from me to proceed?

Sometimes direct instruction is the right response. If the person has never handled a particular failure, share what you have seen. Just be clear whether you are teaching a technique, offering an opinion, or making the decision yourself. Leave that implicit and a suggestion becomes an instruction the person feels unable to question.

Stay present without taking the work back

Agree who leads the stakeholder discussion before the meeting. If you need to step in, explain why afterward. Otherwise the analyst learns that ownership lasts only until the conversation gets difficult.

The time I stepped in too early was a change the product analyst and the product managers had agreed to make with some unknowns still open, instead of testing it first. I asked for more data, to get a clearer picture. In hindsight, I should have let them make the call. Some changes can rest on experience and judgment and do not need rigorous data collection first. Matching the design palette to the company’s logo and colors is the kind of change I mean. A brand rule already settles it, to keep the brand consistent and recognizable, so there is nothing for an experiment to decide. What it still needs is cheaper than an experiment: a check that the new colors meet the contrast minimums in the Web Content Accessibility Guidelines, and an eye on the key flows after release, since a color change can still move clicks. Asking for more data can feel like rigor and still take the work back, because it tells people the call is still yours.

Debrief while both of you still remember the exchange: what the audience understood, which question changed the recommendation, and where you stepped in too soon. Include your own behavior in that review. Did you answer too quickly, move the boundary, or supply context too late? The next meeting should need less of you.

Feedback should give the person something to practice next time. “Be more strategic” does not tell anyone what to do differently.

Look for growing independence

The outcome to look for is better decisions with less unnecessary dependency, not simply fewer questions. Someone who stops asking because they expect criticism is becoming less visible, not more capable.

Compare a few similar decisions over time. Does the person find the real question sooner, lay out alternatives, recognize a limit, and involve the right people? Do you spend less time assembling the answer while the quality of the decision holds?

Google’s account of Project Oxygen, the research into what its managers do that it began in 2008, associates effective managers with better team results, happier teams and lower turnover, and lists coaching, giving people room to act, career development and technical skill among the behaviors it identified. That is a good reason to treat developing judgment as part of a technical leader’s job, not a distraction from it.

What the leader gives up

Preparation and review take longer than making the call yourself, at first. Someone else will sometimes choose a sound approach you would not have chosen. And you give up some of the recognition that comes from being the person with the answer, which was part of why I held on as long as I did.

Those costs are worth saying out loud. They get much harder to accept when development is squeezed into an already full week and judged only by this week’s delivery speed.