为什么小团队胜过“突击队”

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 (RIP grandpa) 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 team.

Let me explain why.

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.

How small teams at PostHog are 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, and even their own revenue. They make their own decisions about what to build and how to build it.

And crucially: they actually can make their own decisions.

Here's why that matters:

Tiger teams get 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 don't always get what they actually need to succeed: real, self-contained autonomy. Instead, they get the aesthetics of authority: 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.

If autonomy isn't already part of the culture, fully letting go can feel like too big a leap, even for the most open-minded leaders. What if the tiger team they created makes the wrong call? Every decision still reflects back on them, so leadership holds on to the steering wheel, even if they loosen the grip a little. Approval chains might get shortened, but there's still a leash.

Small teams get real autonomy

At PostHog, small teams have final call on what ships – no external QA, no approval chains, no waiting for someone three levels up to sign off. The team lead isn't a manager; they're responsible for making sure the team ships, not for telling people what to do.

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.

Tiger teams are band-aids

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.

Small teams are long-term solutions

When you own something permanently, you think about it differently. This changes behavior 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. Worse, they can have an incentive to not fix things too permanently.

For example, a former organization of one of our engineers was in a constant state of "red alert" (their version of a tiger team). The folks involved had no incentive to improve how the organization worked. This was because, if they solved the upstream problem of organization dysfunction, they'd lose their autonomy (and special status) as a tiger team.

A small team, on the other hand, doesn't benefit from problems – and knows that every shortcut taken is a loan against their own future productivity. So they think long-term by default, and the quality of work tends to be higher, because Future Them is going to deal with it if it's not.

Tiger teams are renters putting a bucket under the leak. Small teams are owners fixing the pipe.

Tiger teams are 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).

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.

Small teams are 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.

Small teams skip the startup costs that make tiger teams slow. The context is already there. The relationships are already built. The codebase is already familiar. When something needs to ship, they just... ship it.

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. Approval 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, PostHog is hiring.