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 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 an issue template in GitHub, which you can view here. 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.
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 send email using Gmail Layouts. You can access Gmail Layouts with this button:
If this is the first time you've used Gmail Layouts, select Default Styling before choosing a template. Choosing Black #00000 as your primary colour will create simple black buttons which match the design of other emails. Please also upload a PostHog logo and enter our Twitter and LinkedIn links. You can use the following text in your email footers.
With default styling set, you can now choose the 'Call to action' template.
With an email template chosen, you can then enter the copy you want to send. This doc is a suggested template 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.
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 if 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 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 and spending time working on any role-specific tasks that are outlined in the new joiner's personal onboarding issue.
- 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.
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
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:
- 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.
- 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.
Looking for learning session ideas?
Here's a non-exhaustive list:
- The lifecycle of an event, from a client library all the way to query results
- How we turn all our TSX and SCSS files into a fast frontend served from S3
- The architecture of PostHog Cloud
- Trunk-based development - how we make use of feature flags
- Query nodes and how they're used throughout the app
- What the dead letter queue is for
- How PostHog experiment results are calculated
- What engineering planning looks like at PostHog
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!
- 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.
- Pair whenever possible. You're all sitting next to each other, so pick work that can benefit from in-person collaboration.
- 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
- Printfection - merch inventory management, YC onboarding merch, and merch drop-shipping for small events
- CharlieHR - holiday tracking, personal details
- Gusto - payroll and benefits (US)
- Deel - contractor payroll (EU and special arrangements)
Engineering
- AWS
- PagerDuty
- Heroku
- Grafana
- Sentry
Design
- Figma
Ops, People & CS
- HubSpot - customer CRM
- Zendesk - our support platform
- Pry - financial modelling
- LTSE Equity - cap table management
- Fondo - US accounting
- Calendly - external meeting scheduling (e.g. demos, sales)
- Gusto - US payroll and benefits management
- Deel - international payroll and contracts management
- Ashby - recruitment
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:
- 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 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 and a blog about why we use GitHub as our CMS to help you out.
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.
Support hero training
Employees are occasionally called upon to act as support heroes, 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 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 and how they can expect to receive tickets/escalations
- An overview of where tickets come from and how to differentiate between paying/free users
- How to create tickets from Slack threads and reassign tickets to other teams
- Advice on how to communicate with customers and prioritize tickets
- How and when to mark tickets as 'On Hold' or 'Pending'
- What our SLAs are and what ticket severity indicates
- How to deal with bug reports and feature requests
- How to use macros to answer questions quickly
- How to avoid duplication of effort in ZenDesk
- How to create and use personal views 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
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 simply serve as a reminder that these checkpoints have arrived. There is no formal requirement for a manager to do anything different at these stages but there are a few helpful suggestions below to help the new team member's experience and to make sure everything is on track with the onboarding and the first 3 months probationary period will be passed.
- Around the 30 day mark, it's good for the manager to provide initial feedback - especially if there is constructive feedback that needs to be given to ensure the person passes probation. Separately, it's also a good time to reinforce the positive work that has been done by somebody on the right track.
- Around the 60 day mark, 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. A member of the Ops team will also check in with the manager to see if things are on track.
- The 60 day mark is likely the latest point a manager should be flagging any issues in performance with a new starter. If there are concerns, it's best to raise these with the Exec team as soon as possible to come up with a plan on how to move forward.
- 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.