PostHog is structured for speed, autonomy and innovation.
Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work.
PostHog started off as a completely flat company with one big goal: to increase the number of successful products in the world.
As we are getting bigger, we anticipate that it will get harder for people to see the direct impact of their work, which reduces the sense of ownership.
We have therefore introduced Small Teams. These are designed to each operate like a startup.
How it works
- The overall goal is for a Small Team is to own an area of the product/company and be as close to its own startup as possible, with only a handful of centralized processes
- A Small Team should strictly be between 2-6 people
- A Small Team has a Team Lead responsible for its performance - whoever is most appropriate depending on what the team is working on. This does not mean the most experienced person on the team.
- A Small Team must have a customer (internal or external)
- There may be certain functions where at our current stage we don't need a Small Team yet.
- Each Small Team runs its own retrospective + sprint every week. This must be done transparently.
- A Small Team has the final call in which of its features get into production, with no need for external QA/control - within our existing release schedule.
- A Small Team will, at some stage, be able to create its own pricing (too complex in immediate future to do this, however)
- A Small Team is responsible for talking to users, documenting what they build, and ensuring their features are highlighted in releases
What does owning an area of the product mean?
The product small team is responsible for everything related to their area, particularly:
- Usage
- Quality
- Revenue
What actions should the small teams be doing for their area?
Each quarter:
- Create good quarterly OKRs
During the quarter:
- Maintain a prioritized roadmap to help them achieve their objectives
- Speak to customers
- Monitor relevant metrics including those covering Usage, Quality and Revenue
- Triage and fix related bugs
- Assist the support hero in answering related questions
- Collaborate with other Small Teams such as marketing
- Become power users of their area of Posthog and use PostHog in their processes
What is the role of the team lead?
The team lead is overall responsible for ensuring the above happens. They should focus on enabling the team to solve these tasks together rather than trying to do it all themself.
How do small teams and product managers work together?
With our engineering-led culture, the engineers on the small team are normally the team leads overall responsible for their area product.
We have a small number of product managers who support the product small teams in achieving their goals. This includes helping with prioritization, creating/updating dashboards, competitors analysis, speaking to customers etc. However, having product managers doesn't mean that the engineers can abdicate these responsibilities. The engineers should be the experts of the product they are building and their customers.
Additionally, the product managers should pay particular attention to cross-team alignment.
How do small teams and designers work together?
Similar to product, designers support small teams. Read our guide for engineers on how to work with design.
Managing larger cross-team projects
Each project should be owned by an individual within a single small team. However, some projects affect multiple other teams and require their support. For example, the performance work owned by Karl in product analytics requires support from the pipeline and infrastructure team.
For these projects, we recommend the individual owning it write a "Status update" every 2 weeks on slack and add a link to this update in the "Updates on bigger projects that affect multiple teams" section of the all hands doc. These status updates might include: what's been done since the last update, any blockers, and what are the next steps.
Small Teams list
See team structure.
FAQ
Who do Small Teams report to? How does this work with management?
The Team Lead has the final say in a given Small Team's decision making - they decide what to build / work on.
Each person's line manager is their role's functional leader (if possible). For example, engineers, no matter which Small Team they're in, will report to an engineer. It's important to note that management at PostHog is very minimalistic - it's critical that managers don't set tasks for those in Small Teams.
Think of the Small Team as the company you work for, and your line manager as your coach.
Can someone be in multiple Small Teams?
No. This defeats the purpose of ownership. We should be hiring in both places. Sometimes that'll mean we "overstaff" certain teams, but in reality there will always be further projects we can move people onto if they run out of work. It's better to do this than to be perpetually understaffed and for our product to suffer as a result.
Despite not being possible to be in multiple small teams - you can certainly attend the meetings of other small teams and otherwise work closely with them for the purposes of collaboration with your small team.
Who is in a Small Team?
No more than 6 people, but that's the only rule. It could be any group of people working together.
Will this lead to inconsistent design?
Eventually, yes. Other companies have a UX team that build components for everyone to use. Since we currently use Ant Design, we don't need this just yet.
Can I still step on toes?
Yes. In fact it's actively encouraged. We still expect people to have an understanding of the entire company and what various people are working on. In engineering, we still expect you to understand how the entire system works, even if you're only working on infrastructure. You can only do your job well if you understand how it fits in with other parts of the system.
You're actively encouraged to raise pull requests or propose changes to stuff that doesn't have anything to do with your small team.
Can people change teams?
We try to keep moves infrequent and when needed. We anticipate moving people roughly every 3-9 months. We'd rather hire new people than create gaps by shifting people around.
There are two scenarios that will trigger a move:
- The Small Team may realize they no-longer need someone, or that they could really do with someone currently in another Small Team internally.
- An individual team member may wish to move in order to develop their skills or experience.
It is at the discretion of the manager of that person if they can move.
Aren't most our Small Teams way too small?
In general, no - it's surprisingly great how much just 2-6 people can get done.
If more mature product areas cannot cope with the workload, small teams will clarify where we need to hire too. In fact, it'll make sure we keep the scrappy fun side of working here as we get bigger. A team doesn't have to be six people.
How does hiring in the Small Team work?
The Small Team is responsible for creating roles for those that they need.
We have a centralized team that will then help you hire.
James and Tim will meet every hire we make - it's a standard startup failure for founders to get too removed from hiring. We are very happy to then give you complete autonomy on the work you do, as best we can.
Does a Small Team have a budget?
Spend money when it makes sense to do so. See our general policy on spending money.
How do you keep the product together as a company?
Luke is ultimately responsible for us having (i) no gaps in product (ii) eliminating duplicate work (iii) making sure all Small Teams are working on something rational. This is how we manage the product.
How do you stop duplicate work?
Luke has the ultimate responsibility to make sure we don't build the same thing in two different teams, or that we don't accidentally compete with each other internally.
By keeping communication asynchronous and transparent, this is made much easier to do than is typical at other organizations.
Can a Small Team "own" another Small Team?
Not for now, no. Perhaps when we're much larger this is something to think about.