The Fundamental Distinction

Managing and coaching are not points on a spectrum. They are different modes with different purposes, different techniques, and different outcomes. Conflating them produces something that is neither - a hybrid that is too directive to build capability and too soft to provide the clarity people need.

Managing is about direction and execution. A manager sets expectations, clarifies requirements, removes blockers, monitors progress, and holds people accountable. The manager owns the outcome and directs the path to it. This is not a lesser mode. It is essential, especially when speed matters, when standards are non-negotiable, or when someone is new and needs structure to succeed.

Coaching is about capability development. A coach helps someone think more clearly, identify their own options, and commit to a course of action they own. The coach does not own the outcome - the coachee does. The coach's job is to ask better questions, not to provide better answers.

The test is simple: after the conversation, whose capability has grown?

If you gave someone the answer, you solved the problem. You may have solved it well. But they are no better equipped for the next similar problem than they were before. If you asked good questions and they found the answer, they have built something that persists.

This is not an argument against giving answers. It is an argument for being deliberate about when you do it.

Giving Answers vs Building Capability

When a senior engineer asks you how to approach a tricky concurrency problem, you have two choices. You can tell them what you would do - drawing on your own experience, pointing them at the right abstraction, saving them two days of investigation. Or you can ask what they have already considered, what constraints they are working within, what they think the trade-offs are - and help them reason through it themselves.

The first is faster. The second is more valuable over time.

The mistake most engineering leaders make is defaulting to the first because they are good at it. They became leaders by being technically strong. Giving answers is what they are rewarded for. But at the point where you are leading a team, the measure is not your individual output - it is the output and growth of the people around you.

If your team cannot function well when you are on holiday, you have not built a team. You have built a dependency.

Short-Term Output vs Long-Term Performance

This is the real tension at the heart of coaching vs managing. Coaching is an investment. It takes longer in the moment. A conversation that draws out someone's thinking takes more time than just telling them what to do. The return comes later - in the form of an engineer who thinks independently, makes good decisions, and does not need you in every conversation.

Leaders who are under delivery pressure default to managing because it is faster. This makes sense in the short term. The problem is that it compounds. The more you solve for your team, the less capable they become of solving for themselves, which means more pressure, which means less time for coaching, which means more dependence. It is a trap that feels like productivity.

The engineering leaders who build genuinely high-performing teams are the ones who treat the slower investment as non-negotiable even when it is uncomfortable.

When to Coach and When to Manage

The answer to "should I coach or manage here?" is not always coaching. The answer depends on the person, the situation, and what outcome you are actually trying to achieve.

Situational leadership is a real idea that is often dismissed because it is associated with a specific model that people find too rigid. But the core insight is correct: the appropriate leadership style depends on the capability and motivation of the person you are working with, not on your personal preference.

Reading the Person

The most common error is using a coaching mode with someone who is new and just needs clear direction. The second most common error is managing someone who is experienced and capable, which tells them implicitly that you do not trust their judgement.

Reading the Situation

Beyond the person, the situation matters:

High ambiguity, low stakes, plenty of time - this is ideal coaching territory. The person can explore options, make mistakes, and learn. The cost of a wrong turn is low.

Low ambiguity, high stakes, time pressure - this is managing territory. People need clear direction, not a Socratic dialogue about their options.

High ambiguity, high stakes - this is where judgment calls happen. You may coach to surface thinking and options, but you may also need to make a call and own it.

The question to ask yourself before a conversation: what is the actual outcome I need from this? If the answer is "I need this problem solved by end of day," manage. If the answer is "I need this person to become capable of solving these problems independently," coach.

The GROW Model

GROW is the most widely used coaching framework in management contexts. It stands for Goal, Reality, Options, Will. It is simple enough to use in a ten-minute conversation and structured enough to actually work when you follow it properly.

How It Works

Goal - What does the person want to achieve? Not the presenting problem, but what they actually want as an outcome. This is often broader than it first appears. "I want to fix this bug" might actually be "I want to understand why our caching layer keeps behaving unexpectedly" or "I want to be more confident debugging performance issues."

