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?

1. 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.

2. 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.

3. 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.

“I feel like a reviewer now. Not a builder.”

A senior engineer told me that in a 1:1 a few months ago. And I haven’t stopped thinking about it.

The AI coding assistant had been doing most of the implementation: first-pass logic, boilerplate, initial test stubs. Her job had shifted. Read what it produced. Catch what it missed. Push it across the finish line. Ticket throughput was up. She was closing more work in a week than she had in a month before.

She wasn’t sure whether this was good. I wasn’t sure either.

Here’s the pattern I keep seeing across my team. Call it the 80% Problem. AI gets an engineer to something that looks 80% done in a fraction of the time it used to take. The last 20% takes about as long as it always has. The edge cases. The design decisions that don’t have a clean precedent. The debugging that needs you to actually understand what the code is doing.

So net throughput goes up. Metrics look great. PR count climbs. Jira burns down faster. If you’re watching the dashboard, everything is working.

But there’s a second number nobody’s tracking. Call it craft growth rate. The judgment you only build by struggling through the hard part yourself. By getting it wrong three times before you understand why the fourth attempt works.

That number is going in the other direction.

When the AI generates the skeleton and the engineer’s job becomes review and correction, the engineer is doing less of the work that builds judgment. They’re checking a machine’s decisions, not making their own. Getting faster at verifying. Not getting faster at inventing.

I use AI tools. My team uses AI tools. This isn’t about whether to use them. It’s about what’s happening to the engineers using them, below the PR count.

In SEA, this pattern has a particular edge to it.

The junior pipeline here is thin. Senior engineers in KL and Jakarta are one LinkedIn message away from a Singapore bank offer, an Australian remote role, a US company paying in dollars. The attrition math is harder before you even add AI to the equation.

The traditional response is to grow your own — hire juniors early, build the mid-level bench yourself over two to three years. But that model depends on juniors doing the hard work that builds judgment. A junior who spends their first two years reviewing AI output instead of building things from scratch is not getting the apprenticeship they need to become the mid-level engineer who stays in year three. They’re getting faster at closing tickets. They’re not learning to carry the last 20%.

Eventually they hit a problem the AI can’t scaffold. A gnarly distributed systems edge case. A product decision with no precedent. A codebase with enough entropy that the AI just hallucinates. They won’t have the reps to push through. In the US or Europe, you hire senior talent from a deeper pool when that gap surfaces. In KL, you’re often waiting eighteen months for the right candidate.

The 80% Problem shows up differently depending on how the engineer is oriented to the tool. I’ve had engineers push back on the AI-first workflow entirely. I’ve learned to read that resistance differently than I used to.

They’re not refusing the tool. They’re refusing to ship code they don’t understand. “I need to know why it works. If I didn’t write it, I’m not sure I do.” They’ll use AI for research, for understanding a library, for testing edge cases. They won’t let it author the implementation and hand them the result.

I used to frame this as friction. Now I frame it as signal about what kind of engineer they’re trying to remain.

On a velocity dashboard, the engineer who leans heavily into AI generation looks faster. The engineer who insists on writing the core themselves looks slower. Neither metric tells you what’s actually accumulating in each of them.

Which means the dashboard is asking the wrong question.

So what’s the EM job here?

I don’t think it’s to impose AI-off days or restrict tool usage. Engineers will — correctly — ignore it.

I think the EM job is to make the distinction visible.

The 80% Problem isn’t that AI does 80% of the work. It’s that the 80% it does is exactly the part that used to build the engineer. AI accelerates getting things done. Whether it accelerates becoming someone who can do things depends entirely on how the engineer is using it.

In 1:1s, the question I’ve started asking is: “What did you write without AI this week?” Not as a gotcha. Not as surveillance. It’s craft growth rate made legible — a way to see whether an engineer is using AI as a tool that extends their capacity, or as a shortcut that’s quietly offloading the work that would otherwise build it.

The answers are telling. Engineers who are growing tend to have a clear answer. They can point to a decision they made, a problem they debugged, a design choice they argued for. Engineers who are drifting toward pure review-and-correct often can’t.

That’s the signal I’m trying to catch early.

The uncomfortable claim underneath all of this: forcing AI-off constraints for junior engineers is not gatekeeping. It’s apprenticeship.

Not as a punishment. Not as skepticism about AI. As a deliberate pedagogical structure — the same reason you don’t let an intern spend their whole rotation summarizing PowerPoints. The constraint is the learning.

A junior who writes 200 lines of working code they fully understand is building something the AI can’t give them. A junior who shepherds 800 lines of AI-generated code through review is closing tickets faster, but the judgment isn’t accumulating at the same rate.

That doesn’t mean AI tools are off the table for juniors. It means the EM has to be intentional about which problems juniors own end-to-end. Where the constraint lives. What the AI augments versus what it replaces.

The dashboard doesn’t tell you this. The 1:1 might.

The senior engineer who said she felt like a reviewer rather than a builder wasn’t asking me to fix anything. She was doing what good engineers do: naming a pattern she’d noticed in herself before it became a problem. Not every engineer has that self-awareness — especially juniors who don’t know what they’re not building yet.

The EM’s job is to hold that awareness on their behalf.

The PR count is real. The engineer underneath it is the thing you’re actually managing.

Earlier this year my boss asked me, mid-week, to weigh in on a decision that had nothing to do with code.

Not a product call. A question with legal weight attached. The kind where the right answer depends on context that most engineering management writing doesn’t account for.

I went looking for writing on how engineering managers handle this kind of decision. There isn’t any.

There is a whole canon of engineering management writing. It assumes your hardest Wednesday problem is a reorg or a missed sprint. Mine wasn’t.

Most engineering management writing assumes a context that doesn’t exist here.

Most of my problems do.

That canon assumes at-will employment, deep talent pools, no resident-director rule, no foreign-currency salary anchoring, no second passport quietly draining your senior bench every quarter toward Singapore or Australia. Those assumptions hold for the people writing. They don’t hold for me, and they don’t hold for the engineers I manage.

When the assumptions don’t translate, the advice doesn’t either. You can read a thousand words on ownership in critical situations and still not know what to do when the critical situation involves a regulator’s portal, a corporate secretary in another office, and a 72-hour window. The frameworks aren’t wrong. They’re out of frame.

So I’m going to write from inside the frame.

This series will be specific. Composite characters, blurred dates, names changed — but the moments are real ones from the chair. A senior engineer testing whether AI-assisted output survives code review. A skip-report whose growth arc nobody documented until it was almost too late. A hiring freeze whose math only makes sense once you know what the ringgit is doing against the dollar that month.

What I won’t write: five-bullet productivity lists, AI-hype takes you’ve read already, frameworks dressed up as insight. There is enough of that on this platform.

What I will write: roughly one piece a week on Substack, with names and details changed, because the people I write about deserve that much.

I’m not writing to teach. I’m writing to think, in public, in the hope that a few other EMs in Kuala Lumpur, Jakarta, Manila, Ho Chi Minh, and the rest of the region will recognise the shape of these problems and push back.

If the lens is useful, follow. The next one is about what happens when an engineer’s output doubles on paper and the review queue tells a different story.

Same chair, same frame, same week.