Start here

Last updated:

|Edit this page

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.

Big picture

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 you have the right context and are working on the right things.

You should start with the 'Company' section and work your way through everything there. It is not a lot to read. In particular, the sections on our Strategy and Roadmap are a must-read for everyone.

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:

  1. Communication - we have a distinctive style. If PostHog is your first all-remote company, this page is especially helpful.
  2. Team structure - we are structured in Small Teams. These pages will help you get the lay of the land, and who does what.
  3. 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.

Onboarding

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:

  • Media - official PostHog logos and backgrounds
  • Customer Support - we don't have a dedicated support team. Learn why!
  • Benefits - we are adding more all the time!

Questions?

Was this page useful?

Next article

Meetings

We are anti-meeting by default . However, while we default to written and asynchronous communication , we find that having a few regular touch points for the whole team to come together on a call useful for sharing certain types of information, strengthening our culture and discussing more dynamic issues in real time. We keep these minimal in terms of time expectation - no more than 2hrs total per week. They are usually scheduled around 8.30am PDT/4.30pm GMT to allow people across multiple…

Read next article