🐯 Crouching Tiger, Hidden Debt

A tiger team isn't a staffing choice. It's an escape hatch.

It's how leadership pursues something without doing the two things that make a project real: naming an owner, and giving it a manager whose entire job is making the thing good. You get the urgency-branding — tiger team, sounds like Delta Force — without the admin of actually committing. No headline in the org chart. No line item anyone has to defend in a planning review. Just a rotating cast of borrowed people, doing someone else's job on top of their real one, for as long as leadership can avoid saying this matters enough to own properly.

Here's the thing about avoiding a decision: the bill doesn't disappear. It just moves to whoever's closest to the fire.

🐯 What a Tiger Team Actually Is

A tiger team is urgency without accountability — a group assembled to look like commitment while structurally avoiding it.

In engineering terms: it's a project running with all the authority of a real initiative and none of the ownership.

What it looks like

• 🎯 Assembled fast, around a specific fire, with an implicit "temporary" attached
• 🔄 Staffed by borrowing people from teams that already have full plates
• 📋 No dedicated manager — someone senior enough to sponsor it, not someone whose job it is
• 🚪 No stated exit condition beyond "until it's handled"

The upside

It moves fast. No committee, no headcount request, no quarter-long planning cycle before work starts. For an actual emergency — a real fire, with a real end date — that's exactly the right shape.

The danger

The shape that makes it fast is the same shape that makes it permanent by accident. Nothing about "temporary and borrowed" naturally converts into "owned and staffed." So it doesn't. It just keeps running, indefinitely, on borrowed time that was never actually borrowed — because nobody ever gave it back.

🔥 What Ours Is Actually Eating

A month of our tiger team's Slack channel tells you exactly what "temporary and unowned" costs in production.

What it looks like

• 🔐 A permission gate that 403'd before it evaluated the actual request — a deliberate anti-privilege-escalation check that worked exactly as designed, except for the one case nobody designed for: removing access you'd already lost. You couldn't fix it, because fixing it required re-proving access to the thing you were trying to remove. A catch-22, shipped as hardening.
• 🧨 A merge toggle labeled "automatically merge when approved" that actually meant don't wait for approval at all. Code went straight to merged, zero review, because of what a settings page called it.
• 🔁 The same GitHub rate-limit failure, recurring across multiple tickets, months after it was first diagnosed — because the fix proposed the first time never got implemented. Nobody owned making sure it did.

The reality drift

None of these are user error. None of them are a "power user" problem. They're what happens when a platform this consequential doesn't have anyone whose job is this platform, full stop. A catch-22 in your auth flow isn't a bug when nobody owns the auth flow. It's a symptom.

🧑‍🚒 The Bill Comes Due — And They Pick Who Pays

Here's the cost that never shows up in a channel summary: someone has to be assigned to answer these threads. On our team, that someone was our most junior person.

I want to be precise about what that means, because it's not what people assume. She's not green. Three years in, independent, a notch below senior — this is just her first job out of college, on a team where everyone else has six-plus years. "Most junior" here means most junior relative to us, not junior in any way that should've made her the obvious pick.

The original ask was three months. It's now six, and counting. And the math never made sense: we were already resource-strapped, and the person leadership pulled was the one closest to the team's mentoring, the one our team could most use back, the one with the most to gain from staying embedded with people further along than her. If anything, the calculus runs backward — a more senior engineer, someone who doesn't need the scaffolding of a team around them and who can sit comfortably in an ambiguous, unowned system, is the better fit for a tiger team assignment. We sent the wrong end of the roster.

I've watched leadership do this before — not just on this, and not just now. Both as a manager and, later, as someone back on a team, I've seen the same move: go over the manager's head, headhunt whoever on the team is most likely to say yes without pushing back, and assign them straight past the process and prioritization everyone else is expected to follow. The same leadership that built that process. The same leadership that would not enjoy having their time reassigned by someone skipping past them to reach the most agreeable person in their chain.

That's not a knock on her. It's a knock on a pattern: when ownership is optional, so is the process for deciding who pays for it.

📊 The Math Nobody's Showing You

The senior director overseeing this told me the tiger team shipped over 400 commits in a single month — just addressing issues surfaced in that one channel.

Four hundred commits, to keep a beta standing. In that same month, the platform produced 165 merged pull requests, against roughly 5,800 merged across the rest of engineering. A rounding error's worth of output, generating a full-time maintenance operation to sustain it.

This is the moment a tiger team is supposed to graduate — into a real team, with a real manager, a real roadmap, and a headcount line that survives the next re-org. It didn't. Because graduation was never the plan. Temporary was always going to be the permanent state, right up until someone forces the decision leadership avoided making in the first place.

A hundred engineers, twenty squads, and — by our own team's experience — not even all of our work is routed through it yet. The fires scale with usage. Usage is nowhere near where it's headed. Nobody's staffing for that, because staffing for it would mean admitting this stopped being a tiger team a long time ago.

📏 Measuring the Wrong Thing

I was told directly, by that same senior director, that PR throughput is a significant indicator of whether this platform is considered a success.

Sit with that. Measuring a platform's success by how many pull requests it produces is the same mistake as measuring an individual engineer's value by lines committed — a metric we spent a decade, collectively, teaching each other to distrust. A smaller, sharper diff beats a sprawling one. Velocity without judgment is just faster mistakes. We know this about people.

We're re-adopting the metric anyway, one layer up, because the thing producing the volume is a platform instead of a person. And here's the real reason nobody's caught it: nobody owns defining the right metric, because nobody owns the platform. A dedicated manager, with this as their actual job instead of their emergency, kills a metric like "PR count" in the first planning meeting. A borrowed sponsor, checking in between their real responsibilities, doesn't get the chance.

Someone Has to Decide

Every symptom in this piece — the catch-22, the toggle, the six-month reassignment nobody meant to make permanent, the metric nobody questioned — traces back to the same root. Not bad engineering. Bad ownership.

Here's the reframe I keep landing on: a tiger team is tech debt. Leadership takes out a loan — skip the owner, skip the manager, skip the headcount request, borrow whoever's willing — and pockets the speed. The interest comes due later, and it doesn't come due for them. It comes due for whoever's still paying it down six months after the sprint that created it was supposed to end.

We'd never let an engineer ship that trade quietly and walk away. We'd call it what it is: debt, disclosed, with someone accountable for paying it off on a timeline. A tiger team is the same trade, made at the org level, without any of that discipline — no ticket, no owner, no plan to retire it. Just compounding interest, paid by whoever leadership found most willing to carry the balance.

If this platform is important enough to route a hundred engineers through, it's important enough to stop financing it this way. Give it a name that isn't borrowed. A roadmap that isn't a Slack channel. A manager whose actual job — not their side quest — is paying down what leadership took out.

You don't fix a tiger team by feeding it better. You fix it by admitting the loan is due.