Start with the goal because without it, the rest of the conversation has no anchor.

Reality - What is the current situation? What have they already tried? What do they know? What do they not know? What constraints are they working within? This phase is about establishing shared understanding - not you telling them what the reality is, but them articulating it clearly.

Options - What could they do? Not what should they do - what are all the things they could do? This phase should generate options, not evaluate them. Evaluation comes later. Good coaching at this stage produces more options than the person would have generated alone, often because they have been too close to the problem to see sideways moves.

Will - What will they actually do? Not what are they going to try - what are they committing to, by when, and how will they know if it worked? This is where coaching produces action rather than just reflection.

A Worked Example

Context: A mid-level engineer, Priya, has come to you frustrated. She says the pull request review process on the team is broken - reviews are slow, feedback is inconsistent, and she is not learning anything from them.

Without GROW: You give her three suggestions for improving the process. She thanks you, goes away, does one of the three things, and the problem mostly continues.

With GROW:

Goal phase: You: "What would good look like for you here?" Priya: "Reviews that are useful and that don't block me for days." You: "What does 'useful' mean to you specifically?" Priya: "I want to actually understand why my choices are being questioned, not just be told to change things."

Now you know the real goal is learning, not throughput.

Reality phase: You: "What have you already tried?" Priya: "I've asked people to add more comments. It helped a bit." You: "What's stopping you from asking directly in review? Like, 'I made this choice because X - what would you have done differently?'" Priya: "I didn't want to seem defensive."

Options phase: You: "What are all the ways you could make reviews more useful for your learning, setting aside what feels awkward for a second?" Priya generates: asking direct questions in review, having a follow-up conversation after review closes, pairing on a review with someone she wants to learn from, writing up her own reasoning before submitting a PR to invite specific feedback.

Will phase: You: "Which of these are you going to try first?" Priya: "I'll add a brief note to my next PR explaining my decisions and explicitly asking for feedback on those specific choices." You: "When's your next PR?" Priya: "Tomorrow, probably." You: "Come back and tell me how it goes?"

Why Most Managers Use It Badly

The most common failure is turning GROW into a script for delivering your own answers more cleverly.

In the options phase, managers who have already decided what the person should do ask leading questions: "Have you thought about doing X?" "What about trying Y?" This is not generating options - it is reverse-engineering to the answer you were going to give anyway. It is slower and it is slightly dishonest. The person eventually figures out that the "coaching conversation" is just a roundabout way of getting told what to do, and they stop engaging with it.

The second failure is skipping the Will phase. A conversation that ends at Options is a discussion, not a coaching session. Coaching produces commitment to action. If you end the conversation without a specific next step and a timeframe, you have not coached - you have chatted.

The third failure is rushing past Reality. Leaders who are problem-solvers by instinct find it almost physically uncomfortable to sit in the reality phase and ask more questions when they already know the answer. The discipline of staying in that phase longer than feels necessary is the actual skill.

Coaching in the Flow of Work

Coaching does not require a formal session with a whiteboard and a GROW framework written at the top. The most valuable coaching often happens in the middle of existing work conversations.

Turning a Code Review into a Coaching Moment

Instead of: "This approach is O(n^2) - use a hash map."

Try: "What's the performance profile of this going to be at scale? Have you thought about the complexity here?" If they have not, you can ask what options they see. If they say "I could use a hash map," you have coached. If they are stuck, you can point them toward the approach - but you have still expanded their thinking first.

The review now contains a question, not just a correction. Over time, this changes how the engineer thinks before they submit code, not just after they get feedback.

Turning a Problem-Solving Conversation into a Capability-Building One

An engineer comes to you with a problem they cannot solve. The managing move is to solve it. The coaching move is:

1. Ask what they have already tried and what they learned from it.
2. Ask what they think the problem actually is - not the symptom, the cause.
3. Ask what they would need to know to be more confident about the diagnosis.
4. Ask what options they see.

