Part of our strategy is to provide all the tools in one for evaluating feature success.
Speed
This means we need to ship a lot of products into one platform. We can see a need for at least 20. That's a lot of engineering work.
After we'd started hiring, we asked ourselves a question – how could we structure the company to optimize for speed above everything else?
I happened to go to an excellent talk by Jeff Lawson, the CEO of Twilio. It made me realize I should be asking, "Who ships more per person, a startup or an enterprise?" Clearly the former. So we structured PostHog like a series of startups.
Small teams
We decided that we should split PostHog into a series of small teams, each working like its own startup, fully owning at least one of our products.
As with any startup, the principles that govern these small teams are:
- Can decide what to build within their own products
- Can ship without outside interference as far as possible
- No product by default
- No design by default
- Should work directly with its own users (until it has hit product-market fit within PostHog's platform)
- Should be small
Minimal hierarchy
We deliberately keep the number of levels and people managers at PostHog to the absolute minimum we can get away with. This maximizes team member autononomy and increases shipping speed, as you don't need to run things past a manager or wait to get something signed off the vast majority of the time.
This means that, if you need something or need to flag an issue, you are strongly encouraged to communicate directly with the person or team working on the thing you care about. We want to avoid people going up and down the org chart via managers as much as possible. 90% of the time, this approach means you'll get what you need faster. 10% of the time, this might cause a tiny bit of confusion if what you are asking for doesn't beautifully align with that team's objectives. We believe that trade-off is ok - we'll figure it out.
We have a tiny exec team - this is what they are responsible for:
- Set the overall direction and strategy for PostHog
- Decide which products to build
- Make key people decisions (e.g. who to hire, pay, disciplinary issues)
- Ensure complicated cross-team initiatives run smoothly (e.g. pricing)
For everything else, you and/or your small team should be able to decide this or talk directly to the teams involved. This includes deciding which feature to build next within a particular product. We trust you to bring in the right people as you feel appropriate, relative to the scale of what you're doing.
PostHog is not a good place for managers who are territorial and prefer for all communication to go through them for 'efficiency'. Over time, doing this would undermine autonomy and cause our best people to quit!
Titles based on what you do
Companies give out titles to people that primarily show how senior they are.
This means titles, as adopted by the wider world, imply that seniority is more important than what people do. We do not believe that seniority should determine how decisions get made - people should own decisions in their area of the business. We trust every employee to fully own their area of the business.
When you are prompted to put your title somewhere like LinkedIn, please just say as clearly as you can what you are focused on. Please do not focus on how senior you are. Feel free to be weird with it.
Before "Senior Engineer at PostHog" (this is not a title that exists at PostHog anyway) After "Product Analytics Engineer at PostHog"
Goal setting
When you build a startup from scratch, you are in an existential crisis. One day you might be building a gym, the next day a software product for accountants. The problem changes. At PostHog, we give each small team a product to build. (James and Tim focus on which products we should build, as they often need sequencing.)
Once we had product-market fit, and we had reached 15 people or so, we realized we needed to set some kind of goals. We started by using OKRs as they're pretty standard.
However, one of our engineers one day told me, "I realized I needed to change my objective. Then I started rewriting my OKRs into the handbook. I realized I was spending time stressing about the wording of it, which was going to have zero impact on what I knew I had to build." That seemed silly, so instead we make a point of calling them just "goals". We intentionally don't sweat the wording.
Another best practice we choose to ignore is "goals should be output driven". It sounds great in principle, but what is going to happen after a product team, which is nearly every team here, sets an output driven goal like "improve activation by 20%"?
Either the team will decide on some things it should build, or they won't manage to figure out what to build to do this. In either case, if a team knows what it should achieve, it should then figure out which things it needs to ship, and write those things down instead. It's clearer, and clearer is faster.
And if that list turns out not to be helping our metrics? Switch the goal to a new thing.