111 lines
6.1 KiB
Markdown
111 lines
6.1 KiB
Markdown
---
|
|
title: Why Small Teams
|
|
sidebar: Handbook
|
|
showTitle: true
|
|
hideAnchor: true
|
|
---
|
|
|
|
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 to be as close to its own startup as possible, with only a handful of centralized processes
|
|
* A Small Team should never be more than six people
|
|
* A Small Team has an Accountable Person responsible for its performance - whoever is most appropriate depending on what the team is working on. This does _not_ mean the most senior person on the team.
|
|
* A Small Team must have (1) a customer (internal or external), (2) a mission and (3) metrics
|
|
* 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)
|
|
* Small teams should document what they build.
|
|
|
|
# Small Teams list
|
|
|
|
* Core Experience (trends, retention, funnels)
|
|
* Extensibility (plugins/APIs)
|
|
* Deployments and Infrastructure (AMI/VPC/PostHog Cloud)
|
|
|
|
# Functional teams
|
|
|
|
* People & Culture
|
|
* Marketing (includes website)
|
|
* Growth Engineering (proactive experiments / activation flow / revenue flow)
|
|
* Design
|
|
|
|
# FAQ
|
|
|
|
## Who do Small Teams report to? How does this work with management?
|
|
|
|
The Accountable Person 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 minimalist](management) - 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.
|
|
|
|
## 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](https://ant.design/), we don't need this just yet.
|
|
|
|
## Can I still [step on toes](/handbook/values)?
|
|
|
|
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 certain cases, but not everywhere. This will clarify where people will work. 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?
|
|
|
|
Marcus (Tim until Marcus starts) will be 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?
|
|
|
|
Marcus (Tim until Marcus starts) 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.
|