---
title: "Onboarding"
source: PostHog Documentation
source_url: https://github.com/PostHog/posthog.com
licence: MIT
domain: data-and-analysis
subdomain: posthog-docs
date_added: 2026-04-25
---

Welcome to PostHog!

Giving a new joiner a great onboarding experience is super important to us. We want new joiners to feel they’ve made the right decision to join us, and that they are excited and committed to what we’re doing as a company.

> Want to introduce a new joiner to the People team for onboarding, but don't know who on the team does what? Just introduce them to people@posthog.com and a member of the team will jump in and take it from there!

Our [team](/people) is spread across the world, and so are our new joiners. In order to ensure the best possible onboarding experience, we aim for the new joiner to meet up with someone from their team in their first week. Depending on the new joiner's location, they might fly out to one of our team members, or the other way around. So the onboarding experience will look a little bit different, depending on where the new joiner is based and which team they will be joining.

## Onboarding checklist

This is maintained as <PrivateLink url="https://github.com/PostHog/company-internal/blob/master/.github/ISSUE_TEMPLATE/onboarding.md">an issue template in GitHub</PrivateLink>. The People team will create a new onboarding issue for each new joiner.

### Onboarding email

We send an introductory email to all new hires to welcome them to the team and ease them in the some of the essential actions we need them to take. This needs communicating openly, as users may not be able to access the `company-internal` repo yet. So, we send them an email.

> Once you've joined PostHog, we will **not** use email for communicating with each other. For example, James or Tim will never ask you to do something critical over email only – they'll always confirm it over Slack, and so will everyone else. Be extremely cautious of direct emails from James, Tim, or other people of PostHog.

The onboarding email is sent by the People team directly. We want to strike a balance between sending attractive, personalized emails and avoiding creating process or using overpowered tools, such as Customer.io or Mailchimp. So, we landed on a simple email with the necessary links.

<p><PrivateLink url="https://docs.google.com/document/d/1O3_d4v3xgOr1awKkJb8K3xj8-6VV_fHsPkwtgaEhWKI/edit?usp=sharing">This doc is a suggested template</PrivateLink> with important actions specified, though we recommend personalizing it to the individual. We've linked to these as docs and direct images to make the formatting easier for you, but here is an accompanying image for use in emails.</p>

