Coaching vs Covering
I used to think every time I picked up a task my report had dropped, I was failing as a manager. Took me three years to see I had it backwards.
It started with a design document that wasn’t moving.
A KL tech lead had handed a workstream to one of their engineers three weeks earlier. Clear enough brief, reasonable timeline. Then: silence. No draft, no questions, no blockers surfaced. When the lead finally checked in, the engineer had a half-formed doc, no real thinking in it yet.
The lead’s reflex was instant: I’ll write the first draft. That’ll unblock them. We’ll talk through it together.
And they did. And it worked — if by “worked” you mean the document got done and the sprint didn’t slip.
What didn’t work was everything that came after.
What the lead did has a name — covering. From the outside it looks almost identical to coaching. The difference is whose hands are on the keyboard.
A useful frame: think of your reports as having a growth account. Every time you let them struggle through something hard and come out the other side, the balance goes up. Every time you take the problem off their hands, the balance goes down.
Covering feels like a deposit. You helped, you were generous, the team didn’t suffer. But the report’s growth account is lower than it was before, and you’ve made yourself more indispensable to the next hard problem.
The diagnostic question I started asking myself: Whose growth account am I drawing from?
When I pick up the task — am I doing it because I can’t tolerate the uncertainty, the slowness, the imperfect output? Or because my report genuinely can’t proceed without me?
Most of the time, if I’m honest, it was the first one.
The pattern shows up differently depending on the seniority of the report.
With junior engineers, covering is obvious. You write the ADR. You fix the approach. You clean up the PR. The junior watches the diff land with a thank-you emoji and learns something — but mostly learns that hard things get rescued. Everyone knows it happened; no one quite names it.
With senior engineers, it goes underground. A TL who “provides input and guidance” on every major design decision isn’t enabling their report — they’re providing a service. The senior engineer learns to wait for the input. The manager learns to expect to provide it. Neither side notices the dependency hardening.
The subtler version: the engineer who stops driving their own ideas. They surface them, hand them off, wait. They’ve learned that ideas need a champion above them to go anywhere. The EM had been providing that function for long enough that the engineer stopped reaching for ownership. It doesn’t look like a problem — the ideas are still flowing, the work is still moving. What’s disappeared is the engineer’s belief that the initiative is theirs to hold.
I’ve seen this from both seats. As the manager providing input, I felt productive — I was adding value, the work was better, my report was happy. It took a while to notice that my report was happy because I was doing the hard part.
As the engineer on the receiving end, years earlier, I remember the relief of a senior who’d “just take a look” at my drafts and return them sharper than I could have made them. I thought I was being mentored. I was being covered for. The clue was that I couldn’t tell you, afterwards, what I’d actually learned — only that the work had shipped.
There’s a Malaysia-specific pressure here worth naming.
In a lot of KL engineering teams, the senior-to-junior ratio skews heavily senior. Hiring pipelines are slow, junior talent needs heavy ramp, and the path of least resistance is always the senior picking up the task. They’re faster, the quality is better, the deadline doesn’t slip.
The math feels fine until you look at it three cycles later. Senior-heavy teams that cover instead of coach don’t stay senior-heavy. They become seniors-who-do-everything, with no bench to absorb growth or absorb departures. The hiring problem doesn’t go away. It gets worse, because now the team can’t function unless the same four people are always available.
It shows up most visibly during incidents. If only two or three engineers have enough context to respond to production issues, that’s a coverage problem. It got baked in over many sprints, one rescue at a time. The team didn’t fail to grow. They were never given the surface area to grow into.
Covering is individually rational and collectively destructive.
Which is almost a definition of a structural problem.
So what does coaching actually look like in practice, when the reflex is to cover?
Name the call out loud, in the moment. “I could write this first draft. I’m not going to. Here’s what I want you to try instead.” That sentence is uncomfortable. Saying it means accepting that the document will probably be worse, the sprint might slip, the report might be frustrated. It also means the report will have written a hard document — not watched you write one.
Set a structured checkpoint, not an open-ended offer of help. “Send me what you have by Thursday” is a coaching move. “Let me know if you need anything” is a covering move wearing coaching clothes.
Sometimes let the work be late. Not deliberately, not carelessly. But if the choice is between late work the report learned from versus on-time work the manager rescued, late is often the better trade. The sprint metric looks worse. The growth account looks better.
A report who can’t deliver something in two sprints isn’t ready to deliver it in one. That’s data about the gap, not a verdict on their potential. The EM’s job is to name the gap clearly and help build the bridge. Not to become the bridge.
There’s one more thing covering does that’s easy to miss: it teaches reports to hide difficulty.
When a manager consistently rescues struggling work, the report learns that incomplete output is a problem to solve before the 1:1, not a thing to surface during it. The tell: the engineer who only ever brings finished work to your one-on-ones. No half-formed designs, no “I’m stuck on this,” no thinking-out-loud. Just polished updates. Looks like a high performer. Often it’s a high performer who has learned that polish is the price of admission.
Over time, the engineer who never brings half-formed things is performing confidence, not feeling it. The gap is still there. It just went underground. By the time it surfaces, it’s usually a resignation nobody saw coming, or a project that looked healthy in status updates right up until it stalled.
Coaching requires creating safety for the mess to be visible. “Send me what you have Thursday” isn’t just a deadline. It’s a signal that rough drafts are allowed, that struggle is something to name out loud instead of hide. The first time a report sends you something genuinely unfinished and you respond with questions rather than rescue, you’re teaching them the actual rules of the room. That’s the part that doesn’t show up in the framework.
The last thing I’ll say: coaching over covering isn’t about being hands-off. The managers I’ve seen do this well are intensely involved. They ask harder questions, they’re more calibrated about where the report actually is, they’re more explicit about expectations. The difference is they add challenge instead of taking it away.
There’s a version of this that becomes a rationalization for neglect: “I’m coaching, not covering” as a reason to not follow up, not look at the work, not give the hard feedback. That’s not coaching. That’s walking away with a good name.
The real version asks more of you, not less. It just puts the demand in the right place.
This week, pick one task you’re about to pick up on a report’s behalf. Before you touch it, ask: whose growth account is this withdrawal from? If the answer is yours, write the draft. If the answer is theirs, write the checkpoint instead.