When every decision still needs you
Being the strongest technical contributor can make you the team’s default decision maker. How I would develop someone else’s judgment without leaving them unsupported or quietly taking the work back.
In Data in the boardroom, I describe a mistake: I stayed the single interface between the team and executives for too long. It was efficient in the moment, and it was gratifying. It also concentrated context in me and limited the team’s development.
That is a useful starting point for a new data manager. If every recommendation needs your approval, ask whether the team lacks judgment or whether you have kept the information and authority required to exercise it.
I have managed and mentored people across data engineering and analytics, including teams working across technical and analytical responsibilities. Part of that work was establishing code review, deployment standards, and data quality practices that continued beyond an individual project. Technical judgment became something to teach and review, rather than something only the lead could supply.
The approach below draws on that experience. It is guidance for developing judgment, not an account of a particular person’s promotion.
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 evaluating 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 an easy way to offer encouragement where the person needs a structural change.
Hand over a decision with a boundary
Start with something consequential enough to teach judgment and contained enough that a mistake is recoverable. Agree the decision, the person affected, the deadline, and when to escalate. Make clear which constraints are fixed and which are open to challenge.
For example, an analyst might recommend whether to reduce a dashboard’s refresh frequency. They would need to understand its consumers, the freshness each decision requires, and the operating cost. The exercise is illustrative: the learning comes from defending the tradeoff, not from guessing which refresh schedule the manager prefers.
For higher-consequence work, keep the appropriate approval. Developing someone does not require 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.
Questions I would use in that review:
- 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 mode, share the relevant experience. Make clear when you are teaching a technique, offering an opinion, or making the decision yourself. Leaving that implicit can turn a suggestion into 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 intervene, explain why afterwards. Otherwise the analyst learns that ownership lasts only until the conversation becomes difficult.
Debrief soon enough that both people remember the exchange. Discuss where the recommendation became clearer, which question exposed a gap, and what support was missing. Include the manager’s behavior in that review: did you answer too quickly, change the boundary, or provide context too late?
Feedback should give the person something to practise at the next opportunity. A general instruction to be more strategic does not tell them what to do differently.
Look for growing independence
The outcome to look for is better decisions with less unnecessary dependency. It is 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. Can the person identify the real question sooner, explain alternatives, recognize a limit, and involve the right people? Can you spend less time assembling the answer while the quality of the decision holds? These are proposed observation points, not a score that proves readiness for promotion.
What the leader gives up
Preparation and review can initially take longer than making the call yourself. Someone else may choose a sound approach you would not have chosen. You also give up some of the recognition that comes from being the person with the answer.
Those costs are worth discussing openly. They become harder to accept when development is squeezed into an already full workload and judged only by this week’s delivery speed.
Working through this with your team?
I’m opening up advisory and mentoring for data managers and first-time heads of data. Bring a decision you’re facing. Different experiences and disagreements are welcome too.