The freeze looks clean on paper. Headcount flat, budget protected, no awkward requisitions to defend in the quarterly review. What the paper doesn’t show is the shape of what’s left.

Last quarter, one of my squads had quietly become a squad of seniors. Not by design — by attrition and selective hiring. Every backfill over two years went to “we need someone who can hit the ground running,” which always means senior. A junior left and wasn’t replaced. The result was a team where everyone was three or four years in, everyone was good, and nobody was junior.

Then one of them told me, in effect, that he couldn’t see why all the interesting problems kept landing on the same two desks. The answer was uncomfortable: there was no one to hand the boring work to. The toil that a junior would normally absorb — the manual verification, the flaky local setups, the cross-checking before a release — was being done by people who were hired to do hard things. They were doing it anyway, between the hard things, and it was wearing them down.

That’s the first failure mode of a senior-only team: toil compression. The grunt work doesn’t disappear when the juniors do. It gets absorbed by people who experience it as a demotion. Engagement drops. And a disengaged senior is not a quiet problem — it’s a flight risk wearing a calm face.

The second failure mode is no succession ladder. On a balanced team, when a senior leaves, there’s a mid-level engineer who’s been shadowing the hard parts and can step up. On a senior-only team, when a senior leaves, the replacement is a hire — a three-month search, a three-month ramp, in a market where senior supply is thin. You don’t lose one person. You lose a capability with no one shaped to inherit it.

The third is status friction. When everyone is senior, everyone wants the meaty work, and there isn’t enough meaty work to go around. The political cost of allocating it rises. You start spending management energy refereeing who gets the interesting problem — energy that, on a mixed team, the seniority gradient handles for you.

Here’s the math leadership doesn’t model. If one senior of, say, six leaves in a year, that’s a sixteen percent capacity hit landing in a single event — and a capability gap with no internal successor. On a team with a healthy junior layer, the same departure is closer to an eight percent hit, cushioned, with someone already half-shaped to fill it. The freeze that “saved” a junior salary bought you a fragile team that breaks loudly the first time someone resigns.

And in Malaysia, the fragility runs deeper than the org chart suggests.

In SEA, juniors are the export market. The strongest KL juniors don’t stay junior — they get pulled to Singapore, to remote-Australia and remote-US contracts, at two to three times the local salary. “We’ll hire seniors only” is a strategy that works in markets where senior supply is deep and replaceable. In KL it’s the opposite: senior supply is thin, and the junior pipeline is leaking out of the country before it ever matures into senior supply. Both pumps are off. You’re not running a freeze. You’re running an aquifer dry and assuming it refills.

So the senior who looks settled — three years in, owns the gnarliest system, never complains — is one recruiter message away from a relocation conversation. Loyalty is real, but it isn’t an asset class you can put on a forecast. The math doesn’t care how settled he looks.

Which is why the cheapest hire on the spreadsheet is rarely the cheapest hire in practice. Finance reads the senior as more expensive per head and stops there. But an intern plus one junior, taking the toil off four seniors who are quietly running hot, is cheaper than the fifty-percent productivity tax of senior toil compression — and far cheaper than the one departure it prevents.

Here’s the thing to do Monday: model your team’s “if one senior leaves” scenario explicitly. Name the person who’d backfill them, and if the answer is “we’d open a req,” that’s your flight-risk exposure in one sentence. Bring that sentence to the table when you negotiate hiring slots. Don’t argue for headcount. Argue for distribution.

The cheapest hire isn’t always the senior who can hit the ground running. Sometimes it’s the junior who lets the seniors stop running so hard.

Early this year I sat in a 1:1 with an engineering lead whose work runs across both markets. We were unpacking the aftermath of a compliance-driven re-verification exercise: a slice of the customer base needed their records re-checked, against a deadline, in two countries at once.

The Singapore half barely registered as engineering work. The flow pulls government-verified identity data through an API, runs the checks, approves. A customer who responds gets cleared in minutes, untouched by human hands. Then he got to the Malaysian half and his voice changed. “For Singapore, we can automate this end to end,” he told me, in effect. “For Malaysia, we can’t.” The same flow, for the same company, dead-ends into a document upload, a manual review, and a queue that an operations team works through by hand while the deadline doesn’t move.

He wasn’t complaining. The infrastructure just doesn’t exist yet — and that fact had been missing from every estimate we’d made about that rollout.

The regional fallacy

There’s a sentence that shows up in roadmap discussions at every company that operates across Southeast Asia: “It works in Singapore — we’ll just turn it on for Malaysia.”

That sentence is a smoke alarm.

