Coaching as a practical leadership competence for building clarity, ownership, and growth.
Have you ever heard someone dismiss a conversation as “coaching talk”?
Or maybe you have done it yourself.
I understand the reaction.
The word coaching has been used in many ways. Sometimes to describe meaningful development work. Sometimes to describe vague motivation, empty questions, polished speeches, or people selling certainty without much depth.
Because of that, coaching can sound suspicious.
In software engineering environments, the skepticism can be even stronger. We tend to value clarity, evidence, problem-solving, and practical outcomes. When coaching sounds abstract, performative, or disconnected from real work, people naturally push back.
And they are not completely wrong.
Bad coaching exists.
Superficial coaching exists.
Theater disguised as people development exists.
But dismissing coaching because of bad examples is like dismissing engineering because of bad code.
The problem is not the discipline.
It is poor practice.
Why coaching became suspicious
Coaching loses credibility when it becomes performance.
Questions without clarity.
Encouragement without substance.
Reflection without action.
Challenge without compassion.
Positive language without accountability.
People also react badly to coaching when it is used in the wrong moment.
If production is unstable, priorities are unclear, or a delivery risk is growing, people usually do not need vague inspiration. They need context, decisions, direction, and honest conversations.
If a developer is blocked because the expected outcome is unclear, asking “What do you think you should do?” may not be coaching. It may just be unhelpful.
Maybe the technical direction is missing.
Maybe the person lacks context.
Maybe the decision is above their current scope.
Maybe the leader is avoiding responsibility.
Real coaching does not replace leadership responsibility. It supports it.
That distinction matters.
Coaching is not every form of help
One reason coaching is misunderstood is that it sits close to other forms of support.
Mentoring is different. A mentor shares experience, perspective, examples, and lessons learned.
Training is different. A trainer teaches a specific concept, tool, process, or technique.
Counseling is different. It belongs in a deeper emotional or therapeutic space and requires different preparation.
Direct help is different. Sometimes a blocker needs to be removed, a decision needs to be made, or a solution needs to be explained.
Coaching helps someone think more clearly, explore options, make decisions, take ownership, and learn from the process.
In a formal coaching process, the coach is not there to give ready-made answers. The work is to use meaningful questions, reflection, and challenge to help the coachee find their own path.
In leadership, the reality is more contextual. The same conversation may require coaching, mentoring, feedback, or clear direction depending on the person, the situation, and the risk involved.
That is why coaching cannot be reduced to a script. The value is not in the question itself, but in whether the question serves the person, the context, and the moment.
The coach does not need to be the expert in the other person’s field
Another misconception is that a coach must have personally achieved the exact outcome the other person wants.
I understand where this comes from.
If you need mentoring, you probably want someone who has walked a similar path. If you need training, you need someone who understands the subject. If you need technical guidance, expertise matters.
But coaching serves a different purpose.
I experienced this clearly when I applied a structured coaching process with someone starting a career path in biomedicine.
I have no expertise in biomedicine. That was exactly what made the distinction clear.
My role was not to teach the field, give technical advice, or pretend to know the profession. The value of the process was helping the person clarify direction, understand choices, build confidence, define next steps, and take responsibility for the path ahead.
A mentor may need to know the road.
A trainer may need to teach the method.
A coach helps the person create movement with more clarity.
The same applies in engineering leadership. The leader does not always need to be the person with the answer. Sometimes the leader’s contribution is helping someone build better judgment.
Coaching in engineering leadership
In engineering teams, coaching often appears in ordinary moments.
A developer keeps asking for validation before making technical decisions.
A senior engineer is frustrated because others do not follow their standards.
A team member wants to grow but cannot explain what growth would look like.
Someone receives feedback and immediately defends their intention instead of understanding the impact.
A discussion keeps circling because nobody is naming the actual trade-off.
These are not abstract leadership situations. They happen in real teams, around real work. And in those moments, giving the answer may solve the immediate problem, but it may not develop the person.
That does not mean the leader should never give answers. Direct guidance is sometimes the right thing to do: when the situation is urgent, the person lacks context, or the risk is too high.
But when the situation allows it, coaching creates a different kind of progress. It helps people improve the way they see, think, decide, and act.
What real coaching helps build
At its best, coaching creates at least three forms of movement.
First, clarity.
Many problems feel bigger because they are unclear. A good coaching conversation helps someone separate facts from assumptions, identify the real decision, understand trade-offs, and define what success looks like.
This matters in software engineering because complexity is not only technical. It is also human, organizational, and contextual.
A production issue may reveal a monitoring gap.
A delayed delivery may reveal unclear ownership.
A quality problem may reveal misaligned standards.
A conflict may reveal expectations that were never made explicit.
Coaching helps people slow down enough to understand what they are really dealing with. Not as an excuse for inaction, but as a way to avoid solving the wrong problem with confidence.
Second, ownership.
Ownership does not grow when people are only told what to do. It grows when people understand context, participate in the reasoning, make decisions, and learn from the consequences.
This is especially important for engineers moving beyond task execution. At some point, growth requires more than technical delivery. It requires judgment, communication, understanding impact, and the ability to navigate ambiguity without waiting for every step to be defined.
A leader might ask:
“What options do you see?”
“What risk are you trying to reduce?”
“What would you recommend if you had to decide today?”
“What support do you need to move this forward?”
“What will you do differently next time?”
These questions are not theater when they are connected to real decisions. They help the person move from passive execution to active ownership.
Third, growth.
Advice can be useful. Mentoring can be powerful. Training can accelerate learning. But growth also requires internal movement.
The person needs to notice patterns, challenge assumptions, test new behaviors, and take responsibility for change.
That is where coaching helps.
Not by giving people artificial confidence, but by helping them build confidence through clarity, action, and reflection.
Coaching requires standards
If coaching is treated as performance, it becomes noise. If it is treated as a serious leadership competence, it requires standards.
It requires listening, but not passive listening.
Questions, but not random questions.
Empathy, but not avoidance.
Challenge, but not ego.
Patience, but not lack of accountability.
Good coaching is contextual.
The same question can be helpful in one situation and useless in another. The same person may need coaching today, mentoring tomorrow, and direct feedback next week.
A leader needs to understand the person, the context, the level of autonomy, the urgency of the situation, and the impact of getting it wrong.
This is where coaching becomes practical leadership work: a competence that helps people grow without disconnecting development from reality.
Coaching without the theater
One subtle danger in coaching is turning the leader into the center of the process.
The leader with the perfect question.
The leader with the calm voice.
The leader who “unlocks” everyone.
That can become its own kind of theater.
Real coaching is not about the leader looking wise. It is about the other person leaving the conversation with more clarity, more responsibility, and a better next step.
Sometimes that happens through a powerful question.
Sometimes through silence.
Sometimes through direct feedback.
Sometimes through saying, “In this situation, I think you need more direction, so let me be clear.”
The goal is not to perform coaching. The goal is to develop people.
At its best, coaching helps people contribute at a higher level. Not by becoming dependent on a leader, repeating someone else’s answers, or waiting for permission all the time, but by developing their own judgment.
For engineering teams, this matters deeply.
Teams grow when knowledge spreads.
Teams move faster when decisions do not depend on one person.
Teams become stronger when people can think beyond their own tasks.
Teams become healthier when accountability and support exist together.
That is why coaching, when done properly, is not just “coaching talk.”
It is part of building teams where people grow and contribute with more clarity, ownership, and intention.
And maybe that is the real test.
Not whether the conversation sounds like coaching.
Whether the person leaves with more clarity, more ownership, and a better next step.
That is coaching without the theater.