From 87fe29cb0dc902f8d66786062f96ca1ad5dc5915 Mon Sep 17 00:00:00 2001 From: Andy Vandervell <92976667+andyvan-ph@users.noreply.github.com> Date: Fri, 10 Jan 2025 10:51:37 +0000 Subject: [PATCH] Culture handbook updates (#10241) * Culture handbook updates * Fix typos * Update help.md * Cory's suggestions * fixing-url * fixing url 2 * Update culture.md * suggestions Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com> * Update culture.md * Suggestions Co-authored-by: Raquel Smith * Suggestions Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com> * Suggestions Co-authored-by: Raquel Smith * Heading * Apply suggestions from code review * Apply suggestions from code review --------- Co-authored-by: PostHog Co-authored-by: Ian Vanagas <34755028+ivanagas@users.noreply.github.com> Co-authored-by: Raquel Smith Co-authored-by: James Hawkins <47497682+jamesefhawkins@users.noreply.github.com> --- contents/handbook/company/culture.md | 50 +++++------ contents/handbook/company/lore.md | 41 +++++++++ contents/handbook/help.md | 92 ++++++++++++--------- contents/handbook/why-does-posthog-exist.md | 21 +++-- src/navs/index.js | 12 ++- 5 files changed, 145 insertions(+), 71 deletions(-) create mode 100644 contents/handbook/company/lore.md diff --git a/contents/handbook/company/culture.md b/contents/handbook/company/culture.md index 9f64587af359..28fd10ae9c2a 100644 --- a/contents/handbook/company/culture.md +++ b/contents/handbook/company/culture.md @@ -6,30 +6,28 @@ showTitle: true So, what's it like working at PostHog? - +## We're 100% remote -## All remote +[Our team](/people) is 100% remote, and distributed across more than 15 countries. -Our [team](/people) is 100% remote, and distributed across over 10 countries. - -As well as the equipment you'll need, we provide [a budget to help you find coworking space](/handbook/people/spending-money#work-space) or to cover the costs of coffees for those who prefer not to work at home. - -All remote has a bunch of advantages: +Being all remote has a bunch of advantages: * We can hire [amazing people](/people) from a global talent pool. -* Being remote encourages a deeper level of personal thought and writing things down. -* It allows for uninterrupted work. -* It makes results clearer, which helps us hold people to account for outcomes rather than hours spent in the office. +* It encourages thoughtful, and intentional, written communication +* It creates space for lots of uninterrupted work. +* We judge performance based on real outcomes, not hours spent in an office. + +In addition to all the equipment you'll need, we provide [a budget to help you find coworking space](/handbook/people/spending-money#work-space), or to cover coffee shop expenses. Everyone also has a [$1,500 quarterly travel budget](/handbook/people/spending-money#budget-for-working-togethersocializing) for ad-hoc meetups. -## Extremely welcoming +## We're extremely welcoming -This is actually so important to us that it has [its own dedicated page](/handbook/company/grown-ups). +This is so important to us that it has [its own dedicated page](/handbook/company/grown-ups). -## Extremely transparent +## We're extremely transparent As the builders of an open-source product, we believe it is only right that we be as transparent as possible as a company. -This isn't just a meaningless corporate statement. Most of our communication happens publicly on GitHub, our roadmap is open for anyone to see, and our open source handbook explains everything from how we hire and pay team members to how we email investors! +This isn't just a meaningless corporate statement. Most of our communication happens publicly on GitHub, our roadmap is open for anyone to see, and our open-source handbook explains everything from how we hire and pay team members to how we email investors! Almost everything we do is open for anyone else to edit. This includes things like the contents of this very Handbook. Anyone can give direct feedback on work they think could be improved, which helps increase our responsiveness to the community. @@ -48,13 +46,13 @@ To accomplish this, we use [asynchronous communication](/handbook/company/commun Putting things in writing helps us clarify our own ideas, as well as allow others to provide better feedback. It has been key to our development and growth. -## Don't let others fail +## We give direct feedback early and often Everyone should help everyone else raise their game. Fatigue sets in when you complete a task, so it's easier for outsiders to help those creating the work to raise their game. We are direct about the quality of work. That doesn't always mean work needs to be completely polished, as it depends on the speed and impact of a task. Being great at [giving and receiving feedback](/handbook/people/feedback) is a key part of our culture. -## Bias for impact +## We bias for action If given a choice, go live. If you can't go live, reduce the task size so you can. @@ -63,16 +61,22 @@ If given a choice, go live. If you can't go live, reduce the task size so you ca Default to _not_ asking for permission to do something if you are acting in the best interests of PostHog. It is ok to ask for more context though. -## Have fewer meetings +## We're on the maker's schedule + +We're big believers in the importance of the [maker's schedule](http://www.paulgraham.com/makersschedule.html). If we have meetings at all, we'll cluster them around any stand-ups, so our day doesn't get split up. + +![Screenshot of an engineer's calendar at PostHog](https://res.cloudinary.com/dmukukwp6/image/upload/a0d634a2_bd3e_4229_ae8f_f98269a6c4f7_2268x1473_06595e2e80.jpg) + +On Tuesdays and Thursdays, we don't have internal meetings at all. Occasionally an external meeting will slip in on those days, such as interviews, but we try to keep those to an absolute minimum. -We're big believers in the importance of the [maker's schedule](http://www.paulgraham.com/makersschedule.html). If we have meetings at all (which we try to avoid, see _"Write stuff down"_ above), we'll cluster them around any standups so our day doesn't get split up. On Tuesdays and Thursdays, we don't have internal meetings at all. Occasionally an external meeting will slip in on those days such as interviews, but we try to keep those to an absolute minimum. +## We're structured for speed and autonomy -## Structured for speed and autonomy +Hiring high-performing and self-sufficient team members means we don't need the typical corporate processes that are designed to slow teams down. Instead, we're organized into [small teams](/handbook/team-structure), which prioritize speed by delegating decision-making autonomy as much as possible. -One of the benefits of hiring high-performing, self-sufficient, empowered team members is that we don't need to put in place some of the typical corporate structures and processes that can slow teams down. +Our [management approach](/handbook/company/management) is super simple - small teams report to their team leader, and each of the team leaders reports to one of our four execs. We don't want to create a fancy hierarchy of titles, as we believe this can lead, consciously or not, to people feeling less empowered to make changes and step on toes, especially if they are not in a 'senior' role. -We have optimised for this by introducing [Small Teams](/handbook/team-structure), which prioritise speed by delegating decision-making autonomy as much as possible. +It's up to you how to get things done. If you want to make a change, feel free to just create the pull request. If you want to discuss something more widely for a bigger piece of work, it might make sense to [use an RFC](/handbook/company/communication#requests-for-comment-rfcs) for a change inside your team. -Right now, our [management approach](/handbook/company/management) is super simple - James H, Tim and the team leaders are the only managers, and everyone else reports to one of them. We don't want to create a fancy hierarchy of titles, as we believe this can lead, consciously or not, to people feeling less empowered to make changes and step on toes, especially if they are not in a 'senior' role. +If your RFC could significantly impact other teams as well, it usually works best to book a call with them as well as it usually saves time – "fewer meetings" doesn't mean "no meetings", just that they should be meaningful and intentional, not routine. -It's up to you how to get things done. If you want to make a change, feel free to just create the pull request. If you want to discuss something more widely for a bigger piece of work, it might make sense to use an RFC for a change inside your team. If you want to ship something that could significantly impact other teams, it usually works best to book a call - communicating with the relevant team (and using this to particularly focus on who you're building for, the goals of your idea before you get into the tactics) as a meeting tends to work better and usually saves time. +Read [How you can help](/handbook/help) to understand how you can contribute to this culture. diff --git a/contents/handbook/company/lore.md b/contents/handbook/company/lore.md new file mode 100644 index 000000000000..879b88631cff --- /dev/null +++ b/contents/handbook/company/lore.md @@ -0,0 +1,41 @@ +--- +title: Lore +sidebar: Handbook +showTitle: true +--- + +## 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. + +* Yakko always had bad internet when demoing. Always. + +* wore a skin tight green all-body suit for months to improve his Zoom background game without us realizing. + +* has the same pose in 90% of PostHog photos. It's a reference to a meme. + +* 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](https://en.wikipedia.org/wiki/Mr_Blobby) is a creepy '90s TV character from the UK. This project was nightmarishly hard, which is why this character was fitting. + +* 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. + +* 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. + +* / 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 + +* / 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. + +* 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, 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.) \ No newline at end of file diff --git a/contents/handbook/help.md b/contents/handbook/help.md index 7de543c889b7..857d072eba3c 100644 --- a/contents/handbook/help.md +++ b/contents/handbook/help.md @@ -4,7 +4,15 @@ sidebar: Handbook showTitle: true --- -## Getting yourself up and running – your first week +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](/handbook/values) are a great place to start, as is as the [handbook page on culture](/handbook/company/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. @@ -16,76 +24,86 @@ This will require: 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 +## Ask for help, but only after you've tried first -### Don't assign issues to people +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: -You can list and categorize issues. +- If it's one of our own products that we build and sell: + - We expect you to [read our docs](/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. -If you want someone to see an issue, @mention them and/or Slack them the link. +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. -### Don't yolo merge +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. -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. +## Don't expect perfection -### PRs > issues > Slack +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. -Bias for impact. If you can just pick up the work, do so. We want a culture of individual contribution _not_ of delegation. +## Make it better -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 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. -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. +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." -### Do things as publicly as possible by default +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. -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. +## Don't wait for someone else -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). +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. -Internally, _everything_ can be shared apart from people issues – such as HR / personal (i.e. recruitment or health data). +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. -### Be proactive with community questions +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 -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 definitely don't need to have opinions on everything, but you should absolutely have opinions on your area of expertise. -You can find these in [posthog.com/questions](/questions). +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. -## Lore of PostHog / inside jokes +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. -A beginner's guide to some of our custom Slack emojis and various anecdotes you'll see and hear about. +## Look around corners -* Yakko always had bad internet when demoing. Always. +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? -* wore a skin tight green all-body suit for months to improve his Zoom background game without us realizing. +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. -* has the same pose in 90% of PostHog photos. It's a reference to a meme. +## Don't assign issues to people -* where X is a team member. Used in times of extremely impressive performance, unless used sarcastically. +You can list and categorize issues. If you want someone to see an issue, @mention them and/or Slack them the link. -* Mr Blobby. We once changed how we ingest session recording data, to use S3 blob storage. We called it Mr Blobby. [Mr Blobby](https://en.wikipedia.org/wiki/Mr_Blobby) is a creepy '90s TV character from the UK. This project was nightmarishly hard, which is why this character was fitting. +## Don't yolo merge -* will make you eat gelato at every offsite. +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. -* Sometimes people screenshot each other's faces and Zoom screens and use them as their backgrounds. Usually when an all-hands is too dry. +## PRs > issues > Slack -* 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. +Bias for action. If you can just pick up the work, do so. We want a culture of individual contribution _not_ of delegation. -* 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. +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_. -* / 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 +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. -* / 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. +## Do things as publicly as possible by default -* IPO promises. There is a list of these that is brought out at certain moments. You may see. +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. -* 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. +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). -* 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. +Internally, _everything_ can be shared apart from people issues – such as HR / personal (i.e. recruitment or health data). + +## Be proactive with community questions -* When we hit 10,000 GitHub stars, read every username on a live stream that took over six hours. +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. -* 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.) +You can find these in [posthog.com/questions](/questions). ## And if you don't work here... -[Apply for a job at PostHog](../careers)! +[Apply for a job at PostHog](../careers)! \ No newline at end of file diff --git a/contents/handbook/why-does-posthog-exist.md b/contents/handbook/why-does-posthog-exist.md index a4659276de11..9703419de7c2 100644 --- a/contents/handbook/why-does-posthog-exist.md +++ b/contents/handbook/why-does-posthog-exist.md @@ -10,18 +10,25 @@ Equip every developer to build successful products ## Our strategy -### Provide every tool needed to build successful products +### 1. Provide every tool needed to build successful products -Building a successful product is hard. It gets harder when you don't understand how your customers are using your product. +Building a successful product is hard; doing so when you don't understand your customers is even harder. -PostHog includes all the tools you need to understand how people use your product. All with one simple snippet. +We aim to offer every tool software teams need to find, sell to, get users, understand who they are, support them and improve their product experience. -### Start from the start +### 2. Get in first The tools we build help you from your first user to when your product is everything it could be. -This means PostHog gives you the best practices and the industry standard tools so that you can focus on what you do best - build successful products. There's a generous free tier, no-brainer pricing and data infrastructure that scales until IPO and beyond. +This means PostHog gives you the best practices, and the industry standard tools, so you can focus on what you do best: building successful products. -### Be the source of truth for customer and product data +We offer a generous free tier, no-brainer pricing, and data infrastructure that scales until IPO and beyond. -Traditionally, as companies scale, their data warehouse becomes the source of truth, and non-warehouse native tools (like product analytics) become less relevant as people lose trust in the data in them. By providing the data and data-intense tools in one place, we can enhance the power of our products (like product analytics), provide increased trust, and enable companies to build on top of the warehouse itself as they see fit, all without them having to set up a complex stack. +### 3. Be the source of truth for customer and product data + +Traditionally, as companies scale, their data warehouse becomes the source of truth, and non-warehouse native tools (like product analytics) become less relevant as people lose trust in the data in them. + +By providing the data and data-intense tools in one place, we can: +- Enhance the utility of our products when used together +- Increase trust in data by eliminating complex data stacks +- Provide all the tools companies need as they grow \ No newline at end of file diff --git a/src/navs/index.js b/src/navs/index.js index 79e0e89eb669..772284d185e5 100644 --- a/src/navs/index.js +++ b/src/navs/index.js @@ -163,10 +163,6 @@ export const handbookSidebar = [ name: 'Progression', url: '/handbook/people/career-progression', }, - { - name: 'Clubs', - url: '/handbook/people/clubs', - }, { name: 'Training', url: '/handbook/people/training', @@ -179,6 +175,14 @@ export const handbookSidebar = [ name: 'Feedback', url: '/handbook/people/feedback', }, + { + name: 'Clubs', + url: '/handbook/people/clubs', + }, + { + name: 'Lore', + url: '/handbook/company/lore', + }, { name: 'Onboarding', url: '/handbook/people/onboarding',