Most engineering managers I’ve worked with have the same problem, and it’s not the one they think.
They think they need to coach more. They’ve read the books, attended the workshops, internalized the message that great managers ask questions instead of giving answers. They’ve been told, repeatedly, by people they respect, that their job is to “unlock potential” and “empower their teams.” If someone on their team is struggling, the prescription is always the same: ask better questions. Be curious. Hold space. Coach.
I think a lot of them are coaching too much. And I think many of them are doing it for themselves, not for the people they manage.
This is a post for engineering managers, new and experienced, who have a nagging feeling that something about the coaching-first orthodoxy doesn’t quite fit. Who have sat in a 1:1, asked a string of open-ended questions, and watched their report’s face go from hopeful to frustrated. Who suspect that sometimes, the most helpful thing they could do is just say the thing.
How we got here
The coaching-first movement in management isn’t wrong. It emerged from a real problem.
For decades, the default management style, especially in engineering, was command and control. Managers hoarded context, made decisions unilaterally, and treated their reports as executors of their vision. The senior engineer would come to their manager with a technical problem, and the manager would say “do it this way” without understanding the constraints. Or worse, the manager had been promoted out of their technical depth and was directing work they couldn’t actually evaluate.
The coaching model was a corrective to this. And it’s a good corrective. When you ask questions instead of giving answers, you force yourself to listen. You help people develop their own judgment instead of creating dependency on yours. You learn things about the problem that you wouldn’t have learned if you’d just started talking.
I practiced this heavily at my last two companies, and it genuinely made me a better manager. I learned to shut up in 1:1s. I learned to ask “what have you tried?” before jumping to solutions. I learned that the best outcome of a conversation is often the other person arriving at an insight they own, rather than one I handed them.
But here’s what I’ve also learned: the coaching model has become so dominant that questioning it feels almost heretical. It’s the water we swim in. Every management book, every leadership course, every conference talk reinforces the same message. Coach, don’t tell. Ask, don’t direct. Empower, don’t decide.
And when something becomes orthodoxy, people stop thinking about when it doesn’t apply.
The three failure modes
I’ve seen coaching go wrong in three distinct ways. Each one is common enough that I’d bet most engineering managers reading this have done at least one of them in the past month.
Failure mode 1: Coaching when someone needs an answer.
An engineer comes to you and asks: “Should I use approach A or approach B for this migration?” They’ve thought about it. They have context. They’re not stuck because they lack critical thinking skills. They’re stuck because they lack a piece of information you have, or because they need someone with authority to make a call so the team can move forward.
And instead of answering, you say: “Well, what do you think? What are the tradeoffs of each approach?”
I’ve done this. It feels like good management. It feels like you’re developing their decision-making skills. But from the other side of the table, it often feels like something else entirely: Why won’t my manager just tell me what they think?
There’s a particular look people get when they’re being coached and they didn’t want to be coached. It’s subtle. A slight deflation, a beat of silence before they gamely try to answer your question. I’ve learned to watch for it. It means I’ve misread the situation.
Sometimes people need information. Sometimes they need a decision. Sometimes they need your opinion, not as a coaching prompt, but as actual input from someone they respect who has more context than they do. Responding to those moments with questions isn’t coaching. It’s withholding.
Failure mode 2: Coaching as avoidance.
This one is harder to see in yourself, because it feels so much like doing the right thing.
An engineer on your team is underperforming. Their code quality has dropped. They’re missing commitments. Other team members are starting to notice and compensate. You know you need to address it.
So you set up a 1:1. And you open with: “How do you feel things are going?” You ask about their goals. You ask what obstacles they’re facing. You ask what support they need from you. You’re coaching.
Except what you’re actually doing is hoping they’ll say the hard thing so you don’t have to.
I’ve evolved my thinking on this a lot over the years. I used to think coaching through performance issues was more respectful than direct feedback. I thought I was treating people like adults by letting them self-diagnose. What I eventually realized is that I was being a coward. I was using coaching as a way to avoid the discomfort of telling someone, clearly and directly, that their work wasn’t meeting the bar.
The engineer in that conversation often knows something is wrong, but they don’t know how wrong, because you haven’t told them. They walk out of a coaching conversation thinking it was a normal 1:1. They walk out of a direct conversation knowing exactly where they stand.
Which one is actually more respectful?
Failure mode 3: Coaching as status performance.
This is the subtlest one. It’s when managers adopt coaching behaviors because it signals a particular kind of leadership identity (thoughtful, empowering, modern) rather than because it’s what the situation calls for.
I’ve sat in skip-levels where an engineering manager spent 45 minutes asking me Socratic questions about a problem I’d already solved. They weren’t trying to help me think. They were performing the role of “leader who coaches.” The questions weren’t curious. They were procedural. They were going through the motions of a coaching framework they’d learned somewhere.
The tell is this: if your questions have predetermined right answers, you’re not coaching. You’re giving a quiz.
Your manager is not your coach
Here’s the thing nobody in the coaching literature wants to talk about: the relationship between a manager and their report is not a coaching relationship. It has a fundamental asymmetry that no amount of psychological safety can erase.
Your manager decides your compensation. They influence your promotion. They choose what projects you get. They can fire you. A real coach, an external coach, has none of that power. That’s what makes coaching work. You can be fully honest with a coach because there are no consequences to vulnerability. You can say “I have no idea what I’m doing” to a coach. Saying that to your manager carries risk, no matter how good your manager is.
I’m not saying managers shouldn’t use coaching techniques. They absolutely should. The question-asking, the active listening, the “keep the thought bubble over their head” approach: these are valuable skills. But we should be honest about what we’re doing. When a manager coaches a report, it’s management that borrows from coaching. It’s not coaching.
The distinction matters because when managers fully inhabit the “coach” identity, they sometimes abdicate the parts of management that coaching doesn’t cover. A coach doesn’t need to give you a performance rating. A coach doesn’t need to make a decision about headcount. A coach doesn’t need to tell you that your project is being cancelled. Those are management acts. They require directness, clarity, and the willingness to be the person with authority.
Some of the worst managers I’ve worked with were the most “coach-like.” They created an environment that felt warm and supportive and psychologically safe, but they never told you where you actually stood. They never made the hard calls. They facilitated endlessly. And their teams drifted.
When managing is the generous act
There’s a framing I keep coming back to: sometimes the most generous thing you can do is be direct.
I had a report once, a senior engineer, smart, capable, who was agonizing over whether to accept a tech lead role. They’d been going back and forth for weeks. In our 1:1s, I’d been coaching: asking about their fears, exploring what they wanted from their career, helping them think through the tradeoffs.
After the third conversation that covered the same ground, I stopped and said: “I think you should take it. You’re ready. The reason you’re hesitating isn’t that you don’t know the answer. It’s that the answer is scary. But you’re going to be good at this.”
They took the role. Months later, they told me that conversation was the most helpful one we’d ever had. Not the coaching. The moment I dropped the questions and just told them what I saw.
I think about this a lot. Coaching assumes that the person has the answer inside them and just needs help finding it. That’s often true. But sometimes people don’t have the answer. Sometimes they have the answer but need someone they trust to confirm it. Sometimes they need permission, or a push, or just the simple reassurance of someone with more experience saying “yes, this is the right call.”
Coaching helps people find their own path. Managing sometimes means pointing at the path and saying “that one, go.”
Neither is inherently better. The skill is reading which one the moment requires.
Engineers are not generic employees
Most of the coaching-vs-managing literature is written for a generic corporate context. It assumes a median employee in a median role at a median company. It doesn’t account for the specific culture and communication norms of engineering teams.
In my experience, engineers tend to value a few things that the coaching orthodoxy sometimes conflicts with:
Directness. Most engineers I’ve managed prefer clear, direct communication over Socratic dialogue. They want to know what you think. They want your opinion to be on the table alongside theirs, not hidden behind a series of questions. When I ask “what do you think?” an engineer will often answer, then immediately follow up with “but what do you think?” They want the exchange, not the facilitation.
Speed. Engineering work often has genuine time pressure. When there’s an incident, when a deadline is real, when a decision is blocking three other teams: that’s not the moment for coaching. That’s the moment for clarity. “Here’s what we’re doing. Here’s why. Let’s go.” You can debrief and coach after.
Technical respect. Engineers notice when you ask questions you could answer yourself. If you know the answer to a technical question and you withhold it to “let them discover it,” many engineers will read that as condescension, not empowerment. They’d rather you share what you know and have a real discussion about the tradeoffs.
Honesty about uncertainty. I’ve found that engineers respond well to “I don’t know, let’s figure it out together,” which is neither coaching nor directing, but collaborating. The coaching model doesn’t have a great mode for this. It assumes the manager is the facilitator, not a participant. But some of the best engineering conversations happen when the manager drops the facilitator role and just thinks alongside their team.
None of this means coaching doesn’t work with engineers. It does. But the vanilla coaching playbook (open-ended questions, reflective listening, GROW model) needs significant adaptation for an engineering context where people expect and respect directness.
A framework for reading the room
So how do you know when to coach and when to manage? I don’t have a perfect model, but I’ve developed some heuristics over the years.
Coach when:
- The person has the skills and context to solve the problem, but hasn’t connected the dots yet
- The goal is long-term development, not immediate output
- There’s genuine room for multiple good answers, and you want them to develop judgment
- The person is explicitly asking for help thinking through something (not asking for an answer)
- You honestly don’t know the best answer and believe they’re closer to it than you are
Direct when:
- The person is missing context or information that you have
- There’s time pressure and a decision needs to happen now
- The person has been going in circles and needs someone to break the loop
- You’re addressing a performance issue. Be clear, be specific, be kind, but be direct
- The person is new and needs orientation, not exploration
- There is a genuinely right answer and you know what it is
Collaborate when:
- Neither of you has the full picture
- The problem is genuinely novel and requires real-time thinking together
- You want to model how you reason through hard problems
- The person is senior enough that the manager-report dynamic matters less than the “two smart people working on a hard problem” dynamic
The mistake most managers make isn’t being in the wrong mode. It’s being in the same mode all the time. The manager who always coaches is as limited as the manager who always directs. Flexibility is the actual skill.
The coaching question you should ask yourself
If I had to distill this into one piece of advice, it would be this: before you coach, ask yourself why you’re coaching.
Is it because this is genuinely the best way to help this person, right now, with this specific problem? Or is it because coaching is your default, the mode that feels safe, the approach that makes you feel like the kind of manager you want to be?
If it’s the former, great. Coach away.
If it’s the latter, if you’re reaching for questions because making a statement feels risky, because you’re not sure of your own opinion and coaching lets you hide that, because directing feels “old school” and you’d rather be the cool, empowering manager: then you owe your report more than that.
I’ve been that manager. I’ve sat in 1:1s where I coached someone through a problem I could have just helped them solve in five minutes, because I thought coaching was always the right answer. I’ve watched people flounder while I asked open-ended questions, telling myself I was developing their skills when really I was avoiding the harder work of having a real opinion and sharing it.
The best managers I’ve worked for, the ones I learned the most from, weren’t the ones who coached me. They were the ones who saw me clearly and responded to what I actually needed. Sometimes that was a question. Sometimes it was an answer. Sometimes it was “I disagree, and here’s why.” Sometimes it was “I trust you, go do it.”
They weren’t performing a management style. They were paying attention.
Managing is not a dirty word
I think we’ve accidentally created a culture, especially in tech, where “managing” has become a slightly pejorative term. It implies control, bureaucracy, micromanagement. “Coaching” and “leading” are the aspirational words. Nobody puts “I’m a great manager” on their LinkedIn bio. They say “servant leader” or “people-first leader” or “I grow teams.”
But managing is the job. It includes coaching, sure. It also includes deciding. Prioritizing. Saying no. Giving feedback that makes people uncomfortable. Making calls that not everyone agrees with. Owning outcomes, not just facilitating processes.
The best engineering managers I’ve known weren’t the best coaches or the best directors. They were the most situationally aware. They could read a room, read a person, read a moment, and respond with whatever that situation actually needed. Sometimes it was a question. Sometimes it was an answer. Often it was something in between: sharing context, thinking aloud, being honest about uncertainty.
If you take one thing from this post, let it be this: your job isn’t to coach. Your job isn’t to manage. Your job is to help your team do their best work. Coaching is one tool for that. Managing is another. The fixation on one over the other is what gets people into trouble.
Pay attention to the person in front of you. Respond to what they need, not to what your management philosophy prescribes. That’s the whole thing.