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.
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.