This takes longer in the moment. It builds engineers who diagnose problems well rather than engineers who escalate problems efficiently.

The test is this: if the same engineer came to you with the same class of problem six months from now, would you expect a different conversation? If yes, you have coached. If no, you have managed.

Questions That Open vs Questions That Lead

This is the most important practical skill in coaching. The difference between a question that opens thinking and a question that leads to your predetermined answer is not always obvious from the outside, but it is always obvious to the person being asked.

Questions That Open

• "What have you already considered?"
• "What's the thing you're most uncertain about?"
• "What would you do if I wasn't available?"
• "What does a good outcome look like for you?"
• "What's stopping you?"
• "What else?"

These questions share a quality: there is no correct answer embedded in the question. You genuinely do not know what the response will be, and that is the point.

Questions That Lead

• "Have you considered just simplifying the interface?" (I have decided you should simplify the interface)
• "Wouldn't it be better to just talk to them directly?" (I think you should talk to them directly)
• "Don't you think this is getting overcomplicated?" (I think it is overcomplicated)

These questions have a correct answer baked in. They are advice in question clothing. They feel less directive, but they are not. The person being asked can feel the answer being sought, and most will give it to you, not because they have thought it through but because that is what the social situation requires.

The test for a genuine question: would you be interested in any answer they gave, or only certain ones?

Catching Yourself Leading

The pull toward leading questions is strong because you are often asking from a position of genuine knowledge - you have seen this before, you know what works, and you want to be helpful. The leading question feels like a gentler way of being helpful.

The practice is to notice the question forming and ask: am I looking for their thinking or am I delivering mine? If the latter, either ask it straight ("I think you should consider simplifying the interface - what do you think?") or stay genuinely curious. Disguised advice is worse than direct advice.

The Manager's Trap

The expert trap is specific to engineering leaders. You became a leader because you were technically strong. You got promoted because you solved hard problems well. Now you lead a team, and the habits that made you successful as an individual contributor are the habits that will undermine you as a leader.

What the Trap Looks Like

• Engineers come to you with problems and you solve them, because you can, and it feels productive.
• In architectural discussions, your view carries disproportionate weight because of your track record.
• When a decision is hard, people wait to see what you think before committing.
• Pull requests get substantially rewritten in review rather than discussed.
• You are in every critical path conversation because the team expects you to be.

None of this feels like a trap. It feels like high performance. You are delivering. The team is shipping. Problems get solved.

What It Costs

What you do not see is what is not happening:

• Engineers are not developing their own problem-solving approaches because you short-circuit the process.
• Architectural thinking is not being distributed because you own it.
• Nobody on the team is building the judgement to make hard calls because you always make them.
• Your absence - holiday, illness, a new role - creates a genuine performance cliff.

The team becomes a group of people who are dependent on you, not a team. A good team can function well without the leader present. That is the test.

Stepping Back

The practical move is to create a rule for yourself: before giving an answer, ask a question. Not always, not in every situation - but as a default. Get curious about their thinking before you share yours. Let the conversation breathe before you close it.

This is uncomfortable at first because it is slower and because you will sometimes watch someone come to a less-than-optimal conclusion. That is the actual cost of building capability - sometimes people take longer routes. The question is whether the investment pays off over time.

Building a Coaching Habit

Habits are not built through willpower. They are built through practice, repetition, and feedback. The shift from a default of telling to a default of asking requires deliberate practice over time.

Start with One Conversation Per Day

Pick one conversation - just one - where you commit to asking before telling. It does not have to be a formal coaching session. It can be a quick stand-up exchange. Practice asking "what do you think?" before offering your own view.

This sounds trivial. Do it for a week and notice how uncomfortable it feels to stay in the question when you know the answer.

Use the Pause

Before responding in any significant conversation, pause. Not theatrically - just a beat longer than your instinct. The pause gives you space to choose your response rather than react from habit.

The question to ask yourself in the pause: am I about to tell or am I about to ask? Either is fine - but choose deliberately.

Track Your Ratio

