Management Coaching for Programmers: A Practical Guide

As an Amazon Associate I earn from qualifying purchases.

Management coaching for programmers means helping developers solve problems, make better decisions, and take responsibility for their work. You do that by asking useful questions, giving specific feedback, and agreeing on a next step. You also need to know when to stop asking questions and teach something directly.

If every difficult bug lands on your desk, you haven’t finished the job. The goal is a developer who can handle more of the next problem without you.

This guide is for senior developers, tech leads, and engineering managers who coach people on their team. You don’t need a management title to use it.

Coaching, mentoring, and management: know which job you’re doing

These activities overlap, but they aren’t interchangeable. A developer needs to know whether you’re helping them think or telling them what their job requires.

• Coaching: Help someone work through a problem they can learn to solve. Ask what they want to achieve, what they’ve tried, and what they’ll do next.
• Mentoring: Share experience they don’t have yet. Explain how you approach a code review or decide whether to specialize.
• Management: Set expectations, assign work, and address performance. Be clear about what is required and what support is available.

Suppose a developer doesn’t understand a race condition. Teach the concept. If they understand it but aren’t sure how to investigate this particular bug, coach them through an experiment. If they repeatedly ship changes without the required tests, explain the expectation directly.

Don’t turn a performance warning into a guessing game. “What do you think you could do differently?” isn’t enough when there’s a requirement you haven’t stated.

John Sonmez’s Soft Skills discusses mentoring as something developers can do before they feel like experts. You can help someone a few steps behind you. Be honest about what you know, and don’t pretend you have the answer to everything.

A practical coaching conversation for developers

Start with one real situation. A blocked pull request is easier to work on than “I need to become a better programmer.” You can discuss the bigger career goal once you understand the immediate problem.

The original version of this article drew on Michael Bungay Stanier’s The Coaching Habit. These five questions remain a useful starting point. Use them as a conversation, not a script you recite at someone.

1. What’s on your mind?

Give the developer room to choose the issue. Then get specific. “The backend is confusing” could mean they don’t understand the architecture, can’t reproduce a bug, or are afraid to ask the team a question.

Try: “Which part of the task is blocking you right now?” Ask them to show you the ticket or the behavior they’re seeing. Listen before opening your editor.

2. And what else?

The first answer may be only part of the problem. A developer might say the requirements are unclear, then explain that they haven’t spoken to the person who requested the feature.

Ask once, pause, and let them finish. You don’t need to keep digging until an ordinary work problem becomes a life story.

3. What’s the real challenge here, for you?

This brings the conversation back to something the developer can act on. “The product owner never writes good tickets” puts the entire solution in someone else’s hands.

A more useful problem is: “I don’t know which acceptance criteria to clarify before I start.” Now you can work on a short list of questions and decide who needs to answer them.

4. What do you want?

Define an outcome you can recognize. “Understand the service” is vague. “Trace a request from the endpoint to the database and explain where authorization happens” gives you a finish line.

For a career conversation, the outcome might be owning a small feature or leading the next design discussion. Avoid promising a promotion or raise. Those decisions depend on more than a coaching session.

5. How can I help?

Let the developer ask for the kind of support they need. Maybe it’s a diagram, a second pair of eyes, or an introduction to someone who knows the subsystem.

Agree on the smallest useful next step. “Try logging the value before and after the transformation, then bring back the result” is better than “Keep working on it.” Set a follow-up time if the task is blocking other work.

Example: coach a developer through a bug without taking over

A junior developer says, “The total is wrong, and I’ve been changing the calculation for an hour.” Here’s how a coaching conversation might go:

Lead: What result did you expect, and what result did you get?

Developer: Two items at ten dollars each should total twenty. The response contains twenty-two.

Lead: Where have you checked the value so far?

Developer: At the API response. I haven’t checked it before the tax calculation.

Lead: What would tell you whether the item calculation is wrong or the tax rule is different from what you expected?

Developer: I can inspect the subtotal and the configured tax rate separately.

Lead: Good. Try that with one reproducible request. If the rule is unclear, we’ll confirm it before changing the code.

The lead hasn’t supplied a clever fix. They’ve helped the developer separate an observation from an assumption and choose a test.

Keep the keyboard with the person learning when practical. If you need to demonstrate a technique, explain what you’re doing. Then have them use it on a second example. Watching you work isn’t the same as being able to do it.

