PostHog Handbook Library

1,476 words. Estimated reading time: 7 min.

# How you can help

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. Getting yourself up and running quickly
2. Ask for help, but only after you've tried first
3. Don't expect perfection
4. Make it better
5. Don't wait for someone else
6. Have an opinion
7. Look around corners
8. Don't assign issues to people

People who work at PostHog have come from all sorts of different backgrounds – large companies, small companies, agencies, single-founder startups, and so on.

Their modes of working necessarily differ from each other and from PostHog, but we expect you to work in some fairly specific ways.

Being the transparent company that we are, we want to let you know about those expectations, because you can only meet expectations when you are aware of them!

Generally, our values are a great place to start, as is as the handbook page on culture, but here are a few specific ways to apply those values, and reinforce our culture as we grow:

### Getting yourself up and running quickly

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 review your work
- You get what the company, your customers, 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.

### Ask for help, but only after you've tried first

If you've just joined us, there's a lot you probably don't know. That's okay! However, we _do_ expect that you try to help yourself. Here's a framework to use as a guide:

- If it's one of our own products that we build and sell:
- We expect you to read our docs.
- We expect you to search through GitHub or Slack.
- If it's in beta, it might be buggy or missing features. Definitely request/report them, but also figure out how to do your job with plan B and plan C if it won't be fixed quickly - this is what we generally call grit.
- For engineers: try to figure something out by yourself for at least 1 hour, but don't remain totally stuck on something for more than 2 hours before asking for help. This time window should increase over time as you run into more questions that likely no one has the answer to, at which point it's time to dig in and figure it out.
- If it's an external product:
- We expect you to read the docs
- If it takes you more than 10 mins to figure it out, then ask someone internally.

You can also try self-serving an answer in our #ask-max Slack channel. It's trained on our handbook and documentation, so it's capable of answering both questions about internal processes and procedures, as well as product-related questions.

If you don't get the context you're looking for, try #ask-posthog-anything where team members are willing to point you in the right direction. Take a moment to explain how you've tried to help yourself and linking to resources. That saves others valuable time searching the docs again, or typing up a suggestion to do just that.

### Don't expect perfection

PostHog is a startup. As solid as our stack / product / CI / dev experience is for a company of our size (super solid, tbh), it might not be the extremely-well-oiled machine you had at BigCo. If something doesn't Just Work, follow the framework above to get help.

We're all human - you shouldn't expect perfection for adhering to our culture, either. But you should help others learn how to stick to our culture, especially new joiners. We're all prone to occasional lapses, and it takes everyone on the team nudging each other in the right direction to keep us all on track. If you notice something happening all the time, take it upon yourself to make it better - see the next section!.

### Make it better

If you run into something you found that is confusing or needs fixing, we expect you to update the docs or handbook at minimum, and if you're keen then definitely improve the experience yourself. For example, CI is _everyone's_ job. If it sucks, fix it.

That being said, there is often a _reason_ why things are the way they are. That reason might be "because no one wanted to fix it," but it also might be "because it broke yesterday and we're on it" or "we've carefully considered this before and decided to make it this way."

We encourage you to step on toes, but don't be a bull in a china shop. Context is oftentimes your best friend – gather it up and keep it close.

### Don't wait for someone else

We expect you to be proactive about answering questions in your domain, even very early on after you are hired – e.g. after the first week. Look in the code. Read the docs. Find the answer.

Being wrong is way better than being silent – if you are wrong, someone will correct you. If you are silent, you're not doing your job.

Similarly, if you need something to get done, you are responsible for making _sure_ it gets done. This is not your team lead's job or some other team's job - if you need it, you own it. _Most_ of the time this means doing it yourself (see section on helping yourself above); other times it means getting the right people together to understand the urgency and do it with you. But at the end of the day, the responsibility rests on you.

### Have an opinion

You definitely don't need to have opinions on everything, but you should absolutely have opinions on your area of expertise.

If you don't have opinions on your area, you are realistically then just waiting for someone to tell you what to do, which is very much at odds with our autonomous way of working.

Opinions can take a bit to form, and that's okay – you don't need to have them on day one. But we expect you to start forming them rather early on, even if it's just on little things.

### Look around corners

We expect you to be thinking through not only the one change you're making right now, but also how that change plays out down the road. What might happen with this code / process / thing in 6 months? Where will that leave my change today?

We do have more senior people on the team (both in industry experience and in their tenure at PostHog), but they shouldn't be the only ones looking ahead – you should be the primary one looking ahead for _your_ changes.

### 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 action. 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 _You're the driver_.

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 _"Make it public"_ 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.

### And if you don't work here...

Apply for a job at PostHog!

Canonical URL: https://posthog.com/handbook/help

GitHub source: contents/handbook/help.md

Content hash: `2ba7a2c497fd1223`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: PrivateLink.