For one week, after significant conversations with your team, note whether you told more or asked more. Not as a guilt exercise - as data. Most engineering leaders discover that their telling-to-asking ratio is radically skewed toward telling. Awareness of the actual ratio is the starting point for changing it.

Invite Feedback

Ask your team: "When I give feedback, do you feel like you understand the reasoning, or does it sometimes feel like a directive?" Ask directly. This surfaces how your communication is landing, not just how you intend it.

Common Failures

Coaching Theatre

The most common failure: the leader asks coaching questions but has already decided the answer. The conversation is structured to arrive at the predetermined destination. The coachee eventually notices - usually through repeated "right answer" moments - and stops engaging authentically. They learn to play the game of finding the answer the leader already has.

This is worse than direct advice because it is dishonest and it trains people to be compliant rather than to think.

How to avoid it: If you have a strong view, say so directly and ask for their reaction. "My instinct is X - does that land with you or am I missing something?" This is more honest and more useful than pretending to be neutral.

Managing by Abdication

The opposite failure: calling non-intervention "coaching." "I'm giving them space to find their own way" - when actually there is no support, no check-in, no feedback, and the person is floundering.

Coaching is active. It requires presence, questions, and feedback. It is not stepping back and hoping for the best.

How to identify it: If a team member would describe you as "hard to get time with" or "not very involved in my development," you are not coaching - you are absent.

Inconsistency Across Team Members

Coaching one person while managing another, without awareness of why. The result is that some team members grow in capability and some remain dependent on direction - and the difference often tracks seniority or personal connection rather than development need.

The pattern to watch for: Do you have rich development conversations with some team members and purely transactional conversations with others? If yes, why?

Skipping the Contracting

Not establishing at the start of a conversation what kind of support is wanted. The engineer wants a quick answer because they are blocked; you want to coach because you believe in developing capability. The mismatch means neither gets what they want.

The fix: Ask explicitly. "Do you want me to help you think this through or do you want my view directly?" Most engineers, most of the time, know what they need.

Connection to Your Operating Model

Coaching is not a soft add-on to good engineering leadership. It is the mechanism by which your team's capability compounds over time.

Every interaction where you choose to ask rather than tell is an investment in a team that can think independently, make good decisions in your absence, and grow engineers who will eventually lead others.

The managing mode is appropriate and necessary. Direction, standards, and accountability are not replaced by coaching - they are complemented by it. The leaders who build the strongest engineering organisations are the ones who move fluidly between both modes, deliberately, based on what the person and situation need.

If your team is not growing in capability, the question to ask is not "am I working hard enough?" It is "am I coaching enough?"

The structural patterns in this operating model - team autonomy, clear accountability, distributed decision-making - all depend on a workforce of people who have been coached to think well. They do not emerge from teams that have been managed into compliance.

Your job is not to be the best engineer in the room. It is to make the room full of the best engineers you can develop.

Coaching Across Levels

The coaching approach is not uniform across career levels. What works with a graduate engineer is different from what works with a staff engineer who has fifteen years of experience. Getting this wrong in either direction is expensive.

Coaching Graduate and Junior Engineers

New engineers often do not know what they do not know. The Socratic approach - "what do you think?" asked before providing context - can feel disorientating when the person has no frame of reference to form a view from.

For junior engineers, coaching works best when it provides scaffolding first. Explain the context, the constraints, and the relevant considerations - and then ask for their thinking. "Here's the trade-off space: we're choosing between consistency and availability, and here's what each means in this system. Given that, what would you prioritise?" is a coaching question. "What would you prioritise?" without the preceding context is a test that they have not been given the materials to sit.

The coaching goal for junior engineers is not immediate independent problem-solving. It is learning how to think about problems - the framing, the relevant considerations, the process. The output is a cognitive model that becomes more useful over time.

Coaching Senior and Staff Engineers

The coaching failure with experienced engineers is usually the opposite: over-direction. The leader's instinct is to share what they would do, to bring their experience to bear, to point at the pattern they have seen before.

