Transcription
As a startup, the single advantage that you have over all of these gigantic competitors that are probably in your market is that you're able to ship a lot quicker, which is pretty weird when you think about it. How come two people or five people or 20 people can outship a team of hundreds?
However, as you yourself become successful, you start to grow, you get to 50 people, you get to 100, certainly by the time you hit 200, things tend to grind to a halt. And this is because the number of relationships between your team members is exponential. The more people you have, there are disproportionately more ways people can collaborate or prove things or look for buying or whatever else.
PostHog hasn't been like this at all. We're 200 people and we're shipping faster than we ever have. In 2025, we built six new products. We've supported all our existing products for hundreds of thousands of users. We have dozens of new features coming out each week. We've nearly tripled our revenue.
There are loads of reasons why this has been the case. If I had to pick just one single thing, it is our small team structure. Today, I want to walk you through exactly how small teams work at PostHog. I want to talk you through what's great about small teams and also what sucks.
Here are four golden rules to follow. Golden rule number one is that small teams must be genuinely small. A small team should be absolutely no more than two to six people. Any more than this and you've got yourselves a little department with nine or 10 people in it. When you've got your little department going on, you're going to feel the need to coordinate work, decide who's doing what, and before you know it, you're going to feel the need to hire a traditional product manager who's going to assign tasks to people. That puts you in a bit of a doom loop.
With a product manager deciding what people need to do, the engineers lose autonomy over their work and they stop thinking about why they're building the thing they're building or if they are thinking about why, they're probably getting frustrated that they're having to do it in the first place. This isn't good. It creates a bunch of internal approvals and process. Good engineers are going to leave. You'll end up with Jira being used and all kinds of traditional things that just slow companies down. You look like a big company suddenly.
Instead, there's another way. At the time we're recording this video, PostHog has over 50 small teams with average of just 4.2 people in each. When the work within a small team gets too large or too broad or too vague and kind of complicated feeling, that's often time to spin out a new small team instead, so you end up with two rather than one.
For example, earlier this year we took a few members of our product analytics team to create a new platform analytics team instead. The platform analytics team would focus on things like query performance alerts, basically existing things, whilst our product analytics team could continue to ship new features because users were asking us for both sides of this.
The way small teams work is they fully own an entire area of the product for a company. They can operate completely autonomously from everyone else. The inspiration for small teams actually came from when I did my company later back in 2020 with Tim, my co-founder. One of the things that was really startling was how all these two-person teams could ship an entirely new product in just a couple of weeks. We realized that that kind of structure is how you optimize for speed, and speed is the thing we're winning on over polish or anything else.
Golden rule number two, small teams should own everything from end to end. The whole point really is that small teams need to be able to ship with the bare minimum number of dependencies on other teams internally. Each small team needs to work in the open. They share internally and even on the internet of Posthog everything they work on. You can see things like their goal planning and their sprint notes. This means other teams can give feedback on their work. They can help say, "Yo, your infrastructure should be a little bit more like this." For example, but ultimately the call on what to build and how it gets built sit exclusively in that small team.
They do not need sign-off from the design people, from product people, from other small teams, or even the exact. Because each small team operates like its own startup, they fully own their road map, their pricing model and revenue, support and documentation, and the monitoring of their product's performance. The exact team will informally give each small team feedback on their progress and performance, but ultimately the accountability sits with the small team itself, not some department head, VP, or director.
Working in this way means each small team truly is autonomous and accountable. That means they make their own decisions. There's no need for process or buying from anyone else so that we don't have any of the kind of issues that are associated with that, like slowness, politics, or conservative decision-making. Those are the kind of ways you lose in technology.
Golden rule number three, everyone is a driver. So, each small team has got a team lead and another person who's ultimately accountable for that team's performance. They also act as a tiebreaker for any difficult decisions over what to build, for example. However, this does not mean that the individual contributor people in the team are going to be spoon-fed anything at all. We think it's really important culturally that small team leads are mostly doing individual contributor type work and they're therefore just three things they need to remember to do.
Number one, they need to set good context so that all their direct reports are able to do their jobs properly. For example, in a product team this means the engineers need to know what's going on that's relevant in the rest of the company and kind of what the company overall cares about and how the product is performing so they can decide what to work on individually.
Number two, they need to make sure everyone in their team is happy and productive and the two often go hand-in-hand.
Third and finally, they need to make sure that the bar for their small team is astronomically high from a talent point of view. This means that small team leads are heavily involved in the hiring process for their own team and they're also responsible for giving direct feedback to everyone in their team on an ongoing basis.
This means there's a bunch of stuff that small team leads do not have to do. The typical things like dealing with pay reviews, designing career progression frameworks, approving holiday. This stuff is all centralized away. The irony is the more you focus on getting great work done, the less of a big deal all that other stuff seems to be because the overall business is doing so well when you focus on the quality and you take pride in the actual work that's taking place.
If a small team lead suddenly starts talking about management a lot and they're doing more managing than contributing, it means something's going wrong. Probably their team has got too big, there's too much stuff in it and it's time to think about splitting up into two teams instead.
This brings me on to my fourth and final golden rule for small teams. Golden rule number four, small teams should be easy to change and flexible. As teams get bigger, it gets harder and harder to change what they're doing. They get less agile, less nimble and so on. And what this means is if you let the teams at your company get bigger and bigger, you're going to be more and more hesitant to change what people are doing and you're going to have to change stuff a lot in a startup.
The problem is if the teams get big, changing them becomes harder and so you're less likely to do it. Changing a team at PostHog takes no more than 3 days, and often it's way quicker. For example, some internal meeting where it becomes obvious to us that we should make the change, followed by just a Slack message.
One of the less delightful things about being a founder is making a series of terrible choices. In this case, the trade-offs aren't too bad, but I wanted to go through them. So, we're going to start with the first trade-off, which is overlaps and fuzzy ownership. We try as much as possible to avoid this happening between our small teams, but a little bit of it happening from time to time is inevitable, especially if you're innovating and building very quickly.
When this happens, we do two main things to mitigate. Number one, we're as transparent as possible about what everyone is doing, so everyone can see what everyone else is up to. All of our internal sprint notes, for example, are transparent. Number two, we will maintain a list of all our features by engineer. So, you always kind of know who the right person to talk to is about a particular thing.
What may happen is if two engineers from two separate teams want to work together on the same thing, they'll often join forces for a sprint or two to get it done. If that thing is larger or broader in scope, it might take a quarter or longer, for example, to achieve. We may even form a new project team to get that thing shipped.
For example, we wanted to redo the UX for an entire platform. This monumental task was originally just one person, Michael, trying to get it done. And it was too big a task. It became really obvious to us after a couple of months. So, instead, we took two extra engineers from two separate teams, joined forces with Michael, they created a PostHog 3000 team, they shipped the UX change, and then they went back to their original small teams.
The second trade-off is speed over seamlessness. We are very happy to tolerate not-so-perfect polish in the interest of greater speed. And in fact, if you really ask us, we think polish comes from very fast iteration, rather than getting it perfect first time round, anyway.
We've experimented with the concept of glue teams at PostHog. These are teams that cut horizontally across a range of products and features, rather than owning a vertical slice. A good example of this is our billing team. Doesn't sound sexy, but it is critical to making all of our stuff work, from our perspective and from our customers, cuz we have to charge across 10 different products appropriately. We're really hesitant to add these teams, and we don't like adding them by default because they introduce a dependency, but we will introduce them if we've decided that not adding them would make us go slower.
The third trade-off is by far the most important, and it's hiring the right people in the first place. Not everyone is equipped to work well like this. In fact, probably most people will struggle working environment that's this sort of loosey-goosey and this autonomous. And so, there's an extreme level of ownership, authenticity, proactivity, and low ego that's required for every single person if your whole team is to pull this thing off.
For example, when at Posthog we're looking for product engineers, we've got to find people who are superbly talented engineers, but they've also got to be really comfortable talking to users and really owning and making product decisions. And that's a big ask. Remember, if you take a single thing from this whole video, it's that having the right people in your company in the first place makes everything else way easier to pull off. But yeah, we're actually going to have a video on this topic, so like and subscribe if you don't want to miss out.
Back when Posthog was just product analytics, Karl noticed that many customers were asking for session replays. He wanted to build it, but I thought it was a terrible idea. I thought it would take too long, and I was worried about losing focus. Karl disagreed and built it anyway during a hackathon. It ended up being wildly popular with customers. This made me realize that Posthog could be more than just product analytics.