{title} Blog post(?) - What no one tells you about tiger teams #13889
Description
What no one tells you about tiger teams
There are a few core milestones in the lifecycle of a PostHog employee.
The first one is when your friends or family ask, "So… what does your company actually do?" and suddenly you're explaining the concept of B2B SaaS to your 87-year-old grandpa who just recently figured out how to operate Alexa.
Once that's settled, one of two things happens: you've either bored them to death and they never ask about it again, or they double down on wanting to better understand how on earth you do what you do.
"But how do you handle that many products?!"
Congratulations, you've reached the next milestone: talking about small teams. If they’ve ever worked in a large company, the response is predictable: "Oh okay, so like tiger teams."
This is the moment where I take a deep breath, as the self-appointed president of the Tiger Team Hater Club™️.
No.
Not like a tiger teams.
Let me explain why.
What even is a tiger team?
The term "tiger team" originated in the military (because of course it did) and was popularized by NASA, who famously assembled one during the Apollo 13 mission in 1970. Remember "Houston, we have a problem"? Well, they were the group tasked with dealing with said problem.
It has since been usurped by corporations who wanted their problem-solving initiatives to sound less boring ("temporary cross-functional committee" doesn't have quite the same ring to it).
A tiger team is typically a group of specialists and subject matter experts pulled into a smaller unit to tackle a specific problem, investigate a failure, or push through a critical project. The goal is to stay agile and deploy focused efforts when there's urgency – a deliberate contrast to the slow, bureaucratic pace of traditional org structures.
The intent behind it is good. The execution rarely is.
Why tiger teams sound great but often aren't
1. It's performative autonomy
Someone somewhere recognized that the normal way of doing things (i.e. the endless approvals, the alignment meetings, the death-by-committee) was too slow to solve urgent problems. So they thought: what if we pulled together our best people, gave them a focused mission, and let them move fast?
Good instinct. Makes sense.
The problem is that tiger teams rarely get what they actually need to succeed: real autonomy. Instead, they get the aesthetics of autonomy: a cool name, a "war room" (aka a sad corner office with a big table, post-its, and fluorescent lights), and maybe some pizza budget. What they don't get is the actual authority to make decisions without playing telephone across the org.
2. It's a band-aid
Tiger teams are the corporate equivalent of calling in a SWAT team to fix your leaky faucet. Sure, they'll get the job done, but at what cost? And more importantly, what happens when the faucet starts leaking again next month?
Here's the fundamental issue: tiger teams are designed around problems, not products. They're reactive by nature. Something breaks, someone assembles the Avengers, they heroically save the day, everyone gets a pat on the back, and they go back to their regular jobs.
Tiger teams are, therefore, a symptom of organizational dysfunction – a sign that your normal operating mode can't handle important problems in its "normal state". They exist because someone realized that day-to-day operations are too bogged down by collaboration to actually ship anything urgent.
3. It's deceptively inefficient
They feel fast because there's urgency and focus and probably some executive breathing down everyone's necks, but it's an inefficient approach.
These are people who don't usually work together, which means they're spending the first chunk of their time building context, learning each other's working styles, and figuring out who actually makes decisions (see: performative autonomy). Half the early meetings for newly assembled tiger teams are just getting everyone on the same page about how to get on the same page.
Then, once they ship their fix, high-fives all around, and everyone goes back to their regular jobs. But where does the knowledge go? Who maintains the thing they built? Who remembers why certain decisions were made six months from now when something breaks again? The answer is usually "nobody" or "some poor soul who wasn't even on the original team."
Then the next fire starts, and you do it all over again.
How are small teams different
PostHog is organized into organizational units called "small teams". Each small team is a multi-disciplinary, self-sufficient group of 2-6 people who own an area of the product or company. We have small teams spanning product, engineering, and operations (see the full list here).
Small teams at PostHog operate like their own tiny startups. They have their own goals, their own roadmap, their own retrospectives. The team lead isn't a manager in the traditional sense; they're responsible for making sure the team ships, not for telling people what to do. They make their own decisions about what to build and how to build it.
And crucially: they actually can make those decisions.
| Tiger teams | Small teams |
|---|---|
| Own a problem | Own an area of the product |
| Designed to find solutions | Built to ship, maintain, and improve solutions |
| Report to someone else's boss' boss | Have final call on what ships |
| Disband after the fix | Stick around, and so does the institutional knowledge |
What makes small teams better?
Ownership changes behaviour (and leads to higher quality work)
When you own something permanently, you think about it differently. This changes behaviour in subtle but important ways. A tiger team might ship a quick fix that technically solves the problem but creates technical debt. Why wouldn't they? They won't be around to pay it off.
A small team, on the other hand, knows that every shortcut is a loan they're taking out against their own future productivity. So the quality of the work tends to be higher, because Future Them is going to be dealing with it if it's not.
You can spell collaboration without bureaucracy
This is usually how tiger team defenders push back: "but what about cross-functional collaboration?"
Small teams don't mean siloed teams. At PostHog, toe-stepping is actively encouraged. You can (and should) raise PRs for things outside your team's domain, and we consult each other whenever it makes sense to do so.
The difference is that we treat collaboration as a resource to pull from, not a process to comply with.
Nimble by default
Knowing that smaller, more autonomous units move faster, but only applying that insight when there's a fire to put out is akin to knowing that exercise is good for you, but only working out when you're already having a heart attack.
Having an organizational structure grounded in velocity and autonomy isn't something we switch on during emergencies, it's how we operate all the time – whether we're responding to an outage or building a new feature on a random Tuesday.
TL;DR
Tiger teams are what happens when you admit your org is too slow – but only sometimes, and only for special problems, and only temporarily. Small teams are what happens when you decide to fix the actual problem.
Whether you're rethinking how your org operates or ignoring everything I just said and spinning up a tiger team anyway, here's the cheat sheet:
Make speed the norm. If you only move fast during emergencies, your normal is too slow. Audit your day-to-day processes: how many approvals does it take to ship something small? How many meetings happen before code gets merged? If the answer makes you uncomfortable, that's your sign to cut them in half.
Give people real autonomy, not the semblance of it. Ask yourself: if this team decided to ship something tomorrow, what would stop them? Count the blockers, and if the answers involve a bunch of people who aren't on the team, something needs to change. Approvals chains are signals you don't trust your teams to make good decisions. If you've hired well, remove the roadblocks. If you haven't, that's a different problem.
Let teams own products, not problems. When teams have real, long-lasting ownership, they build context over time, catch issues before they become fires, and actually care about long-term quality. If you do spin up a tiger team, define who owns the output once they disband: What does "done" look like? Who owns it after? If you can't answer these before kickoff, you're creating a handoff nightmare.
And if any of this resonated, welcome to the Tiger Team Hater Club™️. Grab a t-shirt, make yourself at home, and if you want to see what working in small teams actually looks like, we're hiring.