With experienced engineers, the coaching question is not "do they have the capability?" - they often have more domain knowledge than the leader. The question is "are they using their capability well?" Are they getting stuck in local optima? Are they carrying assumptions that should be questioned? Are they too close to the problem to see alternatives?

The coaching role with a staff engineer is often as a thinking partner - someone who asks good questions, challenges assumptions, and helps them stress-test their reasoning. The content of the question matters less than the presence of a thoughtful challenge.

A useful set of questions for coaching experienced engineers:

• "What's the strongest argument against what you're proposing?"
• "What would you need to see to change your view on this?"
• "Who else has a stake in this decision that you haven't talked to?"
• "If this doesn't work, what's your theory of why it wouldn't?"

The Promotion Inflection Point

One of the most important coaching moments is just before or just after a promotion. Engineers who have been excellent individual contributors often struggle with the transition to roles that require them to lead others, manage ambiguity at a different scale, or operate with less direct feedback on their output.

The coaching focus at this inflection point:

• Helping them articulate what the new role requires that is different from the previous one
• Exploring the beliefs about themselves that might not serve them in the new context ("I need to know the answer before I can have confidence")
• Building a map of what success looks like in the first ninety days

This is some of the highest-leverage coaching available to an engineering leader - the investment at this transition point shapes the trajectory of the person's effectiveness in the new role.

Coaching vs Mentoring vs Sponsorship

These three are often conflated. They are different activities with different purposes, and engineering leaders need all three in their toolkit.

Coaching is most valuable for current performance challenges and near-term development. It builds self-sufficiency.

Mentoring is most valuable when someone is navigating territory you have been through. Your experience is directly relevant. Sharing it is faster than helping them rediscover it.

Sponsorship is most valuable for career trajectory. It requires the leader to actively advocate for someone in rooms the person is not in - nominating them for projects, including them in discussions above their grade, naming them as capable when others are being considered.

Most engineering leaders mentor moderately well when asked, coach accidentally, and sponsor rarely. The leadership impact of intentional sponsorship - particularly for engineers from underrepresented groups, who are less likely to be sponsored without deliberate effort - is disproportionate to the effort it requires.

Choosing the Right Mode

The question to ask before any developmental conversation: "What does this person need right now - their own thinking surfaced, my experience shared, or my influence deployed on their behalf?"

The answer changes with context. A coaching question when the person needs a mentor's direct experience is frustrating. Mentoring when the person needs coaching removes their ownership of the development. Sponsorship when the person needs coaching misses the point entirely.

Getting the mode right is itself a leadership skill.

Measuring the Impact of Coaching

Most coaching in organisations is unmeasured. This is partly because the outcomes are slow to appear and hard to attribute. But the absence of measurement does not mean coaching has no impact - it means leaders are operating without feedback on whether their coaching is working.

Leading Indicators

These are observable in the short term:

• Are engineers making decisions independently that they previously escalated?
• In conversations you have coached on, do people arrive with better-formed thinking than before?
• Are the questions engineers ask getting more sophisticated over time?
• Are there engineers on your team actively developing others?

Lagging Indicators

These take longer to appear but are more definitive:

• Career growth of engineers on the team (promotions, scope expansion, readiness for new challenges)
• Team capability during the leader's absence (the holiday test)
• Engineers who have moved into leadership roles and lead well
• Retention of high performers

The Coaching Log

A practical tool: a brief note after each formal coaching conversation. Not an assessment of the person - a note to yourself. What was the topic? What questions worked? What did the person commit to? Did they follow through?

Over three months, this log reveals patterns - who you coach often, who you have not invested in, which conversations produce action and which do not. It is a form of accountability that most leaders find uncomfortable and valuable.

Self-Assessment

Once a quarter, answer these honestly:

• Which engineer on my team has grown most in the last three months? What role did I play?
• Which engineer on my team has grown least? What role did I play?
• What is the ratio of conversations where I told to conversations where I asked?
• If my team described my development conversations, what would they say about them?

The answers provide direction. The action is in changing the pattern.