Sit in on a hundred one-to-ones between engineering managers and their engineers, and roughly ninety of them sound the same.
"How's the ticket going?"
"Fine. Blocked on the API team, should clear Thursday."
"Great. Anything else?"
"Nope."
Twenty-two minutes back in the calendar and a mutual sense of a job done. What happened there was a status meeting with a nicer name. Your ticket board already told you everything in it.
Ask an engineering manager why coaching never shows up in those twenty-two minutes and you get one of three answers. Coaching is soft. Coaching is slow. Coaching is expensive. All three are wrong, and each one is wrong in a way the evidence settles.
Myth one: coaching is soft
This is the one I hear most from technical leaders, usually with a shrug. Real work is shipping. Coaching is the fluffy bit for people who like feelings.
Google ran the numbers on their own managers under Project Oxygen. They tried to prove managers had little effect and failed. The behaviors separating high-scoring managers from low-scoring ones came out as a list of ten, and the first one on it is "be a good coach". Teams under effective managers reported better results, more satisfaction and lower turnover.
Gallup put a number on the same effect from the other direction. Their State of the American Manager research found managers account for at least 70% of the variance in team engagement scores across business units. Not comp. Not the mission statement. Not the snack wall. The person running the one-to-one.
And for anyone who wants delivery metrics rather than people metrics, DORA has been measuring this for years. Their work on transformational leadership found teams with the weakest leadership behaviors were half as likely to reach high software delivery performance. Leaders shape delivery indirectly, by making it possible for teams to adopt better technical practices. Supportive leadership and intellectual stimulation sit inside their five dimensions. Both are coaching behaviors wearing an academic suit.
Soft skills with hard consequences. Deploy frequency and lead time are downstream of whether your engineers think out loud in front of you.
Myth two: coaching is slow
The second objection sounds practical. We have a release. Talk to me about coaching in Q3.
The best evidence here comes from a meta-analysis by Jones, Woods and Guillaume, published in the Journal of Occupational and Organizational Psychology in 2016. They pooled 17 studies of workplace coaching and found positive effects on organizational outcomes overall, with a delta of 0.36, rising to 0.51 on affective outcomes and 1.24 on individual-level results.
Then the part nobody quotes. They tested whether the number of sessions or the length of the program moved the effect size. It did not. Duration showed no moderation of the outcome. Format made no difference either, face to face or blended with remote sessions.
Read this as an engineer would. The dose-response curve is flat. A six-month program is no better supported by the data than a short series of focused conversations. Which means the version fitting inside your existing one-to-one is the version with evidence behind it.
You already own the time. You spend it asking about tickets.
Myth three: coaching is expensive
Now the finance objection. External coaches run hundreds per hour, so coaching is a perk for directors and above.
The same meta-analysis tested coach type as a moderator, and the effect was stronger for internal coaches than for external ones. Read it again. The cheap option outperformed the expensive one.
I have a theory about why, drawn from watching both kinds work in engineering orgs. An external coach arrives with better technique and no context. They have no idea your platform team owns four services nobody wants, or your principal engineer holds a grudge from a 2023 architecture review. An internal coach starts with the map. Technique matters less than knowing the terrain.
Your engineering managers are sitting on the map right now. Nobody has told them their job includes using it.
What coaching looks like in engineering terms
Here is the reframe landing best with technical leaders.
You are not doing therapy. You are debugging a model.
When an engineer brings you a problem, they arrive with a mental model of the system, the constraints and their own options. Some part of the model is wrong or incomplete. Hand them your answer and you patch one symptom while leaving their model untouched, guaranteeing the same conversation next sprint. Ask them to walk the model out loud and the broken assumption surfaces, usually to them before you.
It is rubber duck debugging with a duck who asks follow-up questions.
Three of them do most of the work:
"What have you tried?" Reveals whether the problem is knowledge, permission or fear.
"What would you do if I were out for two weeks?" Nine times in ten they already have the answer and want cover for it. What they need from you is authorization, not analysis.
"What has to be true for this to work?" Turns a vague plan into a testable list.
None of these take longer than telling them what to do. All of them leave the engineer able to run the next one without you.
Why your managers resist
Coaching is uncomfortable for a specific reason in our industry, and pretending otherwise wastes everyone's time.
We promote engineers for having answers. Ten years of being the person who knows why the build broke at 2am builds an identity around instant, correct responses. Then we hand them a team and ask them to sit on the answer while somebody slower works toward it. Silence feels like failure. Saying "what do you think?" feels like a dodge.
I wrote before about how only amateurs think leadership is about having the answers, and this is where the cost shows up. A manager solving every problem builds a team unable to move without them, then wonders why the on-call rotation always routes back to their phone.
The stakes are higher than delivery speed. My own survey research found 99.5% of respondents have had one or more types of bad boss. Nearly everyone. Most of those bosses were not cruel. They were absent in the specific way a manager is absent when the one-to-one is a status report, and the engineer spends two years never once being asked a question worth thinking about.
Try it in the next one-to-one
Do not build a program. Do not book training. Take your next one-to-one and set one rule: for the first ten minutes, give no answers. Ask questions only.
It will feel awkward and slow, and you will want to jump in around minute three. Sit on your hands. Notice how much your engineer works out on their own once nobody fills the silence for them.
If you spot anything useful, run it again next week. One rule, ten minutes, and the evidence says a short focused version works as well as the expensive one.
So look at your calendar for tomorrow. Those one-to-ones are already booked and already paid for. What are you spending them on?