![onboarding image](https://res.cloudinary.com/dmukukwp6/image/upload/v1710055416/posthog.com/contents/images/handbook/handbook-onboarding-email.jpg)

## Onboarding buddy

Every new joiner at PostHog has an onboarding buddy. If possible, a new joiner will meet their onboarding buddy in person during their first week. In case in-person onboarding isn't an option, we will make alternative arrangements. The onboarding buddy is usually a member of the team a new joiner is joining - ideally the team lead - and they can help with any questions that pop up and with socializing during the first couple of weeks at PostHog. Of course, everyone is available to help, but it’s nice to have a dedicated person to help.

### Guidance for onboarding buddies

-   Once we have decided which team a new joiner will join, the People & Ops team will reach out to the team to find an onboarding buddy. _Please make sure that you don't have any leave booked in the week before and the two weeks after the new starter joins_
-   We will intro the new joiner and the onboarding buddy via email - please say hi and decide together where and when the in person onboarding will happen.
    > If any travel is needed for the in-person onboarding, please check our [Spending Money page](/handbook/people/spending-money) and book your travel accordingly. _You don't need to let us team know, just use your Brex/Revolut card._
-   Please make sure you spend at least 3 days together, working through the [first week onboarding list](/handbook/people/onboarding#during-their-first-week) and spending time working on any role-specific tasks that are outlined in the new joiner's personal onboarding issue.
    -   Make sure to add the details of the in-person onboarding to the [In-person Onboarding Calendar](https://calendar.google.com/calendar/u/0?cid=Y19lMzdjNjE0NzM0NDAyOGJlY2ZkMTc0Y2MxZjUxZjY5ZTkxMzY0NzVlNTFjMTE3MjA4OGM2NWQwNjE1YTczNmRlQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20) so that other PostHog team members can join, if possible. Simply create an event in your calendar and then invite the in-person onboarding calendar as a guest.
-   You will remain the new joiner's main point of contact for the first few weeks, so please continue to check in with them at least once a week for the first month or so.

## In-person onboarding

Except under special circumstances, new joiners meet with members of their team in-person to go through the onboarding process. Upon acceptance of an offer, your Team Lead will notify the People & Operations team who will help you coordinate travel if necessary. We encourage team leads to consider the Hedgehouse as a location for in-person onboarding. Regardless of location, everyone should have their own bedroom.

In these cases, the process is:

-   Preemptively create the new team member a Google account
-   Issue them a Brex card to their work email with a sufficiently high temporary balance to cover travel costs
-   Have the new team member book travel as usual

While there is no fixed budget for onboardings they should be relatively less expensive than a small team offsite, which is $2,000 per person. Some considerations to reduce the cost:

-   Avoid intercontinental travel or choose a location that limits it to the minimum number of people possible
-   Consider doing more casual social activities that are less expensive: dinners, drinks etc
-   You can request budget for the team lead +1 more team member as an onboarding budget, any other team members joining can use their working together budget (be mindful that onboardings are distracting so the more team members you have join, the less productive the team will be that week, you also have offsites for the team to all get together).
    -   Create a Slack channel for the onboarding (`#onboarding-[who]-[team]-[month]-[year]-[where]`) add everyone who’s going 
-   The new team member already has their own onboarding budget to book their flights and accommodation, so do not include them in the budget.
-   See if there are any other onboardings at the same time you could pair up with

Aim to keep things sensible and cheap. As always, use your best judgement when [spending money](/handbook/people/spending-money). Request a budget in Brex in USD for any onboardings you are doing. There will of course be some exceptions to this, please just include the reasoning in your brex budget request, and ensure to list who the budget request is for.

> You should by default avoid combining in-person onboarding with [small team offsites](/handbook/company/offsites#small-team-offsites) as they serve different purposes. The focus of onboarding is generally on making the new team member successful, but offsites feature things like hackathons and 360 feedback which aren't usually helpful for this and detract from useful onboarding time. However, it may occasionally make sense to combine the two - just use your judgement.

It is important that you make the most out of the sync time with the new joiner on your team. You should not spend the whole week sitting next to them doing your usual work. Having something planned each day is sufficient, some ideas include:
- An intro to PostHogs values & strategy
- A history of your team, your current quarterly goals and a product demo of the features you own (product teams only)
- Interview feedback session between the team lead and new joiner
- Deep dive into a specific feature where you walk through the code (product teams only)
- Mock demo (sales team only)
- "No stupid questions" where the new joiner is expected to come with questions they had since starting

### Your first week

Your first week can definitely be a bit overwhelming at any new company, so here's what you can (roughly) expect!
- You will meet (either in person or virtually) your team lead to discuss goals and aims over the next 30/60/90 days and beyond
- You will get all your equipment set up and get access to all the accounts you need
- You will receive your new hire kit (which includes [No Rules Rules](https://www.penguin.co.uk/books/439530/no-rules-rules-by-meyer-reed-hastings-and-erin/9780753560969) which we encourage everyone to read as it gives you a great insight into how we work as a company)
- You should try and set up a few calls with a range of people to introduce yourself
- You should try and speak to some actual users of your product. Your manager or PM will help you set these up, and this can be a great source of things to work on in your first week.
- You should dive straight in, fix a typo in the handbook, ship a tiny bug fix, anything to get you going! 

> **If your laptop is delayed:** In rare cases your PostHog-issued laptop may not arrive until several days after your start date. If that happens, you can begin non-sensitive onboarding tasks (reading the handbook, intro calls, etc.) on your personal laptop in the meantime. Treat a personal laptop as less trusted:
>
> - Do **not** access production cloud environments (AWS, GCP, etc.) from it.
> - Do **not** store or handle any secrets on it, including secrets used for local development.
>
> Move anything sensitive to your company laptop as soon as it arrives.

### Engineering

We hire engineers on a regular basis, running in-person onboarding practically every time. Over the years, we've learned a lot about doing this efficiently and there's much to gain from sharing the knowledge between teams.

Based on this ongoing learning process, here are our **five rules for onboarding an engineer**:

1. Ship something together on day one – even if tiny! It feels great to hit the ground running, with a development environment all ready to go.
2. Run 1:1 learning sessions with the new teammate every day. Give them all the context they need to succeed. By the end of the onboarding, each team member present should've run at least one such session.
 <details>
   <summary>Looking for learning session ideas?</summary>
   <p>Here's a non-exhaustive list:</p>
   
     <li>The [lifecycle of an event](/handbook/engineering/databases/event-ingestion), from a client library all the way to query results</li>
     <li>How we turn all our TSX and SCSS files into a fast frontend served from S3</li>
     <li>The architecture of PostHog Cloud</li>
     <li>Trunk-based development - how we make use of feature flags</li>
     <li>Query nodes and how they're used throughout the app</li>
     <li>What the dead letter queue is for</li>
     <li>How PostHog experiment results are calculated</li>
     <li>What engineering planning looks like at PostHog</li>
   
   <p>
     Any of these chats can take as little as 15 minutes or as long as 1 hour, depending on the level of detail.
     You'll also find that some topics apply perfectly in some teams, but not so much in others.
     This is all up to you!
   </p>
 </details>
3. Do at least one brainstorming session on a topic important for the team, writing down actionable conclusions. Use the time together to discuss issues and involve the new joiner in decisions.
4. Pair whenever possible. You're all sitting next to each other, so pick work that can benefit from in-person collaboration.
5. Have fun, because life isn't all work! Do some sightseeing, go out for dinner, or find a fun activity – just hang out together any way you like.

## Tools we use

We use a number of different tools to organise our work and communicate at PostHog. Below is a summary list of the most important ones - this list is not intended to be exhaustive

### Everyone

-   Google Suite - Gmail, Google Apps such as Docs, Sheets, Slides
-   GitHub - most comms and product work
-   Slack - we have an internal workspace and a users Slack as well
-   Brex (US, RoW) or Revolut (UK, EU) - company cards and expenses tracking
-   Shopify - powers our merch store
-   Time off by Deel (Slack App) - holiday tracking
-   Bamboo HR - payroll and benefits (US)
-   Deel - contractor & EOR payroll & HRIS

### Engineering

-   AWS
-   Incident.io
-   Heroku
-   Grafana

### Design

-   Figma

### Ops, People & CS

-   Salesforce - customer CRM
-   Zendesk - our support platform
-   Mosaic - financial modelling
-   Carta - cap table management
-   Fondo - US accounting
-   Deel - international payroll and contracts management
-   Ashby - recruitment
-   Micromerch - merch inventory management, [YC onboarding](/handbook/growth/sales/yc-onboarding) merch, and merch [drop-shipping for small events](https://github.com/PostHog/meta/issues/31)

## Signatories

Charles, James and Tim at this time are the only people able to sign legal paperwork on behalf of the company.

## How we work

Now it's time to dive into some of the more practical stuff - these are the most important pages:

1. [Communication](/handbook/company/communication) - we have a distinctive style. If PostHog is your first all-remote company, this page is especially helpful.
2. [Team structure](/handbook/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](/handbook/company/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](https://github.com/PostHog) 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 [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](/handbook/engineering/posthog-com/developing-the-website) and a blog about [why we use GitHub as our CMS](/blog/github-cms) to help you out.

Our most active repositories (aka 'repos') are:

-   [PostHog](https://github.com/PostHog/posthog) - main app
-   [PostHog.com](https://github.com/PostHog/posthog.com) - website
-   [Product Internal](https://github.com/PostHog/product-internal) - product-related issues that need to be kept internal, e.g. security issues, customer-specific issues (private)
-   [Company Internal](https://github.com/PostHog/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](https://github.com/orgs/PostHog/projects). Most teams run two week sprints - as part of onboarding, you will be invited to the relevant planning meetings.

### Support hero training

Employees are occasionally called upon to act as [support heroes](/handbook/engineering/support-hero), or need to deal with support tickets that are escalated to them. This most often applies to engineers, but can include any employee regardless of their team. For this reason, we need everyone to have a broad idea of our support processes and know how we deal with customers.

All new hires should schedule a 30 minute session with the [support engineer closest to their timezone](/teams/support) within their first three weeks at PostHog.

In this call the support engineer will be able to answer any questions, as well as demonstrate how we deal with support at PostHog. In particular, the support engineer should cover:

-   [ ] [What the role of a support hero is](/handbook/support/customer-support#support-is-done-by-actual-engineers) and how they can expect to receive tickets/escalations
-   [ ] [An overview of where tickets come from](/handbook/support/customer-support#its-easy-for-customers-to-reach-us) and how to differentiate between paying/free users
-   [ ] [How to create tickets from Slack threads](/handbook/engineering/support-hero#pylon-to-create-zendesk-tickets-from-slack-posts) and [reassign tickets to other teams](https://support.zendesk.com/hc/en-us/articles/4408887127450-Manually-assigning-a-ticket)
-   [ ] [Advice on how to communicate with customers](/handbook/engineering/support-hero#how-do-i-communicate) and [prioritize tickets](/handbook/engineering/support-hero#how-do-i-prioritize)
-   [ ] [How and when to mark tickets as 'On Hold' or 'Pending'](/handbook/engineering/support-hero#ticket-status)
-   [ ] [What our SLAs](/handbook/support/customer-support#response-targets) are and [what ticket severity indicates](/docs/support-options#severity-levels)
-   [ ] HogHero - how to deal with bug reports and feature requests, and how to merch customers (including [macros](https://support.zendesk.com/hc/en-us/articles/4408887656602-Using-macros-to-update-tickets))
-   [ ] How to avoid duplication of effort in Zendesk
-   [ ] [Which views should be used in Zendesk](https://support.zendesk.com/hc/en-us/articles/4408832792986-Managing-your-views)
-   [ ] How to use [side conversations](https://support.zendesk.com/hc/en-us/articles/4604286879642-Creating-side-conversations) in Zendesk

It can be especially helpful for new hires if support engineers demonstrate how to solve a few simple tickets from start to finish, through shadowing.

## 30/60/90 day check-ins

Managers are responsible for helping their new members navigate the [first 3 months probationary period](/handbook/people/compensation#probation-period). There is a strong importance on 1) providing feedback to the new team member, and 2) communicating with execs about unresolved performance issues, so that there is enough time for action. Managers are, again, not responsible for hiring or firing, nor communicating these possibilities directly to teammates - this is handled by the exec team, and is frankly a very rare situation - the vast majority of people we hire do pass their probationary period!

As part of the onboarding checklist, the Ops team will schedule reminders for a new team member's manager at the 30, 60 & 90 day mark to serve as a reminder that these checkpoints have arrived and to make sure everything is on track for the probationary period to be passed.

-   30-day checkin
    -   Manager to provide initial feedback to the team member - especially if there is constructive feedback that needs to be given to ensure the person passes probation.
    -   It's also a good time to reinforce the positive work that has been done by somebody on the right track.
-   60-day checkin
    -   Ops team will check in with the manager to see if things are on track.
    -   Manager to provide another round of feedback to the team member.
        -   If things are going well, the manager might want to give an indication of this as it can ease any fears the team member may have.
    -   Exec team will get involved as necessary to provide an additional layer of feedback to the team member.
-   90-day checkin
    -   We've made it! Congratulate the new team member on passing their probationary period.
    -   Give any extra feedback as necessary, though things _should_ feel like they're humming at this point.

Feedback is a really important part of the onboarding process and as a manager it's a good idea to ensure the new team member receives feedback from their peers - either from you collecting it or them receiving it directly from their peers. It won't always be possible or necessary to do a 360 feedback session within the first 3 months, so it's up to you as a manager how best to approach that. As a manager you can also have blind spots on performance, so checking in with their peers can be helpful and can be done during your normal 1-1s.

These check-ins are designed to ensure every new starter is set up for success. Every manager will deal with these slightly differently, but it will hopefully be clear to everybody by around the 60 day mark how things are going and what needs to be worked on, if anything. It is important for a manager to ensure that they do not wait for one of these check-ins to communicate with an exec team member that there could be issues with the team member passing probation. They should let them know immediately, so that a fair and reasonable plan can be put in action ASAP.

If you have any issues or any feedback on how to improve a specific intro just post in the #team-people-and-ops slack channel and tag the relevant people

## Finding answers at PostHog

Need help finding something? We have a strong culture of self-sourcing answers - it helps you get unblocked faster and builds your intuition for where things live. Start with #ask-max, our AI that's read every handbook and documentation page. It'll point you to relevant docs instantly and is available 24/7.

Of course, if you're stuck or need context beyond what's documented, just ask in the relevant channel - people are always happy to help. The goal isn't to make you figure everything out alone, it's to give you the fastest path to answers.

## Slack Channels

Below are a list of Slack channels you may find helpful:

### Work-related channels

-   `#ask-max` - Max has access to all of our documentation and our handbook, and is a great place to start with many questions
-   `#content-docs-ideas` - for suggesting ideas for the newsletter, tutorials, and docs to be written by the content and docs team
-   `#brand-mentions`
-   `#do-more-weird`
-   `#newsletters`
-   `#team-blitzscale`
-   `#dev`
-   `#general`
-   `#alerts`
-   `#industry-news`
-   `#changelog` - keep up with all the cool things we're shipping across the team

### Social channels

We encourage you to join and create channels focused around different types of hobbies and interests. We explicitly don't allow channels based on categories that we legally (and rightly!) can't discriminate against in the hiring process, such as gender, sex, political affiliation, religion, and age. 

-   `#food`
-   `#kids`
-   `#no-context-posthog`
-   `#random`
-   `#whereintheworld`
-   `#devel-random`
-   `#books-and-films`
-   `#climbing`
-   `#coffee-snobs`
-   `#dad-jokes`
-   `#fitness`
-   `#hoglife`
-   `#rockets`
-   `#stonks`
-   `#cycling`
-   `#listening-to`
-   `#design-inspiration`

### Location specific channels

-   `#london`
-   `#germany`
-   `#sf-bay-area`
    etc.
