Startups ship more per person than big companies – everyone knows this. But how do you retain that advantage as you scale?
Our answer is small teams – speedy, innovative, and autonomous one-pizza teams where individuals can still have an outsized impact. They enable us to scale, while retaining the culture and speed of an early-stage startup. (View Highlight)
Right now we’re 47 people spread across ten countries working asynchronously and shipping fast. And we’re organized into 15 small teams.
Most teams cover individual products, such as data warehouse, replay, pipeline, or product analytics, but we also have small teams covering people and operations, marketing, and growth. (View Highlight)
When we launch a new product, or a project on an existing team becomes too large for the current team, we often spin out a new small team. This allows us to push forward with new ideas and keep shipping without sacrificing quality.
(View Highlight)
They need to be genuinely small
Two to six people is ideal. More than this and you have a department, which is what we’re trying to avoid. Less than two people and, well, you don’t have a team. (View Highlight)
Small teams are effectively one-pizza teams, as opposed to the two-pizza teams idea popularized by Amazon. They’re mostly comprised of product engineers – i.e. engineers who also talk to users, and own product decisions. (View Highlight)
The overall goal of small teams is to own an area of the product or company, and behave like an early-stage startup. They don’t have all the functions of a startup, but their spirit and approach to work should be exactly the same.
This startup-made-of-startups structure minimizes the number of centralized processes and the need for lots of layers of management. It biases to the maker’s schedule – and makers get shit done. (View Highlight)
They run themselves
Each small team runs its own retrospective and sprint each week, with notes taken and shared in GitHub for the entire company to see. (View Highlight)
Small teams also make the final call on which features get into production, with no need for external quality assurance or control. And they can merge whenever. (View Highlight)
Each quarter, every small team at PostHog outlines their goals and projects for that period. We prefer goals orientated around what teams will ship, rather than more abstract goals like “increase conversions by 10%“. Our executive team will give feedback on this to keep everyone on track. (View Highlight)
And, as each one is like a startup in its own right, they’ve got to cover everything. That means:
• Prioritizing their roadmap and talking to customers
• Monitoring relevant metrics, including those covering usage, quality, and revenue
• Triage and fix bugs related to the products or areas they’re responsible for
• Assist the support hero in answering related questions
• Collaborate with other small teams such as marketing (View Highlight)
They have one leader
One of the purposes of the small team structure is to keep a startup’s structure flat even as it scales. That means minimal layers of management and lots of autonomy. (View Highlight)
Each small team has a team lead who is responsible for its performance. They’re not always the most experienced person on the team – we prefer to choose the person best-suited to leading the product the team is working on. Because we’re engineering-led, product teams are always led by an engineer. (View Highlight)
Team leaders do not automatically equal managers. Team leads are responsible for making sure that teams perform well and for giving direct feedback. Managers have a different remit. They’re more focused on the happiness of direct reports and setting the right context for people to do their jobs, onboarding new hires, and discussing performance issues with the executive team.
A team lead’s remit is deliberately more product-focused. (View Highlight)
They have their own mission
Regardless of size or scope, each team has its own mission that feeds into our overall company mission of equipping every developer to build successful products. (View Highlight)
The growth team’s mission is to maximize the number of people who get value out of PostHog, and help them realize and leverage all the value we offer. The infrastructure team’s mission is to make deploying, scaling, and managing PostHog easy, fast, and reliable. (View Highlight)
As well as a main mission, each small team also sets:
• Long-term goals and key metrics
• What features or processes they own
• A target customer (they can be external or internal)
All of this information is in our handbook and updated when changes are made and confirmed each quarter.
This keeps everyone on the same page and makes it easy for anyone in the company to quickly find out what other teams are working on, and why. (View Highlight)
They’re flexible
We’d rather hire new people than keep moving people around to fill gaps.
That said, we’re happy for people to move between teams when needed, ideally no more often than every three to nine months. (View Highlight)
There are two scenarios that could trigger a move:
A small team may realize they no longer need someone, or that they could use the help of someone internally on another small team.
Someone might want to move to another small team to develop their skills or experience. (View Highlight)
Rather than the team lead making the call, it’s always the manager who decides if one of their direct reports should move between teams. But, once in a small team, you’re only in one team. Someone being in multiple small teams at once defeats the purpose of ownership. (View Highlight)
If someone feels the need to be in more than one small team, that likely means we need to hire. That can mean we’re overstaffed at times, but ultimately good people will do good work to push our product forward. And it’s better to have slightly overstaffed small teams than to be perpetually understaffed, and for your product to suffer as a result.
Small teams are also able to work with other small teams on multidisciplinary projects, and members of one small team can and should attend meetings on other small teams to help with collaboration if needed. (View Highlight)
Small teams aren’t perfect. And sometimes, to make them work, we’ve had to create workarounds and accept some tradeoffs. (View Highlight)
Overlap
Some overlap is inevitable, especially when teams work on features that are used across multiple products. We mitigate this by being aggressively transparent. We also have a list of everything we do and who owns it, so it’s easy to see who someone should talk to about a shared problem (View Highlight)
Fuzzy ownership
This isn’t unique to small teams, but we still mitigate against it. If a product or project doesn’t have a clear owner, our fuzzy ownership process encourages people to create a PR and find a solution. If a problem is big enough and it doesn’t have an owner, we sometimes form a temporary team just to solve that problem. We also actively encourage people to step on toes in a low-ego way. (View Highlight)
Speed over seamlessness
Small teams allow us to ship fast. But the tradeoff here is that we tolerate some level of not-so-great integration in exchange for speed. This isn’t a problem unique to PostHog. AWS is a great example of a very, very big company that favors speed over integration. (View Highlight)
You’ve got to hire right
Not everyone will embrace this way of working. It requires people who take extreme ownership of ideas, are self-starting, authentic, and low-ego. We’ve developed some strong opinions about the kind of people who work in this culture, and those that don’t. (View Highlight)
(View Highlight)