Here’s what “turning it on” actually meant for the flow above, and for most flows I’ve watched cross that border: a separate compliance interpretation, because the two regulators read the same risk differently. A different set of acceptable documents, because the national identity ecosystems aren’t equivalent. A different bank-rail integration, because money moves on different pipes here. A different operational fallback, because when automation isn’t possible, a human queue has to exist, be staffed, and be monitored. Different timing assumptions, because a step that’s instant in one market takes days in the other.

None of that is visible in the codebase. The codebase looks 80% shared. That’s what makes the estimate wrong: teams scope the Malaysian rollout as the remaining 20%, and it lands at 60-80% of the original build — sometimes more, because the manual-fallback machinery (admin tooling, queue visibility, ops reporting) is work the Singapore version never needed at all.

The cost isn’t only engineering hours. It’s that the gap gets discovered mid-rollout instead of at scoping. The Singapore launch announces itself as a regional win, the roadmap moves on, and the Malaysian half quietly becomes an ops burden that engineering “will automate later.” Later meets the next roadmap cycle and loses.

And it compounds. Re-verification this quarter, a deposit flow next quarter, an account-maintenance flow after that — every flow that touches identity, money movement, or documents replays the same split. Engineers who have crossed the border once start padding estimates on instinct. The roadmap never learns, because the padding is invisible and the assumption keeps getting written down as “regional”.

Why Malaysia specifically

This isn’t Malaysia being difficult. It’s an infrastructure asymmetry with a date on it.

Singapore has had Singpass and MyInfo for the better part of a decade: government-verified identity data, exposed through APIs, that the regulator explicitly accepts as a reliable source for customer verification. When the government runs the identity rail and the regulator recognizes it, “automate the KYC step” is an integration project. Engineering can build on it the way they build on a payments API.

Malaysia is building the equivalent — MyDigital ID verifies directly against the national registry, registrations crossed ten million in early 2026, and banks have been testing integration readiness in a sandbox. But “in a sandbox in 2026” versus “regulator-recognized API for most of a decade” is the whole story. The rail engineering wants to build on doesn’t exist yet at integration grade. So the same product requirement — verify this customer — resolves to an API call on one side of the causeway and a staffed queue on the other.

And identity is just the visible example. Run the same comparison across payment rails, data-residency rules, document standards, and licensing, and the pattern holds: what product sees as one market, compliance and operations experience as six. Founders who’ve built across Southeast Asia describe needing not a licence but a list of licences. Every fintech operating regionally rediscovers this; most rediscover it after the estimate is committed.

There’s a second-order cost that lands specifically on the Malaysian side of the org chart. When the automatable version ships in Singapore and the manual version ships in Malaysia, the KL team inherits the remainder: the admin tooling, the queue dashboards, the weekly check-ins with an ops team under deadline pressure. That work is real, hard, and customer-protecting — and it photographs terribly. The engineer who integrated the identity API gets a demo at the all-hands. The engineer who built the manual-review queue gets a support rotation. A few cycles of that and your regional teams learn what kind of work gets noticed — and it isn’t theirs.

Here’s the part I care about as a KL-based engineering manager: the engineers in Kuala Lumpur already know all of this. They’re the ones who built the manual queue. They’re the ones who sit closest to the ops team working through it. The knowledge gap isn’t in the region — it’s at headquarters, where a product org anchored in the most automatable market in Southeast Asia keeps writing “regional” on a one-line roadmap item. The bug is at headquarters. The technical work is only the symptom.

What an EM should do with this

The leverage point isn’t technical. It’s the moment a regional feature gets scoped, before any estimate enters the roadmap.

My rule now: when a rollout is described as regional, I make the per-country fan-out cost visible before engineering commits a number. Not a disclaimer — a table. For each market: can this step be automated today, what rail does it depend on, what’s the manual fallback if it can’t, and who staffs it. For the re-verification flow, the Singapore row read identity API, automated, no fallback needed. The Malaysia row read document upload, manual review, ops queue, needs admin tooling that doesn’t exist yet. Same feature. Two different projects. Five minutes per country, and “we’ll just turn it on for Malaysia” stops being an assumption and becomes a line item someone has to defend.

Which leads to the take I’ll defend: “regional” features should be scoped per-country from day one, even when the build is shared. If the scoping doc has one row for a six-country rollout, the doc is lying to you. Six countries, six rows — even if four of them say “same as SG, verified.” The point isn’t paperwork. The point is forcing the verification, because the rows that say “same as SG” without verification are where the next quarter’s surprise lives. Yes, this makes scoping slower. Scoping is the cheapest place to be slow.

The transferable version, for anyone running engineering across this region: a shared codebase is not a shared product. Code crosses borders for free. Compliance, identity rails, bank integrations, and operations queues do not. Estimate the second list, not the first.

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.