Time-box the investigation based on the risk and the deadline. A production incident needs a different response from a practice task. Don’t sacrifice customers so you can finish a coaching exercise.

Give feedback that helps a programmer improve

Useful feedback points to something the developer can inspect and change. “Be more careful” doesn’t tell them what to do.

Try: “This function reads the same account twice. Between those reads, another request can change the balance. What would keep the decision and the update consistent?” If they don’t know the underlying concept, explain it.

Google’s code review guidance recommends explaining why a change matters and balancing direct instructions with room for the developer to choose a solution. It also recommends making clear which comments require changes and which are optional.

Apply that distinction in your reviews:

• Required: “This endpoint needs the authorization check before it returns account data.”
• Suggestion: “Consider extracting the validation so the happy path is easier to read.”
• Positive feedback: “This test covers the empty input case that caused the last failure. Keep that pattern.”

Discuss the code and its consequences. Calling someone careless makes the conversation about defending themselves.

If the same issue keeps returning, ask the developer to explain the principle in their own words. Then choose a small task where they can apply it. Another comment saying “we talked about this” won’t fill a gap in understanding.

A simple engineering one-to-one template

A coaching one-to-one needs more than a status update. Tickets already tell you what is in progress. Use the conversation to understand where the developer needs help.

Here’s a suggested structure for a short meeting. The timing is a starting point, not a rule.

1. Choose the problem: Ask what’s on their mind and identify one situation worth discussing.
2. Understand the evidence: Ask what happened, what they expected, and what they’ve already tried.
3. Choose a next step: Let them propose an experiment or a change. Add technical guidance where they’re missing knowledge.
4. Agree on support: Decide who needs to help and when you’ll check back.
5. Write a short note: Record the goal, the next action, and the follow-up. Keep private details out of shared project notes.

A useful note could read: “Goal: investigate intermittent test failures independently. Next action: reproduce one failure and record the seed, inputs, and environment. Support: pair for fifteen minutes if reproduction fails. Follow-up: next one-to-one.”

Don’t use private development conversations as a surprise performance record. If an issue is a formal performance concern, state that clearly and follow your company’s process.

When to stop coaching and teach directly

Questions are useful when the person has enough knowledge to reason through the problem. They’re frustrating when you’re asking someone to discover a fact they couldn’t reasonably know.

Explain directly when they need access instructions, an unfamiliar API contract, or a safety requirement. During an incident, give clear direction and save the teaching discussion for the follow-up.

You can say, “There’s a concept missing here. Let me explain it, then we’ll try an example.” That is more helpful than ten questions that hint at the answer you already want.

Also respect the person’s willingness to participate. You can offer coaching, but you can’t do their learning for them. Agree on a task they will actually attempt rather than creating a development plan they haven’t accepted.

If you’re new to leadership, read Some Advice on Becoming a Lead Developer. Taking responsibility for the team’s success includes helping other people do the work, not proving you can do all of it yourself.

Measure progress by what the developer can do next

Feeling encouraged after a meeting is good. It isn’t enough evidence that the coaching worked.

Look for a change in a specific task: the developer writes a reproducible bug report, explains a design trade-off, or completes a familiar kind of change with less help. Compare similar tasks. A harder assignment can require more support even when someone is improving.

Avoid turning lines of code or ticket counts into a verdict on someone’s growth. Those numbers leave out difficulty and the work needed to help teammates.

The dependency problem in The Phoenix Project is a useful reminder: routing every problem through one expert creates a bottleneck. Keep the existing expertise, but help other developers build some of it too.

For a team, that might mean a short troubleshooting note or a second person who can safely maintain a service. For an individual, use a technical-skill practice plan with a clear outcome. A workplace learning culture gives them room to practice between conversations.

Questions about coaching programmers

Can a senior developer coach without being a manager?

Yes. You can help someone think through a technical problem without authority over their performance. Make that distinction clear, and leave formal management decisions to their manager.

How do you coach a developer who keeps asking for answers?

Ask them to bring the expected behavior, the actual behavior, and one thing they’ve tried. Help them choose the next test. If they’re missing basic knowledge, teach it rather than withholding the answer.

Is coaching useful for experienced engineers?

Yes. The discussion may focus on design choices, delegation, or disagreement with another team. You don’t have to be the best programmer in the room to ask a question that clarifies the decision.

Start with the next real problem on your team. Ask what the developer has tried, agree on one useful action, and check what happened. Which part of the work would you like them to handle more independently?