How you can help

Getting yourself up and running – your first week

If you're new, the default goal is to be able to get work done autonomously.

This will require:

You know how to ship things in our environment and with your equipment
You get to know your team and have a sense of who can QA your work
You get what the company (and your small team) care about and needs to get done, so you can prioritize appropriately

Everything else is a means to this end! We often do onboarding in person to accelerate all the above. This usually takes around a week.

General etiquette

Don't assign issues to people

You can list and categorize issues.

If you want someone to see an issue, @mention them and/or Slack them the link.

Don't yolo merge

Do not "yolo merge", i.e.: force a change to our website or platform without someone else checking it. This should only happen in emergencies, even for simple changes. It is so frequent that we find issues. If you have any doubt, get someone else to look at it first.

PRs > issues > Slack

Bias for impact. If you can just pick up the work, do so. We want a culture of individual contribution not of delegation.

It is fine (and encouraged) to pick-up side quests, or to deviate from your goals if you think you should. Especially if something is a quick fix, do it yourself as part of our value that Everyone Codes.

If you aren't able to make a change yourself, create an issue in GitHub. Avoid simply relaying to-dos in Slack as a means of getting someone to pick up a task. It's hard to track and easy to forget.

Do things as publicly as possible by default

For discussions, public repos are the best place. Then private ones, then Slack public channels, then Slack private channels or DMs. This is part of our "We are open source" value, and helps with general context setting for the wider team, which means everyone can work more autonomously.

There are only a few exceptions to what we can't share publicly, for example if you are discussing security concerns, specific customers (for privacy reasons), revenue, or growth numbers (since these cause signalling issues with investors or competitors).

Internally, everything can be shared apart from people issues – such as HR / personal (i.e. recruitment or health data).

Be proactive with community questions

Don't only help the community when you're the person on support hero in your small team. No matter what your goals may be, if you can quickly ship fixes to real life user problems, then you are going to build goodwill, word-of-mouth growth, and a better product all in one swoop.

You can find these in posthog.com/questions.

Lore of PostHog / inside jokes

A beginner's guide to some of our custom Slack emojis and various anecdotes you'll see and hear about.

:bad-internet: Yakko always had bad internet when demoing. Always.
James GreenhillJames Greenhill wore a skin tight green all-body suit for months to improve his Zoom background game without us realizing.
:ben-peace: Ben WhiteBen White has the same pose in 90% of PostHog photos. It's a reference to a meme.
:hype-X: where X is a team member. Used in times of extremely impressive performance, unless used sarcastically.
Mr Blobby. We once changed how we ingest session recording data, to use S3 blob storage. We called it Mr Blobby. Mr Blobby is a creepy '90s TV character from the UK. This project was nightmarishly hard, which is why this character was fitting.
Paul D'AmbraPaul D'Ambra will make you eat gelato at every offsite.
Sometimes people screenshot each other's faces and Zoom screens and use them as their backgrounds. Usually when an all-hands is too dry.
Charles CookCharles Cook wore a suit to his performance review. He is the only person in history to wear a suit to anything PostHog-related. Unsure if he was making a point, we later abandoned the practice of performance reviews regardless.
We took lots of buses at an offsite in Portugal. The roads were incredibly twisty, the driver was in a bad mood, drove too quickly, and people threw up. It was bad.
:sparksjoy: / :does_not_spark_joy: A reference to Marie Kondo's book on tidying your house, generally used to describe things that are particularly good or bad from a user's perspective
:eu-thumbsup: / :thumbs-down-eu: We once made isgoogleanalyticsillegal.com when there were privacy rulings about Google Analytics. We put it on Hacker News, got the top of the front page, and it was our biggest ever day of signups at the time. The website was supposed to be tongue in cheek, but the internet took it seriously. The person in the emoji is Ursula von der Leyen, who introduced the GDPR legislation.
IPO promises. There is a list of these that is brought out at certain moments. You may see.
Marius AndraMarius Andra will train you on Post-it notes if you go to an offsite with him. Success of a good Post-it note posting is in the lift away from the surface – the most important thing is to peel off the Post-it note, as opposed to pulling.
Three finger rule - another Marius invention, if someone holds up three fingers while you're talking, it means you aren't being concise enough. We don't actually use this much as it's predictably awkward and distracting, so ruins any meeting it could have otherwise helped.
When we hit 10,000 GitHub stars, Ian VanagasIan Vanagas read every username on a live stream that took over six hours.
We like to nail things. It's not uncommon to see a GitHub issue titled "Nail [feature name]". Sometimes we'll even assign an absurd version number like "3000". (The codename for the next generation UI of the PostHog app is referred to as PostHog 3000, and other projects have also adopted this naming convention as well.)