Welcome to the PostHog Handbook! If you are a new starter, this page will help you navigate the Handbook and highlight some of the most important things you should know about working here.
We encourage everyone to start at the beginning first before diving in. We have a strong bias for action, but it is still worth taking a step back and looking at the 'why' first. This helps ensure sure you have the right context and are working on the right things.
Next, familiarise yourself with our approach to Culture and our Values. You might take a bit of time to adjust to PostHog's way of working, and that's ok! In addition to bias for action, you may find that you have a lot more autonomy than you are used to here - you'll realise very quickly that you shouldn't be asking for permission for most things.
How we work
Now it's time to dive into some of the more practical stuff - these are the most important pages:
- Communication - we have a distinctive style. If PostHog is your first all-remote company, this page is especially helpful.
- Team structure - we are structured in Small Teams. These pages will help you get the lay of the land, and who does what.
- Management - we have a relatively unusual approach to management, and it is possible that you will not be familiar with our approach.
Working in GitHub
We use GitHub for everything, including non-engineering task management. This might take some getting used to if you are non-technical. If that is the case, we have this intro video that will teach you the basics and a detailed guide on how to set up a local version of Posthog.com so that you can make changes to the docs, handbook and website.
Our most active repositories (aka 'repos') are:
- PostHog - main app
- PostHog.com - website
- Product Internal - product-related issues that need to be kept internal, e.g. security issues, customer-specific issues (private)
- Company Internal - company-facing issues, e.g. internal processes, hiring planning (private)
When you have a new Issue or want to submit a Pull Request, you do that in the relevant repo.
We use GitHub Projects to track the status of Issues in an easily viewable way. When you create an Issue, you can assign it to a Project - think of a Project as a way of organising and filtering Issues in a particular view. This makes it easy for Small Teams to easily track what they are working on without having to jump between different repos. Some Issues may be assigned to multiple Projects if they involve the work of more than one team.
You can also assign an Issue to a specific person, and tag it with a relevant label - use these to help people filter more easily.
Each Small Team has its own Project for tracking their Issues - full list here. Most teams run two week sprints - as part of onboarding, you will be invited to the relevant planning meetings.
Our onboarding checklist will take you through all the main admin bits you need to get set up, such as accounts access and payroll. The list will vary slightly depending on where you are based and which Small Team you are in. The People team will create an Issue in the Internal repo to track your personal checklist.
Other useful resources
It is worth trying to at least read the entire Handbook once, even if you skim over the other sections. If you are engineer, the Engineering section will obviously be useful, but you might want to know how we're approaching our Marketing strategy.
A few additional pages that may occasionally come in handy: