How do you talk to someone who sends every hard call up?

Someone who sends every hard call up needs a clear boundary between asking for support and transferring ownership. Bring examples where they presented a problem without a recommendation, waited for you to make a decision within their role, or turned your coaching into work for you. Return one current decision, define the authority they have, and set a date to review what they chose.

What does upward delegation look like?

The engineer forwards a difficult review and asks what to write, brings two design options but refuses to recommend one, or reports a conflict and waits for the manager to hold the next conversation. The manager answers quickly to keep work moving. Soon the engineer owns only easy execution while the manager becomes an extra pair of hands for every uncertain call.

Do not confuse escalation with delegation. Security exceptions, staffing decisions, and major product tradeoffs may genuinely require your authority. The problem is transferring choices that belong within the engineer's role. Prepare examples and identify who actually held decision rights before you give feedback.

How should you open the 1 on 1?

Say: “I have noticed that several decisions within your project role are arriving with me as questions for me to solve. On the cache change, you brought two options but no recommendation. On the review conflict, you asked me to write the response. I want to support your judgment without taking over decisions you own.”

Ask what makes those calls hard. They may be unclear about authority, fear punishment for a wrong choice, lack context, or have learned that you rewrite decisions anyway. Your management behavior may be part of the loop. Listen for the barrier, then preserve the ownership boundary.

Which decisions are actually theirs?

Name the envelope. A senior engineer may choose implementation within an accepted design, resolve routine review disagreement, and sequence technical tasks. You may retain staffing, performance, budget, and cross team priority decisions. Write local examples because titles alone rarely make authority obvious.

If you previously overruled choices without explaining why, acknowledge it. State what conditions trigger your involvement, such as customer risk above a threshold or a change to committed scope. Freedom without boundaries feels like a trap. Boundaries without freedom create dependence.

How do you return a decision?

Use a calm response: “This choice is within your role. Bring me your recommendation, the main tradeoff, and the risk you want help testing by 3 PM. I will challenge the reasoning, but you will make the call.” This gives support and a deadline without accepting the problem as your task.

Resist the urge to answer when they ask, “What would you do?” You can ask which option they favor and what evidence would change it. If urgency requires immediate action, state who decides now and review the pattern later. A crisis is not the best time to teach through deliberate delay.

Which support preserves ownership?

Support should make the engineer more capable on the next call. Writing their message, attending every review, or choosing every option may solve today's issue while deepening dependence. Ask whether your help transfers context or transfers responsibility.

What sequence builds decision ownership?

1. Select one current hard call.
2. Confirm that it sits within their role.
3. Ask for a recommendation and tradeoff.
4. Provide missing constraints only.
5. Let the engineer decide and communicate.
6. Review the result without punishing reasonable risk.
7. Increase the decision range gradually.

Choose a decision with meaningful stakes but recoverable consequences. A review approach or internal design choice is often better than an irreversible production action. Practice requires room for an answer that differs from yours. If you accept only your preferred choice, the engineer will keep sending decisions up.

What if they fear making the wrong call?

Explain how reasonable errors will be handled. Ask them to state assumptions, preserve reversibility where possible, and define a check. If the outcome is weak, review the reasoning and evidence instead of saying they should have known. Psychological safety becomes credible through the manager's response to the first imperfect decision.

Also distinguish a bad result from a bad process. A well reasoned cache choice can meet unexpected traffic. A lucky choice can succeed despite ignored evidence. Evaluate whether the engineer gathered enough context, made the tradeoff visible, and adapted when facts changed.

How do you stop becoming the extra pair of hands?

Notice tasks disguised as questions. “Can you look at this draft?” may mean useful feedback, or it may mean the manager must finish it. Ask what stage it is in, what feedback is needed, and who owns the final version. Return unfinished thinking with a clear next step rather than silently completing it at night.

Change your availability pattern if instant answers have trained dependence. Keep a regular decision clinic or ask for recommendations in writing before a discussion. Do not become unreachable. Make access more intentional so support rewards preparation and leaves ownership visible.

What should you check at follow up?

On the named date, ask the engineer to explain the choice, tradeoff, communication, and result. Look for independent movement, not whether they guessed your answer. Recognize where they used support appropriately and where they attempted to pass the decision back.

If they continue refusing decisions clearly inside the role, state the performance impact: work waits, peers lack direction, and you cannot operate at your own scope. Set another bounded expectation or use the appropriate formal process. Endless rescue hides the gap from both of you.

How can you coach a recommendation without giving the answer?

Ask the engineer to start with the decision, their recommendation, and the strongest reason against it. This forces a useful level of synthesis. If they provide a long list of facts with no judgment, ask which fact changes the choice. Do not reward volume by solving the final step for them. Give missing organizational context only when it is genuinely unavailable from their role.

Use questions that expose reasoning: What outcome matters most? Which option is reversible? Who bears the risk? What evidence would make you switch? These questions help the engineer build a decision method they can reuse. A leading question that points obviously to your preferred choice teaches them to wait for coded instructions.

Agree on the amount of uncertainty the role can carry. Some engineers escalate because they believe a decision must be certain. Explain that many engineering choices are made with partial evidence, a safe boundary, and a check date. Let them choose a reversible path, define the signal that would stop it, and communicate the rationale to affected people.

After the decision, do not rewrite their message into your voice. Review for missing audience, risk, owner, or date, then let them send it. If a phrase could create a serious misunderstanding, explain the issue and ask them to revise. Ownership includes representing the choice, not merely whispering a preference to the manager.

When peers push back, keep the engineer in the conversation. It is tempting to enter the channel and defend the decision because your support feels efficient. Ask the engineer to answer the concern and bring you in only for authority you actually hold. Public rescue can undo the ownership you established privately.

At the review, discuss where your involvement added value and where it replaced judgment. Perhaps you supplied a product constraint but left the architecture choice with them. Perhaps you answered a review question they could have handled. Adjust both sides. Upward delegation is a relationship pattern, so the manager's rescue habit belongs in the evidence too.

Expand scope gradually after a sound decision. Name the next category they can own without prior approval and the conditions that still require escalation. Increased trust should become visible authority, not only praise. If the decision went poorly, narrow the lesson to the reasoning gap rather than taking every future call back forever.

How can a manager change their own rescue habit?

Track one week of requests that you answered too quickly. Note which decision owner, context gap, and deadline applied. You may discover that your speed rewards unfinished thinking, that you enjoy being the expert, or that leadership pressure makes delegation feel risky. Choose a replacement response for each pattern. Ask for a recommendation before meetings, publish decision rights, or reserve a short block for questions that truly need your context. Tell the engineer about the change so a slower answer does not feel like sudden withdrawal. When you return a decision, remain available for the promised support and avoid taking it back at the first pause. Notice your language in group settings. If you routinely answer questions directed to the engineer, wait and let them respond. If you disagree, ask about reasoning before announcing your solution. Your behavior teaches the real authority map more loudly than a role document. At the follow up, review your interventions alongside their decisions. The engineer should own more calls, and you should spend less time completing work that belongs at their level. If dependence remains, identify whether the remaining barrier is skill, authority, confidence, or your unwillingness to accept a different reasonable answer.

What are common questions?

Related: having a difficult conversation with an engineer, talk to someone who dislikes the job, talk to a former peer you now manage.

Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.