Coaching, Feedback, Mentoring, and Sponsorship

Coaching, feedback, mentoring, and sponsorship are different forms of support. Choosing the wrong one creates familiar frustration: advice when reflection is needed, questions when direct context is missing, or encouragement when access is the actual barrier.

A simple decision path prevents managers from defaulting to their favorite style. Diagnose what is missing before acting.

Ask permission when switching modes: “I can keep asking questions, share a similar experience, or give a direct observation. Which would help?” Sponsorship also requires learning what contribution and opportunity the engineer wants; do not nominate people for stereotyped or unwanted work.

Coaching helps someone examine their own assumptions, options, and commitments. It is most useful when the engineer owns the problem and has enough context to reason, but needs space or challenge rather than an answer.

Coaching sequence:

1. “What outcome are you trying to create?”
2. “What do you know, and what are you assuming?”
3. “Whose constraints or incentives are missing?”
4. “What options have you ruled out, and why?”
5. “What is the smallest next experiment?”
6. “What will you do, and when?”

Manager trap: asking leading questions until the engineer guesses the manager's preferred answer. If there is only one acceptable action, state the constraint directly rather than staging fake discovery.

Engineer move: say what form of thinking help you need: “Please challenge my stakeholder model, not the database design.”

Feedback supplies information the engineer cannot observe alone. Keep it timely, specific, and open to context; distinguish a development observation from formal evaluation.

Script: “During the platform review, you changed the recommendation after Finance explained the cost constraint. That made the tradeoff credible and moved the group to a decision. What helped you adapt? Please reuse that constraint-first approach in the identity review.”

Feedback can reinforce effective behavior, not only correct problems. Do not save material feedback for the standard 1:1 if the next relevant moment happens sooner.

Mentoring offers a model, story, connection, or warning from relevant experience. It is useful when the engineer has not encountered a situation before, but advice must be labelled and adapted because the mentor's context and power may differ.

Consent script: “I faced a similar standards-adoption problem. Would an example and the mistake I made be useful, or would you prefer to reason through your case first?”

Useful mentoring structure:

• Context: what was similar and importantly different.
• Choice: what you did and what alternatives existed.
• Consequence: what happened, including unintended effects.
• Transfer: which principle may apply here.
• Agency: “What, if anything, fits your situation?”

Engineer move: ask for models and tradeoffs instead of recipes: “How did you learn whether apparent agreement would become adoption?”

Sponsorship changes the environment around the engineer. Lara Hogan's practitioner guidance includes raising a person's name for leadership assignments, talks, visible technical work, and feedback from influential people.

Modes often form a sequence rather than a choice made once. Suppose a Staff engineer's architecture direction is technically strong but has weak adoption.

1. Feedback: “Two teams cannot explain the decision or their role after the review.”
2. Coaching: “What do you think they needed before a recommendation existed?”
3. Mentoring: “Would a model for stakeholder discovery from another migration help?”
4. Sponsorship: “I will introduce you to both directors and state that you own the decision process.”
5. Feedback again: observe whether discovery and adoption improve.

The manager does not coach around a missing mandate. The engineer does not interpret sponsorship as proof that no capability development is required.

Access and visibility are distributed through everyday choices, so sponsorship requires a deliberate fairness check. Familiarity, similarity, confidence, availability, and prior visibility can make the same few names feel “obvious.”

Effective development uses the support mode that matches the actual need. Senior engineers can also use all four modes with peers and developing leaders; sponsorship is not limited to managers.

• Coach when the engineer needs to strengthen their own reasoning.
• Give feedback when an observed behavior and effect are not visible to them.
• Mentor when relevant experience or a model is missing, with context and consent.
• Sponsor when opportunity, access, authority, or visibility is the constraint.
• Name mode changes so advice, questions, and evaluation are not confused.
• Audit opportunity allocation for evidence, interest, access history, support, and bias.

This exercise builds mode fluency. Pick a current development situation and write one response in each mode before choosing the best next move.

These practitioner sources ground the distinctions; the decision path, combined sequence, and fairness audit are course syntheses.

• Lara Hogan: What does sponsorship look like?
• Lara Hogan: One-on-one resources
• GitLab: Feedback classification
• GitLab Handbook: 1-1