TSYSGroupBOD/TSYSGroupHandbook
2
0
Fork 0
Code Pull Requests Actions Packages Projects Releases Activity

merging in material that will be folded in

Browse Source
This commit is contained in:
Charles N Wyble - admin 2021-08-03 21:48:37 -05:00
parent ca1e9cebd4
commit e6f1eae94f
71 changed files with 5990 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

281
SourceMaterial/company/branding.md Normal file
View File

@ -0,0 +1,281 @@
---
title: Branding
sidebar: Handbook
showTitle: true
---
<br />
> **Note:** This page currently refers only to this website (posthog.com). It will later be updated to also include information about app.posthog.com following the rebrand.
## Resources
#### Figma: PostHog Branding
Refer to this [Figma Project](https://www.figma.com/file/8iM3Damgbl4PyHq6x8JJbu/PostHog-Branding?node-id=1%3A661) for a comprehensive overview of our colors, fonts, logos, and related resources.
#### Logos
To get access to our various logo formats, check out our [Media page](/media).
<br />
## Colors
Our three main colours are Blue, Orange, and Yellow.
##### <span style="color:#1D4AFF; font-size: 20px">■</span> Blue: #1D4AFF
##### <span style="color:#F54E00; font-size: 20px">■</span> Orange: #F54E00
##### <span style="color:#F9BD2B; font-size: 20px">■</span> Yellow: #F9BD2B
<br />
Accompanying these colours are Black and White, as well as a Dark Navy. Navy was introduced to tone down the blue against the yellow and orange, and provides a vintage feel to the page.
##### <span style="color:#000000; font-size: 20px">■</span> Black: #000000
##### <span style="color:#000000; font-size: 20px">□</span> White: #FFFFFF
##### <span style="color:#35416B; font-size: 20px">■</span> Dark Navy: #35416B
<br />
If possible, all artwork is to be made with these colours, as well as typography and social media images.
## Text
# H1
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 64px
* Line Height: 100
* Color: Black
* Opacity: 100%
## H2
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 48px
* Line Height: 70
* Color: Black
* Opacity: 100%
### H3
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 36px
* Line Height: 60
* Color: Black
* Opacity: 100%
#### H4
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 30px
* Line Height: 50
* Color: Black
* Opacity: 100%
##### H5
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 20px
* Line Height: 35
* Color: Black
* Opacity: 100%
###### H6
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 18px
* Line Height: 30
* Color: Black
* Opacity: 100%
#### Normal Text
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 16px
* Line Height: 25
* Color: Black
* Opacity: 100%
#### Small Text
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 16px
* Line Height: 20
* Color: Black
* Opacity: 30%
#### Note
If the text is secondary and you think it is less important feel free to put the opacity down to 60%. This will turn it to a dark gray color. This way, the user's eyes are brought to the darker text first and will read the lighter text if they need to.
The color of text should always be black - with the occasional lowered opacity to 60% when necessary.
## Numbers
For numbers you have two options, the first being *statement* and the second being *subtle*.
#### Statement Numbers
Statement numbers tend to be used on the landing page or pages where the product is being explained. Usually accompanied by visuals and a small amount of text.
**Specifications**
Statement No. Gosha Sans, bold, size 64px, colour - Blue (#1D4AFF), Orange (#F54E00), Yellow (#F9BD2B) alternating, opacity 100%.
#### Subtle Numbers
Subtle numbers are seen within docs and blogs, usually employed to give instructions or list things.
**Specifications**
Subtle No. Helvetica Neue, regular, size 20px, colour Yellow (#F9BD2B), opacity 100%
## Layout
When creating layouts on Figma, always start with the 'Desktop' Frame (1440 W x 1024 H).
Then create a grid with the following specifications:
- Rows: 14 | Stretch | Gutter: 10 | Color: 2%
- Columns: 24 | Stretch | Gutter: 10 | Color: 2%
This will give you the basis of PostHog's visual structure.
## Logos
The logo consists of both a symbol and type next to each other, but they can be used separately if need be. It is advisable for the website and product to keep the logo elements together. However, this isn't as important for other instances like swag or social media posts.
When putting the logo over color, type and symbol should all be white. Copies of this are available on the branding page on [Figma](https://www.figma.com/file/8iM3Damgbl4PyHq6x8JJbu/PostHog-Branding?node-id=1%3A661) for you to copy or download. If for whatever reason you need to make the logo all black, that is also fine, but only with a grey or white background.
## Icons
Under any H2 text there should be a divider. The divider helps separate the subtitle from the body text underneath. This icon is a long, thin rectangle with rounded edges.
**Dimensions:** 120 x 10px with a 10 corner radius.
On the landing page the dividers alternate between the three PostHog colours, Blue (#1D4AFF), Orange (#F54E00) and Yellow (#F9BD2B). However, on any other pages they are always Orange (#F54E00).
These dividers should be 35px below H2 text, and any body copy text below should be 35px from the divider.
## Background Textures and Color
To stop the website from looking dull we have employed the use of color and texture to give it some depth.
The three main colors are Orange (#F54E00) and Yellow (#F9BD2B), with a bit of Navy (#35416B).
Color blocks can be any size, but they must not fill more than one third of the screen. They must have a curved radius of 100 and usually have illustrations or icons over the top.
On top of the color blocks (or on its own) you could also use the halftone grey panel on opacity 20%. This gives the page some texture without distracting the USER from the text.
## Menus and Sidebars
Most of the menus on PostHog will be in tones of grey with pops of color for clicked pages. The most common menu featured on the bottom of the website page holds 5 sections for users to navigate the website. This menu is Mid Grey (#BEBEBE), and its size is 315px in height, while occupying the entire length of the screen in width.
Within the block are the 5 categories: Why PostHog, Resources, Community, Support, Company.
This uses 'Extra Large Text', as defined in the 'Fonts' section.
Underneath these 5 categories are the sub sections, which use 'Normal Text', as defined in the 'Fonts' section.
Side Menus, found on pages such as Docs, are to be a Light Grey (#F0F0F0) and 430px wide. The text and dropdown options should be fixed so that even when reading the consumer can still have quick access to other areas within the site.
The text in this sidebar should be Extra Large Text. The arrows that accompany the categories will be in Figma - they are a simple vector and the stroke needs to be 2.
When you click on a dropdown menu, the text and arrow turn Blue (#1D4AFF) to indicate that they have been clicked. The subcategories text should be Normal Text. When a subcategory is clicked this should also turn Blue, along with the Category text and arrow.
The last menu is the navigation menu that can be found in Docs. This uses Small Text.
Alongside the text on the left is a line with a small circle to indicate the part of the document you are in. Like the text, the line is black with an opacity of 30%. The stroke is 3, while the circle is 12x12px (white fill) with an inside stroke of 3 (orange).
Depending on what section of the text you are reading, the text will turn orange and the circle will be aligned with that selected text.
## Mobile Content
When transforming any desktop page to mobile please use the iPhone 8 frame on Figma.
### Headers
The header consists of the logo (206 W x 40.13 H) centered, a menu bar (36 W x 32 H) and a grey background (375 W x 110 H) in colour #F0F0F0. On the landing page the header is different, but generally the header should be consistent. The landing page header consists of the logo, (206 W x 40.13 H) centred, a menu bar (375 W x 390 H) in grey (#EDEDED) with halftone dots (This image can be found on the Figma file) (375 W x 390 H) laid over the top at 20% passthrough. This gives a subtle halftone effect.
### Text
#### H1
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 18px
* Line Height: 30
* Color: Black
* Opacity: 100%
#### H2
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 14px
* Line Height: 20
* Color: Black
* Opacity: 100%
#### H3
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 12px
* Line Height: 20
* Color: Black
* Opacity: 100%
#### H4
###### Font Specifications
* Family: Gosha Sans (Regular)
* Size: 10px
* Line Height: 20
* Color: Black
* Opacity: 100%
### Numbers
Follows the same principles as the Desktop format, using Statement and Subtle numbers.
**Statement Numbers**
Gosha Sans | Regular | Size 20 | Line Height 20 | Color: Yellow, Orange, or Blue | Opacity: 100%
**Subtle Numbers**
Helvetica Neue | Bold | Size 14 | Line Height 20 | Color: Yellow | Opacity: 100%
## Shapes and Dividers
Curved rectangle backgrounds, size (203 W x 170 H), with a curved radius of 20, in either Yellow (#F9BD2B), Orange (#F96132), or Navy (#35416B). These can be overlaid with halftone dots, at 20% pass through.
Dividers on the mobile format are similar to the desktop version but smaller (70 W x 7 H) and generally orange (#F96132), except for the landing page where they alternate between the three PostHog colours.

176
SourceMaterial/company/communication.md Normal file
View File

@ -0,0 +1,176 @@
---
title: Communication
sidebar: Handbook
showTitle: true
---
## Introduction
With team members across several countries, it's important for us to practice clear communication in ways that help us stay connected and work more efficiently.
To accomplish this, we use **asynchronous communication as a starting point** and stay as open and transparent as we can by communicating on GitHub through public issues and pull requests, as well as in our PostHog User and internal Slack.
## Our Communication Values
1. **Assume Positive Intent.** Always coming from a position of positivity and grace.
1. **Form An Opinion.** We live in different locations and often have very different perspectives. We want to know your thoughts, opinions, and feelings on things.
1. **Feedback is Essential.** Help everyone up their game in a direct but constructive way.
## Golden rules
1. Use **asynchronous communication** when possible: pull requests (preferred) or issues. Announcements happen on the appropriate Slack channels and [people should be able to do their work without getting interrupted by chat](https://m.signalvnoise.com/is-group-chat-making-you-sweat-744659addf7d#.21t7089jk).
1. Discussion in GitHub issues or pull requests is preferred over everything else. If you need a response urgently, you can Slack someone with a link to your comment on an issue or pull request, asking them to respond there. However, be aware that they still may not see it straight away (and that's OK in our book).
1. You are not expected to be available all the time. There is **no** expectation to respond to messages outside of your planned working hours.
1. It is 100% OK to ask as many questions as you have - please ask in public channels! If someone sends you a handbook link, that means they are proud that we have the answer documented - they don't mean that you should have found that yourself or that this is the complete answer. If the answer to a question isn't documented yet please immediately make a pull request to add it to the handbook in a place you have looked for it.
1. When someone asks for something, reply back with a deadline or by noting that you already did it. Answers like: 'will do', 'OK', or 'it is on my todo list' are not helpful. If it is small task for you but will unblock someone else, consider spending a few minutes to do the task so the other person can move forward.
1. By default, avoid creating private groups for internal discussions.
## Public by default
We make things public by default because [transparency](/handbook/company/culture#transparency) is core to our culture. The kinds of information we share falls into one of three buckets:
- _Public_ - most things, including our product, roadmap, handbook and strategy.
- _Shared internally_ - almost everything else, such as financial performance, security, fundraising and recruitment.
- _Private internally_ - personal team information, i.e. compensation, disciplinary issues.
Information that is not publicly shared is in areas with complex signals that can impact our ability to sell, raise money or are inappropriate to share more widely for personal privacy reasons.
We have two repos to centralize and document all internal communication. These are the source of truth for any internal information, and anything that should be written down (as established in these guidelines) should live here, not on Slack. This will make it easier when having to search for older stuff, sharing context between public and internal repos, and for newcomers to have all information they might need readily available.
### Company Internal
Repository can be found in https://github.com/PostHog/company-internal
Documents any company-wide internal information, in addition to any information related to People, Ops, Legal & Compliance, Finance or Strategy.
**Examples of information that should go here:**
- ✅ Hiring plans and discussions before we post a job ad
- ✅ People discussions, e.g. benefits, pensions, share options, org structure
- ✅ Onboarding/offboarding checklists
- ✅ Non-engineering team sprint planning
- ✅ Sensitive discussions around future positioning, customer strategy, fundraising, board meetings
**Examples of information that should NOT go here:**
- ❌ Any information that should be public (see guidelines on [public by default](http://localhost:8000/handbook/company/communication#public-by-default)), this should go in the public repositories (`posthog`, `posthog.com`, ...).
- ❌ Bug reports, security issues, or any other engineering-related discussions. These should go in the [Product Internal](#product-internal) repo.
- ❌ Billing issues, product or growth discussions. These should go in the [Product Internal](#product-internal) repo.
### Product Internal
Repository can be found in https://github.com/PostHog/product-internal
Contains internal information related to the PostHog product. Documents any non-public information (as established in these guidelines) that specifically relates to engineering, product, growth or design.
This repository was introduced to aid maintenance and day-to-day usage of internal repositories. Having these discussions together with the company-wide information proved unwieldly. More context on [this decision](https://github.com/PostHog/company-internal/issues/262).
<blockquote>
Please be sure to read the README of the repo for guidelines on how to file specific issues.
</blockquote>
**Examples of information that should go here:**
- ✅ Vulnerabilities (security bugs) reports
- ✅ Bug reports where most of the context of the report depends on customer's PII. *Some bug reports require screenshots, recordings, or some other information that contains PII and as such can't be public.*
- ✅ Post-mortems on outages, or other issues affecting a large portion of customers. The results of these should usually be made public though.
- ✅ Documentation of internal infrastructure, where if it was public knowledge could provide valuable information to an attacker.
- ✅ Experiment (A/B testing) results.
- ✅ Product or growth strategy discussions (unless they should be public).
- ✅ Interview exercises or questions for engineering, product, growth or design tasks that should not be public.
- ✅ Documentation of engineering or product requirements documents that can't be public (these should be quite rare).
- ✅ Billing or pricing-related discussions that is not yet public.
**Examples of information that should NOT go here:**
- ❌ Any information that should be public (see guidelines on [public by default](http://localhost:8000/handbook/company/communication#public-by-default)), this should go in the public repositories (`posthog`, `posthog.com`, ...).
- ❌ Any internal information that does not fall under the scope of purely engineering, product, growth or design. This should go in the [Company Internal](#company-internal) repo.
- ❌ Bug reports that don't contain any PII or where the PII only contains supporting information. In this case, file the bug under the relevant public repo and add a protected link to the additional information (e.g. a private Slack link, or a link to this repo).
## Written Communication
### GitHub
#### Everything Starts with a Pull Request
It's best practice to start a discussion where possible with a Pull Request (PR) instead of an issue. A PR is associated with a specific change that is proposed and transparent for everyone to review and openly discuss. The nature of PRs facilitate discussions around a proposed solution to a problem that is actionable. A PR is actionable, while an issue will inevitably lead to a longer period before the problem is addressed.
Always open a PR for things you are suggesting and/or proposing. Whether something is not working right or we are iterating on new internal process, it is worth opening a pull request with the minimal viable change instead of opening an issue encouraging open feedback on the problem without proposing any specific change directly. Remember, a PR also invites discussion, but it's specific to the proposed change, which facilitates focused decisions.
By default, pull requests are **non-confidential**. However, for things that are not public please open a confidential issue with suggestions to specific changes that you are proposing. When possible, consider not including sensitive information so the wider community can contribute.
Not every solution will solve the problem at hand. Keep discussions focused by _defining the problem first_ and _explaining your rationale_ behind the Minimal Viable Change (MVC) proposed in the PR. Have a bias for action and don't aim for consensus - some improvement is better than none.
#### Issues
GitHub Issues are useful when there isn't a specific code change that is being proposed or needed. For example, you may want to start an issue for tracking progress or for project management purposes that do not pertain to code commits. This can be particularly useful when tracking team tasks and creating issue boards.
However, it is still important to maintain focus when opening issues by defining a single specific topic of discussion as well as defining the desired outcome that would result in the resolution of the issue. The point is to not keep issues open-ended and to prevent issues from going stale due to lack of resolution. For example, a team member may open an issue to track the progress of a blog post with associated to-do items that need to be completed by a certain date (e.g. first draft, peer review, publish). Once the specific items are completed, the issue can successfully be closed.
### Slack
Slack is used for more informal communication, or where it doesn't make sense to create an issue or pull request. Use your judgment to determine the appropriate channel, and whether you should be chatting publicly (default) or privately.
Also keep in mind that, as an open source platform, PostHog has contributors who don't have access to Slack. Having too much context in a private location can be detrimental to those who are trying to understand the rationale for a certain decision.
**Slack etiquette**
Slack is used differently in different organizations. Here are some guidelines for how we use Slack at PostHog:
1. Keep `#general` open for company-wide announcements.
1. `@channel` or `@here` mentions should be reserved for urgent or time-sensitive posts that require immediate attention by everyone in the channel. (Examples: changing a meeting invite URL just before a meeting, or soliciting urgent help for a service disruption, where you're not sure who is immediately available)
1. Make use of threads when responding to a post. This allows informal discussion to take place without notifications being sent to everyone in the channel on every reply.
1. When possible, summarize multiple thoughts into a single message instead of sending multiple messages sequentially.
### Google Docs and presentations
Never use a Google Doc / presentation for something non-confidential that has to end up on the website or this handbook. Work on these edits via commits to a pull request. Then link to the pull request or diff to present the change to people. This prevents a duplication of effort and/or an out of date handbook.
We mainly use Google Docs to capture internal information like meeting notes or to share company updates and metrics. We always make the doc accessible so you can comment and ask questions.
Please avoid using presentations for internal use. They are a poor substitute for a discussion on an issue. They lack the depth, and don't add enough context to enable asynchronous work.
### Email
1. Internal email should be avoided in nearly all cases. Use GitHub for feature / product discussion, use Slack if you cannot use GitHub, and use Google Docs for anything else.
1. The only uses we have for internal email are:
- Obtaining approvals for legal things
- Sending some types of more official company documents (e.g. job offers, payroll forms)
- Communicating with external partners
### Writing Style
1. We use American English as the standard written language in our public-facing comms, including this handbook.
1. Do not use acronyms when you can avoid them. Acronyms have the effect of excluding people from the conversation if they are not familiar with a particular term.
1. We use the [Oxford comma](https://www.grammarly.com/blog/what-is-the-oxford-comma-and-why-do-people-care-so-much-about-it/).
1. Do not create links like "here" or "click here". All links should have relevant anchor text that describes what they link to. Using meaningful links is important to both search engine crawlers (SEO) and people with accessibility issues.
## Internal Meetings
PostHog uses [Zoom](https://zoom.us/) for video communications. Zoom also has useful plugins for [Google Calendar](https://chrome.google.com/webstore/detail/zoom-scheduler/kgjfgplpablkjnlkjmjdecgdpfankdle?hl=en-US) and Slack which you may wish to use.
Use video calls if you find yourself going back and forth in an issue/via email or over chat. Sometimes it is still more valuable to have a 40+ message conversation via chat as it improves transparency, is easy to refer back to, and is friendlier to newcomers getting up to speed.
1. Most scheduled meetings should have a Google Doc linked or a relevant GitHub issue. This contains an agenda, including any preparation materials.
1. Please click 'Guests can modify event' so people can update the time in the calendar instead of having to reach out via other channels. You can configure this to be checked by default under [Event Settings](https://calendar.google.com/calendar/r/settings).
1. Try to have your video on at all times because it's much more engaging for participants. Having pets, children, significant others, friends, and family visible during video chats is encouraged - please introduce them!
1. As a remote company we are always striving to have the highest fidelity, collaborative conversations. Use of a headset with a microphone, is strongly recommended - use your company card if you need.
1. Always advise participants to mute their mics if there is unnecessary background noise to ensure the speaker is able to be heard by all attendees.
1. You should take notes of the points and to-dos during the meeting. Being able to structure conclusions and follow-up actions in real time makes a video call more effective than an in-person meeting. If it is important enough to schedule a meeting, it is important enough to have taken notes.
1. We start on time and do not wait for people. People are expected to join no later than the scheduled minute of the meeting, and we don't spend time bringing latecomers up to speed.
1. It can feel rude in video calls to interrupt people. This is because the latency causes you to talk over the speaker for longer than during an in-person meeting. You should not be discouraged by this, as the questions and context provided by interruptions are valuable.
1. We end on the scheduled time. Again, it might feel rude to end a meeting, but you're actually allowing all attendees to be on time for their next meeting.
1. It is unusual to smoke or vape in an open office, and the same goes for video calls - please don't do this out of respect for others on the call.
For external meetings, the above is also helpful. We also have separate guidance on [how to run a great demo](/handbook/growth/sales/demos).
### Indicating Availability
1. Put your planned away time including holidays, vacation, travel time, and other leave in your own calendar.
1. Set your working hours in your Google Calendar - you can do this under _Settings_ > _Working Hours_. This is helpful as we work across different timezones.
### Google Calendar
We recommend you set your Google Calendar access permissions to 'Make available for PostHog - See all event details'. Consider marking the following appointments as 'Private':
1. Personal appointments
1. Particularly confidential & sensitive meetings with third-parties outside of PostHog
1. 1-1 performance or evaluation meetings
1. Meetings on organizational changes

80
SourceMaterial/company/culture.md Normal file
View File

@ -0,0 +1,80 @@
---
title: Culture
sidebar: Handbook
showTitle: true
---
So, what's it like working at PostHog?
<iframe width="560" height="315" src="https://www.youtube.com/embed/rRwzJiljpSA" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
## All remote
Our [team](/handbook/company/team) 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:
* We can hire [amazing people](/handbook/company/team) 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.
## Diverse & inclusive
This is actually so important to us that it has [its own dedicated page](https://posthog.com/handbook/company/diversity).
## 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!
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.
We're committed to much more than just [public code](/handbook/company/values#we-are-open-source).
## We write everything down
We're an all-remote company that allows people to work from almost anywhere in the world. With team members across many countries, it's important for us to practice clear communication in ways that help us stay connected and work more efficiently.
* It creates clear and deep thought.
* We have an open core business model. This helps the community understand our decision-making.
* It is usually clearer than a conversation, so everyone can row in the same direction.
* It is very leveraged as we grow a large community and look to hire people around the world.
To accomplish this, we use [asynchronous communication](/handbook/company/communication) as a starting point and stay as open and transparent as we can by communicating through public issues, pull requests, and (minimally) Slack.
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
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 of our culture.
## Bias for action
If given a choice, go live. If you can't go live, reduce the task size so you can.
* We are small, and can only win based on speed and agility.
* Going live forces a level of completion, on which you can build.
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 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.
## Structured for speed and autonomy
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.
We have optimised for this by introducing [Small Teams](/handbook/people/team-structure/team-structure), which prioritise speed by delegating decision-making autonomy as much as possible.
Right now, our [management approach](/handbook/company/management) is super simple - James H, Tim and Charles 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.
## A day in the life
<iframe width="560" height="315" src="https://www.youtube.com/embed/xlODCLrZyvM" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

64
SourceMaterial/company/diversity.md Normal file
View File

@ -0,0 +1,64 @@
---
title: Diversity and Inclusion
sidebar: Handbook
showTitle: true
---
PostHog is proud to be an international group of misfits. You can't disrupt an industry by thinking the same way as everyone else.
## Diversity & inclusion
Diversity refers to the traits and characteristics that make people unique. While there are an infinite number of differences in humans, most people subconsciously define diversity by categories including gender, race and age.
Inclusion refers to the behaviours and social norms that make people feel welcome. This includes everyone being treated fairly and with respect, and ensuring that everyone has equal access to opportunities and being able to contribute fully to the company’s success.
We are aware that Diversity & Inclusion efforts are a lifelong work and that we will never have it all figured out and ‘done’. This means we will have to constantly learn and develop. This also means we will make mistakes - the important thing is that we learn from them. At PostHog, everyone is committed to building a culture of diversity, inclusivity and belonging.
## How diversity helps us
At PostHog, we view diversity as a tactic, like paying people towards the top of the market, or communicating company goals to set context for our team. There is plenty of research into the link between highly diverse teams and increased [performance](https://www.ucdenver.edu/docs/librariesprovider68/default-document-library/jmna-articles-bonuscontent-2.pdf?Status=Temp&sfvrsn=84c0fb9_2) and [innovation](https://www.bcg.com/en-us/publications/2018/how-diverse-leadership-teams-boost-innovation).
In order to build the most diverse team, we have introduced the [Rooney rule](https://en.wikipedia.org/wiki/Rooney_Rule) to our Recruitment process. Originally implemented by the National Football League (NFL) but increasingly used by companies, the Rooney rule requires at least one person of an underrepresented minority to be considered for every open position.
In the context of tech and startups, categories of people who are underrepresented include those who identify as:
* A person of color
* Indigenous
* Women
* Members of the LGBTQ+ community
* Being from a working-class background
* Those who struggle with mental illnesses
* Having a disability whether visible or not
Based on the Rooney rule, we are committed to not only consider a person of an underrepresented minority, but to bring at least one of them into the [final stage of the interview process](/handbook/people/hiring-process/#posthog-superday). In order to be successful with our approach, we focus on diversifying the top of the recruitment funnel. We are committed to not making an offer until we have brought an underrepresented candidate into the final stages.
We are currently trialing this approach and we still have some limitations to overcome:
* We don’t currently track diversity data as part of the application process. While some characteristics of underrepresentation will be visible in the interview process, others are not.
* For some roles (e.g. Full-Stack Engineer), we hire constantly. This makes the Rooney rule a little harder to make meaningful, but we also want to make sure to keep the pipeline as diverse as possible.
* Speed is a core PostHog value, and that includes hiring. So we need to work out how to be fast, deliver a great candidate experience, while also doing a better job at diversifying our hiring.
## An inclusive place to work
We are always keen to find ways to make the culture at PostHog as inclusive as possible. We are by no means perfect, but we are committed to acting with positive intent and pushing ourselves to improve.
We don't just state that we care - these are some of the things we've implemented so far:
* [All remote](/handbook/company/team) - so we can hire people from any country in the world. We have people in ~10 countries, with no office. We also provide everyone with $200/month to use on a coworking space of their choice.
* [Asynchronous and transparent communication](/handbook/company/communication) - so people can get the context they need to work effectively across multiple time zones and on schedules that suit them.
* [Unlimited vacation policy](/handbook/people/time-off/#permissionless-time-off) with mandatory minimum time off - so you can fit work around your life.
* Very [generous parental leave](/handbook/people/time-off/#parental-leave) - so those raising families can do so while still working for us.
* Very generous and [transparent pay](/handbook/people/compensation) - to reduce the financial stress that often comes with working for startups, or prevents many from even applying.
* Proactive recruitment to encourage underrepresented groups of people to apply - so we are meeting with a balanced group of applicants for every role.
* Anyone can contribute to [our handbook](/handbook/) - so if we miss something, others can ask for a change in our policy!
* [Paid SuperDay](/careers#the-process) as part of the hiring process - to allow you to see what it's really like working on the team, before starting.
* [Training budget](/handbook/people/training#training-budget) for those in roles where we don't have lots of existing experience as a company.
* Life story Fridays (when we have a new team member, we'll ask them to present their life story for an hour on a Friday) - so you have more context on the points of views of others in the team.
* [Sponsored visas](/handbook/people/hiring-process#visa-sponsorship) for those who need them.
* Health insurance for those from countries that do not provide this freely.
* Mental Health Counselling provided via our partner [Spill](https://www.spill.chat/).
Are you a potential candidate reading this? [Let us know](mailto:careers@posthog.com) how we can do a better job!
## Thinking about working here?
Check out our [careers](/careers) page to see if there could be a fit, or drop us [an email](mailto:careers@posthog.com).

123
SourceMaterial/company/intro.md Normal file
View File

@ -0,0 +1,123 @@
# TSYS Group overview and introduction
## Introduction
Welcome to the TSYS Group Company Handbook. This explains how we operate as a company.
If you are considering joining TSYS Group, or have recently joined, this section will help you navigate the Handbook and highlight some of the most important things you should know about supporting the TSYS Group mission.
The reason for making this transparent is to improve our communication, one of our [key values](/board/values).
Anyone can submit a pull request to suggest updates or enhancements to this handbook through the [TSGHandbook repo](https://git.turnsys.com/TSGBod/TSGHandbook)
We treat this handbook as part of our Docs. Learn how to [update them](/docs/updating-documentation).
## Big picture
We encourage everyone to start at the beginning first before diving in. We have a strong bias for action, but it is still worth taking a step back and looking at the 'why' first. This helps ensure sure you have the right context and are working on the right things.
You should start with the '[Company](//company/story.md)' section and work your way through everything there. It is not a lot to read. In particular, the sections on our [Strategy](/strategy/strategy) and [Roadmap](/strategy/roadmap) are a must-read for everyone.
Next, familiarize yourself with our approach to [Culture](//company/culture) and our [Values](/company/values). You might take a bit of time to adjust to TSYS Group way of working, and that's ok! In addition to bias for action, you may find that you have a lot more autonomy than you are used to here - you'll realise very quickly that you _shouldn't_ be asking for permission for most things.
## How we work
Now it's time to dive into some of the more practical stuff - these are the most important pages:
1. [Communication](/company/communication) - we have a distinctive style. If TSYS Group is your first all-remote organization, this page is especially helpful.
2. [Team structure](/people/team-structure/team-structure) - we are structured in Small Teams. These pages will help you get the lay of the land, and who does what.
3. [Management](/company/management) - we have a relatively unusual approach to management, and it is possible that you will not be familiar with our approach.
### Working in Git
We use [GitHub](https://git.turnsys.com/explore) for _everything_, including non-engineering task management. This might take some getting used to if you are non-technical.
We use Projects to track the status of Issues in an easily viewable way. It is up to each Small Team to decide how to manage their tasks, and you'll find most have a dedicated Project - [full list here](https://github.com/orgs/PostHog/projects) - and run two week sprints. As part of the onboarding process, you will be invited to the relevant planning meetings.
## Onboarding
Our [onboarding checklist](/people/onboarding) will take you through all the main admin bits you need to get set up, The list will vary slightly depending on where you are based and which Small Team you are in. The People team will create an Issue in the Internal repo to track your personal checklist.
### Other useful resources
It is worth trying to at least read the entire Handbook once, even if you skim over the other sections. If you are engineer, the CTO and CIO sections will obviously be very useful, but you might want to know how we're approaching our Sales (CRO) or Marketing (CMO) strategy or other aspects. Everything is here in this handbook for everyone to read.
## TSYS Group Mission
TSYS Group is a collection of entities whose common goal is providing internet connectivity to everyone in all of North America (in particular rural areas) for $25.00 per user
per month.
## Who does TSYS Group serve?
Everyone in North America and international waters who wants internet connectivity.
## What does the TSYS Group do?
The TSYS Group seeks to handle every aspect of internet connectivity, soup to nuts. From design and manufacture of the equipment, to
educating users on it's safe and efficient operation to raising the capital for the venture.
## Where can you contact TSYS Group?
Website: www.turnsys.com
## TSYS Group Brands
### Redwood Group
The below table documents the not primarily for profit entities performing capital raising and management for TSYS Group entities and their members.
| Entity | Description | Website |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------ |
| Redwood Group LLC | Sibling organization to TSYS Group for all capital raising and management | <https://www.redwgr.com> |
| Redwood Springs Capital Partners Management Co LLC | management company of the various funds setup to finance TSYS Group operations | <https://www.rwscp.net> |
| Redwood Family Office LLC | Wealth management/healthcare/estate planning/tax advice broker for LLC members and their families | <https://www.redwfo.com> |
### Non Profit Properties
The below table documents the non profit entities performing the educational, advocacy, lobbying and legislative functions for TSYS Group.
| Entity | Description | Website |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------- |
| Americans For A Better Network INC | A non profit (seeking 501c3 status) to educate americans about internet provider choices | <https://www.afabn.org> |
| Free Network Foundation INC | A defunct 501c3 (replaced by AFABN) | <https://www.thefnf.org> |
| Free Network Foundation INC | (wiki) comprehensive body of knowledge about community networking | <https://commons.thefnf.org> |
| Free Network Foundation INC | (static files) Assets (pdfs etc) linked from blog/wiki | <https://staticbits.thefnf.org> |
| Side Door (Solutions) Group INC | A non profit (seeking 501c4) / PAC to drive the necessary legislative and executive changes to enable internet for all | <https://www.sidedoorgroup.org> |
| TSYS Group Non Profit Portal | Landing page for non profits | <https://nonprofit.turnsys.com> |
### For Profit Properties
The below table documents the not primarily for profit entities performing the R&D and providing supporting services functions for TSYS Group.
| Entity | Description | Website |
| ------------------------------------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------ |
| Axios Heart Studios LLC | Art, 2d,3d and other fabrication services for TSYS Group | <https://www.axiosheartstudios.com> |
| Suborbital Systems Development Company LLC | Manufacturer of Morse product line - technical blog and information | <https://www.suborbital-systems.com> |
| Suborbital Systems Development Company LLC | Manufacturer of Morse product line - product page | <https://www.meetmorse.com> |
| RackRental LLC | network and lab equipment rental by the hour for training, config testing, competitive testing | <https://www.rackrental.net> |
| Team Rental LLC | HR/staffing of IT/dev professionals (2 million net new job goal by 2025) | <https://www.teamrental.net> |
| Known Element Enterprises LLC | IT/business back office services | <https://www.knownelement.com> |
| Your Dream Name Here LLC | Business in a box | <https://www.yourdreamnamehere.com> |
| The PeerNet LLC | Community, media, public relations / (live/time shifted) streaming/broadcast service | <https://www.thepeernet.com> |
| The PeerNet LLC | Software platform powering ThePeerNet.com service | <https://www.ezpodstack.org> |
### Coop Properties
The below table documents the fairshares cooperatives for financing, building, owning and operating community networks.
| Entity | Description | Website |
| ----------------------------------------- | -------------------------------------------------------- | -------------------------------- |
| High Flight Network Finance Company LLC | Financing network builds | <https://www.hfnfc.net> |
| High Flight Network Operating Company LLC | User owned/operated network backbone | <https://www.hfnoc.net> |
| KickFund.me LLC | Crowdfunding of network and other infrastructure builds | <https://www.kickfund.me> |
| The Campus Trading Co LLC | treasury/investment management/market and other research | <https://www.thecampustrade.com> |
### Misc Properties
| Entity | Description | Website |
| -------------------- | -------------------------------------- | -------------------------------- |
| CNWCO LLC | Charles Wyble blog | <https://www.reachableceo.com> |
| Turn Net Systems LLC | Overall entity for many subsidiary LLC | <https://www.turnsys.com> |
| Turn Net Systems LLC | Governance information for TSYS group | <https://governance.turnsys.com> |
Please see <https://www.turnsys.com> for more information.

69
SourceMaterial/company/management.md Normal file
View File

@ -0,0 +1,69 @@
---
title: Management at PostHog
sidebar: Handbook
showTitle: true
---
As we grow, we'll increase the number of managers at PostHog. Here's what a manager at PostHog looks like.
## Defining the role of manager
A manager at PostHog has two tasks:
1. Making sure their direct reports are happy and productive
1. Setting the right context for direct reports to do their job
That's it.
A manager at PostHog is _not_ responsible for:
1. Setting compensation (we have transparent compensation)
1. Setting tasks for their direct reports
1. Creating a career path (career paths should be transparent and documented, and for now centrally managed)
1. "Approving," whether that's projects, expenses, days off or accounts (people should have admin access by default to most things)
1. Giving feedback (managers give feedback in their capacity as individual contributor, but so does everyone else)
## What does setting context mean?
At PostHog, we exclusively hire people that are the best in their field.
That means managers won't need to spend time telling their direct reports what to do.
However, for those people to make the best decisions, they need context. That context can be:
- what a customer said was or wasn't important to them
- what the metrics are saying needs to be improved
- what another team in the organisation is working on
- what the overall goals are for PostHog
The shift here, and the biggest difference between PostHog and other places, is that in the end it is up to the individual to make the decisions.
All you can do as a manager is set context. From there, you'll have to trust that we've made the right hiring decisions and that the individual is able to execute on that. If they can't, we have a [generous severance policy](/handbook/people/compensation#severance).
Decisions aren't just about buying a piece of software or choosing a color for a button. It's also about what to work on, what to invest time in, or where to take entire parts of our product.
Again, we've hired the best people and have high talent density, so we trust everyone to make these kinds of decisions.
As a manager, it's tempting to see yourself as the sole owner of all the information, and give it out sparingly.
People will come to you often with questions (because they don't have the context) and when they do you'll get more validation that holding all the context yourself makes you an Important Person.
What managers should aim for at PostHog is to make themselves obsolete. Share as much context as possible, preferably in written form in a public channel. That way everyone will be able to do their best work.
## Part-time managers
Because of the relatively short list of tasks that managers have, management at PostHog is a part-time job.
That means everyone, including the CEO and CTO, still spend the majority of their time on practicing what they do best (which likely isn't management!).
As an engineer, you wouldn't respect the opinion of someone who can't code on a coding specific question.
As a designer, you really want your manager to have an eye for design.
As an operator, you want to be managed by someone who has scaled a business.
That's why it's important for managers to keep practising their craft.
Management tasks do come first, as giving context to your team tends to have a multiplying effect vs getting one more PR out. After that though, it's back to work.
## Anti silos
There are teams at PostHog that need to work across functions, so we have an anti-silo approach when it comes to the tasks that people work on.
That means:
* Task setting happens transparently in [Small Teams](structure). Anyone can read notes from or show up to any of the sprint planning meetings.
* Anyone can give feedback to anyone else on their priorities, and it's our expectation they do so.
* Every [Small Team](structure) has complete control over what they ship.
This has the added benefit of cross functional teams forming as needed, whilst people having a specialist manager (i.e. an engineer managing engineers) as far as we are able.

21
SourceMaterial/company/security.md Normal file
View File

@ -0,0 +1,21 @@
---
title: Security
sidebar: Handbook
showTitle: true
---
It is critical that everyone in the PostHog team follows these guidelines. We take people not following these rules very seriously - it can put the entire company and all of our users at risk if you do not.
## Password Managers
You **must** make use of a password manager; it simply isn't possible to use appropriate passwords securely without one.
PostHog uses [1password](https://1password.com/) for storing all passwords.
## Password Strength
Please use strong passwords for everything. Use the 1password password generator that comes with the app in all cases. Do not repeat passwords across different sites.
## Dual Factor Authentication
You should enable dual factor authentication for any account where the option is available, especially those which are core to your work.

35
SourceMaterial/company/standups.md Normal file
View File

@ -0,0 +1,35 @@
---
title: Daily Standups
sidebar: Handbook
showTitle: true
---
While we default to [written and asynchronous communication](/handbook/company/communication), we find that having a few regular touch points for the whole team to come together on a call useful for sharing certain types of information, strengthening our culture and discussing more dynamic issues in real time.
We keep these minimal in terms of time expectation - no more than 2hrs total per week. They are usually scheduled around 8.30am PDT/4.30pm GMT to allow people across multiple timezones to attend more easily.
You should have been invited to our regular standups as part of your [onboarding](/handbook/people/onboarding).
## Daily Standup Schedule
- **Monday** - PostHog News. Members of the team share company-wide updates about things like recruitment, product metrics and commercial performance. The content of these meetings is always confidential. We then go around the team and each person summarises what they did last week and what they plan to do this week.
- **Tuesday** - No standup (we keep Tuesdays meeting-free).
- **Wednesday** - Anyone can propose to have a meeting about any topic. Stuck with a technical problem? Want to get feedback on something? Want to brainstorm? Schedule those meetings during this timeslot and advertise in Slack.
- **Thursday** - No standup (we keep Thursday meeting-free).
- **Friday** - These alternate between Sprint Planning and Life Stories.
### Sprint Planning
This is a longer 45min meeting every other Friday where we review the previous two week sprint and then outline what we want to achieve in the next 2 weeks. We split into Engineering and Not Engineering teams for this, but schedule the meetings sequentially so that anyone can sit in on both if they would like to.
You will be asked to add your comments to the relevant GitHub planning issue in advance of each meeting on Slack the day before.
### Life Stories
Alternating with Sprint Planning, Life Stories we hear from 1-2 members of the team who share a bit about themselves with us. No particular format - it's one of the few times a presentation makes sense! Each team member has up to 30min, inclusive of Q&A. These are a fun opportunity for us to get to know a bit about the people we work with, what cool things we didn't know about them, and whether or not they believe that pineapple belongs on pizza...
## Standup Bot
Outside of the above meeting schedule, we still write up our tasks in a standard format in Slack - you will be prompted by Standup Bot. You will be asked what you did since the last standup, what you plan to do before the next one, and any issues or blockers you might have.
This means that everyone still has visibility and context for what everyone else is working on, but delivered in a format that is quick to digest and easier to respond to. We don't do this on meeting-free Tuesdays and Thursday, to minimise interruptions.

58
SourceMaterial/company/story.md Normal file
View File

@ -0,0 +1,58 @@
---
title: Story
sidebar: Handbook
showTitle: true
---
## The start - January, 2020
PostHog was founded by James and Tim on January 23rd, 2020.
We started working together on a startup in August 2019 with the first idea being to help engineers manage technical debt. It didn't work out, but we realized the power of treating growth as an engineering problem. We also knew that many engineers struggle to understand their impact on their users.
There are plenty of product analytics tools out there, but all the alternatives are SaaS-based. While they are very powerful, they can be frustrating for developers. From our perspective, these tools can be problematic because:
* We didn't want to send all our user data to 3rd parties.
* We wanted full underlying data access.
* They don't give you choice and control over pricing.
## Launch - February, 2020
We got into YCombinator's W20 batch, and just a couple of weeks after starting realized that we needed to build PostHog.
We launched on [Hacker News](https://news.ycombinator.com/item?id=22376732) with our MVP, just 4 weeks after we started writing code.
The response was overwhelmingly positive. We had over 300 deployments in a couple of days. 2 weeks later, we'd gone past 1,500 stars on [GitHub](https://github.com/PostHog/posthog).
Since then, we've realized that the same reasons that PostHog was appealing to us as individual developers are the reasons why many enterprise customers also find the software is very appealing. We got a lot of inbound demand, and realized we weren't just onto a cool side project, we were onto what could be a huge company.
## \$3M Seed round - April, 2020
After we finished YCombinator, [we raised a \$3.025M seed round](../../blog/raising-3m-for-os). This was from YCombinator's Continuity Fund, 1984 Ventures. You can learn more about how we raised the money.
As we started raising, we started hiring. We brought on board [Marius, Eric and James G](../../handbook/company/team).
## First 1,000 users - May, 2020
We kept shipping, people kept coming!
## Billions of events supported - October, 2020
This was a major update - PostHog started providing [ClickHouse support](../../blog/the-posthog-array-1-15-0#clickhouse-). Whilst we launched based on PostgreSQL, as it was the fastest option, this enabled us to scale to billions of events.
## Building a platform - November, 2020
We realized that our users, whether they're startups, scale ups or enterprises, have simple needs across a broad range of use cases in understanding user behavior.
PostHog now supports [product analytics](../../product-features/trends), [feature flags](../../product-features/feature-flags), [session recording](../../product-features/session-recording) and [plugins](../../product-features/plugins) (beta).
## $9M Series A - December, 2020
We kept growing organically and took the opportunity to raise a \$9M Series A, topping our funding up to [$12M](../../blog/posthog-announces-9-million-dollar-series-A) led by [GV](https://www.gv.com/) (formerly Google Ventures).
Our focus remains firmly product, engineering and design oriented, so we're increasing our team in those areas.
We've now people in 10 countries around the world, and still feel like it's day one.
Everyone takes a mandatory two weeks off over Christmas to relax.

59
SourceMaterial/company/team/charles-cook.md Normal file
View File

@ -0,0 +1,59 @@
---
title: Charles Cook's README
sidebar: Handbook
showTitle: true
---
This guide might be helpful in working with me.
## Bio
Born and raised in the United Arab Emirates, I'm half British, half Lebanese, and lived in a variety of places growing up across the Middle East, Africa and Europe. Now based in London, I live with my wife Steph and son Remy, who was serendipitously born right at the beginning of lockdown here in the UK.
I take care of all things business ops-related at Posthog, across finance, people, legal and basically anything else that doesn't involve actually building the product! Posthog is now my 3rd startup - I was previously COO at [Vitl](https://vitl.com), (personalised nutrition), and before that I was Director of Product at [ROLI](https://roli.com) (electronic music products).
I'm a big fan of terrible jokes, beautifully crafted sandwiches and looking at [designer houses](https://www.themodernhouse.com/) I will never live in. I like to occasionally torment my son with my piano playing and spend more time than is probably reasonable making lists of things, à la [High Fidelity](https://en.wikipedia.org/wiki/High_Fidelity_(film)).
## Areas of responsibility
- Making sure all our business operations run smoothly
- All of our finance stuff (accounting, tax etc.)
- Any legal matters, including compliance and privacy
- Sales operations, ie. making sure we follow up with customers, generating quotes
- Customer support oversight
- I contribute a lot to our people and culture initiatives
- Investor relations and fundraising ops, supporting Tim and James
- I do regular 1-1s with most of the team to chat about non-work stuff
## Quirks
- I'm hyper responsive across any channel (email/Slack/whatever) - don't worry about interrupting me if you have a question! Always happy to take a quick call too if you prefer.
- I definitely err on the side of speed at the expense of polish. Sometimes this means I don't take enough time to bring other people on board when I should.
- I tend towards being generous with spending money, _especially_ if it means getting something done faster.
- I make a lot of jokes at my own expense. I encourage you to as well.
- You don't have to 'earn' my trust - I like to assume high trust with people I work with from the start and go from there.
- I don't respond to work emails at evenings or weekends. I do have Slack on my phone if something really urgent comes up though. Please don't abuse this.
## What I value
- [Brutal honesty, delivered kindly](https://feld.com/archives/2014/08/brutal-honesty-delivered-kindly.html).
- Kindness generally, in fact.
- Not taking yourself too seriously and keeping a sense of perspective.
- Speed - I can get frustrated if people don't move as quickly as I like to.
- People who understand privilege and how it affects power dynamics.
- Taking on something that is outside your comfort zone if no one else is available.
## How I can help you
- I can help you figure out where X account is, what our Y number is or where we keep Z thingy.
- I can help you unblock any legal or financial issues. Anything admin-related really.
- I can be a listening ear any time you need, for work or non-work stuff.
- I can provide you with general career advice, especially if you are interested in people management.
## How you can help me
- Tell me what we could be doing better from a company-building perspective. I'm particularly interested in unusual ideas.
- Let me know when I need to slow down and do something to a higher standard.
- I try to make sure our ops systems for things like expenses have an absolutely minimal impact on your time. Please don't make me chase you for boring admin stuff like that.
- If you need something from me, let me know when you need it by. Otherwise I'll probably do it immediately.

68
SourceMaterial/company/team/tim-glaser.md Normal file
View File

@ -0,0 +1,68 @@
---
title: Tim Glaser's README
sidebar: Handbook
showTitle: true
---
This guide might be helpful in working with me.
## Bio
I've been coding since I've been 11, which isn't as long ago as I'd like it to be. Someone first paid me to write code when I was 13 (though I'm sure they regretted it) and someone else gainfully employed me when I was 16.
Originally from the Netherlands, though I quickly moved to London (I do not generally enjoy nice weather) where I joined Arachnys and shortly met James Hawkins. I went from being a software engineer, to product manager, to "leading" an R&D team, which consisted of just me.
After four years I thought it was time to go do something else and had lined up a new job. Roughly 37 seconds after it was announced James wanted to "grab a beer." While plying me with alcohol, he convinced me to give up this fancy new job and instead start a startup with him.
In my 'spare' time, I fall down snowy mountains, wrestle in the mud over an egg-shaped ball and watch a lot of Bondi beach in order to perfect my Australian accent.
## Areas of responsibility
- Build the engineering team
- Make sure we move fast
- Make sure the engineering team has all the context it needs
- Make sure the engineering team is happy
- Make sure we're building in the right direction
- Sounding board to James Hawkins (CEO)
## Quirks
- I come out with opinions quickly and strongly. They are actually weakly held so please push back when you disagree, I'll take it well.
- I will likely talk way too much. Please just interject/talk over me.
- A lot of what I say sounds like a definitive statement ("this is what we're going to do") when I actually mean "here's something we could do".
- I'm easily distracted in meetings and can come across as disinterested. It's something I'm working on but if you notice I'm drifting off please mention it.
- Weekends are holy to me and I'll almost never work on a weekend (and don't expect anyone else to!). I also don't like to have meetings after ~8pm my time, or before 10-11am.
- Please don't message me "hey" and then spend 3 minutes typing your question. Adding those two together is fine.
- I like my meetings clustered together.
- I can be too frugal with company money.
## What I value
- Ownership. Please don't wait for me to give the go-ahead. Bias over action.
- People who get things done without me having to chase. I love it if we mention something should get done and there's a PR for it the next day.
- Speed. It's much easier to get things right if you take more shots at goal. Let's just get something up and iterate on it.
- Receiving feedback. Please give me a ton of feedback, I still have a huge amount to go and will only improve if I get feedback.
- When I give feedback, I'd appreciate if you consider it first before defending yourself. I may have gotten it wrong and feel free to push back, but I don't like it when people start defending themselves straight away.
- I'm not a big fan of meetings. Please write your thoughts up in a GitHub issue/PR first. We can always have a meeting after that which will likely be more productive.
- I like short, to the point writing. Use short words, bullet points and screenshots.
- Directness. If you don't like something please just say so.
## How I can help you
- I can help you figure out how to build something in 1/2 the time you think it should take
- I can help you figure out what you should be working on
- I can help you figure out what to do in your career
- I can help be a rubber duck
- I can help bounce ideas around
## How you can help me
- Come to 1:1s with an agenda and clear things I can help with
- Give me feedback
- Bring up problems, don't hide them. As a startup we'll always have a million problems, it's our job to surface those and fix the important ones.
## Nomading
I currently don't have a fixed address, and tend to move places every 2-3 months. If I remember to update it, [you can see where I am and where I'm going here](https://nomadlist.com/@timgl). I'd love to meet up with anyone if it's within a reasonable distance (and sometimes even if it's not). Would love for you to reach out and organise something.

42
SourceMaterial/company/values.md Normal file
View File

@ -0,0 +1,42 @@
We think of the company as a product, not just the software we're building. This is what we *currently* value in how we operate - this may evolve as we grow.
## We are open source
Building a huge community around a free-for-life product is key to [PostHog's strategy](/handbook/strategy/strategy).
We default to transparency with everything we work on. That means we make public our handbook, our roadmap, how we pay (or even let go of) people, what our strategy is, and who we have raised money from.
This enables the strongest community growth possible. It causes the core team to raise the bar on their work, it provides the context needed for people to work across multiple timezones, and it enables a deep work-heavy and meeting-light culture. It creates trust.
## We haven't built our defining feature yet
We will never stop innovating.
The more valuable we make our product, the better every team in the company will perform. That means more features, more polish, fewer bugs, and pushing for as much ambition as possible.
You learn faster by getting what you're working on into the real world. We expect you to ship new designs, features or whatever is needed for your role in tiny chunks, frequently, and often a little before you feel ready.
Iteration is a *huge deal* to us.
## Everyone codes
...although this doesn't mean everyone has to be a software developer, and not everyone needs experience in this before they join.
Our platform is built for developers, and we use GitHub to build a large community of technical users. Being able to do the basics of shipping, no matter your role, helps understand the people who we're building for and it helps empower teams outside of engineering with greater context.
Whether you're a designer or you're in operations, we will encourage and help you to be able to make basic changes to our website and docs on GitHub.
## Step on toes
PostHog is driven by context-based leadership. We'll explain what we need to achieve, but the reason we hire the best people is that they know what to do.
We expect you to pick out the very most important thing you can think of, and work on that. It is *not* ok to follow instructions blindly - not that you're likely to receive instructions in any case. We judge your performance based on the results you deliver overall. You'll make a lot of mistakes along the way - and that's ok! What matters is that you're making mistakes quickly, iterating, and getting better over time.
Likewise, [we don't expect you to watch your colleagues fail](/handbook/company/culture/#dont-let-others-fail) - it is a basic part of working at PostHog that you provide direct feedback to those around you. If you don't give feedback when you see something going wrong, you have missed an opportunity to make PostHog better.
## Talent compounds
Getting into PostHog is a huge challenge. Once you're here, it stays that way. We are *extremely* demanding of performance. What is most important to us is the quality of your output - not the number of hours that you put in.
In return, you get to work with others producing the best work of their careers. We are a team, not a family - we pay top of market, offer exceptional benefits, provide an environment for you to do your best work, and give generous severance.

120
SourceMaterial/company/working-with-design.md Normal file
View File

@ -0,0 +1,120 @@
---
title: Working with Design
sidebar: Handbook
showTitle: true
---
Design is currently a shared resource at PostHog. This explains what we do, our design process, and how we can assist across the PostHog team.
## Design's Role at PostHog
1. Support Small Teams (and contributors) in building better versions of PostHog
1. Enable customers to build better products (using PostHog)
1. Communicate to prospective customers the value we provide
### Tangibly, we:
1. Initiate new projects to support the roles listed above
1. Support Small Teams in completing their sprint tasks
1. Iterate based on feedback from customers
## Our Process
Design tasks are managed with our [GitHub Org project](https://github.com/orgs/PostHog/projects/3), otherwise known as our Design Board. This aggregates design-related tasks from the main three repositories for the company:
1. [PostHog app](https://github.com/PostHog/posthog) - open source repo
1. [posthog.com](https://github.com/PostHog/posthog.com) - website + docs
1. Internal - higher-level company strategy
### How Our Design Board Works
Cards generally move from left to right.
1. **Backlog** - Things on our radar, and where triaged requests will land unless they're urgent enough to pick up immediately
1. **This week** - Equivalent of our sprint
1. **In progress** - Tasks we've started but haven't completed
1. **Awaiting implementation** - In development or in review
1. **Done** - Shipped! 🚀
## Design Request Process
Since design is currently a shared resource, the best way design requests can be handled is by creating an issue in the relevant repository, then adding to the _Design_ project.
![image](https://user-images.githubusercontent.com/154479/114764251-b759b500-9d31-11eb-9767-c9fd9aad25b2.png)
After triaging, the Issue will appear in our [GitHub Org project](https://github.com/orgs/PostHog/projects/3) where we manage our current design projects.
The following details will help us triage incoming requests:
1. What do you need designed and why?
1. What is the deadline?
**Note:** We may defer some design requests if we're planning a larger overhaul in the near term. For example, if a request is to create an icon, we may suggest an alternate solution (like pulling an icon from The Noun Project) if we have a larger plan for revamping all icons in a section in the near future.
### When to Loop in Design
Because we hire self-starters, there is no expectation that every project should start by running through design _first_.
Depending on your preferred workflow, there are different ways we can get involved.
When looping in design, be sure to reference a GitHub issue so we have full context of the problem. Threads should primarily be kept on GitHub. (If an Issue is time-sensitive, mention the Issue on Slack in `#design-feedback`.)
_The scenarios below largely pertain to work on the main PostHog app._
**If you built something and just need some polish...**
Feel free to share a link (or screenshot) of what you've built. We can provide UX or design feedback for your consideration.
**If you built something and realize it needs some UX love...**
Share a link (or screenshot) of what you've built. Depending on the state of the project, we can either go back to the wireframe stage to rethink some things, or figure out a phased approach to incremental improvement.
**If you designed your own wireframes or mocks...**
Sometimes if you have domain knowledge or have been thinking about a project for a while, it might make more sense for you to start the design process. Feel free to share with us for a second opinion, or if you think certain UIs or flows are suboptimal.
**If you'd like some design help before you break ground...**
More like a typical product development process, please share the high level goals or spec, or any other documentation you have about a feature or enhancement. Be sure to specify the line between MVP and nice-to-haves.
**Need help brainstorming a flow?**
Provide as much documentation about the goals of the project. Depending on the project, we may be able to sketch out some ideas and share in the GitHub issue.
In some cases, it may make sense to jump on a Zoom to sketch out some ideas together.
## Sharing work in progress
We often share designs in early, unfinished phases. Since our audience is developer-friendly, we have a built-in audience to gut check our designs and solicit feedback.
When providing feedback, it's worth keeping in mind the level of fidelity of the mockup we're sharing for feedback.
### Wireframes
If an early draft is being shared, we'll build a wireframe in Balsamiq. At this stage, we're mostly focused on laying out content, crafting messaging, and loosely tying in a visual hierarchy and layout. (Don't look too closely at fonts, specific colors, or visualizations - those come later.)
_Note: Balsamiq uses its own Comic Sans-style font. Don't get hung up on this!_
![image](https://user-images.githubusercontent.com/154479/114972248-2b887b80-9e4c-11eb-92fe-bce7bf14c808.png)
### Mockups
Once a design is laid out, we'll move into hi-fidelity mockups built in Figma. This process usually takes a few rounds to perfect, and we often iterate up until the moment the design is passed off for development.
### Providing feedback
We typically share links to mockups in the relevant GitHub Issue.
When we share a design, we do our best to explain the type of feedback we're looking for. (Ex: Overall visual aesthetic, flow, if a design communicates to our developer-focused audience, etc.)
Our main design tools, Balsamiq and Figma, both have built-in commenting. If your feedback is specific to an element on the page, please leave a comment inside the app's comment system. This helps us review and take action on comments later.
If your feedback is higher level, summarize your feedback in the GitHub Issue itself for a higher-level discussion.
## Slack
We often use the `#design-feedback` Slack channel to share updates when we're particularly interested in feedback. We'll always link to the relevant place for discussion. (It's best to keep direct feedback off of Slack.)
This Slack channel isn't limited to the design team. If you're looking for a second opinion on the UX of something you're building, we encourage anyone to share screenshots and a link to Figma or wherever the mockup was produced so we can provide useful feedback or assist in iterating on a design.
If the design requires further collaboration, create an Issue.

65
SourceMaterial/engineering/beginners-guide/developer-workflow.md Normal file
View File

@ -0,0 +1,65 @@
---
title: 4. Developer Workflow
sidebar: Handbook
showTitle: true
hideAnchor: true
---
If you haven't already, it's worth your time to read [Contributing to PostHog](https://posthog.com/docs/contributing).
Most developers use either [vscode](https://code.visualstudio.com/) or [pycharm](https://www.jetbrains.com/pycharm/) but
you are free to use whatever IDE makes the most sense to you.
## Backend w/ Vscode
1. Create a git branch
2. Start PostHog with `bin/start`
3. Open app in Chrome and login
4. Open Chrome devtools to network tab
5. Navigate to scene (aka screen or page) and click on the area of interest
6. Find network request in devtools and find request
- Request maps to ./posthog/api/*.py, i.e. http://localhost:8000/api/insight/funnel/?insight=FUNNELS -> ./posthog/api/insight.py:197
7. Make code changes including tests
- Use [print()](https://realpython.com/python-print/) as needed for debugging
- Some developers prefer [Pycharm](https://www.jetbrains.com/pycharm/) for local development
8. Run backend tests
- `bin/tests posthog` runs only posthog tests excluding ee tests
- `./bin/tests ee/clickhouse/queries/test/test_trends.py -k test_active_user_math` for specific tests
9. Commit changes to git branch
10. Open PR for review
- Include Github issue number `#1234` which Github will automatically link for you
## Frontend w/ Vscode
1. Same as backend 1-5
2. Find frontend code, i.e. `frontend/src/scenes/insights/Insight.tsx`
3. Use `console.log` liberally
3. As of writing, there are no unit tests for the frontend although we do have integration tests for the frontend via Cypress
4. Same as backend 9-10
## Alternative: Pycharm
Some developers prefer to use [Pycharm](https://www.jetbrains.com/pycharm/) and for
good reason. While there are many benefits, below you'll find a few keys benefits.
1. `Debugging and no print() statements` this is probably the biggest win in my opinion.
Since we are learning a new codebase there is no shame in having an assistant. Pycharm
will show you the call stack and variable values. This is huge for understanding what
is going on.
2. `Code navigation` when you are new to a codebase, moving easily through the code
can be a real challenge, especially when there are multiple layers of abstraction.
Pycharm allows you to Ctrl+Click nearly all methods to jump to their definitions.
While editors like vscode have a similar feature, you'll find that Pycharm works
in cases where vscode does not.
3. `Run configurations` make starting celery, django, and webpack services simple. It's
mostly just clicking things.
4. `Excellent TypeScript support` with code completion and type checking directly in your
editor.
5. `Click instead of type` which means that you spend much more time typing code than
running commands. Nearly everything in Pycharm is clickable.
Pycharm offers a try it for free 30-day trial. It's recommended that you use it for at least
that amount of time before you buy. I recommend watching [The Future of Programming](https://www.youtube.com/watch?v=8pTEmbeENF4)
that will blow your mind and perhaps give you a new perspective on tools like these.
**[Next: Technologies to learn](technologies-to-learn)**

27
SourceMaterial/engineering/beginners-guide/getting-started.md Normal file
View File

@ -0,0 +1,27 @@
---
title: 3. Getting Started
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## First goals
1. Set up your dev environment and configure with your IDE
2. Get PostHog running locally on Postgres: [http://localhost:8000](http://localhost:8000). You'll need postgres, redis, celery, and django running.
3. Successfully run PostHog tests: `bin/tests posthog` (which omits Clickhouse tests)
4. Create [your first PR](https://github.com/PostHog/posthog/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
and have it be approved. If you work for PostHog someone (Tim or small team lead) will suggest the
first assignment.
## Suggested learning roadmap
1. [Setup your local dev environment](https://posthog.com/docs/developing-locally)
2. Ask your [PostHog Buddy](https://posthog.com/handbook/people/onboarding#posthog-buddy) for a product walk-thru. It's important to get to know the product you are building. I recommend doing this before you become deeply involved in it's internal design. This is a great time to view our product through the eyes of our users.
3. [Review PostHog Project Structure](https://posthog.com/docs/project-structure)
4. Learn [React](https://reactjs.org/docs/hello-world.html), [Redux](https://redux.js.org/introduction/core-concepts), and [Kea](https://kea.js.org/docs/introduction/what-is-kea) - If you're experienced with frontend frameworks I suggest going directly to Kea.
5. Take a brief overview of [Python](https://learnxinyminutes.com/docs/python/).
6. Complete [Django Tutorial 1-5 of 7 parts, skip 6+](https://docs.djangoproject.com/en/3.1/intro/tutorial01/). If you're interested in learning more about Django, pick a copy of [Django book](https://www.feldroy.com/products/two-scoops-of-django-3-x). The company will happily pay for this since they [believe in training us to do our jobs with excellent](https://posthog.com/handbook/people/training). Great place to work, right?
**[Next: Developer Workflow](developer-workflow)**

22
SourceMaterial/engineering/beginners-guide/getting-to-know-posthog.md Normal file
View File

@ -0,0 +1,22 @@
---
title: 2. Getting To Know PostHog
sidebar: Handbook
showTitle: true
hideAnchor: true
---
It's surprising how enjoyable and calming learning about PostHog's people can be.
You'll find [all their bios here](../../people/team). It's well worth your time!
### PostHog via James Hawkins, CEO
Additionally, James put together some great YouTube videos. I watched them all.
- [Why we built our business in the first place](https://www.youtube.com/watch?v=TIxxIEEvczM)
- [Open Source is Eating SaaS](https://www.youtube.com/watch?v=bh3j_9jVeqg)
- [How we raised a $3M seed round a few weeks after starting our open source project](https://www.youtube.com/watch?v=lJ41-95Ey3w)
- [Open source business models - your choices and how PostHog makes money](https://www.youtube.com/watch?v=L1Ovbzs7vyo)
- [We've never met each other in real life. How we designed PostHog for remote work from day one.](https://www.youtube.com/watch?v=rRwzJiljpSA)
- [Coffee + iPads + Feedback = A day in the of PostHog's graphic designer](https://www.youtube.com/watch?v=xlODCLrZyvM) by Lottie (helpful to see the design side of PostHog)
**[Next: Getting started](getting-started)**

75
SourceMaterial/engineering/beginners-guide/introduction.md Normal file
View File

@ -0,0 +1,75 @@
---
title: 1. Beginner's Guide
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## Introduction
The *Beginners Guide* started as a project to help me and others get up to speed on PostHog's tech stack.
I also wanted to include bits of advice to make the process encouraging to make working on PostHog even better.
I needed this approach personally since I've been hardcore programming in other languages and tech stacks
for years so most of PostHog's tech stack was newish to me.
## Consider your learning style
Some people like to jump in and go. Some people like to read the docs. I'm the latter. Another way of saying it
that I'm a holistic learner. My plan was to spend part of the time accomplishing work given to me and part
of the time on intentional education. The point is to know your own learning style so that you can be effective.
To that end, if you're a get started now type, you'll appreciate the
[getting started section](getting-started).
It's also important to note that whatever you learn needs to be reviewed several times. It doesn't
matter what learning style you have because review is essential to learning from a neuroscience
perspective. If you create small exercises for yourself such as the projects I've created in this repo
you'll do even better. The good news is that this process doesn't take up an extraordinary amount of time.
## A word about mindset
> You get more than you give.
My mindset is one of wanting to get the most out of life. For me, in part, that
means being excellent and taking full ownership of my career. Learning new
material can be overwhelming not to mention difficult. But remember this:
*it's worth it*! Investing in yourself makes for a better, more capable
version of you. Therefore, trust the difficult process of learning and elevate
your skills. The future you will thank you for your hard work.
If you get discouraged come back to this section.
## What has helped me personally
First thing to remember: starting a new job is like beginning a book in the middle of a
series where the characters are well-formed, and the story is far along. It's fair to say,
you have no idea what is going on. You can read words and understand but not understand
why they are being said. There our goal is to *develop a solid mental model for the codebase*.
> “You don’t care about the answer until you have the question.” - Unknown
- On my first day, I was given an assignment to work on. It began the process of showing me what I needed to learn. Struggling to complete the assignment helped me to *have the question* from the quote above.
- Reading the [project structure doc](/docs/project-structure)
- Browsing the [issues in GitHub](https://github.com/PostHog/posthog/issues) by playing with the various labels. This helped me get a better feel for PostHog's communication style and open-mindedness.
- Pairing with Tim & Eric. They used devtools to examine network traffic, console.log, and I was able to ask specific questions. It was basic stuff and reminded me to use the basic tools I've been using for years. I guess the anxiety of a new job confused my brain a little.
- Reading the kea docs. This is *clutch* to understand the frontend. It's a rather nice library but you won't make progress without understanding Kea.
- Creating a simple app with create-react-app with typescript support `yarn create react-app learn-kea-typescript --template typescript`
> "Take care of yourself. There's no need to burnout in the first month." - Eltje
- Eltje encouraged me to take care of myself, so I did.
> "So, what?!" - [Dare: The New Way to End Anxiety and Stop Panic Attacks](https://www.amazon.com/Dare-Anxiety-Stop-Panic-Attacks/dp/0956596258/) where "D" stands for defuse the anxiety by considering the worst and saying so what.
- Often I felt anxious about my daily contributions. Using the quote above really helps deal with this kind of anxiety. So what if I fail to deliver these assignments timely?! I'm an expert and in time I'll be a great asset to PostHog.
- Additionally, it's important to remember to trust the process. Being new (bad) at something isn't a great feeling initially until you realize that it's a part of the process. Soon you'll be good. It's better to reframe and remember that you only get to have new eyes once. Plus, it's fun to learn new things.
> "When you are working, close your email and slack. No one is watching to see if you are online. In fact, it's the opposite." - Tim, CTO
- Tim told me this on the first or second day, and it was liberating. It allowed me to think of my role as a true `async` open-source contributor. Do what needs to be done so that you can be the most effective.
> Read the docs
- For my learning style, this has been a **must**. I'm keeping a list of resources for learning I've used.
- I also spent time creating projects as you see in this repo which helped me consolidate the knowledge I was gaining.
**[Next: Getting to know PostHog](getting-to-know-posthog)**

32
SourceMaterial/engineering/beginners-guide/notes/django.md Normal file
View File

@ -0,0 +1,32 @@
---
title: Our Notes On Django
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## Start here
If, like me, you haven't worked with Django before, the best place to start with is
[Writing your first Django app](https://docs.djangoproject.com/en/3.1/intro/tutorial01/)
from the official Django website. This gives you a quick understanding of the major
parts of Django without needing to read an entire book to get it.
## Useful Django commands
- `django-admin startproject mysite` - creates Django project
- `python manage.py runserver` - starts Django web server (optionally add a port at the end `8080`)
- `python manage.py startapp polls` - creates Django app in project
- `python manage.py makemigrations polls` - creates migration scripts in migrations folder
- `python manage.py sqlmigrate polls 0001` - shows SQL that will run for this migration but doesn't perform it
- `python manage.py migrate` - performs all migrations
- `python manage.py shell` - puts you in a Django ORM shell to play with the models on the command-line
- `python manage.py createsuperuser` - creates super user for django admin app which comes by default with all Django projects, url `/admin`
- `python manage.py test polls` - run tests for polls app
## Useful resources
- [Writing your first Django app](https://docs.djangoproject.com/en/3.1/intro/tutorial01/). I recommend
reading Parts 1-5 of the 7 parts, skip 6+ since they are not relevant to PostHog. We do use Django built-in testing so part 5 is required reading.
- [Two Scoops of Django (e-book)](https://www.feldroy.com/products/two-scoops-of-django-3-x)
**[Back: Technologies to learn](../technologies-to-learn)**

103
SourceMaterial/engineering/beginners-guide/notes/docker.md Normal file
View File

@ -0,0 +1,103 @@
---
title: Our Notes On Docker
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## Docker Nomenclature and Notes
- `Docker Image` - the actual package, **artifact** which can be shared with others, docker images are built in layers via Dockerfile
- `Docker Container` - a *running* instance of a docker image, file system is virtual, contains a port for communication
- Docker run - command which executes *pull* and *start* (only pulls images we do not have locally)
- Docker vs Virtual Machine
- Operating System = Hardware > OS Kernel (layer 1) > Applications (layer 2)
- Docker = Virtualization of applications (layer 2)
- Virtual Image = Virtualization of OS (layer 1)
- Benefits of Docker = images are much smaller, runs faster
- Benefits of VM = you can run different OS (Windows on Linux) since it has it's own OS Kernel
- Docker Port vs Host Port
- Multiple containers may use the same port
- Bind host port to docker port, i.e. host 3000 -> docker 3000, host 3001 -> docker 3000
- `Docker Compose`
- Configuration file specifying *docker commands* to make it easier to work with
- Automatically handles creating a common *docker network*
- Docker compose is usually installed with docker so you already have it
- `Docker Volumes`
- Provides data persistence between host machine and docker containers
- The data between volumes is replicated between the host and docker container volumes
- 3 docker volume types: specified, anonymous, and named volumes, named volumes on the host are managed by docker
- Production should use *named volumes*
- Container Mongodb = /data/db
- Container MySQL = /var/lib/myself
- Container Postgres = /var/lib/postgres/data
- Host Windows = C:\ProgramData\docker\volumes
- Host Linux = /var/lib/docker/volumes/[hash]/_data
- Host Mac = /var/lib/docker/volumes/[hash]/_data
- `screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty` add access linux VM on mac where data is stored, `ctrl + a + k` to exit screen session
## Basic commands
- `docker pull` downloads a docker image locally
- `docker images` shows a list of local docker images and their sizes
- `docker run` run a docker container, it's two commands in one *docker pull* and *docker start*
- `docker run -d` runs the docker container in *detach mode*
- `docker run -p` binds the container to host port i.e. *-p6000:6370*, *-p [host]:[container]*
- `docker run --name` give the container a name so that you do not need to use the SHA
- `docker run -d -it python` runs python images in *interactive terminal* mode
- `docker run -e` runs an image with an environment variable
- `docker run -net` specify a docker network to run within
- `docker start` start a container, retains the settings from the run command
- `docker stop` - stops a container
- `docker ps` shows *running* containers
- `docker ps -a` shows *running and not-running* containers
- `docker logs` shows the *standard output* of the *running* container
- `docker logs -f` follow the *standard output*, similar to *tail -f*
- `docker exec -it` runs the container with interactive terminal
- `docker network ls` shows a list of the internal docker network
- `docker network create` create a docker network
- `docker build -t my-app:1.0 .` builds an image from a *Dockerfile* in the current directory
- `docker rm` removes a docker container which you need to do before docker rmi
- `docker rmi` removes a docker image, i.e. docker rmi my-app:1.0
- `docker run -v` mounts host filesystem to docker container filesystem
## Docker Compose
- `docker-compose -f mongo.yaml up` pulls, starts, and creates container network
- `docker-compose -f mongo.yaml up -d` runs containers in *detached mode*
- `docker-compose -f mongo.yaml down` stops container, removes container, and stops container network
## First Dockerfile
```docker
FROM python:3.9-alpine3.13
RUN apk add bash nodejs
COPY hello.* /
CMD ["bash"]
```
## First commands
- `docker build .` builds the container
- `docker run --name [name] [sha]` installs the container
- `docker run -it --name [name] [sha]` installs the container and starts in interactive mode
- `docker ps` shows all the running containers
- `docker ps -a` shows all the running and exited containers
- `docker stop [name]` stop container
- `docker start -ai [name]` start container interactively
- `docker rm [name]` removes container
## Resources
- [Creating your first Dockerfile, image and container](https://www.youtube.com/watch?v=hnxI-K10auY) great place to start
- [Docker Tutorial for Beginners [FULL COURSE in 3 Hours]](https://www.youtube.com/watch?v=3c-iBn73dDE) most helpful
- [Docker For Beginners: From Docker Desktop to Deployment](https://www.youtube.com/watch?v=i7ABlHngi1Q)
## Related Resources
- [Kubernetes Tutorial for Beginners FULL COURSE in 4 Hours](https://www.youtube.com/watch?v=X48VuDVv0do) To manage distribution of contains across many servers
**[Back: Technologies to learn](../technologies-to-learn)**

89
SourceMaterial/engineering/beginners-guide/notes/kea.md Normal file
View File

@ -0,0 +1,89 @@
---
title: Our Notes On Kea
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## Actions
- All code lives inside `logic` which is created with `kea({ ... })`
- Files are typically named `[name]Logic.js|ts`
- `import { useActions } from 'kea'` provides access to action all functions
- All operations start from `actions`
- The mental model for actions is that of *event capturing*, they signal intent
- Sample action: `increment: (amount) => ({ amount })`
- **Actions** map to `reducers` and `listeners` to perform operations
- Actions can invoke several reducers if the name of the action maps to multiple reducers
- Actions defined with `someActions: true` are actions with no arguments
## Reducers
- Reducers define `state` and `operations` on that state.
- `import { useValues } from 'kea'` provides access to the state
- Sample reducers: `counter: [0, { increment: (state, { amount }) => state + amount}]`
- Notice how increment is the same name as the action
- Reducers should never mutate the state directly, they must be pure functions
## Listeners
- Listeners are how you do `side-effects` and async calls to load data
- Listeners may invoke other actions via `actions`, example: `listeners: ({ actions, values }) => ({ ... })`
- Listeners are `async` functions
- Notice we have access to actions and values in the listeners functions
- *Set this or that* is better done by reacting to actions
## Loaders
- Available via the `kea-loaders-plugin`
- Encapsulates the pattern of action > listener > loading > success | failure
- Example: `users: [[], { loadUsers: async () => await api.get('users') }]`
## Selectors
- Selectors handle mapping data across reducers
- Similar to computed values in Vue
## Values
- `import { useValues } from 'kea'`
- You can access values frorm React with useValues or from listeners via listeners function
## Input objects vs functions
- Any of kea's built-in primitives: actions, reducers, listeners, etc. may be declared with an object or function
- Functions are invoked lazily
- Functions are passed 1 argument which can be destructured for actions and values
- Use objects first then functions as you need them
## Props
- Using kea logic as a function allows you to pass in props which are available as destructured props for primitive key functions
## Keyed logic
- If you give your logic a key, you can have multiple independent copies of it. The key is derived from props
- Example: `key: (props) => props.id`
## Breakpoints
- Serves as a debounce function or out of order network calls
## Events
- Handles lifecycle events
## Defaults
- Allows you to specify default values instead of doing them in the reducers
- Defaults may be a function as well to calculate the default values
## Connecting kea logic together
- You may [connect logics together](https://kea.js.org/docs/guide/additional#connecting-logic-together)
## Useful resources
- [Kea](https://kea.js.org/docs/introduction/what-is-kea)
**[Back: Technologies to learn](../technologies-to-learn)**

53
SourceMaterial/engineering/beginners-guide/notes/python.md Normal file
View File

@ -0,0 +1,53 @@
---
title: Our Notes On Python
sidebar: Handbook
showTitle: true
hideAnchor: true
---
Along with reading about any given programming language it's necessary to use that
knowledge. I've prepared exercises that will help you use the knowledge you are
learning.
Start by reading [Python via Learninyminutes](https://learnxinyminutes.com/docs/python/)
then work to complete the exercises below.
## 1. Fibonacci
You can learn about the [fibonacci here](https://en.wikipedia.org/wiki/Fibonacci_number). Fibonacci
sequence means each number is the sum of the two preceding ones, starting from 0 and 1.
The sequence looks like this `0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144...`
**Exercise: Calculate the fibonacci sequence up to 100**
## 2. Invictus text processing
1. Read [invictus.txt](https://raw.githubusercontent.com/buwilliams/learn-posthog/main/docs/exercises/02_invictus.txt) into a string
2. Split the string an array of words and print them out
3. Correct words with invalid characters and print the cleaned words out
4. Create an array of maps of all unique words and how many times they occurred
5. Sort the array of maps by the number of times they occurred in descending order
6. Convert the code into a class, implement interfaces and type checking if applicable
## More exercises
- [Programming Problems](https://adriann.github.io/programming_problems.html)
## Create your own exercises
One interesting strategy is to:
1. Buy/find a programming book you're interested in.
2. As your read, create an exercise for that chapter.
3. Code the exercise that you created before moving on.
4. Rinse and repeat until you've finished the book.
By creating the exercise and solving it, you'll learn better than if you just read the chapter.
Remember that many programmers are lazy and are unwilling to put this kind of effort. You'll
be light years ahead of your peers as you apply yourself.
## Useful resources
- [Python via Learninyminutes](https://learnxinyminutes.com/docs/python/)
**[Back: Technologies to learn](../technologies-to-learn)**

116
SourceMaterial/engineering/beginners-guide/notes/react.md Normal file
View File

@ -0,0 +1,116 @@
---
title: Our Notes On React
sidebar: Handbook
showTitle: true
hideAnchor: true
---
The [React docs](https://reactjs.org/docs/getting-started.html) are great for getting from zero to one.
## Hooks
I found hooks somewhat counterintuitive at first, but they're very powerful once you grasp them. Refer to the [Rules of Hooks](https://reactjs.org/docs/hooks-rules.html). - @samwinslow
1. Only call from the top level of a functional component
2. Do not call outside a functional component or from plain JS (you can call from custom hooks)
### useState
Uses destructured array assignment syntax
`const [value, setValue] = useState(initialValue)`
An updater function can be passed to the setter so that multiple updates can be called in sequence, or to merge-update the state via spreading if it's an object. The updater is a pure function which takes previous state and returns next.
```jsx
// bad
setValue(value + 1)
setValue(value + 1)
// good
setValue(value => value + 1)
setValue(value => value + 1)
```
In general, derive data while rendering rather than storing derived values in state (e.g. filtering local data). However, if expensive filtering or join operations are to be performed and/or the component re-renders frequently, a memoized state management library might be better.
### useEffect
Takes a callback function which may have (potentially global) side effects. Runs on every re-render by default.
```jsx
function EffectExample() {
const [value, setValue] = useState(initialValue)
useEffect(() => {
document.title = `The value is now ${value}`
})
return (
<div>
<p>{value}</p>
<button onClick={() => setValue(value => value + 1)}>Use Effect</button>
</div>
)
}
```
The rendered value is not a special data binding that causes it to listen. It is merely a reflection of a new value rendered as a result of calling the setter.
Can return a cleanup function from the effect and declare when it should run
```jsx
function ApiStatus({ service }) {
const [isOnline, setOnline] = useState(null)
const { id } = service
useEffect(() => {
const handleStatusChange(status) => {
setOnline(status.isOnline)
}
SomeApi.subscribe(id, handleStatusChange)
return () => SomeApi.unsubscribe(id, handleStatusChange)
}, [id]) // Only run when `id` changes (sync to state)
// rendering
}
```
### useLayoutEffect
Same as `useEffect`, but runs callback synchronously during commit lifecycle phase
### useMemo
Recalculates value only when dependencies change
### useCallback
Updates callback function reference when dependencies change
### useRef
Mutable ref used to access returned child.
- Persists between renders
- Default: `{ current: null }`
- Plain object; mutating does not trigger re-renders
### Custom Hooks
Listeners and API connections can be extracted to a custom hook and reused
Examples from popular libraries:
- React-Redux: `useSelector`, `useDispatch`
- React-Router: `useHistory`, `useLocation`, `useParams`
- `useFormState`
## Useful resources
- [Dan Abramov - A Complete Guide to useEffect](https://overreacted.io/a-complete-guide-to-useeffect/)
- [Mark Erikson - A Complete Guide to React Rendering Behavior](https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-mostly-complete-guide-to-react-rendering-behavior/)
**[Back: Technologies to learn](../technologies-to-learn)**

23
SourceMaterial/engineering/beginners-guide/notes/typescript.md Normal file
View File

@ -0,0 +1,23 @@
---
title: Our Notes On TypeScript
sidebar: Handbook
showTitle: true
hideAnchor: true
---
The best way to learn TypeScript is to read introductory material then get hands on with exercises.
## Exercises
You can complete the exercises on the [TypeScript Playground](https://www.typescriptlang.org/play)
You can use the same [exercises for Python](python) as starting place.
## Great places to learn
- [TypeScript via learnxinyminutes](https://learnxinyminutes.com/docs/typescript/)
- [TypeScript in 5 minutes](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html)
- [TypeScript Handbook](https://www.typescriptlang.org/docs/handbook/intro.html)
**[Back: Technologies to learn](../technologies-to-learn)**

33
SourceMaterial/engineering/beginners-guide/technologies-to-learn.md Normal file
View File

@ -0,0 +1,33 @@
---
title: 5. Technologies To Learn
sidebar: Handbook
showTitle: true
hideAnchor: true
---
Each of the links below will send you to the best resources for learning I found. As I went through learning the
various technologies, I took notes. Below you'll find all the notes that I took along with resources I felt were
particularly useful. I'd suggest using *our notes* links as you would a cheatsheet.
## Backend
- [Python](https://www.python.org/) ([our notes on Python](notes/python))
- [Django](https://www.djangoproject.com/) ([our notes on Django](notes/django))
- [Django Testing](https://docs.djangoproject.com/en/3.1/intro/tutorial05/)
- [Pytest](https://docs.pytest.org/en/stable/getting-started.html)
- [Clickhouse](https://clickhouse.tech/) (enterprise database)
- [Celery](https://docs.celeryproject.org/en/stable/) (we use Redis as Celery's message broker)
- [Docker](https://www.docker.com/) ([our notes on Docker](notes/docker))
## Frontend
- [React](https://reactjs.org/docs/hello-world.html) ([our notes on React](notes/react))
- [Redux](https://redux.js.org/introduction/core-concepts)
- [Kea](https://kea.js.org/docs/introduction/what-is-kea) ([our notes on Kea](notes/kea))
- [TypeScript](https://www.typescriptlang.org/) ([our notes on TypeScript](notes/typescript))
## Useful tech
- [Tmux](https://github.com/tmux/tmux/wiki)
- [Fish](https://github.com/fish-shell/fish-shell)
- [Zsh](https://github.com/ohmyzsh/ohmyzsh)

57
SourceMaterial/engineering/bug-prioritization.md Normal file
View File

@ -0,0 +1,57 @@
---
title: Bug Prioritization
sidebar: Handbook
showTitle: true
---
## User experience degradation
When bugs are reported it's critical to properly gauge the extent and impact to be able to prioritize and respond accordingly. These are the priorities we use across the entire engineering org, along with the relevant labels to quickly identify them in GitHub.
> Please always remember to tag your issues with the relevant priority.
<span>
<table>
<tr>
<td>GitHub Label</td>
<td>Description</td>
</tr>
<tr>
<td><span class="tag-label" style="background:#ff0000; color: white;">P0</span></td>
<td>Critical, breaking issue (page crash, missing functionality)</td>
</tr>
<tr>
<td><span class="tag-label" style="background:#f0a000;">P1</span></td>
<td>Urgent, non-breaking (no crash but low usability)</td>
</tr>
<tr>
<td ><span class="tag-label"style="background:#ffe000;">P2</span></td>
<td>Semi-urgent, non-breaking, affects UX but functional</td>
</tr>
<tr>
<td><span class="tag-label" style="background:#1d76db; color: white;">P3</span></td>
<td>Icebox, address when possible</td>
</tr>
</table>
</span>
## Security issues
Security issues, due to their nature, have a different prioritization schema. This schema is also in line with our internal SOC 2 related policies (Vulnerability Management Policy). When filing security-related GitHub issues, remember to attach label `security` and the appropriate priority label. More details on filing can be found in the [README](https://github.com/PostHog/product-internal#README) of the `product-internal` repo.
<blockquote class="warning-note">
Security issue information should not be made public until a fix is live and sufficiently (ideally completely) adopted.
</blockquote>
PostHog security issues include a priority (severity) level. This level is based on our self-calculated CVSS score for each specific vulnerability. CVSS is an industry standard vulnerability metric. You can learn more about CVSS at [FIRST.org](https://www.first.org/cvss/user-guide) and calculate it using the FIRST.org [calculator](https://www.first.org/cvss/calculator/3.1).
| GitHub Label | Priority Level | CVSS V3 Score Range | Definition | Examples |
|---|---|---|---|---|
|**security-P0**|Critical|9.0 - 10.0|Vulnerabilities that cause a privilege escalation on the platform from unprivileged to admin, allows remote code execution, financial theft, unauthorized access to/extraction of sensitive data, etc.|Vulnerabilities that result in Remote Code Execution such as Vertical Authentication bypass, SSRF, XXE, SQL Injection, User authentication bypass|
|**security-P1**|High|7.0 - 8.9|Vulnerabilities that affect the security of the platform including the processes it supports.|Lateral authentication bypass, Stored XSS, some CSRF depending on impact|
|**security-P2**|Medium|4.0 - 6.9|Vulnerabilities that affect multiple users, and require little or no user interaction to trigger.|Reflective XSS, Direct object reference, URL Redirect, some CSRF depending on impact|
|**security-P3**|Low|0.1 - 3.9|Issues that affect singular users and require interaction or significant prerequisites (MitM) to trigger.|Common flaws, Debug information, Mixed Content|

13
SourceMaterial/engineering/common-issues.md Normal file
View File

@ -0,0 +1,13 @@
---
title: Common Issues
sidebar: Handbook
showTitle: true
---
A page to host big issues raised by users (rather than small bugs) that we have certain answers for.
### Shopify Event-Logging "Bug"
Admin users who have PostHog setup for Shopify may experience their events being logged for another user.
This is not an issue with PostHog. Rather, this is due to a feature Shopify offers where it stores all the session data and lets you browse your website as if you were your client with all their cookies and local/session storage.

75
SourceMaterial/engineering/development-process.md Normal file
View File

@ -0,0 +1,75 @@
---
title: Development Process
sidebar: Handbook
showTitle: true
---
> _**Note:** This guide is aimed at people who work for PostHog. If you want to contribute, [see our Contributing Guide](/docs/contributing)._
<br />
Any process is a balance between speed and control. If we have a long process that requires extensive QA and 10 approvals, we will never make mistakes because we will never release anything.
However, if we have no checks in place, we will release quickly but everything will be broken.
## 1. How to Decide What to Build
There are 3 places that work comes from.
- Issues/bugs (raised by the community or us)
- [Roadmap](/handbook/strategy/roadmap)
- "This should be better"
## 2. Sizing a Task
When picking up a task, it should be doable in a day, including code review and QA. If it's not, you need to break it down into smaller chunks until it is. Tasks of this size are easy to test, easy to deploy, less likely to cause merge conflicts, and should still deliver some kind of value.
Even if you're contributing, this is helpful as it means you'll be able to contribute to PostHog faster.
## 3. Writing Code
We're big fans of Test Driven Development (TDD). We've tried to create test infrastructure that helps you rather than annoys you. If that isn't the case, please raise an issue! Keeping tests on point is a high priority to keep developer productivity high.
Other than that, you know what to do in this section.
## 4. Creating a PR
To make sure our issues are linked correctly to the PRs, you can tag the issue in your commit.
```bash
git commit -m "Closes #289 add posthog logo to website"
```
## 5. Code Review
When we review a PR, we'll look at the following things:
- Does the PR actually solve the issue?
- Does the solution make sense?
- Will the code perform with millions of events/users/actions?
- Are there tests and do they test the right things?
- Are there any security flaws?
Things we do not care about during review:
- Syntax. If we're arguing about syntax, that means we should install a code formatter
See: [How we review](/handbook/engineering/how-we-review).
## 7. Merging
Merge anytime. Friday afternoon? Merge.
Our testing, reviewing and building process should be good enough that we're comfortable merging any time.
## How to Test
See: [How to test](/docs/contributing#testing).
## How we Review
See: [How we review](/handbook/engineering/how-we-review).
## How to release a new version
See: [Release new version](/handbook/engineering/release-new-version).

46
SourceMaterial/engineering/how-we-review.md Normal file
View File

@ -0,0 +1,46 @@
---
title: How We Review PRs
sidebar: Handbook
showTitle: true
---
Almost all PRs made to PostHog repositories will need a review from another engineer. We do this because, almost every time we review a PR, we find a bug, a performance issue, unnecessary code or UX that could have been confusing.
## How to review
1. Have a flick through the code.
- What to look for:
- Code that does the wrong thing or will produce bugs
- Code that you think will cause performance issues
- Are there tests for all of the new functionality, and do they test the right thing?
- Any security issues or project leakage?
- Is the code properly instrumented to allow tracking of every relevant action (i.e. all the relevant frontend elements have unique and helpful `data-attr`s, and there are backend events where appropriate)?
- What _not_ to look for:
- Formatting issues (prettier should handle this, raise a PR to fix that)
- "I would have done it differently" (Unless the code is completely incomprehensible or unreadable, or will cause us massive harm long term - as long as it works, it's good enough.)
2. Open the review app or check the branch out locally.
- What to look for:
- Bugs in the new functionality (if you're reviewing the insights page, make sure you try breakdown, cohorts, filters, different time frames etc)
- Confusing UX
- Confusing wording
- Backend tracked events not being fired properly or with an incorrect payload.
- Should the code be behind a feature flag?
- If the code is behind a feature flag, do all cases work properly? (in particular, make sure the old functionality does not break)
- Are we building the right thing? (We should be willing to throw away PRs or start over)
- Don't be shy here - try to break it!
- What not to look for:
- Issues _not_ related to this PR. Create a new issue for those.
The emphasis should be on getting something out quickly. Endless review cycles sap energy and enthusiasm.
## Setting up Heroku Test Environment
1. Go to the pull request you want to QA on.
2. Go to the Heroku test environment.
Check/do the following:
1. If the environment was already deployed, it should say "This branch was successfully deployed"
1. If it says ‘This branch was not deployed’ go to the Heroku pipeline and click ‘Create review app’
1. If the PR was submitted from a fork, you'll need to test the changes locally.
3. Open the app, create a new account, and start testing!

54
SourceMaterial/engineering/onboarding-customer.md Normal file
View File

@ -0,0 +1,54 @@
---
title: Onboarding Customers
sidebar: Handbook
showTitle: true
---
A lot of people want to set up PostHog on their own without talking to anyone, and we'll make sure that path is as optimised as possible. However, sometimes it's more efficient/better to talk to one of us over a call.
Our user notes are not shared publicly. [Read them here](https://docs.google.com/document/d/1gJlsUDrlW7ur8zT5scqRvXZhapm_0JdvKGiw68Iyx9E/edit#heading=h.q9lg9hgl34g2).
A standard structure you could maintain while doing that call is:
## 1. Introductions / Find Out About Their Business
1. Make sure you introduce yourself and check it's ok if you take notes.
1. Introduce PostHog: "We're open-source product analytics. Think Mixpanel or Amplitude, but with full control over your data and focused on engineers"
1. Ask questions about their business:
- Why did they reach out in the first place?
- What are their main goals/most important metric for this quarter/batch/year?
- Are they familiar with other product analytics tools? Are they using any right now?
- What stage is their company at - do they have users, are they about to launch, are they trying to expand?
- How does their app work?
- Where does the app live? Website, online app, mobile app, backend?
## 2. Demo
Share your own screen and wizz through a demo of PostHog. The following order tends to work best:
1. Tell them the big picture of how the demo will work "I am going to show you two main things - how we collect data and what we help you do with it"
1. Go to /events, show raw events coming in and explain how we're different from Mixpanel/Amplitude as we track all clicks, which means no `posthog.track()` calls necessary
1. Go to /trends, show filtering by url, DAU, breakdown by initial domain referrer, anything else they ask for. It's a good opportunity to share some knowledge e.g. how to understand where traffic is coming from (UTM tags or referring domain)
1. Go to /funnels, explain how those work and that PostHog specifically allows you to see each user that goes through the funnel, rather than aggregates
1. Go to /people/retention and explain how the Retention table works
1. Show off the Toolbar using the "Launch Toolbar" button
1. Explain Feature Flags
1. Go to Default Dashboard
1. Optional: show paths
1. Ask if any questions
## 3. Setup
Flip it around and ask them to share their screen.
0. If they haven't setup PostHog yet, walk them through and help them install the snippet on their website (and anywhere else necessary)
1. Based on the questions from Section 1, set up relevant dashboards for them.
- DAUs are already there, but they might want a /trends view split out by different pages. Have them add that to default dashboard. They may also want to see where traffic is coming from as a separate item in trends to add to the dashboard.
- Have them create an action for a click on their CTA on the home page
- Create a funnel with two steps: pageviews and the CTA action
1. (Optional) if they have an app, help them set up `identify` calls correctly
1. Ask if there any questions
## 4. Conclusion
1. Ask them to join our Slack group (and send an email right after!)

58
SourceMaterial/engineering/release-new-version.md Normal file
View File

@ -0,0 +1,58 @@
---
title: Releasing a New Version
sidebar: Handbook
showTitle: true
---
At the moment, we release a new version every two weeks ([unless it makes sense not to!](/blog/we-ship-whenever)). This might change in the future.
## Version Numbers
Every week we up the 'minor' in `major.minor.patch`. At the moment, we're at version 1 for major. This will only change once we have released sufficient functionality under stage 2 of [our Roadmap](/handbook/strategy/roadmap/).
Hopefully we will not have to do many patch versions, but if between versions we discover a breaking bug, we will.
## Timeline
Three days before we release, on Monday, we institute a code freeze. We branch master into release-[version] and deploy that to our production environment (app.posthog.com). Only bugfixes are allowed to be merged into this branch (and thus put on production) between Monday and the release going out. This gives us about three days to test if this release has any bugs.
## Checklist
<input type="checkbox"/> Figure out what's updated in this release
- `git checkout release-[version]`
- `git log --pretty=format:%s [old-version]..head`
<br />
<input type="checkbox"/> Write up the PostHog Array [blog post](/handbook/growth/marketing/posthog-array)
<input type="checkbox"/> Copy from PostHog Array and write up the changes into `CHANGELOG.md` following the structure of the previous release
- `git add CHANGELOG.md`
- `git commit -m "Changelog version 1.7.0"`
<br />
<input type="checkbox"/> Update the `VERSION` in `posthog/version.py`
- `git checkout release-[version]`
- `git add posthog/version.py`
- `git commit -m "Bump version [version]"`
<br />
<input type="checkbox"/> Tag the version
- `git tag -a [version] -m "Version [version]"`
- `git push origin head --tags`
Once a new Docker image has been built (see [Docker Hub](https://hub.docker.com), password in 1password) for the new version, open the [charts](https://github.com/PostHog/charts) repo and make the changes:
1. Edit the **two** Chart files: [Chart.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/Chart.yaml) and [ChartV3.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/ChartV3.yaml), in both:
- Bump `appVersion` to the latest app version (same number as on the docker image).
- Bump `version` (chart version) patch number, unless making big changes to the chart itself. Lesson learned: this can only be `x.x.x`. It can't have a fourth part.
2. Change the docker tag in [values.yaml](https://github.com/PostHog/charts/blob/master/charts/posthog/values.yaml#L6) to point to [the latest tag](https://hub.docker.com/r/posthog/posthog/tags?page=1&ordering=last_updated).
3. `git commit -m 'Bump PostHog app version to 1.0.XX, release chart version 1.0.YY'`
4. `git tag -a 1.0.YY -m "Version 1.0.YY"`
5. `git push && git push origin head --tags`
Finally to bump the `latest-release` docker image, log to [hub.docker.com](https://hub.docker.com/repository/docker/posthog/posthog/builds) and configure a new automatic build. Set the docker tag to `latest-release` and the source to the tag `1.XX.YY`. Delete any older tag with the same name if present and click "save & build"

12
SourceMaterial/engineering/releasing-python.md Normal file
View File

@ -0,0 +1,12 @@
---
title: Releasing a New Version (Python Library)
sidebar: Handbook
showTitle: true
---
## How to Release
1. Increase `VERSION` in `posthog/version.py`
2. Update `CHANGELOG.md` with a short summary of the changes
3. run `make release` and `make release_analytics`
4. `git commit -am "Release X.Y.Z."` (where X.Y.Z is the new version)
5. `git tag -a X.Y.Z -m "Version X.Y.Z"` (where X.Y.Z is the new version).

137
SourceMaterial/engineering/setup-ssl-locally.md Normal file
View File

@ -0,0 +1,137 @@
---
title: Setup SSL locally
sidebar: Handbook
showTitle: true
---
Setting up HTTPS locally can be useful if you're trying to debug hard
to replicate issues (e.g cross domain cookies, etc).
There are two ways you can get HTTPS locally:
1. ngrok
2. NGINX and a local certificate.
The easiest option is to use ngrok.
## Set up SSL via ngrok
1. Make sure you [have ngrok installed](https://ngrok.com/download).
2. Sign up for an ngrok account (or sign in with GitHub) and run `ngrok authtoken <TOKEN>`
3. Edit `$HOME/.ngrok2/ngrok.yml` and add the following after the line with `authtoken: <TOKEN>`:
```
tunnels:
django:
proto: http
addr: 8000
webpack:
proto: http
addr: 8234
```
4. Start ngrok. This will give you tunnel URLs such as https://68f83839843a.ngrok.io
```bash
ngrok start --all
```
5. Copy the HTTPS URL for the tunnel to port 8234 and set it as the value for the `JS_URL` environment variable. Then, start webpack:
```bash
export WEBPACK_HOT_RELOAD_HOST=0.0.0.0
export LOCAL_HTTPS=1
export JS_URL=https://68f83839843a.ngrok.io
yarn start
```
6. Use the same URL as the value for `JS_URL` again and start the Django server
```bash
export DEBUG=1
export LOCAL_HTTPS=1
export JS_URL=https://68f83839843a.ngrok.io
python manage.py runserver
```
7. Open the HTTPS URL for the tunnel to port 8000.
**Tips & Tricks**
If you're testing the Toolbar, make sure to add the ngrok urls to the list on the 'Project Settings' page.
![Permitted domains](../../images/engineering/toolbar-permitted-ngrok.png)
Also, watch out, network requests can be slow through ngrok:
![Network slow with ngrok](../../images/engineering/ngrok-slow.gif)
## Set up SSL via NGINX and a local certificate
0. Update openssl if "openssl version" tells you "LibreSSL" or something like that.
In case `brew install openssl` and `brew link openssl` don't work well, use
`/usr/local/opt/openssl/bin/openssl` instead of `openssl` in the next step.
1. Create key
```
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-keyout localhost.key -out localhost.crt -subj "/CN=secure.posthog.dev" \
-addext "subjectAltName=DNS:secure.posthog.dev,IP:10.0.0.1"
```
2. Trust the key for Chrome/Safari
```
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain localhost.crt
```
3. Add `secure.posthog.dev` to /etc/hosts
```
127.0.0.1 secure.posthog.dev
```
4. Install nginx (`brew install nginx`) and add the following config in `/usr/local/etc/nginx/nginx.conf`
```nginx
upstream backend {
server 127.0.0.1:8000;
}
server {
server_name secure.posthog.dev;
rewrite ^(.*) https://secure.posthog.dev$1 permanent;
}
server {
listen 443 ssl;
server_name secure.posthog.dev;
ssl_certificate /Users/timglaser/dev/localhost.crt;
ssl_certificate_key /Users/timglaser/dev/localhost.key ;
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://backend;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /static/ {
proxy_pass http://127.0.0.1:8234/static/;
}
}
```
5. Add the following command to start nginx
```bash
nginx -p /usr/local/etc/nginx/ -c /usr/local/etc/nginx/nginx.conf
```
6. You can stop the nginx server with
```bash
nginx -p /usr/local/etc/nginx/ -c /usr/local/etc/nginx/nginx.conf -s stop
```
7. To run local development, use
```bash
bin/start-http
```

89
SourceMaterial/growth/customer-support.md Normal file
View File

@ -0,0 +1,89 @@
---
title: Customer Support
sidebar: Handbook
showTitle: true
---
## We aim to delight
You can build a good company by focusing on getting lots of customers. To build a great company, you must delight your existing customers. This means that the journey doesn't simply end once we sign up a user - even more important is to ensure that PostHog is consistently delivering value for them.
## How we ensure customer delight at PostHog
### It's easy for customers to reach us
We have a few different routes for users to contact us. As an open source company, our bias is towards increasing the bandwidth of communication with our users and making it easy for them to reach us. We do not believe in putting up barriers by saying they can only reach us through a dedicated support email address, for example.
These are the ways in which customers can currently reach us, in order of popularity:
- **Slack** - our active [PostHog Users Slack](https://posthog.com/slack) community frequently post questions
- **Email** - a user may email hey@posthog.com with a specific support query
- **Papercups** - we provide in-app support chat via the [Papercups](https://papercups.io/) widget
- **GitHub** - sometimes users ask about the progress of [certain issues](https://github.com/PostHog/posthog) that are important to them
### No dedicated support people
We intentionally have not hired a single person dedicated to customer support. The direct interaction between our engineering team and our users is _hugely_ valuable, and an important part of building trust in our community is the ability for users to talk directly with the people who are actually building the product.
Providing support is a responsibility shared across our team - we expect everyone to jump in and help a user if you see they have a question or problem (though obviously not at the same time!) Once you have made the initial contact or response, it is your responsibility to see it through or explicitly hand over to someone else if they are better-equipped to help.
This does mean sometimes that, especially when we are particularly busy, customer success can take a bit of a back seat.
This is why, in addition, one person takes on the **Support Hero** role each two week sprint. This is a rotating responsibility, where the person involved spends a significant chunk of their time responding to support queries across Slack, email and Papercups, and sharing that feedback with the team and/or building features and fixes in response. We have found that each stint as Support Hero has thrown up a lot of really valuable feedback.
### Simple, lightweight tools
We go to where our users are. That means **we respond in the same channel that they reached out to**, rather than trying to funnel them somewhere else.
We use [Papercups](https://papercups.io/) as our internal platform to get an overview of our support requests. This ensures that we don't miss anyone, especially when their request is passed from one person to another at PostHog, or if they message us over the weekend. If customer success is part of your role, you should have received an invite to join as part of your onboarding - if you didn't, ask Charles.
The first time you sign into Papercups, please make sure you include your name and [profile picture](https://posthog.com/handbook/company/team) so our users know who they are chatting to!
A quick overview of Papercups' main features:
- _Main conversations view_: when you sign into Papercups, you can either [view all conversations](https://app.papercups.io/conversations/all), or just those [assigned to you](https://app.papercups.io/conversations/me). If you are the first person to respond to a query, you will be automatically assigned that conversation. Don't forget to close a conversation by ticking the box in the top right when you are done, so we know which queries have been resolved!
- _Slack integration (1)_: You can reply directly to PostHog app questions either in the Papercups app itself or in the private _customer support_ channel in the [PostHog Users Slack](http://posthog.com/slack) - both work.
- _Slack integration (2)_: In the PostHog Users Slack, messages posted in the _general_ and _feedback_ channels are also synced with the Papercups app. As above, this means you can reply to users in that Slack channel directly or in Papercups. Please try to reply in a Slack thread to any questions. This makes it easier for other users to navigate the channel without a lot of noise, and also prevents Papercups creating a new conversation for each response (as Papercups treats each thread in Slack as a conversation).
- _Email integration_: Any emails that come into hey@ get synced with Papercups and Slack, so you can reply on either of those platforms, or directly to the email. If you reply via email, please make sure you at least bcc hey@ so we know that someone has responded!
- _Notes_: You can leave a 'Private Note' in the right hand pane in Papercups if you need to make a note of something for future reference, e.g. a relevant GitHub issue.
- _Sharing_: If you click 'Share Conversation' at the bottom of the right hand pane in the Papercups app, you can link directly to a conversation. This is useful for sharing context with other team members.
- _Analytics_: 'Reporting' in the left hand panel shows some interesting analytics, such as how many queries we're receiving, average response time etc. We don't report on these yet as we're still figuring out the best way for us to do support.
Papercups are an open source company, so if there are any additional features you'd like to see then you can check out their [repo on GitHub](https://github.com/papercups-io/papercups/issues). They are building new features quickly, so it's worth checking in to see what new functionality is available from time to time.
## Some useful questions to ask
The below questions are evolving so please add more as they come up!
### Set up
- Has the customer logged in?
- Has the customer added their team?
- Are events coming into the platform on a recurring basis?
- Are identify calls being made so user profiles are being created?
- Are additional relevant user properties being sent?
- Has the customer set up actions?
- Has the customer set up funnels?
- Has the customer created or modified a dashboard?
- Has the customer used the toolbar?
- Has the customer gotten PostHog into production?
- If applicable, has the customer removed any test data?
- If applicable, is the customer using feature flags?
### Training and support
- Does their team have enough general product analytics experience?
- Has their team received a demo of the product?
- Has everyone on the team used the product at least once?
- Does the customer's team know where to find our use case guides?
- Have we told the customer where to get support?
- Have we set up a joint Slack channel with the customer?
### Providing more value over time
- Have we added their whole team to our email newsletter?
- Are we monitoring the customer's usage on a dashboard at a team level?
- Is the customer generally above 80% usage for their current plan?
- Have we set up a quarterly catchup with the customer to talk about roadmap/issues/expansion?
- Has their team had a good experience asking for help or reporting issues to us?
- Is the customer using PostHog on a weekly / monthly basis?

61
SourceMaterial/growth/marketing/blog.md Normal file
View File

@ -0,0 +1,61 @@
---
title: Blog
sidebar: Handbook
showTitle: true
---
The [blog](/blog) is for telling PostHog stories and updates around our product positioning.
Accessible content with jokes, memes and gifs have done well.
## Successful Hacker News topics
A successful post on Hacker News can currently increase traffic by 5-10%.
Stories about PostHog's early hustling days have done well.
- Feb 20, 2020 [Launch HN: PostHog (YC W20) – open-source product analytics](https://news.ycombinator.com/item?id=22376732)
- Feb 28, 2020 [Our experience moving to SF to do YC](https://posthog.com/blog/moving-to-sf/)
- Jun 2020 [How we raised $3M for an open source project](https://posthog.com/blog/raising-3m-for-os)
- Jan 2020 [A story about pivots](https://posthog.com/blog/story-about-pivots)
## Future topic areas
We want to start writing stories about our team, customers and community.
To view and contribute blog post ideas join our #ideas-for-blog-post Slack channel.
Todo: organize the blog post ideas into topic categories and priority list.
## Publishing
Submit a PR to [posthog/posthog.com](https://github.com/posthog/posthog.com) with the following content:
- with a new Markdown file (md, mdx) in `/contents/blog/`
- any assets [optimized]((/docs/updating-documentation)) and added to a new folder under `contents/images/blog/`
- the post added to relevant sidebar in `src/sidebars/sidebars.json`
Create an annotation on [app.posthog.com](https://app.posthog.com) for the content to track the effect.
Share the live content with out PostHog Users Slack group first, in the `#editorial` channel.
Arrange further promotion via the newsletter, social channels and 3rd party communities.
## PostHog Array
The PostHog Array is our product release series.
It's named the PostHog Array, because hedgehogs are collectively known as an *array* of hedgehogs.
Yakko adds new items to the Array ;) by gathering changes and highlights from PRs and the engineering team.
Each array includes:
- a community MVP
- a summary of new features, improvements and fixes
- important announcements e.g. deprecations
- detailed overview of each change with an image/video
- community shoutout for other contributors
- open roles
- complete list of PRs included
Before merging and distributing the release post, check with Tim that the new version has been released.

95
SourceMaterial/growth/marketing/community.md Normal file
View File

@ -0,0 +1,95 @@
---
title: Community
sidebar: Handbook
showTitle: true
---
See [./](Marketing) for community goals.
## Replying to the community
- Be kind, concise and direct
- Do not promise delivery dates
- Ask people to create GitHub issues for bugs and feature requests
- Provide a links to relevant GitHub issues and/or pull requests
## Discussions
Questions to consider about the platforms we use:
- Does it align with our mission and values, e.g. open source and its implications
- Does it exclude people
- How does it compare in terms of accessibility
- How does it compare in terms of ease of use
### Chat/Forum
We use Slack for our [community chat](https://posthog.com/slack) and share new content in *#editorial* before other non-Slack channels.
### GitHub
Community discussions can take place in GitHub issues and pull requests.
The engineering team can people in rather than having to following everything.
### Social
Speak to James for access.
**Channels:**
- [Twitter](https://twitter.com/posthoghq)
- [LinkedIn](https://www.linkedin.com/company/posthog/)
- [YouTube comments](https://www.youtube.com/channel/UCn4mJ4kK5KVSvozJre645LA)
**Content sources:**
- Original content from our blog, YouTube, GitHub and other channels
- Reply to discussions on our content
- Engage with wider community topics TBD
**Communities:**
Discuss sharing specific content with relevant communities:
- Startup School
- Hacker News
- Indie Hackers
- Reddit:
- [/r/analytics](https://www.reddit.com/r/analytics/)
- [/r/businessintelligence](https://www.reddit.com/r/businessintelligence/)
- [/r/opensource](https://www.reddit.com/r/opensource/)
- [/r/programing](https://www.reddit.com/r/programing/)
- [/r/python](https://www.reddit.com/r/python/)
- [/r/django](https://www.reddit.com/r/django/)
- [/r/startups](https://www.reddit.com/r/startups/)
- [/r/entrepreneur](https://www.reddit.com/r/entrepreneur/)
- [/r/business](https://www.reddit.com/r/business/)
- [/r/marketing](https://www.reddit.com/r/marketing/)
- [/r/dataisbeautiful](https://www.reddit.com/r/dataisbeautiful/)
### Events
Speak to James for access.
We use Eventbrite to organize events.
### Contributors
We created a [contributors platform](https://posthog.com/contributors) to recognize the community's work.
Merch is automatically awarded to people who contribute to any PostHog repos.
Notable PRs can be manually tagged with `extra merch` to reward large contributions.
### Merch
Speak to James, Yakko or Paolo for access.
We use Shopify for our [merch store](https://merch.posthog.com).
Note: a large portion of the vouchers will cover shipping.
### Orbit
We use [Orbit](https://app.orbit.love) for community analytics.

141
SourceMaterial/growth/marketing/index.md Normal file
View File

@ -0,0 +1,141 @@
---
title: Overview
sidebar: Handbook
showTitle: true
---
**The Marketing/Acquisition Team**
Philosophy: Be kind, concise and direct.
## Product positioning
An **open source product analytics platform** addresses the lack of choice and control amongst disconnected analytics solutions by offering a **unified platform** with **control** over hosting, pricing, source, data, privacy and security.
**Free PostHog** is positioned to solve product analytics problems for small non-enterprise teams.
**Enterprise PostHog** is positioned to solve product analytics problems for larger teams and enterprises.
**PostHog Cloud** is positioned to service clients who need less control.
**PostHog Self Hosted** is positioned to service clients who need more control.
## Target audience
*Innovative technical teams*, more commonly found in startups, who care about:
- a unified product analytics platform
- open source
- control: hosting, pricing, source, data, privacy and security
We will expand to non-technical teams when we have achieved technical awareness saturation.
### Goal 1: User acquisition
Increase:
- Open source self hosted installs
- Tracked in [AARRR dashboard](https://app.posthog.com/dashboard/2973)
- Page views tracked in [Marketing dashboard](https://app.posthog.com/dashboard/2881)
- Premium self hosted leads
- Todo: needs consolidated tracking
- Free cloud signups
- Todo: needs consolidated tracking
- Premium cloud signups
- Todo: needs consolidated tracking
### Goal 2: Community growth
Increase:
- GitHub stars
- Tracked in Orbit
- GitHub contributors
- Tracked in Orbit
- GitHub contributions
- Todo: needs consolidated tracking
- Plugin contributions
- Todo: needs consolidated tracking
See [Community](./marketing/community) for community function.
### Requirements
#### Achieve complete tracking
Tracking marketing efforts that contribute to acquisition and growth.
Going beyond marketing, tracking through the funnel to improve targeting.
#### Reduce effort to contribute
Reduce the actions, time or complexity for us and our community to contribute.
#### Reduce acquisition cost
Reduce cost to acquire users and grow our community.
## Functions
Functions that contribute more to *Acquisition* than another metrics are owned by Marketing.
Documentation contributes more to *Activation* and *Retention* than *Acquisition*. Marketing is a stakeholder in coverage and completeness.
*Activation* and *Retention* contribute more to *Referral* than *Acquisition*.
- Product marketing:
- research: market, competitor
- product positioning
- buyer personas
- messaging: website, careers, channel bios, README.md
- Content marketing:
- [Blog](./marketing/blog): product releases, stories (team, product, customer)
- Audio: audio stories, podcast series
- [Video](https://www.youtube.com/channel/UCn4mJ4kK5KVSvozJre645LA): video stories, vlog series, showcases, tutorials
- [Newsletter](./marketing/newsletter): general, investor
- Handbook: team, culture
- [Community](./marketing/community):
- social: Twitter, LinkedIn
- discussions: Slack, HN, StartupSchool, Reddit
- [onboarding](https://posthog.com/handbook/growth/sales/yc-onboarding): YC startups
- events: online, in-person
- networking: open source, analytics
- sponsorship: open source
- [Press](./marketing/press):
- relationships
- announcements
- media packs
- [Paid](./marketing/paid):
- search
- social
- communities
- newsletters
- websites
- podcasts
- events
- video
- Technical:
- reporting
- tracking
- tooling
- SEO
- Design:
- visual identity
- web properties
- channels
### Team
Prioritizing hiring for functions based on acquisition success and capacity in relation to other functions.
- Product marketing: currently hiring
- Content marketing: Mo
- Community: hiring next
- Press: 2022
- Paid: 2022
- Technical: hiring next
Design provided as a service by the Design team.

33
SourceMaterial/growth/marketing/newsletter.md Normal file
View File

@ -0,0 +1,33 @@
---
title: Newsletter
sidebar: Handbook
showTitle: true
---
Speak to James or Yakko for access.
We use Mailchimp for our newsletter.
## Lists
### Newsletter
Our general list which grows from:
- Newsletter signups from the website
- PostHog users who opt-in
- Event attendees
Sean sends a newsletter after every product release (2-4 weeks) and include a summary of the new version and and recent news.
We aim to include at least one new blog post in every newsletter.
Use few links and emojis, and 1-2 images.
Users are automatically tagged to indicate where they came from e.g. Newsletter Subscribers, Deployed Posthog, Eventbrite, etc.
### Investors
List of interested investors.
James manually manages this list.

27
SourceMaterial/growth/marketing/paid.md Normal file
View File

@ -0,0 +1,27 @@
---
title: Paid
sidebar: Handbook
showTitle: true
---
We are running limited ads at the moment and will dedicate more resources after improving product marketing and various metrics.
Todo: create a database of tactics and success.
## Platforms
### Twitter
We actively use Twitter Ads with a small budget for awareness.
### Google Ads
We actively use Google Ads with a tiny budget to capture PostHog search keywords.
### Reddit
We've used Reddit for campaigns.
### LinkedIn
We've used LinkedIn for campaigns and hiring.

71
SourceMaterial/growth/marketing/press.md Normal file
View File

@ -0,0 +1,71 @@
---
title: Press
sidebar: Handbook
showTitle: true
---
## Press enquiries
Any press-related enquiries should be directed to press@posthog.com. Only James, Tim or Charles should be talking to the press on PostHog's behalf. If someone from the press approaches you, please raise with one of them in the first instance.
## Managing press releases
From time to time, we may have significant company news that we want to release via the press, in addition to our usual channels. This is usually for significant company milestones such as funding rounds.
We have a simple process to ensure that any press releases go smoothly.
### First steps
- [ ] Write up objectives and comms strategy - what is the purpose of the press release? What key message(s) are we trying to get across?
- [ ] Set an approximate target date
### Two weeks before release
- [ ] Confirm key messages and write first draft press release
- [ ] Finalize target date
- [ ] Pitch and secure a media exclusive - our investors can help with this
- [ ] Secure approval for any third party involvement, e.g. quotes we want to use
We currently prefer working with a single media partner on an exclusive basis, as we believe a single, high-quality story is more impactful than taking a broad approach, given our current early stage.
### One week before release
- [ ] Finalize press release and share with exclusive media partner
- [ ] Any media prep if interviews have been scheduled
### On the day of release
- [ ] *Wait for the media partner's story to go live first!* Check it carefully and ask for any errors to be amended before proceeding with the below...
- [ ] Push out the press release via BusinessWire
- [ ] Submit via YC's social media request from
- [ ] James to post on his personal LinkedIn (and tag all relevant people)
- [ ] Post in our PostHog Users Slack
- [ ] Post in YC Slack
- [ ] Write post on our blog about the news
- [ ] Post on PostHog Twitter (and tag all relevant people)
- [ ] Share links to all of the above to the PostHog team so they can share
## Press release template
Include media and quotes from James, Tim or influential people.
```
# Headline
News
## About PostHog
PostHog is an open source, product analytics platform. PostHog enables software teams to understand user behavior – auto-capturing events, performing product analytics and dashboarding, enabling video replays, and rolling out new features behind feature flags, all based on their single open source platform. The product’s open source approach enables companies to self-host, removing the need to send data externally.
Founded in 2020 by James Hawkins and Tim Glaser, PostHog was a member of Y Combinator’s Winter 2020 batch, and has subsequent raised $12m in funding from GV, Y Combinator and notable angel investors including Jason Warner (CTO, GitHub), Solomon Hykes (Founder, Docker) and David Cramer (Founder, Sentry).
## About Y Combinator Continuity Fund
YC Continuity is an investment fund dedicated to supporting founders as they scale their companies. Our primary goal is to support YC alumni companies by investing in their subsequent funding rounds, though we occasionally invest in non-YC companies as well.
Like YC’s early-stage partners, the entire YC Continuity team has strong operating experience. We work to create opportunities for founders to continue their personal growth and scale their companies successfully.
We also run the YC Growth Program, which brings together founder-CEOs who are leading rapidly growing companies.
```

22
SourceMaterial/growth/marketing/releasing-content.md Normal file
View File

@ -0,0 +1,22 @@
---
title: Releasing Content
sidebar: Handbook
showTitle: true
---
<br />
We aim to regularly publish content in the form of videos and articles as part of providing value [to build a big community](content).
As a result, we have formulated a loose strategy for how to approach publishing the content produced once it is ready to be exposed to the world.
#### Suggested Workflow
1. If the content requires a visual element, create a [design request](https://posthog.com/handbook/company/working-with-design) (more than 24 hours in advance) to have a graphic produced. For example, if the content is a YouTube video, we'll make a thumbnail image. If it's a blog post, we'll create a post image that is featured at the top of the post.
1. Make sure the content is actually live: If it is an article, ensure that the changes are reflected on the website following the merge of the pull request, which might take 10 to 30 minutes.
1. Post a link to the article/video on our `#editorial` channel in the PostHog Users Slack group. This group should always the first to hear about new content.
1. Include the article in the **body** of an email and schedule it to be sent the next day via Mailchimp to people in the 'PostHog Newsletter' audience.
1. Schedule a tweet to be posted 1-2 days later with a link to the content.
1. Consider making a post on HackerNews on the same day as the content goes live on Twitter. Not all posts should go on HN, only the ones that make sense for that specific audience. Videos generally do not do well on HackerNews, for example.
1. Evaluate if the content can also benefit from being published in other mediums, such as LinkedIn, Reddit, or Medium. If unsure, you're generally better to publish it and see what happens.
1. Create an annotation on [app.posthog.com](https://app.posthog.com) about the content release, so that we can determine if it was the cause of any changes in our metrics.

105
SourceMaterial/growth/sales/billing.md Normal file
View File

@ -0,0 +1,105 @@
---
title: Billing
sidebar: Handbook
showTitle: true
---
## Managing billing
This handbook section is sort of the operation manual for the billing engine. If you're looking for the technical details or need to troubleshoot something check out the relevant [tech docs](https://github.com/PostHog/posthog-cloud#additional-docs)
### Self-hosted
For customers with special pricing (i.e. very large volumes or Enterprise & Supported plans), we need to manually set up the billing information on the system. This page contains instructions for setting up billing. Please note this page covers the process after an official PostHog quote has been approved by the customer. For information before this stage, please refer to the [Sales](/handbook/growth/sales/sales-operations) section of the handbook. Contrary to cloud plans, **all self-hosted _paid_ plans must be manually prepared today** (i.e. there's no self-serve option yet). To set up billing for self-hosted, please follow these instructions:
#### Pre-setup
This process only needs to happen once.
1. Download the Postman collection from [license][license].
1. Open the collection & set up the required environment variables (per the instructions on the repo).
1. To test that everything is working as expected go to the "List licenses" request and make sure you get a 200 status code.
#### Setting up a subscription
1. Log in to the [Stripe dashboard](https://dashboard.stripe.com/customers) and go to customers.
1. Tap on New and fill out the form. At minimum please provide the customer's email address. However, it's recommended to add as much information as possible to make ongoing maintenance easier. It is particularly recommended to add the customer's Hubspot ID in the metadata section with a `hubspot_record` key (you need to save the customer record first).
1. Copy the customer ID from the Stripe dashboard (it starts with `cus_`).
1. Open the Postman collection and go to the "Create license [all options]" request.
1. If you don't have the price ID of the plan you can obtain it from the [products page](https://dashboard.stripe.com/products). Be sure to copy the **price ID, not the plan ID** (it should start with `price_`).
1. On the body section, adjust the appropriate parameters (for details on the parameters check out the [license][license] repo),
```json
{
"valid_until": "2021-06-01T00:00:00.000000Z", // Timestamp (UTC) of when the license should expire (this won't affect the ongoing subscription agreement)
"plan": "enterprise",
"client_name": "Company, Inc.",
"client_contact": "John Doe",
"billing_email": "customer@example.com",
"stripe_customer_id": "cus_iwdnHIV5",
"stripe_price_id": "price_1HIbh9QhdPP",
"coupon_id": "qthElB", // Optional (ID coupon for special pricing)
"trial_end": "2021-01-22T00:00:00.000000Z" // Timestamp (UTC) of when the trial should end
}
```
1. After sending the request, make sure that Test Results show `(1/1)` (see below) and open the visualize tab. You should see a message like the one below with a link to set up billing. **Send that link to the customer** who can use it to enter their card details on their own.
![success license](../../../images/license-key-1.png)
1. Finally, go to the _pretty_ tab and you will see the license key for the user. You may share that key with the customer once they have activated their subscription. After [#10](https://github.com/PostHog/license/issues/10) when the activation process happens automatically, you may share the license key with the customer immediately.
#### Activate subscription
As a customer, to redeem a license key:
1. Go to the license page in your PostHog instance. `<your url>/instance/licenses`.
1. Enter the received license key in the input.
1. Tap on activate license key and you are good to go.
### Cloud billing
Cloud billing may be set up using self-serve. For this, the new user just needs to go to the [organization billing](https://app.posthog.com/organization/billing) page and select one of the available plans (internally please note these plans must have both `is_active` and `self_serve` set to `True`). Billing can also be set up from account creation, by adding the `plan_key` as a query string parameter (e.g. `https://app.posthog.com/signup?plan=standard`), this is helpful for redirections from landing sites where a plan has already been selected.
For PostHog Team: to set up a billing agreement, please follow these steps.
1. Go to the [Django admin](https://app.posthog.com/admin/) and open the [Organization billing](https://app.posthog.com/admin/multi_tenancy/organizationbilling/) objects.
2. Search for the relevant user (either by name, company name, email or Stripe IDs).
3. Once you have the appropriate user, select the plan you want to assign to the organization.
4. In addition to the plan, be sure to check the "Should setup billing" checkbox and click save.
After this the user will be prompted in their app to enter their card details to initiate the billing agreement.
If you need to activate a plan bypassing actual billing on Stripe (this should be extremely rare!), just set up a `billing_period_ends` that is after today's date (and be sure that "Should setup billing" is not checked).
#### Non-profit organizations
We offer 50% discount to non-profit companies (see [pricing](/pricing#non-profits)). The activation process is as follows:
1. Non-profit company reaches out to PostHog, likely via email.
1. On our end we validate the company is eligible for the discount.
1. Validate the customer has signed up for the standard plan and completed the billing process. Easiest done in [Stripe dashboard][stripe_dashboard], look up the customer using the owner's email address. The Standard Plan subscription must be active **and** the customer must have a valid payment source on file.
1. On the customer page click on Actions, and then _Apply coupon_. Select coupon "Non-profit organization discount" (ID: `NxipELS0`)
1. Let the customer know via email.
#### Startup & YC plans
We offer [a deal](/handbook/growth/sales/yc-onboarding) for certain YC companies & other startups, while the details of this deal change periodically (and are documented in the main website and/or ops repo), here are the details on how to apply the plan for a company. Internally, these plans have special logic handling in the [posthog-cloud][posthog-cloud] repo. If our deal terms changes (current details detailed below), a new plan needs to be added. This custom logic is handled in `multi_tenancy/models.py#handle_post_card_validation`). Currently we only have one plan (`plan_key = startup`) which provides free billing for 1 year and a 20M monthly event allocation.
**How to apply it**
- Follow the steps above (Go to Django admin, find the relevant customer, ...).
- For the plan, you'll choose the custom startup plan, `plan_key = startup`. Be sure to check the `should_setup_billing` checkbox!
- Let the customer know they need to enter their card information at the prompt (shown on every page of the app).
- After they enter their card information successfully, the plan will be activated and the prompt will disappear. The plan will last for 365 days from the moment they confirm their card details.
**General structure & notes**
- The way this plan works internally is that it creates a checkout session with `mode = setup` and with a card pre-authorization charge instead of a subscription agreement. This way, we validate the card is active and it gets saved on Stripe for future use. When we receive confirmation the charge has been processed and the card saved (via the `payment_intent.amount_capturable_updated` webhook), we do the custom logic handling to enable the plan for 365 days.
- There's an issue, [posthog-cloud#92](https://github.com/PostHog/posthog-cloud/issues/92), with some details on tech debt / improvements to this flow.
#### Updating subscriptions
This section provides instructions for a PostHog team member to change subscriptions for a existing customer (e.g. if they want to upgrade/downgrade, move from legacy plans to standard plans, etc.)
1. Look up the customer on [Stripe dashboard][stripe_dashboard] using their email address or Stripe ID (this ID can be obtained from Django Admin too, under `OrganizationBilling` object).
1. Click on the customer's current subscription.
1. Click on _Update subscription_.
1. Remove the old item from the pricing table and add the new item.
1. Click on _Update subscription_. Do not schedule the update for a later time. There will be unintended side effects if the changes are not applied immediately.
1. Find the corresponding `OrganizationBilling` on [Django Admin](https://app.posthog.com/admin/multi_tenancy/organizationbilling/). You can look up by the same email address.
1. Update the **new billing plan and the new Stripe subscription item ID**. The subscription item ID starts with `si_` (not to be confused with a Subscription ID). This **ID will have changed**, the Subscription ID remains the same.
[license]: https://github.com/posthog/license
[posthog-cloud]: https://github.com/posthog/posthog-cloud
[stripe_dashboard]: https://dashboard.stripe.com/

73
SourceMaterial/growth/sales/demos.md Normal file
View File

@ -0,0 +1,73 @@
---
title: Demos
sidebar: Handbook
showTitle: true
---
## Giving Great Demos
Always focus on delivering what the customer needs. Sometimes that will mean sending them to a competitor or turning them down.
### Initial Call
The purpose of this call is to work out what the potential customer needs.
Don’t be presumptive - ask why they reached out. It’s often a very quick way to understand what they need, but there will likely be adjacent challenges you can also uncover.
You are trying to work out:
- Does the client prefer ease over saving money or vice versa?
- How should the client deploy (i.e. cloud or self-hosted with support). This will depend on their volume and price sensitivity.
- Does our functionality meet their use case? Would it be worth going ahead with what we have now?
- Is the client going to need us to do most of the work? If this is the case, support is really important e.g. because they’re growing very fast.
- How much analytics experience does the client have? More experience means you should focus more on how we are different, less experience means you should try to keep things simple.
As a rule, always understand the context behind the question - it may help you make further useful recommendations.
### Demo
#### Environment
When doing a demo of PostHog, you should prioritize using the following environments:
1. The client's own instance or PostHog Cloud account (if they have one **and** are OK with this).
This is the best way to do a demo because you can help the client with their exact needs and you show them how to do what they want with their own data, so they immediately see the value.
2. The [PostHog Demo Environment](https://playground.posthog.com)
The demo instance was designed to be an environment with a significant amount of "good" demo data that showcases the multiple features of PostHog and allows clients to log in and run the demo themselves (while following your instructions).
To run a demo on the demo environment, you should:
1. **Have access:** Ask Yakko or James to give you access if you don't have it.
2. **Invite the client to the instance:** Invite them to the instance so that they can have access themselves without you having to share credentials.
3. **Guide the client through a demo while they share their screen:** Take them for a spin of the product as you would do if you were the one navigating. But be patient, the client might want to click around and get a feel for PostHog, which is encouraged!
4. **Revoke their access at the end of the call:** After the call, revoke the client's access to the instance or ask Yakko to do it if you do not have permission.
3. A local environment
This is best if you have a good set of demo data locally. You can use some our management commands for data generation to do this.
4. PostHog Cloud
Only demo using PostHog Cloud (on the PostHog team account) if you really have to. Be careful not to expose sensitive data when doing the demo.
#### Guidance
Show the client the product. Pause frequently and make sure there are no questions. Ask if the functionality would help them.
Use this to confirm the benefits to the customer that PostHog needs to provide. If you are talking only about feature X does Y, then you’re doing it wrong. "As a Product Manager, I may want to know 'X' about my users, this is how you do that."
### Follow Up
Keep this as quick as possible - if you can follow up immediately / on the same day, do it.
### Feature Requests
Sometimes client calls will highlight features that they would need which we don’t have. Your first step is to work out if what we do will be valuable enough to move forward with. Avoid committing to new functionality unless you’re already about to work on it. It’s better to underpromise and overdeliver.
### Style
* Be passionate: "This is one of my favorite parts of the system", "the neat thing about X is Y"
* Social Proof: If your current users are using something, or if you built something for a really specific reason, let the client know (obviously without naming names). This helps people know they're not the first to use PostHog!

125
SourceMaterial/growth/sales/sales-operations.md Normal file
View File

@ -0,0 +1,125 @@
---
title: Sales Operations
sidebar: Handbook
showTitle: true
---
## The Basics
We use [HubSpot](https://www.hubspot.com/) as our customer relationship management ('CRM') platform. If you need access, you can ask Charles or James H and they will send you an invite to create an account. 
As a first step, it is _really important_ that you [connect your personal PostHog Gmail account](https://app.hubspot.com/crm-settings-email/6958578/email/connectedEmails), so that if you start a conversation in HubSpot but continue it in Gmail, we'll have a complete record. This will also make it generally easier for you to sync contacts with HubSpot. 
You might also find it useful to install HubSpot's [Chrome extension](https://chrome.google.com/webstore/detail/hubspot-sales/oiiaigjnkhngdbnoookogelabohpglmd?hl=en), as it means you can manage most things directly in Gmail. 
As a general principle, we try to ensure as much customer communication as possible is captured in HubSpot, rather than in individual email inboxes, so that we make sure our users are getting a great experience (and not confusing or duplicate messages from different team members!). You should use the channel that suits the user, not us. Just make sure you keep Hubspot up to date with your interactions. We've seen much higher response rates on Slack than email. You can copy paste from there into Hubspot until we have a way to integrate the two.
Hubspot is a comprehensive tool with a lot of functionality, so we are currently focused on using a few core features well. You are most likely to use the following regularly:
- _Contacts_ - pretty straightforward, under 'Contacts'. You can create contacts manually, or sync with your Gmail.
- _Companies_ - also under 'Contacts'. You will also want to create a company record to associate with any contact (and you can associate multiple contacts with a single company). If you enter the company's domain name, HubSpot is pretty good at pulling in additional data to fill out the record. 
- _Inbox_ - this is under 'Conversations' and is where we deal with messages that come into our public-facing email addresses. New messages will come in as 'Unassigned' and then get assigned to someone.
- _Deals_ - under 'Sales'. This is where we manage our customers who are interested in an Enterprise or Startup plan and is the core of our sales ops process. 
- _Tasks_ - also under 'Sales'. This is a useful place to see a summary of all the tasks that you have created or that have been assigned to you. 
If you'd like to dig deeper, HubSpot have a ton of [documentation](https://knowledge.hubspot.com/) and resources that you can refer to as well.
## Managing our CRM
People currently come into HubSpot through one of 3 ways:
- They email hey@posthog.com, sales@posthog.com or another email address if we have created a custom one for a specific group
- They sign up to the PostHog app
- They are manually added to HubSpot by a member of the team, e.g. if you met someone interested in PostHog at an event
### Email
New conversations come into 'Unassigned', whereas ongoing conversations will go straight to your inbox.
We do not have super defined roles here, but generally:
- James H deals with Enterprise queries
- Yakko takes care of Startup queries
- Paolo focuses on existing customers
- Charles oversees sales ops and HubSpot admin
However, anyone can and should jump in if they can help or they see someone hasn't been responded to, especially when folks are on holiday!
We have lots of handy templates you can use as well - just select _Templates_ in the email window in Hubspot. If you find yourself sending the same type of email repeatedly, you may want to create your own template - go to 'Conversations' -> 'Templates'.
If an inbound email is about one of our Startup or Enterprise plans, you should create a Deal - more on this below. 
In addition to hey@posthog.com and sales@posthog.com, we sometimes create special one-off email addresses to use for specific groups, such as for an event or promotion. If you create a Google group and you want messages to flow into HubSpot to be managed, make sure you add our [HubSpot inbox email address](hello-1@posthoginc.hs-inbox.com) to your group as a member.
### New PostHog signups
All new users are automatically added via our Zapier app to the 'New PostHog User' stage of our Sales pipeline. Sorting these ensures that we can keep communication clear with a customer when they have multiple users on the account - it's really annoying for a customer if we are having parallel conversations with different people on their team!
More on how we manage these users in the Deals section below. 
### Manually adding new users
You can also just manually add a user to HubSpot under 'Contacts'. When creating a new contact, try to add as much useful information as possible, especially about the type of company they work for and what their needs are. This enables us to provide them with the best possible experience. 
Once you have created a contact, you may want to add them to a Deal, depending on the context. 
Make sure you also assign someone as the Contact owner, so it's clear who is responsible for managing that relationship.
## Deals
We manage two pipelines for our deals - _Enterprise_ and _Startup_. This helps us stay organised, given the process is different for each.
Creating a Company with a Contact should be the _first_ thing you do when you are setting up a deal in HubSpot, if one does not exist already. It's then really easy to add a Deal from within a Company record.
Creating a new deal is quite intuitive, but here are a few tips:
- Generally, try to fill out as much information as possible - this is useful for you, but also gives context to other people working with a customer
- Make sure you assign your deal to the right pipeline
- Every deal needs an owner - this is the customer's main point of contact at PostHog
- Tag every deal by 'Deal Type' - use your judgement to determine which category makes sense
- Put the deal in the right _Deal Stage_ - again, use your judgement! Usually this will be 'First Contact' or 'In Discussion'. 
You can also easily add a customer to a deal directly from the Inbox as well - just select 'Create a Deal' in the right hand pane when you have their message selected. 
### Managing the pipeline
We don't have a super detailed process on this yet. That being said, here are a few things to bear in mind:
- Use private notes to tag relevant people for their attention, ask questions etc. Do this in HubSpot (not Slack) so everyone can stay on the same page. If you need to tag someone who doesn't have a HubSpot account, as Charles to add them. 
- Be clear, direct and open - see other deals for examples on tone. We are very opposed to the use of any kind of corporate language.  
- Be responsive! 
Within a deal, you can also set Tasks such as a follow up reminder for yourself. We are working on automating these, but in the meantime you can manually create tasks really easily, e.g. 'Follow up in 3 days'. HubSpot will automatically notify you of your tasks due each day by email.
As a conversation progresses (or not) with a customer, you should move them into the relevant stage as appropriate. 
### Quotes
Any Enterprise customers or Cloud customers wanting to capture over 500k events per month require a custom quote. 
Our Enterprise pricing starts at $2,000 per month, but you will need to determine the appropriate pricing based on factors including:
- What level of support they require, such as monitoring and/or updating their instance
- Approximate user/event volume anticipated
- Hosting requirements
- Number of projects
- Whether they have existing data to migrate
- Any relevant deadlines
We provide a discount for annual upfront invoicing, typically 10%. We may also offer some sort of free trial if appropriate - 30 days is our standard.
We generate quotes directly within HubSpot - go to 'Sales' -> 'Quotes'. 
The process is fairly straightforward for creating a quote. A couple of points to note:
- It is really important that you add our standard payment terms to the quote, so it is clear when the customer should expect to pay.
- You can use 'Snippets' when building a quote to insert frequently used text (like payment terms).
- Do not use the Stripe billing integration as it is very basic and does not enable you to have different types of line item (e.g. 1 month free trial and then an ongoing monthly subscription). 
### Billing
Once a quote has been agreed with a customer, you should proceed to billing and generating a license key for them. See instructions on how to do this on the [Billing](/handbook/growth/billing) page.
## All done - now what?
This is just the beginning of what will hopefully be an awesome relationship with a new customer!
We are just getting started here, but a few things that you should do:
- Make sure you invite the customer to our PostHog Users Slack!
- If they are an Enterprise customer, they should also have a private Slack channel in there with us.
- Set a couple of tasks in HubSpot to check in with them - depending on who they are you may want to check in after 1 week/month/quarter.

99
SourceMaterial/growth/strategy.md Normal file
View File

@ -0,0 +1,99 @@
---
title: Growth Strategy
sidebar: Handbook
showTitle: true
---
<br />
##Self-serve
We believe this approach will lead to the best product for end users, which is how we'll build the best company.
[Adam Gross](https://twitter.com/adam_g?lang=en) has given some excellent [talks on this topic](https://www.heavybit.com/library/video/self-serve-go-to-market/), that we've borrowed from.
#1-2-3 framework
## Product
This means the path to revenue starts with adoption of a Free version, then working out how to get teams (whether a small team at a big company or a 20 person startup) onto a paid version, and ultimately how to get departmental adoption at large enterprises.
| | 1 - Free | 2 - Team (Self Serve) | 3 - Enterprise (C-Level) |
|---|---|---|---|
|Value|Creation|Collaboration|Compliance|
|GTM|Free/Adoption|Self-serve|Enterprise|
### Examples of other companies following (part) of this
#### Postman
As an individual, it is useful for organizing your own API creation activity.
In team mode, it is a way for multiple teams to organize distributed development effort. If you're building across multiple teams with different services, how you coordinate these teams is a big, strategic business problem. By using the same tool with modifications, you can orchestrate this.
#### LaunchDarkly
As an individual, you can view as a pure utility for launching feature flags. I can write myself or use this thing off the shelf to save time. Interesting but limited value proposition.
In team mode, it becomes a way for a team to organize its business process between Product Management and Engineering. It becomes a product management process tool on rails.
## Our structure
As we grow, it'll get important to work out which teams in PostHog own different functions.
<table>
<tr>
<th>Function</th><th>Free</th><th>Team (Self Serve)</th><th>Enterprise (C-Level)</th>
</tr>
<tr>
<td>Marketing</td>
<td colspan="2" style="text-align: center;">Marketing (Developer Evangelism)</td>
<td>Enterprise Product Marketing</td>
</tr>
<tr>
<td>Sales</td>
<td>Developer Experience</td>
<td>Customer Success</td>
<td>Enterprise Sales</td>
</tr>
<tr>
<td>Support</td>
<td colspan="3" style="text-align: center;">Developer Experience</td>
</tr>
<tr>
<td>Success/Retention</td>
<td>Developer Experience</td>
<td>Customer Success</td>
<td>Customer Solutions Architect</td>
</tr>
<tr>
<td>Business Ops</td>
<td colspan="3" style="text-align: center;">Business Ops</td>
</tr>
</table>
Following the 1-2-3 framework, we are currently focused on building our team in the first and second columns - _Free_ and _Team_ - and already have Developer Experience and Business Ops people in place. Only after we have brought in people to take care of Marketing/Developer Evangelism and Customer Success will we then look at recruiting people into the roles in the third column, _Enterprise_.
### Structure FAQ
#### Why do you have "sales" for the free product?
Developer experience will help ensure the open source product is properly adopted, for $0 in this case.
#### What's 'Enterprise Product Marketing' versus 'Marketing (Developer Evangelism)'?
Product marketing is making sure that PostHog is positioned as a platform that can be used organization-wide, to aid with expansion. For example, organizing roadmap discussions with large clients.
Developer-evangelism is more about adoption of the first users - creating content, building an audience across social media and GitHub, etc.
#### What's the difference between Customer Success and Developer Experience?
Customer Success is a more commercially-oriented function, focused on inbound sales.
#### What are business ops?
It'll be important we have good processes in place to grow usage from free to team and beyond. This means making sure we have a CRM set up, integrated with our product, etc.

61
SourceMaterial/people/benefits.md Normal file
View File

@ -0,0 +1,61 @@
---
title: Benefits
sidebar: Handbook
showTitle: true
---
Beyond [pay and equity](handbook/people/compensation), we offer several additional benefits to our team.
With everyone being distributed across the world, we do our best to provide the same benefits to everyone, but they might vary slightly by country depending on the services that are available and local regulations.
If you have any ideas for how we can improve our benefits offering, then please let us know!
### Pension and 401k contributions
We are currently in the process of setting up a 401k for our US team members, and are aiming to roll this out in Q2 2021.
In the UK, we use [Royal London](https://www.royallondon.com/) as our pension provider. Team members contribute 5% and PostHog contributes 4%, but you can opt out if you like. You can also transfer out of the plan as frequently as you like, in case you would rather manage your own private pension.
[Deel](https://app.letsdeel.com/), our international payroll provider, is currently building a pension product for contractors as well, due for release in Q2 2021. We will aim to provide the same percentages as in the UK.
### Private Health Insurance
We currently provide private health insurance in the US and UK.
In the US, our medical insurance is provided via UnitedHealthcare and managed via our payroll provider [Gusto](https://app.gusto.com/). The plan includes medical, dental and vision insurance.
PostHog pays 75% of the premium of the platinum plan, and you pay the other 25%. The same conditions apply to added dependents. UnitedHealthcare also offers cheaper Gold and Silver plans at lower cost, which you can choose if you'd like to contribute less. The exact costs depend on factors like age - the People team can create a quote in Gusto.
In the UK, we use [Bupa](https://www.bupa.co.uk/) for private healthcare (£100 excess per policy year) and [Medicash](https://www.medicash.org/) as our cash plan for dental and vision. Children are included for free. Both of these are taxable benefits which will affect your Personal Allowance each tax year, and you can opt out at any time with 1 month notice.
### Mental Health Support
We know that the world can feel a bit heavy from time to time and we want to make sure everyone gets support, if they need it.
We launched [Spill](https://www.spill.chat/) in March 2021 to give everyone in the team access to comprehensive mental health support. Spill offers access to video therapy sessions with qualified therapists (one-off or a course), together with exercises and helpful reading materials, all integrated into Slack. They also offer a one-off ask-a-therapist feature if you don't want to commit to an entire session.
Spill is 100% free and confidential - they do not share any personal information with PostHog about who is using the service etc. The _only_ exception is if they believe that there is a threat to a person's safety or the safety of others.
### Unlimited Time off
Everyone in the team has [unlimited, permissionless time off](/handbook/people/time-off). This means you won't need to ask for permission before requesting time off - our people platform [CharlieHR](https://posthog.charliehr.com/) will autoapprove your request.
We also offer generous [parental leave](/handbook/people/time-off#parental-leave) for new parents.
### Learning and Development
We currently offer a [Training budget](/handbook/people/training#training-budget) and [free books](/handbook/people/training#books) - you can find more on the relevant pages.
### Equipment and Co-working
As we are fully remote, we provide [all equipment](/handbook/people/spending-money#equipment) you need to have an ergonomic setup at home to be as productive as possible. We provide all team members with a company card for this purpose.
If you ever need change of scenery, we offer $200/month budget towards [coworking or café working](/handbook/people/spending-money#work-space).
### Off-sites and Team Socials
Ideally, we would like to meet up in person at twice a year. The team was able to meet up in Italy in September 2020, but we haven't been able to travel since, so we are planning a virtual off-site in April 2021 instead (and hopefully a real one on Autumn 2021!).
For any work-related travel, we use [Project Wren](https://www.wren.co/) for carbon offsetting.
We also have biweekly coffee catch-ups as a team, and we use the [Donut](https://www.donut.com/?ref=slackdirectory) Slack app to pair you up with random colleague on Slack. Simply join the #virtual-coffee channel on Slack and be paired up with someone on the team to meet for a virtual coffee/tea etc.

141
SourceMaterial/people/compensation.mdx Normal file
View File

@ -0,0 +1,141 @@
---
title: Compensation
sidebar: Handbook
showTitle: true
---
## How it Works
As we are a small (but growing!) startup, we've kept compensation simple.
You can use our calculator below to work out what your salary would be for a few example roles:
<CompensationCalculator />
We think the fastest possible shipping comes from a leaner, stronger team, so we try to pay top of market. We pay well, so you'll work with the best people in the world.
Important:
- If we are missing your country, it simply means we've not hired there before so we'd need to put together some data in advance of hiring you.
- If you're considering applying to PostHog and the salary is the only blocker, then something is wrong with our model (as we aim to pay around the top of the market) for your circumstances in most cases. Please tell us as part of the hiring process and we will review things.
For hiring into executive roles, we usually use a separate database of compensation benchmarks rather than this calculator. The terms of access to this database means that we're unfortunately not able to share it publicly.
### San Francisco Benchmark
​
Our benchmark for each role we are hiring for is based on the market rate in San Francisco. We use a number of difference sources to gather salary data, this includes [Payscale](https://www.payscale.com/), [salary.com](https://www.salary.com/), reported salary on Glassdoor and LinkedIn, and other available sources. We try to have a data set that is as big as possible to reduce the margin for error and add a 1.2x multiplier to the median salary.
As the market often changes quickly, we aim to update our benchmark every 6 months.
### Location factor
​
Most of our location factors are based on GitLab's location factors. GitLab uses a combination of data from Economic Research Institute (ERI), Numbeo, Comptryx, Radford, Robert Half, and Dice to calculate what a fair market rate is for each location. [Read more](https://about.gitlab.com/handbook/total-rewards/compensation/compensation-calculator/#calculating-location-factors) on how GitLab calculates this location factor.
In order to simplify location factors, we have added a floor at 0.5 globally, and 0.65 specifically for the US. This means nobody will have a location factor lower than 0.5. We are aware that this might lead to comparatively low number for certain areas in comparison to others, but this approach allows us to move fast now and adjust the location data later on, if needed.
If your location isn't listed, we will create one for you based on Numbeo's data for the relative Cost Of Living with San Francisco.
​
### Level
More experience does not correlate with increased importance. Seniority is _not_ a title - we don't believe in having a huge hierarchy of roles, as everyone needs to feel like the owner of the company that they are.
We pay more experienced team members a greater amount since it is reasonable to expect this correlates with an increase in skill - being able to ship faster through less time having to work things out for the first time is valuable. Experienced hires can help upskill the less experienced hires on the team too. Team members who have less experience can see a steady increase in pay over time as they increase their experience and skill.
We believe at first increased skill comes from more time spent in the role. Over time, this judgement becomes more subjective and is instead based on the speed with which you can ship or help the team to ship, the quality of your prioritization and decision-making, as well as your technical approach.
### Steps
Within each level, we believe there's a place to have incremental steps to allow for more flexibility. We define these as follows:
- *Learning*: Starting to match expectations.
- *Established*: Matching expectations.
- *Thriving*: Exceeding expectations.
- *Expert*: Exceeding expectations consistently.
With exception of team members at the very beginning of their career, we hire into the *Established* step by default. This will give everyone the opportunity to be set up for success and leave enough room for salary increases, without the need to move up in seniority.
The definition of what is needed to progress from one step to the next in more detail depends on your role. Ask your manager for detail of what you need to work on.
## Equity
​
It’s important to us that all PostHog employees can feel invested in the company’s success. Every one of us plays a critical role in the business and deserves a share in the companies success as we grow. When employees perform well, they contribute to the business doing well, and therefore should share a part of the increased financial value of the business.
As part of your compensation, you will receive share options in the company with a standard 1-year cliff, 4-year vest. Broadly, the amount of options will depend on the Level as per the Experience Factor. We may change this policy from time to time depending on our rate of hiring - e.g. if we had a gap in hiring for an extended period, we would adjust this.
Whilst the terms of options for _any company_ could vary if we were ever acquired, we have set them up with the following key terms:
- 10 years to exercise your options in the event that you leave PostHog
- Double trigger acceleration, which means if you are let go or forced to leave due to the company being acquired, you receive all of your options at that time
- Vesting starts from your start date (not after a "probation period" or similar)
It can take time to approve options, as it requires a board meeting and company valuation. We can clarify the likely time frame at the time we're hiring you. In any case, you will not be disadvantaged as vesting will always start from when you joined PostHog.
## Relocating
​
If you're planning on relocating permanently, your salary will be adjusted (up or down) to your new location.
If this represents an increase in pay, _we need to approve this change in advance_ - we cannot guarantee it is always possible, as our budgets may or may not allow it.
​
## Nomading
​
If you plan on spending >4 months/year in a place different from your home base, that will be adjusted based on your location after 4 months.
For a trip with many destinations over a period of more than 4 months, the location factor will be located along the various places you intend to stay, averaged by the amount of time spent.
If you are uncertain about where you're travelling to in advance, and you are travelling for over 4 months, then we will keep your pay the same as when you departed. 4 months later, we will make a manual adjustment to edit your next pay amount based on the average of the previous 4 months. This will take place every 4 months until you are done travelling. If the adjustment would require reclaiming more than your entire pay amount (for example if you moved from one of the world's most expensive areas to one of the world's least inexpensive areas), then we will work with you on how quickly we reclaim it. Generally this would be over no more than the following 4 months. It is your responsibility if you take this approach to budget appropriately.
​
If this represents an increase in pay from however much you were _most recently_ paid, _we need to approve this change in advance_ - we cannot guarantee it is always possible, as our budgets may or may not allow it.
## Salary Adjustments, Raises, and Promotions
​
We do not expect to do any salary raises, adjustments or promotions until July 2021, outside of role or location-based changes. After that, we will run a bi-annual review cycle to evaluate which Level and Step you are at.
## Exchange Rate
Unless there is a very good reason, you'll be paid in your local currency. This means that you know exactly how much you'll get every month. The rates are from [OpenRates](https://openrates.io/) and were taken on *1st January 2021*. Every year we'll update the rates on the 1st of January.
## Notice period
We are fully committed to ensuring that you are set up for success, but also understand that it may take some time to determine whether or not there is a long term fit between you and PostHog.
During the first 3 months of your employment, you can choose to end your contract with 1 week's notice. If we chose to end your contract, PostHog will give you 4 weeks notice. In both scenarios, we expect you to handover your work to the team, but you won't have to work the rest of your notice period.
Your manager is responsible for monitoring and specifically reviewing your performance throughout the probation period. If under-performance is a concern, or if there is any hesitation regarding the future at PostHog, this should be discussed immediately with you and your manager.
## Severance
At PostHog, average performance gets a generous severance.
If PostHog decides to end your contract after the first 3 months of employment have been completed, we will give you 4 months' pay. It is likely we will ask you to stop working immediately.
If the decision to leave is yours, then we just require 1 month of notice.
We have structured notice in this way as we believe it is in neither PostHog's nor your interest to lock you into a role that is no longer right for you due to financial considerations. This extended notice period only applies in the case of under-performance or a change in business needs - if your contract is terminated due to gross misconduct then you may be dismissed without notice. If this policy conflicts with the requirements of your local jurisdiction, then those local laws will take priority.
## Contracts
We currently operate our employment contracts in the two geographic regions where we have business entities:
- United States of America
- United Kingdom
This means, if you live in one of those countries, you will be directly employed by PostHog as an employee in one of our entities.
If you live outside the US or the UK, we use [Deel](https://app.letsdeel.com/) as our international payroll provider.
In most cases, you would be an independent contractor and you will invoice us monthly via Deel. Deel offers pretty much all countries and currencies. As a contractor, you will be responsible for your own taxes.
In case contracting isn't an option, Deel also offers an Employer of Record service, so you would be employed by Deel on our behalf. However, you must have the independent right to work in the country of residence.
## Payroll
In the UK and for international contractors, we run payroll monthly, on of before the last working day of the month.
In the US, we run payroll twice a month, on the 15th and on the last day of the month.

97
SourceMaterial/people/feedback.md Normal file
View File

@ -0,0 +1,97 @@
---
title: Feedback
sidebar: Handbook
showTitle: true
---
## Feedback at PostHog
Sharing and receiving feedback openly is _really_ important to us at PostHog. Part of creating a highly autonomous culture where people feel empowered is maintaining the most transparent and open flow of information that we can.
This includes giving feedback [to each other](/handbook/company/values#step-on-toes), so we know we are working on the right things, in the right way. While giving feedback to a team member can feel awkward, especially if it is not positive or if you are talking to someone with more experience than you, we believe that it is an important part of [not letting others fail](/handbook/company/culture#dont-let-others-fail).
'Open and honest' != 'being an asshole' - we expect feedback to be direct, but shared with good intentions and in the spirit of genuinely helping that person and PostHog as a whole to improve. Please make sure your feedback is constructive and based on observations, not _emotions_. If possible, share examples to help the feedback receiver understand the context of the feedback.
## Full team feedback sessions
We run full team 360 degree feedback session as part of every off-site (we usually do them every 6 months). The session gives everyone the opportunity to give and receive feedback to everyone else.
With us growing the team, we will be splitting the session into smaller groups in the future, to ensure everyone gets the most ouf of this session.
### Ground rules
- Everybody participates! You should have a think and prepare in advance - don't try and wing it on the day.
- Preparation includes reading our handbook about how to be a good feedback [giver](/handbook/people/feedback#how-to-give-good-feedback) and [receiver](/handbook/people/feedback#how-to-receive-feedback-well).
- Feedback to be 70% constructive - this is an opportunity to help each other to grow.
- Everyone is expected to give feedback to everyone, even if they don’t work together directly. It may be very short feedback, which is ok!
- That being said, avoid piling on and repeating feedback others have given unless you have a different perspective or can add more context. It is ok to say "+1 to what X said about Y" and move on. Do not spend 2min repeating the same point that has already been made by someone else.
- Everyone is responsible for noting down and actioning their own feedback (ie. the people team won't do this for you).
## Performance reviews
In addition to informal day-to-day feedback and the full team 360 degree feedback session, it is important that we enable team members to take a step back every so often and look at their performance and aspirations in a wider context. This helps us to support a team member's growth and ensure it is aligned with PostHog's needs.
This process is intended to be self-serve. The People team will ensure the process is kicked off and recorded properly, but it is the individual team member's responsibility to run the process. If you need support, ask your manager, Eltje or Charles for help.
We currently run performance reviews every 6 months, based on your start date. We will probably need to change this cadence as we scale, but this feels appropriate for our current stage of growth.
### The performance review process
1. The People team adds recurring calendar invites to the calendar of the team member and their manager to kick off the performance review process.
2. The team member will schedule a 1 hour performance review meeting with their manager. A member of the people team may sit in on the occasional feedback meeting to see how well they are working as we get up and running.
3. In advance, the team member writes up a self-assessment in [this document](https://docs.google.com/document/d/1fxP0w_gNno7Y-2Uxw4uSYCaJTpvZpDXiFZ7lFPXsDpw/edit?usp=sharing), and their manager will fill out a similar assessment in [this document](https://docs.google.com/document/d/1UbS9YkGDZsAhPsZmxRRI2g83ZuQzPwoQNQeJ7IGBm9I/edit?usp=sharing). You will likely want to include and reflect on feedback you've previously received in a full team 360 degree feedback session.
4. Afterwards, the manager communicates back to the People team that the review is complete and what next steps are needed (if any), including around any salary adjustments if the team member's Step or Level should change. The People team will store these docs on Charlie HR for future reference.
While the 360 degree team meeetings are purely feedback-focused, you should aim to spend the bulk of the performance review looking ahead to the next 6 months (and beyond).
Part of the review will include your [compensation](/handbook/people/compensation), as we directly link this to your level of experience and your performance. You should not, however, expect every performance review to result in a change to your Step or Level - most of the time, they won't. Additionally, you will find that your Step will change more frequently than your Level.
### How to give good feedback
We know that giving feedback can sometimes be difficult, so here are a few tips on how to give good feedback:
- If something went wrong, focus on what has actually happened, not on whose fault it is. Assigning blame is not productive.
- Be as specific as you can with your feedback. An example can be helpful to give the recipient context.
- Sometimes a question can be more useful if you feel you lack the full context. For example 'I've noticed that you sometimes do X. Can you explain to me what your thought process is when you are doing that?'
- If your feedback is about behavior, focus on the behavior itself and its impact on you, rather than attacking the person's character. For example 'When you do X, it makes me feel Y. Would you be willing to do Z instead?'
- Remember that positive feedback is really important - we should reinforce and affirm the things we want that person to keep doing!
We expect everyone to support each other by giving lots of feedback - it's not ok to stay quiet if you have something constructive to share.
### How to receive feedback well
If someone is making the effort to give you feedback, you should reciprocate by receiving that feedback well. Being a good feedback receiver means that people will be more inclined to give you feedback in the future, which will help you to grow!
Here are a few tips to help you do this:
- Assume positive intent on the part of the feedback giver.
- Try not to hear attack - listen for what is behind the words.
- It can be useful to paraphrase the feedback to ensure you have understood it correctly, or ask questions to clarify.
- You do not have to accept all feedback! However, it's probably worth taking time to reflect on it, rather than reacting in the moment. There is a difference between acknowledging feedback and disagreeing with it.
## Full team feedback sessions
In addition to individual performance reviews, we also hold full team feedback sessions twice a year. These are usually scheduled as part of our offsites. These are super intense and memorable, and create _much_ more trust, transparency and directness.
### How it works
- Everyone gives feedback to everyone else. We have tried this with first a team of 10 (worked well), and a team of 20 (valuable, but slightly too many people).
- Feedback could be anything - i.e. designers will give feedback to engineers and vice versa.
- What you do with the feedback is totally up to you - write down, then choose to accept/discard feedback.
- Repeat every 6 months.
In the future, we will split the session into groups in order to manage time better.
### Ground rules
- Everybody participates! You should have a think and prepare in advance - don't try and wing it on the day.
- Preparation includes reading this page about how to be a good feedback giver and receiver.
- Aim for your feedback to be 70% constructive - this is an opportunity to help each other to grow.
- You are expected to give feedback to everyone, even if you don’t work together directly. It may be very short feedback, which is ok!
- That being said, avoid piling on and repeating feedback others have given unless you have a different perspective or can add more context. It is ok to say "+1 to what X said about Y" and move on. Do not spend 2min repeating the same point that has already been made by someone else.
- Everyone is responsible for noting down and actioning their own feedback (i.e. the People team won't do this for you).
### How is this different from individual performance review?
The full team session prioritises openness, breadth and transparency of feedback, as everyone gets to both give and receive feedback in front of the entire team.
The performance review process centres on a single person for one hour, involves a smaller subset of the team, and is intended to be more of an in-depth conversation.

244
SourceMaterial/people/hiring-process.md Normal file
View File

@ -0,0 +1,244 @@
---
title: Hiring Process
sidebar: Handbook
showTitle: true
---
This page will walk you through how we hire at PostHog. The goal is to have a lightweight process that optimizes for speed for the candidate, but above all for quality of the hire.
## Deciding to Hire
Every hire introduces complexity to the organisation and increases our burn rate. As a result, we think very carefully about each new role, and we set an extremely high bar for the people that we do hire.
See [our Strategy page](/handbook/strategy/strategy) to find out how we are thinking about which people we should be hiring, and when.
If we are hiring a role that we have less expertise in (e.g. a role we've never hired for before), it is worth getting an outside opinion on how to hire for this role before starting any of the below.
## Writing the spec
At the moment, we're not too worried about everyone on the team having really precisely defined job specs. PostHog is growing fast and job descriptions are changing rapidly so it's impossible to define a set list of tasks.
That being said, it is important that any job spec is written with your target audience in mind, in a clear and engaging way. There are several guides on how to this ([here is a good one](https://resources.workable.com/tutorial/how-to-write-a-good-job-description)), and you can also look at previous job ads to get a feel for how we communicate about PostHog.
Once the job ad is out there, don't be afraid to [iterate](https://posthog.com/handbook/company/culture#iteration) and improve on it given the data! You shouldn't feel constrained by your initial spec if it isn't quite working, or if PostHog's needs have evolved since you first wrote it. Bear in mind that you will need to update it everywhere it has been advertised, so it is worth putting the effort in up front to get it right.
## Managing candidates
We manage all of our candidates through [Workable](https://posthog.workable.com/backend) - please ask Eltje or Charles for an invite to view candidates, leave feedback, and schedule meetings. Make sure you record all candidate-related comms on Workable so we can ensure we provide all candidates with the best experience we possibly can - even if they are unsuccessful, they should come away feeling like they had a great interaction with PostHog.
Workable is a pretty intuitive platform to use, but here are a few helpful tips to get you going:
* [A guide to getting started with the basics](https://help.workable.com/hc/en-us/articles/360038712074-Hiring-Manager-Getting-Started-) - this is pretty much everything you need if you are mainly using Workable to leave feedback on candidates you've met, but are otherwise not involved in the recruitement process.
* Link your Gmail account in Settings if you are in direct contact with candidates - this means any emails you send directly from your inbox will automatically be captured on their Workable record for everyone on the hiring team to see.
* When emailing candidates from within Workable, you can select a Template from the drop down bar (and customise it if you want). If you find yourself writing the same email, it is worth saving as a template.
If you receive an application directly emailed to you or if someone contacts us through a non-Workable channel like Slack, you can either:
* Forward their email onto our [dedicated Workable email address](mailto:posthog@jobs.workablemail.com) - this is the most effective option.
* If you think they are a strong candidate but they didn't email, introduce them directly to us via our [careers email address](mailto:careers@posthog.com).
* As a last resort, ask them to apply via the relevant link on our [Careers page](https://posthog.com/careers) - this is the least preferred option as it has the highest likelihood of a candidate dropping out. Only use this option for high volume roles. You should say something like "Thank you for your interest in PostHog! Can I please ask you to apply via our Careers page? We receive hundreds of applications every week, and this will ensure that we have all your details on our system."
### Booking meetings
If you are booking meetings through Workable, you should connect your Google Calendar and Zoom accounts under Settings first - this enables you to schedule meetings from within Workable itself. This is really helpful, as Workable will automatically populate the calendar invitation with all the useful info for interviewers like resumes so you don't need to do it manually.
When you book, you have the option of selecting a Google Meet or Zoom call. You should default to Zoom unless you are scheduling a meeting that you are not attending yourself, in which case use Google Meet (as Zoom will require you to attend as host).
Make sure you have set an agenda for the meeting in order to be welcoming to the candidate and to let the internal PostHog team member know what they need to cover in the meeting. The person who _books_ the meeting is responsible for setting the agenda.
## Our Hiring Process
The stages of our hiring process are:
- Application
- Culture interview with Eltje
- Technical interview with the hiring team
- this is usually Tim and 1 or more PostHog team members interviewing the candidate at the same time who would work closely with the candidate day-to-day
- decide if we will do a SuperDay, else give feedback
- PostHog SuperDay
- Offer
There may be an additional interview where we bring in a 3rd party with specialist expertise in the case of hiring roles that we've not hired for before.
Responsiveness at all stages is really important to us - at each stage of the process, we should aim to get back to candidates with feedback within 48 hours. It is not ok to leave candidates waiting for weeks, or for someone to apply and never hear back from us.
### Application
Read applications and resumes/portfolios carefully and leave your feedback as a Comment on their record in Workable.
If a candidate hasn't customized the application or resume to the role, it is a flag they're aren't that excited about working at PostHog. It is understandable why people don't do this, but at an interview stage, it's important to note how passionate they seem about the company. Did they try out the software already? Did they read the handbook? Are they in our community Slack?
A good rule of thumb when deciding whether not to progress - if the candidate doesn't get a _definite yes_ then it's a _no_. It's almost never worth putting through someone who is a 'maybe'! We provide lots of information about PostHog to enable candidates to put their best application forward.
Candidates who are unsuccessful at this stage will receive automated feedback, unless they personalized their application, in which case a short email is appropriate.
#### Engineering
We hire repeatedly into engineering roles, so here are a few things we look for:
- Experience with relevant technologies (Python or similar, React or similar, something to do with big data is a bonus)
- Has started a project from scratch, without outside help
- Usually this manifests as having been the founder of a startup, or building an impressive side project. It can also be shown through a big project in the day job, but that requires a bit more digging.
- Communication. Do they have writing errors in their cover letter? What does their online presence look like?
- More so than other companies, all of our communication is written and public for the world to see. Good written communication is key.
### Interview 1 - Culture with Eltje
We start with an interview which is designed to get the overall picture on what a candidate is looking for, and to explain who we are. A template scorecard has been created for this stage in Workable.
This is to allow both PostHog and the candidate to assess whether the candidate is a great cultural addition to the team, and to dig into any areas of potential misalignment based on the application. We are looking for proactivity, directness, good communication, an awareness of the impact of the candidate's work, and evidence of iteration / a growth mindset.
- Talk about PostHog, where we're at and what the future looks like, including our long-term vision. If it was cold outreach, we provide a little more context up front.
- Talk about the candidate, dig into any questions we have from their CV.
- Talk about the hiring process and check if the candidate has seen our compensation calculator so we know we're roughly aligned.
Candidates who are unsuccessful at this stage should receive a personalized email with feedback.
### Interview 2 - Technical
The second step is the technical interview. This is usually 2 PostHog team members spending an hour with the candidate (at the same time).
These interviews will focus on the skills needed to fill the role.
For a design hire, questions could be:
- A walk through of an example website page, product or other
- Tell me about one of the pieces in your portfolio
- What does your calendar look like on a day you'd really look forward to - what sort of tasks would be on it?
- How do you educate yourself on design?
For an engineering hire, this would be things like:
- Tell me about a project you started from scratch.
- What was the hardest technical thing you've done in the last month?
- What did you do on your very best day at work?
- Tell me about a project that you led that failed. Why did it fail and what did you learn?
For every role that is created on Workable, we create a structured scorecard with questions listed so you don't need to remember them every time! This is intended as a guide, not a script, so feel free to deviate from the scorecard and go off on tangents - a good interview is a conversation, not a questionnaire. Just try to keep the basic structure of your questions consistent, as this makes it easier to compare candidates to each other.
[Here are some more ideas](https://firstround.com/review/40-favorite-interview-questions-from-some-of-the-sharpest-folks-we-know/) for great questions to ask candidates.
One of the two technical interviewers will lead the discussion. The reason for 2 people is to ensure a deeper, higher quality interview.
The person interviewing outside their area of expertise is the bar-raiser. The bar-raiser is here to qualify that everyone is truly excited about the candidate and that they're an example of us believing in talent compounds. Everyone should still think this way - or they should be clear in why they don't feel like this as part of their feedback.
As a rule of thumb, everyone interviewing must feel a genuine sense of excitement about working with the candidate. Again - if it is not a _definite yes_, then it's a _no_.
Candidates who are unsuccessful at this stage should receive a personalized email with feedback.
### PostHog SuperDay
We offer those who have gotten through the interview process the chance to do a paid PostHog SuperDay. We schedule 1 full day in advance with the candidate where we hire them as a contractor.
This gives the candidate a chance to learn how we work, and for us to see the quality, speed and communication of the candidate. It is a very demanding day of work.
We will pay the candidate their 'normal day rate.' If they have done contracting before they will have one, but if not you can use [this formula](https://www.ellwoodatfield.com/event/how-to-calculate-out-your-day-rate/) to calculate it. In case the candidate is unable to accept pay for the SuperDay, we will donate the amount to a charity of their choice.
This day will be _the same_ task each time for a given role, to be shared with the candidate at the start of the day. For the Full Stack role, the task involves building a small web service (both backend and frontend) over a full day. The task is designed to be _too much_ work for one person to complete in a day, in order to get a sense of the person's ability to prioritize. The tasks should be as close as possible to those that the candidate would be working on every day.
In advance of the SuperDay, you will need to do some additional prep to ensure that the candidate has a great experience:
* Send them an email in the first instance to schedule the SuperDay - you should do this as soon as possible, as candidates often will need to book a day off work. Use the Workable email template for this. If the task involves them doing 'real' work for PostHog, you should ask them to check that their current employment contract permits this - we try to create fake tasks for this reason.
* (One day before the SuperDay) Send the candidate a follow up email with details of the task, and ask them for their day rate and bank details. There is a template for this email in Workable, depending on the role - this will probably need customising.
* (One day before the SuperDay) Create a private channel in Slack for the candidate, you and anyone else relevant - this will be where they can chat to us over the course of the day if they have any questions etc. Invite the candidate as a single channel guest. You may need to add the candidate to one of our systems depending on the role, e.g. Workable for a recruiter SuperDay, but on the whole this should be minimized.
* (One day before the SuperDay) Invite the candidate to a kickoff meeting with the hiring manager at the start of the day. On days where we have a [standup](https://posthog.com/handbook/company/standups) scheduled, invite them along. On days without standup, schedule an informal session with some team members to give them a chance to learn more about our culture. You may also want to have a proper wrap up with them at the end of their day.
* (On the SuperDay) Send the candidate the task - aim to send this before the kick-off session.
* (On the SuperDay) Give the candidate a warm welcome! Make it clear that the team is here to answer any questions, and they should feel free to reach out any time! Otherwise don't feel like you need to check in with them - let them get on with the task and trust that they will message you.
* (One day after the SuperDay) Pay the candidate using the bank details they provided.
### Decide if we will hire
There will be a written catchup over Slack or call via Zoom about the candidate with all people involved during the hiring. A yes/no decision will be made and then communicated to the candidate.
It is expected that everyone has submitted their notes on Workable so we can discuss these to the meeting.
In case of a rejection, it's important to clearly outline why that decision was made. Highlight what went well, but also mention specific points of improvement. Offer to schedule a call if they would like to discuss further. Make sure to leave the door open for the future so they can apply again in 12-18 months time as circumstances and people change.
If there are wildly different opinions, reflect on why.
### Making the hire
Hooray!
To give a candidate an offer letter and to move to the rest of the onboarding, see [Onboarding](/handbook/people/onboarding).
## Referrals
Every time we open a new role, we will share the details and ideal profile with the team during standup.
If you know someone who would be a great addition to the team, please submit them as a referral. If they're successfully hired, you'll receive a $1000 Referral Bonus! The bonus can be either paid to you directly, or towards a charity of your choice (and we will match the amount). You can also split the amount between you and the charity.
**What counts as a referral?**
Someone you have a personal or professional relationship with to confidently say they align with our values and fit our requirements. Please make sure the candidate has given their consent before putting them forward!
**What's the process?**
* If there is an ongoing conversation, please ping Eltje into the email thread with the referred candidate, she will take it over from there.
* Otherwise, Send Eltje their CV and contact details. If you don't have their resume, please include a link to their LinkedIn profile.
* If they have applied themselves already, let Eltje know within 48 hours of them applying.
**Referral payout process:**
The bonus date is 3 months from the new team member's start date and will be processed as part of payroll.
**External referrals**
We also welcome external referrals, e.g. from:
* From our investors
* From the PostHog community (the users Slack Group, and posting on our social media profiles for our followers to see)
* From the YC community (Slack / WhatsApp / Forum)
As a thank you, we will give you $50 credit for our [merch shop](https://merch.posthog.com/).
## Visa sponsorship
Building a diverse team is at the heart of our culture at PostHog and we are proud of be hiring internationally. In some cases, this includes the need for visa sponsorship. We are currently only able to provide visas in the US and the UK.
- If you are already in the country on a visa (e.g. employed, youth mobility), or require a new visa to remain in the country (e.g. student converting to employed), we will cover the costs for any employee, new or current.
- If you wish to relocate and need a visa, we unfortunately will not cover the cost for obtaining the visa or any relocation costs.
For employees where PostHog covers the costs related to obtaining a visa, the employee agrees to reimburse PostHog if they voluntarily terminate their employment prior to the completion of 12 months of service. The costs will be calculated on a monthly basis, so when the employee decided to leave after 10 months, they will have to repay 2/12 of the costs related to the visa.
In case a candidate needs a visa sponsorship, please keep in mind that the process is lengthy and costly.
## Where to find great candidates
### Direct outreach
Outreach has a few advantages:
* We can approach people with very specific or relevant experience, even when they are not currently looking for a new role
* It allows us to encourage candidates from a wider range of backgrounds to apply
* It also helps with building an employer brand and general awareness
It is possible to research a list of potential candidates through:
* Workable - [People search](https://help.workable.com/hc/en-us/articles/115012750768-What-is-People-Search-) is a great tool to find profiles, email addresses and social media profiles!
* LinkedIn - [Boolean searches](https://www.talentlyft.com/en/blog/article/306/boolean-search-a-simple-guide-for-recruiters) are your friend!
* Twitter
* Behance
* Dribble
* AngelList
It is important before starting outreach like this that you consider *why* a candidate messaged through this approach would move to us, so that your note to them can explain why you felt it might be a nice fit.
### Job boards
#### Design
We are learning which boards work well:
- [Behance](https://www.behance.net/adobetalent)
- [Dribbble](https://dribbble.com/jobs/new)
#### Engineering
- HackerNews Who's Hiring
- Tend to get high quality candidates, and people interested in working at startups.
- See [Tim's comment history](https://news.ycombinator.com/threads?id=timgl) for a template.
- [AngelList](https://angel.co)
- We found Eric through there. Higher quality than RemoteOK and pretty high volume.
- [RemoteOK](https://remoteok.io/)
- High volume of candidates, but much lower quality.
#### General
- Workable pushes all jobs to 17 job boards, including LinkedIn, Indeed etc.
- Since PostHog is a YC company, we can place job ads in YC's [Work at a Startup list](https://www.workatastartup.com/jobs).
- [AngelList](https://angel.co)

109
SourceMaterial/people/offboarding.md Normal file
View File

@ -0,0 +1,109 @@
---
title: Offboarding
sidebar: Handbook
showTitle: true
---
Offboarding team members can be a sensitive time. The aim of this policy is to create transparency around how this process works.
Very infrequently, we may have long term contractors working for PostHog, acting essentially like a permanent employee. In this case, the process below is exactly the same. This offboarding policy *does not* apply to regular contractors who are doing short term work for us.
## Voluntary Departure
In this case, the team member chooses to leave PostHog.
We ask for 30 days of notice by default (unless locally a different maximum or minimum limit applies), and for you to work during that notice period. This is so we have some time to find someone to hire and to enable a handover.
If you are a current team member and you are thinking about resigning from PostHog, we encourage you to speak with your manager or the [people team](https://posthog.com/handbook/people/team-structure/people) to discuss your reasons for wanting to leave. We want to ensure that all issues team members are facing are discussed and resolved before a resignation decision has been made.
If resignation is the only solution after you have discussed your concerns, please communicate your intention to resign to your manager or the people team. We will then start a discussion around what is needed for the handover.
## Involuntary Departure
In this case, we require the team member to leave.
This is generally for performance reasons or because the company's needs have changed and the role can no longer be justified.
Once the team member has been with us for 3 months, we will provide a 4-month [notice](https://posthog.com/handbook/people/compensation#severance) (otherwise, it will be a month). We will usually ask the team member to stop working immediately, but still pay them a 4-month severance).
## Communicating Departures
PostHog cannot always provide context around why people are leaving when they do.
In the case of voluntary departure, we will ask the team member if they wish to share what they're up to next with the team.
In the case of involuntary departure, we will aim to be as transparent as possible about the reasons behind the departure, while respecting the individual's privacy.
## The Process for Offboarding
For involuntary leavers, we will schedule a call, covering the following points with the team member:
1. Final pay
2. Share options vested
3. Company property
4. Business expenses
5. Personal email to the company
During the call, someone on the ops team needs to complete the [offboarding checklist](#offboarding-checklist).
For voluntary leavers, the people team will schedule an [Exit interview](https://forms.gle/DaNGRhmvQJcLGfpa9) to hear more about the team members experience working at PostHog, their reasons for leaving and to identify areas for improvement. This will usually happen on their last day.
During the call, we will also cover above questions and answer any open questions the team member has.
If the team members works their notice period, we will start an offboarding issue and document the progress and handover in there.
### Final Pay
Final pay will be determined based on length of service and the reasons for leaving.
* If the offboarding is voluntary, you will be paid up until your last day. We will look at the amount of holiday taken in the last 12 months and will pay any "unused" vacation pay assuming you would have taken 25 days (since we offer unlimited vacation periods).
* If the offboarding is involuntary and due to performance reasons or a change in business needs, you will receive 4 months of pay, provided you have passed your probation period.
* If the offboarding is voluntary or involuntary and due to performance reasons during your probation period, 1 week's notice applies.
* If the offboarding is involuntary and for gross misconduct or breach of contract, you may be paid nothing and receive no notice.
We are likely to ask departing team members to sign a release of claims in order to receive payments beyond their final day of work.
Please note that if there are local laws which are applicable, we will pay the greater of the above or the legally required minimum.
### Share Options Vested
If you have been allocated share options, we will confirm how many have vested and the process by which you may wish to exercise them. We have a team-friendly post-departure exercise window of 10 years, and most team members who leave will be deemed a 'good leaver' unless you have been terminated due to misconduct or negligence.
### Company Property
You will be required to return any company property to us. PostHog will cover the cost of shipping this.
### Business Expenses
We will pay any expenses in line with our policy that are still unpaid.
### Personal Email to the Company
In the case of voluntary offboarding, you will be offered the chance to send a goodbye email to the company, with relevant contact information as you move on.
## Offboarding checklist
<input type="checkbox"/> (Voluntary leavers only) Arrange handover <br />
<input type="checkbox"/> (Voluntary leavers only) Schedule [Exit interview](https://forms.gle/DaNGRhmvQJcLGfpa9) <br />
<input type="checkbox"/> Arrange company property to be returned <br />
<input type="checkbox"/> (Contractor only) End their contract on Deel <br />
<input type="checkbox"/> (UK employee only) Email DRG with their last day, remaining annual leave and to remove them from the pension scheme <br />
<input type="checkbox"/> (UK employee only) Email Parallel to remove them from Bupa and Medicash <br />
<input type="checkbox"/> (UK employee only) Email team member P45 and upcoming payslips <br />
<input type="checkbox"/> (US employee only) Remove the team member from Gusto (Gusto will automatically end any benefits provided via the platform, e.g. medical insurance <br />
<input type="checkbox"/> (US employee only) Get the team member to sign their termination certificate <br />
<input type="checkbox"/> Put on an out of office (forward email if the leavers expects external communication), then deactivate the GSuite account for the team member <br />
<input type="checkbox"/> Make any outstanding notice payments (if applicable) <br />
<input type="checkbox"/> Cancel team member's company card on Brex/Revolut - _check if they have any company subscriptions first that need transferring_ <br />
<input type="checkbox"/> Offboard member on CharlieHR <br />
<input type="checkbox"/> Add departure to hiring forecast on Pry <br />
<input type="checkbox"/> Remove team member from PostHog organization in GitHub <br />
<input type="checkbox"/> Remove team member from the internal company Slack <br />
<input type="checkbox"/> Remove team member from PostHog Users Slack <br />
<input type="checkbox"/> Remove team member from 1password <br />
<input type="checkbox"/> Remove team member from app.posthog.com <br />
<input type="checkbox"/> Remove team member from AWS <br />
<input type="checkbox"/> Remove team member from Workable <br />
<input type="checkbox"/> Remove team member from the [Team page](https://posthog.com/handbook/company/team) <br />
<input type="checkbox"/> Ask their manager for any other accounts they need to be removed from <br />

141
SourceMaterial/people/onboarding.md Normal file
View File

@ -0,0 +1,141 @@
---
title: Onboarding
sidebar: Handbook
showTitle: true
---
As a remote organisation, doing a great job of welcoming a new member of the PostHog team is really important. You may find that you need to invest extra time and effort into onboarding someone than you might at a company where everyone is physically located together.
We have members working all around the world, so their onboarding process may look a little different depending on where they are based and what type of contract they are on. We either bring on new people as an employee or contractor (with equivalent terms and benefits as an employee) dependent on the jurisdiction.
If you have any questions on any of this stuff, ask Charles, James or Tim.
The best way to run through this checklist is to copy the relevant sections below into an onboarding issue on the [Ops Roadmap](https://github.com/orgs/PostHog/projects/2) in GitHub.
## Upon Offer Acceptance
Eltje or Charles will create the contract needed, depending on who is joining. Only James and Tim are allowed to sign on behalf of the company.
### US Team Member Checklist
<input type="checkbox"/> Create a contract using the [Google Docs template](https://docs.google.com/document/d/15cdfWfGj5OWBpVST6VcMwb5TP5qLVPQd9SGWKSnB9bc/edit?usp=sharing) in the Legal Docs shared drive <br />
<input type="checkbox"/> If we are employing someone in a new state for the first time, check the tax filing requirements on Gusto as soon as possible, as there can be a long lead time <br />
### UK Team Member Checklist
<input type="checkbox"/> Create a contract using the Google Docs templates for [CIIA](https://docs.google.com/document/d/1r7Xc1ALf-JKUrL3g_oyzaQ8H3SOuVchBpJrGp7TINdc/edit?usp=sharing) and [Offer Letter](https://docs.google.com/document/d/1ZzF5hbVmTmKIYKxW7JkXzrBFFNrztkcNvcdO643r6sY/edit?usp=sharing) in the Legal Docs shared drive <br />
<input type="checkbox"/> Email Parallel to add them to our pension scheme <br />
### Non-US nor UK Team Member Checklist
<input type="checkbox"/> Use [Deel](https://letsdeel.com) to set up as a contractor. Choose 'Create a contract' and select fixed. Follow the instructions. This contract will cover pay, notice period, confidentiality and IP assignment. <br />
<input type="checkbox"/> Choose the last day of the month to make payments for ongoing work, else choose something appropriate for a short term contract <br />
<input type="checkbox"/> Select a notice period of 30 days <br />
<input type="checkbox"/> Select for the contractor to upload necessary compliance documents <br />
<input type="checkbox"/> Select for the contractor to be potentially allocated equity in the future (if this has been agreed) <br />
<input type="checkbox"/> Under 'Other Specifics' add the following as a special clause: _Contractor agrees to comply with any rules, policies and procedures set out in the Company Handbook, a copy of which is available on the Client's website. To the extent that there is any conflict between the terms of this Agreement and the Company Handbook, the terms which are more favorable to the Contractor shall prevail._ <br />
## The Week Before They Join
Eltje and the new team member's manager will mostly do this.
<input type="checkbox"/> Add the team member to [CharlieHR](https://posthog.charliehr.com/) and ask them to fill in all details, upload relevant docs (e.g. passport scan). Once they are on, manually change their profile so their holiday requests are auto-approved. <br />
<input type="checkbox"/> (UK only) Send a copy of their HMRC new starter form on CharlieHR to DRG, and include their salary and if they are full or part time <br />
<input type="checkbox"/> (UK only) Ask if they want to be part of our [private healthcare](/handbook/people/benefits#private-health-insurance) and if they want to contribute our [pensions](/handbook/people/benefits#pension-and-401k-contributions) <br />
<input type="checkbox"/> Send team member a copy of this page so they can check everything has been done <br />
<input type="checkbox"/> (US only) Add the team member to [Gusto](https://app.gusto.com) <br />
<input type="checkbox"/> (UK only) Send the team member the HMRC new starter form, pass it on to DRG once signed for payroll <br />
<input type="checkbox"/> Create GSuite account for the team member <br />
<input type="checkbox"/> Add team member to 1password <br />
<input type="checkbox"/> Check that the team member is invited to the daily standups and any other regular meetings (e.g. retros, life stories) <br />
<input type="checkbox"/> Send team member a link to the [Handbook](/handbook) <br />
<input type="checkbox"/> Send team member a digital company card <br />
<input type="checkbox"/> Team member to purchase any necessary equipment as per the [spending money](/handbook/people/spending-money) guidelines <br />
<input type="checkbox"/> Ask Charles to give them $100 credit to spend on Shopify <br />
<input type="checkbox"/> Share the [Important Company Details](https://docs.google.com/spreadsheets/d/1k4o4VN5VSsgFZpVYrN28Ib0z_pCJFTJyQdfkZEHhOV0/edit?usp=sharing) sheet with them <br />
<input type="checkbox"/> Add team member to the PostHog app <br />
<input type="checkbox"/> Send them an invite to [Drata](https://app.drata.com) to do security onboarding and their background check <br />
<input type="checkbox"/> Add the team member's details to our hiring plan in Pry <br />
<input type="checkbox"/> Add the team member's share options to Captable.io (if relevant) <br />
## On Their First Day
<input type="checkbox"/> Manager to book a weekly 1:1 with the team member <br />
<input type="checkbox"/> (UK only) Schedule a [right to work](https://www.gov.uk/guidance/coronavirus-covid-19-right-to-work-checks) check with Eltje
<input type="checkbox"/> Send them these instructions on adding the [team time off cal](https://intercom.help/charliehr/en/articles/839648-importing-your-time-off-calendar-to-google-calendar) to their Gcal <br />
<input type="checkbox"/> For the first week or so, book extra sessions as appropriate to provide extra help <br />
<input type="checkbox"/> Add team member to any relevant Google Groups <br />
<input type="checkbox"/> Add team member to the internal company Slack (and give them a warm welcome!) <br />
<input type="checkbox"/> Also add them to the virtual-coffee and standup channels on Slack <br />
<input type="checkbox"/> Add team member to PostHog Users Slack <br />
<input type="checkbox"/> Add team member to PostHog organization in GitHub <br />
<input type="checkbox"/> Share user interview notes with them, found in [this doc](https://docs.google.com/document/d/1762fbEbFOVZUr24jQ3pFFj91ViY72TWrTgD-JxRJ5Tc/edit). If the person is particularly interested in more historical context, here are the notes from [Q4-2020](https://docs.google.com/document/d/1gJlsUDrlW7ur8zT5scqRvXZhapm_0JdvKGiw68Iyx9E/edit), and [Q3-2020](https://docs.google.com/document/d/1vrwn-owF320otkm3oODCFjvqj7gptF6QaFFO6v-_RhY/edit). <br />
<input type="checkbox"> Team member should add themselves to the [customer interviews calendar](https://calendar.google.com/calendar/?cid=Y19tczllaWN1Ym92ZGgxYWhzNmtoY2xpNTQ3b0Bncm91cC5jYWxlbmRhci5nb29nbGUuY29t).
> Not a hard requirement by any means, but we highly recommended that you join a feedback call and/or product demo in your first weeks. It provides great context on our users.
### Additional Access
Add these if appropriate for the role:
#### Engineering
<input type="checkbox"/> 'Team' group in AWS <br />
<input type="checkbox"/> PagerDuty and into on-call rotation - make sure the alerts work <br />
<input type="checkbox"/> Papercups for customer support <br />
<input type="checkbox"/> Heroku <br />
<input type="checkbox"/> Add team member to Grafana, Sentry, and ask yourself if there are any other dev tools in use that the team member needs access to (then update this list) <br />
#### Ops
<input type="checkbox"/> Workable if they are involved in recruitment <br />
<input type="checkbox"/> Google Voice - an admin will need to issue them a licence, add the company address and assign them a number, then invite <br />
<input type="checkbox"/> Any relevant job boards we advertise on <br />
<input type="checkbox"/> Gusto, Deel and/or CharlieHR admin access if they are involved in people ops <br />
<input type="checkbox"/> Hubspot if they are involved in customer-facing roles (e.g. sales, user interviews) <br />
<input type="checkbox"/> Any relevant banking or accounting software (very unlikely) <br />
## PostHog buddy
Starting a new job is really exciting, but it can also be a little bit overwhelming. To make your first few weeks a bit easier, we started a buddy system.
The buddy 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.
We will pair people in similar time zones to make sure you get the most out of each other. The goal is to have a catch up at least once a week during the first few weeks, including time to chat about non-work topics.
## 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) or Revolut (UK) - company cards and expenses tracking
- Shopify - powers our merch store
- CharlieHR - holiday tracking, personal details
### Engineering
- AWS
- Pagerduty
- Heroku
- Grafana
- Sentry
### Design
- Figma - our main design tool
### Ops
- HubSpot - for managing all sales
- Papercups - our support platform
- Pry - financial modelling
- Captable.io - cap table management
- Fondo - US accounting
- Xero - UK accounting
- Calendly - external meeting scheduling (e.g. demos, sales)
- Gusto - US payroll
- Deel - international payroll and contracts
- Workable - recruitment tool
## Signatories
James and Tim at this time are the only people able to sign legal paperwork on behalf of the company.

23
SourceMaterial/people/side-gigs.md Normal file
View File

@ -0,0 +1,23 @@
---
title: Side gigs
sidebar: Handbook
showTitle: true
---
PostHog looks for passion in the people it hires. This often correlates with people who do things like public speaking or have side projects as a hobby. For example, we view pre-existing open source work as a strong qualifier that you're good enough at programming that it's fun to do rather than frustrating and hard!
These side gigs may sometimes earn you money. Sometimes, you may one day want your side gig to become your main gig.
We have deliberately called them "side gigs", as we are ok with you earning money on the side. We are not ok with this being your main focus and PostHog being just a paycheck. Quite simply, we are too small for PostHog not to be your main motivation.
## Managing Time
The key distinction to something being a side gig, and thus it being appropriate, is its impact on your work and the amount of time involved.
A few hours a month on a paid side gig is acceptable. Over 10 hours a week on a paid or open source side gig is a significant amount of extra work which we would expect to start impacting your performance.
If you are doing paid speaking, make it clear that you work for us, and the exception based on time does not apply - we view this as a great way to get PostHog's name out there.
In a few cases, you may want your side gig to become your full time work one day. That is ok - please just let us know, so we can create a plan. We will try to match you with tasks at PostHog that will help your long term goals, while not impacting your work performance, and will create a timeframe for you that works. We know the key to motivated people is to help you achieve your long term goals, and to align this with what PostHog needs, whether or not you eventually achieve them with us.
Above everything else, if you are going above and beyond for PostHog and you're still able to look after yourself properly, side gigs (whether paid or unpaid) are totally fine. We don't think that's possible beyond a certain level of time/energy commitment to them, but we are very happy for you to spend a little time on them each week.

167
SourceMaterial/people/spending-money.md Normal file
View File

@ -0,0 +1,167 @@
---
title: Spending money
sidebar: Handbook
showTitle: true
---
There are many occasions when you will need to spend company money.
PostHog is a lean organization - the less we spend, the more time we have to make sure the company takes off. However, it is more important you are productive, healthy, and happy.
Please just spend company money like it's your own.
If it's a trivial expense, just buy it. We provide you with a company card with a \$1,000/month spending limit for this reason. We use Brex for everyone, and also provide UK team members with a Revolut card.
If you live in the UK, you should use your Revolut card for UK-specific spending (i.e. ordering from UK sites), and Brex for everything else. This is for UK accounts-reporting reasons, as we have a UK subsidiary.
For larger expenses which don't fit into the items here, please **raise a policy suggestion for it as a pull request** in this doc, so we can document our decision making into our policy rather than making everything case by case.
## Trivial Expenses
Just do it.
This means expenses that are under \$75 one off or under \$20/month recurring that we can cancel easily.
## Saving Receipts
Make sure you *keep copies for all receipts*. If you expense something on a company card and cannot provide a receipt, this may be deducted from your pay.
You should default to using your company card in all cases - it has no transaction fees. If you need to use your personal card in an emergency, please just let Charles know afterwards to get reimbursed manually.
PostHog uses Brex and Revolut's built-in expenses tracking feature. You'll find using their apps the easiest way to submit receipts.
### Brex
- Buy something on your Brex card.
- If it's a digital invoice, just forward it to receipts@brex.com. If it's a physical receipt, respond to the Brex or SMS notification with a picture of your receipt.
- You _only_ need to submit receipts for purchases of \$75 or more.
- That's it!
Make sure you forward digital invoices to Brex from your PostHog email address - it won't work if you send from another email address.
### Revolut
- Buy something on your Revolut card.
- If it's a digital invoice, just forward it to ukinvoices@posthog.com. If it's a physical receipt, take a picture and forward it to the same place.
- You need to submit receipts for _all_ purchases.
Accidentally bought something on the company card when it was a personal expense? Don't worry! Again, just let Charles know _as soon as you become aware_ and he will provide you with the relevant bank details for you to repay the company.
## Making Larger Purchases
If your purchase fits within the policy below, there is no need to ask. We **cannot** pay you back for anything without a receipt if you use your personal card.
You may not have enough space on your company card if you're a new starter, just ask Charles (and if he's unavailable, James H or Tim) to increase your limit.
## Equipment
PostHog is an all-remote company. This means it's important you have an ergonomic setup at home to be as productive as possible.
PostHog will provide you with office equipment. Please note that it remains PostHog's property.
### Laptop
We'd prefer you to use a laptop. This is so when we host meetups in real life, you can easily bring your work with you. We'd prefer everyone uses Apple laptops, just to keep life simpler - for example, that means everyone can use the same software, and as we get bigger, it'll mean we're dealing with one supplier, not many.
* If you are in an engineering role, we recommend a Macbook Pro with an Intel processor with 32GB of RAM. The processor selection here is important as we want to ensure that you're able to run all the technologies in our stack and several of them have yet to be adapted on the new Apple architecture. Base processor and storage.
* If you are in a design role, we recommend a Macbook Pro with an Apple Silicon processor and 16GB of RAM. Base processor and storage.
* If you are in a non-technical role, we recommend a Macbook Air with an Apple Silicon processor and 8GB of RAM. Base processor and storage.
These are just general guidelines - the most important thing is that you select the model that is appropriate for _your_ needs. If your requirements are different to the guidelines above please just ask.
Apple offer multiple screen sizes. The larger screen sizes (15 inches +), are disproportionately more expensive. These make sense if you do a ton of work in coworking spaces or cafés where you do not have a second screen. If you are realistically going to do most of your work at home, it is more rational to pick a smaller laptop size, and to get a large (27 inch) monitor.
When buying something at Apple we can get 3% cashback on purchases through Brex. You should be able to find that in the 'Rewards' tab on brex or ask Tim or Charles.
You may be asked if you wanted to purchase Apple Care - please don't buy this as it's not great value for money.
We would expect to spend \$1200 to \$2000 on a laptop, depending on what you need to run. We find the easiest solution is to just purchase directly from Apple's website in your territory.
### Monitor
For monitors, we suggest you pick one that supports 4K. This means you'll get a higher resolution than a standard HD monitor, and thus can fit more content onto the screen.
We would expect to spend \$250 to \$350 on a monitor. Philips have a [great value model](https://www.amazon.com/Philips-276E8VJSB-3840x2160-UltraNarrow-DispalyPort/dp/B07JXCR263). It comes with an HDMI cable, but you'll need an adaptor to USB-C with most Apple laptops.
### Keyboard, Mouse, and Laptop Stand
We'd encourage you to buy a keyboard, mouse and laptop stand.
Again, Apple items for keyboards and mice should be what you default to - refurbished is usually fine.
[Nextstand](https://www.amazon.co.uk/NEXSTAND-K2-Adjustable-Foldable-Portable/dp/B01HHYQBB8) make great value laptop stands that are portable.
### Chairs and Desks
We find that most people already have a desk and chair that are comfortable.
If you do not, please suggest something to us. We aren't yet at the stage where we can afford the latest and greatest here, but we will aim to be reasonable.
For example, if you would like a standing desk, buy one you consider to be good value.
We would expect to spend \$250 on a desk, and around the same for a chair.
### Headphones
If you need to work in a noisy environment and don't already have noise cancelling headphones with a microphone, feel free to buy a pair.
We would expect to spend \$250 on noise cancelling headphones.
## Software
Software expenses are treated as above and will generally fall into trivial.
We are *strongly opposed* to introducing new software that is designed for collaboration by default. There needs to be a very significant upside to introducing a new piece of software to outweigh its cost.
The cost of introducing new collaborative software is that it creates another place where todo items / comments / communication can exist. This creates a disproportionate amount of complexity.
Our entire stack for collaborative software is pleasingly simple. All we use is:
* Google Sheets - spreadsheets
* GitHub - documents, code, discussion
* Slack (premium) - chat (although we encourage you to default into discussion of features/strategy etc into GitHub)
* PostHog - product analytics
* Figma - graphic design
Individual software is down to your personal preference, and we encourage you to share cool software.
### IDEs
* IDEs range widely in cost. Best in class IDE suites can cost up to \$700, which is a bad value proposition for most engineers. However, we are happy to revisit this policy if you have very specific needs.
* Before then, if you wish to spend up to \$200 on an IDE, that is fine. Visual Studio, VIM and PyCharm are the most popular within our team.
## Work Space
We care about you being healthy, happy and productive.
While PostHog will use the money saved from not having office space for real life meetups, we are happy to cover some expenses related to where you work. Most people do most of their work from home, but we understand that getting out of the house from time to time can help you escape cabin fever!
You can spend up to \$200/month to work in cafés or coworking spaces if working from home is impractical. As always, you must provide receipts for all costs, and in this case, they must only be for yourself.
If you live in the US, a particularly good way to use this budget is to cover the cost of Amex Platinum which provides WeWork access. Outside of the US, you may sign your own agreement or buy day vouchers as needed. We will not cover costs beyond this amount of money.
## Celebrations and life events
It's important to us at PostHog to celebrate team member milestones and achievements.
**Birthdays**
We have a budget of $50 for a personalised birthday gift. Eltje will reach out to the team a week before the birthday to start a virtual birthday card and ask for gift ideas.
**PostHog anniversaries**
For every PostHog anniversary, we will donate $50 to a charity of your choice. And just like for birthdays, we will also send a virtual card.
**Significant life events**
For events like childbirth, weddings, return to work after extended sick leave or the loss of a loved one, Eltje will send flowers and a gift, the budget is $100. We will also send a virtual card.
## Client Meetings
If you are meeting a user for an interview or a potential customer, we would encourage you to pick up the bill.
At PostHog's current stage, a fancy coffee shop is encouraged. A fancy lunch or dinner is not.
## Training
We have a separate section on spending money on [training](/handbook/people/training) (which covers things like books and conferences).

23
SourceMaterial/people/team-structure/_team_template.md Normal file
View File

@ -0,0 +1,23 @@
---
title: Team Example
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- [Jane Doe (Team Lead, Full Stack Engineer)](/handbook/company/team/#jane-doe-software-engineer)
- [Max Mustermann (Full Stack Engineer)](/handbook/company/team/#max-mustermann-software-engineer)
## Mission
## Responsibilities
## Customer
## Output metrics
## Slack channel
[#team-example](https://posthog.slack.com/messages/team-example)

39
SourceMaterial/people/team-structure/core-experience.md Normal file
View File

@ -0,0 +1,39 @@
---
title: Team Core Experience
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer)
- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team)
- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer)
- Sam Winslow, Full Stack Engineer
- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer))
## Mission
To create the easiest way to discover insights about products and its users
## Responsibilities
- Extending feature set as suggested by requests, by our own ideas, and by need for parity with other platforms
- Maintaining data quality and clarity
- Ensuring performant and clear user experience across all analytics functionality
## Customer
- Any PostHog user, whether they're an engineer or a product manager, should be able to effectively analyze their product.
## Output metrics
- Retention per feature
[Dashboard](https://app.posthog.com/dashboard/1124)
## Slack channel
[#team-core-experience](https://posthog.slack.com/messages/team-core-experience)

41
SourceMaterial/people/team-structure/design.md Normal file
View File

@ -0,0 +1,41 @@
---
title: Team Design
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- [Cory Watilo (Team lead, Lead Designer)](/handbook/company/team/#cory-watilo-lead-designer)
- [Lottie Coxon, Graphic Design)](/handbook/company/team#lottie-coxon-graphic-designer)
- Mike Nicklas, Front End Engineer
## Mission
## Responsibilities
- Support Small Teams (and contributors) in building better versions of PostHog
- Enable customers to build better products (using PostHog)
- Communicate to prospective customers the value we provide
Tangibly, we:
- Initiate new projects to support the responsibilities above
- Support Small Teams in completing their sprint tasks
- Iterate based on feedback from customers
## Customer
- The other small teams - [here is a guide](handbook/company/working-with-design) on how to best work with the Design team.
## Output metrics
- Acquisition
- Retention
## Slack channel
[#team-design](https://posthog.slack.com/messages/team-design)

59
SourceMaterial/people/team-structure/extensibility.md Normal file
View File

@ -0,0 +1,59 @@
---
title: Team Extensibility
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer)
- [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer)
- [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer)
## Mission
Team Extensibility's job is to turn PostHog into a platform that everyone can integrate with.
In essence, we enable users to:
- get data _into_ PostHog
- get data _out of_ PostHog
- extend PostHog itself according to their needs
## Responsibilities
Team Extensibility is particularly responsible for:
- the plugin server
- the data ingestion pipeline
- PostHog integrations with all sorts of platforms (JS, Go, iOS, Zapier, Segment, etc.)
- the user experience of extensibility features in PostHog (e.g. plugins, webhooks)
## Priorities
1. Making sure there are no cracks in the walls and that we always keep in mind safety, security, and data
integrity of our systems. We code defensively, prefer allowlists to denylists, and so on.
2. A fabulous user experience. Connecting things to PostHog either via plugins or integrations
should spark joy.
## Customer
- Plugin developers, contributors to extensibility
- Plugin users (and in extension, all PostHog app users – who we'd love to make use of plugins)
- Integration users
## Output metric
- Number of plugins installed and/or in active use
- Used plugin-seconds on cloud, breakdown by team (for billing)
- Number of integrations and their usage
[Dashboard](https://app.posthog.com/dashboard/1865)
## Meetings
- Sync: Monday, 9:00 UTC
- Sync: Wednesday, 15:00 UTC
- Internal release planning: Friday every other week
## Slack channel
[#team-extensibility](https://posthog.slack.com/messages/team-extensibility)

62
SourceMaterial/people/team-structure/growth-engineering.md Normal file
View File

@ -0,0 +1,62 @@
---
title: Team Growth Engineering
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- [Kunal Pathak (Team lead, Growth Engineer)](/handbook/company/team#kunal-pathak-growth-engineer)
## Mission
Generate scalable growth by applying focused efforts of product, data, and engineering to specific areas of our business.
## Responsibilities
* Own activation flow
* Own revenue flow
* Proactively search for (and execute) opportunities to run experiments to improve output metrics anywhere in the business
## Customer
Growth engineering works
## Output metrics
* Acquisition
* Activation
* Revenue
## Principles
### Solve Problems, not Metrics
We do not focus on moving a number– we are focused on solving real problems and solving real pain to drive growth. Metrics are used to help inform the work we do, check our assumptions, and measure our progress. However, we believe metric growth is a side effect of great experiences and solving real pain.
### Find the 80-20
It is important that we approach problems with pragmatic solutions – focus on finding the 20% that will solve 80% of the pain.
As a team with a narrow and dynamic focus, it is critical for us to boil down problems to their core and to effect change on those. Future work or progress should be summarized and shared as learnings with the broader team so we can reprioritize when appropriate.
We are a dynamic team that jumps across many different areas. We believe that it is better to be growing and getting better day by day for the next year than to be stagnant everyday but great in a year.
### Any Jank is Jank
We believe in product-led growth. This means that the product experience is always the most important thing to maintain.
Pragmatism, dynamic ownership, and the 80-20 rule are not reasons to ship poor or broken product experiences.
Nothing hurts growth more than a bad product.
### Control the Inputs, Trust the Process
Great execution beats everything.
We believe that rapid iteration, compounding our learnings, and following our experiment process will eventually lead to success. We trust that as long as we are making sound decisions and running great analyses, the right things will happen.
## Slack channel
[#team-growth-engineering](https://posthog.slack.com/messages/team-growth-engineering)

73
SourceMaterial/people/team-structure/infrastructure.md Normal file
View File

@ -0,0 +1,73 @@
---
title: Team Infrastructure & Deployments
sidebar: Handbook
showTitle: true
hideAnchor: true
---
![Image of Cloud Infrastructure](https://github.com/PostHog/posthog-cloud/blob/master/docs/images/infra.png?raw=true)
## People
- [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer)
- [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer)
## Mission
Make using and developing for PostHog as reliable as running water. Wherever you want it.
## Goals
- We don't lose events
- Data is as up to date as possible
- Engineers always be able to ship and build
- Fail fast. Fix faster.
- Ship anywhere
- Stack scales with demand
- Support Small Teams (and contributors) in building and debugging Posthog
- Be frugal.
## Responsibilities
Concrete things we take responsibility over:
- [app.posthog.com](app.posthog.com) and its infrastructure
- On Prem & Single Tenant deployments
- CI/CD - How we deploy
- Data infrastructure (Clickhouse, Kafka)
- Monitoring and Alerting stack
## Customer
- Other Small Teams in making sure they have the tools (databases, queues, etc) and the ability to deploy effortlessly that they need to build
- End users (Both cloud and on-prem teams)
## Output metrics
### VPC
###### Retention
- Metric: Retention
- Objective: Better than cloud
### Cloud
###### Data Loss
- Metric: Data loss %
- Objective: < 0.1%
###### Uptime
- Metric: Uptime
- Objective: > 99.99%
###### Speed
- Metric: Speed
- Objectives
- Event ingestion: TBD
- Query response: TBD
- Overall: We should anticipate increasing demand (either manually or automatically)
##### Cost
- Metric: Infra Costs
- Objective: Our costs should grow at a rate that is sublinear relative to scale
### Dev Experience
##### Dev Experience NPS (Infra)
- Metric: Developer experience (relating to infra) (maybe NPS?)
- Objective: TBD (maybe NPS?)
## Slack channel
[#team-deployments-and-infrastructure](https://posthog.slack.com/messages/team-deployments-and-infrastructure)

36
SourceMaterial/people/team-structure/marketing.md Normal file
View File

@ -0,0 +1,36 @@
---
title: Team Marketing
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People
- Mo Shehu, Content Marketer
## Mission
Make PostHog a ubiquitous developer tool.
## Customer
Innovative technical teams, who care about:
* a unified product analytics platform
* open source
* control: hosting, pricing, source, data, privacy and security
We will expand to non-technical teams when we have achieved technical awareness saturation.
## Output metrics
* Acquisition
## Philosophy
Be kind, concise and direct.
## Slack channel
[#team-marketing](https://posthog.slack.com/messages/team-marketing)

45
SourceMaterial/people/team-structure/people.md Normal file
View File

@ -0,0 +1,45 @@
---
title: Team People
sidebar: Handbook
showTitle: true
hideAnchor: true
---
## People & Culture
- [Eltje Lange](/handbook/company/team#eltje-lange-people-and-talent)
- [Recruitment and Operations Coordinator](https://apply.workable.com/posthog/j/554EC800BE/) (currently hiring!)
## Mission
Make PostHog the best place everyone here has ever worked. Our goal is to create a world-class (remote) culture, prioritising impact, autonomy and personal development.
## Responsibilities
Our people team works across talent, people operations and culture:
- We attract, engage and hire top talent from around the world, while ensuring an outstanding candidate and hiring manager experience.
- Building a [diverse and inclusive culture](/handbook/company/diversity) is at the heart of everything we do.
- We support our team throughout the entire employee lifecycle - from making an offer, to onboarding and career development, to parental leave and eventually parting ways.
- We create light-touch initiatives and processes that allow PostHog to act fast (while complying with local legislation) and [iterate](/handbook/company/culture#iteration) continuously.
- In the people team, we live and breathe our [culture](/handbook/company/culture) and [values](/handbook/company/values), and constantly work to make PostHog an even better place to work.
## Customer
All small teams as well as current, future and past candidates.
## Output metrics
Talent:
- Hiring progress vs. plan
- Time to hire
- Percentage of hires from [under-represented groups](/handbook/company/diversity#how-diversity-helps-us)
People and culture:
- Quarterly Team engagement survey
- Turnover rate (voluntary and involuntary)
## Slack channel
[#people](https://posthog.slack.com/messages/people) - internally public, default for most people discussions
[#people_ops](https://posthog.slack.com/messages/people_ops) - internally confidential, for minority of issues, e.g. salaries, candidate offers

48
SourceMaterial/people/team-structure/team-structure.md Normal file
View File

@ -0,0 +1,48 @@
---
title: Team structure
sidebar: Handbook
showTitle: true
hideAnchor: true
---
We've organised the team into small teams that are multi-disciplinary. [You can read about why we've done it this way.](/handbook/people/team-structure/why-small-teams).
## Engineering
- **Core experience**
- [Eric Duong (Team Lead, Full Stack Engineer)](/handbook/people/team/#eric-duong-software-engineer)
- [Paolo D'Amico (Product Manager)](/handbook/people/team#paolo-damico-product-team)
- [Buddy Williams, Full Stack Engineer](/handbook/people/team/#buddy-williams-software-engineer)
- Sam Winslow, Full Stack Engineer
- [Li Yi Yu, Full Stack Engineer]((/handbook/people/team/#li-yi-yu-software-engineer))
<br />
- **[Extensibility](extensibility)**
- [Marius Andra (Team lead, Full Stack Engineer)](/handbook/company/team/#marius-andra-software-engineer)
- [Michael Matloka (Full Stack Engineer)](/handbook/company/team/#michael-matloka-software-engineer)
- [Yakko Majuri (DevRel + Full Stack Engineer)](/handbook/company/team/#yakko-majuri-technical-writer-and-developer)
<br />
- **[Infrastructure and Deployments](infrastructure)**
- [James Greenhill](/handbook/company/team/#james-greenhill-software-engineer) (Team lead, Data/Infra Engineer)
- [Karl-Aksel Puulmann](/handbook/company/team/#karl-aksel-puulmann-software-engineer) (Full Stack Engineer)
<br />
- **[Growth engineering](growth-engineering)**
- Kunal Pathak (Growth Engineer)
## [Design](design)
- Cory Watilo (Team lead, Lead Designer)
- Lottie Coxon (Graphic Designer)
## [Marketing](marketing)
- Mo Shehu (Content Marketer)
## [People & Culture](people)
- [Eltje Lange](/handbook/people/team#eltje-lange-people-and-talent) (People and Talent)

110
SourceMaterial/people/team-structure/why-small-teams.md Normal file
View File

@ -0,0 +1,110 @@
---
title: Why Small Teams
sidebar: Handbook
showTitle: true
hideAnchor: true
---
PostHog is structured for speed, autonomy and innovation.
Many traditional organizations have big, separate functions. You have a product team, an engineering team, customer support, and so on. This slows things down when you scale because there are more layers of communication and complex approval chains. This stifles innovation - you have to get your boss to talk to someone else's boss to get work done. It also means that people can't really see the impact of their work.
PostHog started off as a completely flat company with one big goal: to increase the number of successful products in the world.
As we are getting bigger, we anticipate that it will get harder for people to see the direct impact of their work, which reduces the sense of ownership.
We have therefore introduced Small Teams. These are designed to each operate like a startup.
# How it works
* The overall goal is for a Small Team to be as close to its own startup as possible, with only a handful of centralized processes
* A Small Team should never be more than six people
* A Small Team has an Accountable Person responsible for its performance - whoever is most appropriate depending on what the team is working on. This does _not_ mean the most senior person on the team.
* A Small Team must have (1) a customer (internal or external), (2) a mission and (3) metrics
* There may be certain functions where at our current stage we don't need a Small Team yet.
* Each Small Team runs its own retrospective + sprint every week. This must be done transparently.
* A Small Team has the final call in which of its features get into production, with no need for external QA/control - within our existing release schedule.
* A Small Team will, at some stage, be able to create its own pricing (too complex in immediate future to do this, however)
* Small teams should document what they build.
# Small Teams list
* Core Experience (trends, retention, funnels)
* Extensibility (plugins/APIs)
* Deployments and Infrastructure (AMI/VPC/PostHog Cloud)
# Functional teams
* People & Culture
* Marketing (includes website)
* Growth Engineering (proactive experiments / activation flow / revenue flow)
* Design
# FAQ
## Who do Small Teams report to? How does this work with management?
The Accountable Person has the final say in a given Small Team's decision making - they decide what to build / work on.
Each person's line manager is their role's functional leader (if possible). For example, engineers, no matter which Small Team they're in, will report to an engineer. It's important to note that management at PostHog is [very minimalist](management) - it's critical that managers don't set tasks for those in Small Teams.
Think of the Small Team as the company you work for, and your line manager as your coach.
## Can someone be in multiple Small Teams?
No. This defeats the purpose of ownership. We should be hiring in both places. Sometimes that'll mean we "overstaff" certain teams, but in reality there will always be further projects we can move people onto if they run out of work. It's better to do this than to be perpetually understaffed and for our product to suffer as a result.
## Who is in a Small Team?
No more than 6 people, but that's the only rule. It could be any group of people working together.
## Will this lead to inconsistent design?
Eventually, yes. Other companies have a UX team that build components for everyone to use. Since we currently use [Ant Design](https://ant.design/), we don't need this just yet.
## Can I still [step on toes](/handbook/values)?
Yes. In fact it's actively encouraged. We still expect people to have an understanding of the entire company and what various people are working on. In engineering, we still expect you to understand how the entire system works, even if you're only working on infrastructure. You can only do your job well if you understand how it fits in with other parts of the system.
You're actively encouraged to raise pull requests or propose changes to stuff that doesn't have anything to do with your small team.
## Can people change teams?
We try to keep moves infrequent and when needed. We anticipate moving people roughly every 3-9 months. We'd rather hire new people than create gaps by shifting people around.
There are two scenarios that will trigger a move:
* The Small Team may realize they no-longer need someone, or that they could really do with someone currently in another Small Team internally.
* An individual team member may wish to move in order to develop their skills or experience.
It is at the discretion of the _manager_ of that person if they can move.
## Aren't most our Small Teams way too small?
In certain cases, but not everywhere. This will clarify where people will work. In fact, it'll make sure we keep the scrappy fun side of working here as we get bigger. A team doesn't _have_ to be six people.
## How does hiring in the Small Team work?
The Small Team is responsible for creating roles for those that they need.
We have a centralized team that will then help you hire.
James and Tim will meet every hire we make - it's a standard startup failure for founders to get too removed from hiring. We are very happy to then give you complete autonomy on the work you do, as best we can.
## Does a Small Team have a budget?
Spend money when it makes sense to do so. See our general policy on spending money.
## How do you keep the product together as a company?
Marcus (Tim until Marcus starts) will be ultimately responsible for us having (i) no gaps in product (ii) eliminating duplicate work (iii) making sure all Small Teams are working on something rational. This is how we manage the product.
## How do you stop duplicate work?
Marcus (Tim until Marcus starts) has the ultimate responsibility to make sure we don't build the same thing in two different teams, or that we don't accidentally compete with each other internally.
By keeping communication asynchronous and transparent, this is made much easier to do than is typical at other organizations.
## Can a Small Team "own" another Small Team?
Not for now, no. Perhaps when we're much larger this is something to think about.

710
SourceMaterial/people/team.md Normal file
View File

@ -0,0 +1,710 @@
---
title: Team
sidebar: Handbook
showTitle: true
hideAnchor: true
---
<!--- Intro Info -->
<div class="team-row intro" markdown="1">
<div class="team-left-text" markdown="1">
<h3> We are proud to be misfits. Why? </h3>
Building an unusually great company starts with an unusual team.
We don't care if you haven't finished (or attended) school, if you were super important at a FAANG company or if you ran a startup that crashed and burned.
What we do care about is your ability to learn, iterate, and ship.
That's why we have people in Belgium, the East and West coast of the US, England, Estonia, South Africa, the Democratic Republic of Congo, among other places. Learn more about [diversity](diversity) at PostHog.
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Remote work globe animation](../../images/team/team-global.gif)
<br /><small class="centered">Our team of 22 is distributed across 10 countries. </small>
</div>
</div>
<!--- Core Team Section -->
<div class="team-title" markdown="1">
## Core Team
</div>
<!--- James Hawkins Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### James Hawkins, Co-Founder & CEO
<div class="team-left-bio" markdown="1">
I spent the first 10 years of my career trying to be a professional cyclist. I used to do web development part time to make some money on the side. I wasn't particularly good at either.
I live in Cambridge with Fran (wife), Ruby (daughter), and Wally (cat). Since you're probably wondering, the cat's name is a reference to [WALL-E](https://en.wikipedia.org/wiki/WALL-E) - work for us to find out why.
After a growing sense of my own mortality combined with a bunch of large crashes put me off continuing with my cycling career, I bootstrapped an online marketing company to several million dollars a year.
I wanted more experience of working in a VC backed startup, so I could work on something really ambitious. I moved to [Arachnys](https://arachnys.com), and somehow wound up as a their VP of Sales for a little over 4 years, where I used to manage a team selling very large enterprise software deals. We learned how to take our sales from an average of \$5K/year to over \$1M/year.
I started working with Tim on a few ideas that didn't work out in August 2019. We built PostHog during the YCombinator W20 batch, and launched in February. You can work out what I've been up to since by stalking me online.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![James Hawkins portrait](../../images/team/JamesH.png)
</div>
</div>
<!--- Tim Glaser Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Tim Glaser, Co-Founder & CTO
<div class="team-left-bio" markdown="1">
I've been coding since I've been 11, which isn't as long ago as I'd like it to be. Someone first paid me to write code when I was 13 (though I'm sure they regretted it) and [someone else](https://en.wikipedia.org/wiki/Cloud9_IDE) gainfully employed me when I was 16.
Originally from the Netherlands, though I quickly moved to London (I do not generally enjoy nice weather) where I joined Arachnys and shortly afterwards met James Hawkins. I went from being a software engineer, to product manager, to "leading" an R&D team, which consisted of just me.
After four years I thought it was time to go do something else and had lined up a new job. Roughly 37 seconds after it was announced James wanted to "grab a beer." While plying me with alcohol, he convinced me to give up this fancy new job and instead start a startup with him.
In my 'spare' time, I fall down snowy mountains, wrestle in the mud over an egg-shaped ball and watch a lot of Bondi beach in order to perfect my Australian accent.
[See my README for tips on how to work with me](/handbook/company/team/tim-glaser)
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Tim Glaser portrait](../../images/team/Tim.png)
</div>
</div>
<!--- Marius Andra Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Marius Andra, Software Engineer
<div class="team-left-bio" markdown="1">
I first got into programming in 1994 when I wanted to make my own computer games... and asked my father for help. He sat me behind a Turbo Basic interpreter, wrote `PRINT "Marius on tubli poiss"` and then left me there. I was 8 years old.
Luckily we had a [Yamaha YIS-805/128R2](https://www.msx.org/wiki/Yamaha_YIS-805-128R2) lying around... with floppy disks full of random .BAS files. I was hooked. Cue to the beautiful loops of CLS, PRINT and GOTO statements that ensued. I even made some games where you could move two dinosaurs who got points when they kissed each other. It was glorious.
I also got into "web development" in 1997 after seeing Netscape at my mother's university. They even provided me with a generous 10MB of space to host my own [beautiful website](https://web.archive.org/web/19980128032518/http://rasi.lr.ttu.ee/~marius/), complete with animated gifs, a Mortal Kombat fanpage and a strong recommendation to use 800x600 with HiColor!
This was followed by years of writing games in C++ and then [writing tutorials](https://web.archive.org/web/20110626030555/http://cone3d.gamedev.net/) about them, coding websites in Perl, PHP, Java and Ruby... and "losing" a decade as the CTO of two failed startups.
On the side I built an [open source database analytics platform](https://github.com/mariusandra/insights)... and when that [got on Hacker News](https://news.ycombinator.com/item?id=22347516), James reached out... and the rest is history.
These days I live in Belgium and code [state management libraries](https://kea.js.org/) in JavaScript for fun.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Marius Andra portrait](../../images/team/Marius.png)
</div>
</div>
<!--- Eric Duong Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Eric Duong, Software Engineer
<div class="team-left-bio" markdown="1">
I recently graduated and while in college I helped cofound a social dining platform. I spent two years trying to get strangers to cook and dine with each other. In reality, it turned into a 2 year stint of teach yourself as much mobile development as you can while simultaneously trying to build a usable platform. My cofounders and I had our fair share of contemplating dropping out of school and becoming a unicorn in 5 years—it didn't work out.
Somewhere along the way I fell down the bitcoin rabbit hole and after realizing day trading crypto wasn't a feasible nor fulfilling long term goal, I remained fascinated by digital currency. This led me to briefly work with a company building a digital cash transfer system for developing economies.
I currently work as a generalist around most of Posthog's stack building many of the user-facing features but occasionally pick up backend tasks.
To end with an obligatory "I dO MoRE ThAN COdE" detail: I plan to take advantage of Posthog's all remote policy to travel and hike as many major mountain treks around the world as possible. Ambitions subject to change as always though.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Eric Duong portrait](../../images/team/Eric.png)
</div>
</div>
<!--- James Greenhill Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### James Greenhill, Software Engineer
<div class="team-left-bio" markdown="1">
When I was a kid the first thing I remember wanting to be was a pilot, so naturally here I am knee deep in code and data!
Growing up was slightly different in Florida. Things that are normal there are growing up in the water and spending almost all of your free time in it. In the Gulf of Mexico for me. We’d go swimming, scuba diving, or fishing in that warm body of water almost every weekend.
Nowadays I’m spending my free time on a bike finding some new trail up in the northern bits of the Bay Area that I call home now. If not on a bike you’ll find my friends and I on a hike either around here or over in Tahoe or some National Forest east of here. Lately I’m trying to get back into flying. I’ve got about 80 hours of flight in the book, but still don’t have my ticket! It’s time to change that. In the winter time you can find me ruining skis on some mountain.
In my professional life I’ve generally managed mopping up the 1’s and 0’s. I’ve led data at an [upstart music streaming company](https://en.wikipedia.org/wiki/Grooveshark), and dove way too deep into the depths of the comment section leading data at [Disqus](https://en.wikipedia.org/wiki/Disqus). Kept an eye on a fleet of [Autonomous Ubers](https://en.wikipedia.org/wiki/Uber#Self-driving_car_research). Most recently I combined my interest in bikes with data leading data engineering at [Jump](https://en.wikipedia.org/wiki/Jump_(transportation_company)), still the best micromobility company out there.
When I’m not out and about in nature you can find me at home with my cat Tesla and Taco our goofball of a Lab Corgi mix.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![James Greenhill portrait](../../images/team/JamesG.png)
</div>
</div>
<!--- Michael Matloka Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Michael Matloka, Software Engineer
<div class="team-left-bio" markdown="1">
Got into software by tinkering with bada OS – if anyone even remembers that! – and just never stopped (though I did move to Android soon and later became an iOS fan).
Before graduating from high school here in Poland – and having some open-source projects under my belt, including [a Discord bot with thousands of users that became my gateway to Python](https://github.com/Twixes/somsiad) – I decided that the most interesting way to grow and meet some great people along the way will be to work on a quality product commercially.
Happy to report that I ended up joining PostHog, where open-source software, a quality product and great people all mix freely!
In free time, I dabble in [outer space](https://www.kerbalspaceprogram.com/), [math](https://codepen.io/Twixes/pen/Zwxxdv), [design](https://www.lingscars.com/), [photography](https://unsplash.com/@twixes) and [cinema](https://www.nowehoryzonty.pl/index.do?lang=en). Decidedly a fan of precipitation and overcast weather, I have a secret plan to move to the Nordics or the UK one day.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Michael Matloka portrait](../../images/team/Michael.png)
</div>
</div>
<!--- Paolo D'Amico Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Paolo D'Amico, Product Team
<div class="team-left-bio" markdown="1">
I started coding when I was about 9 years old, starting with the very basic LEGO RCX & Turbo Pascal language. I always enjoyed learning new languages, frameworks or technologies on my own, especially with a good book. Funnily enough, I decided not to study computer science.
Before joining PostHog, I lead a product team at Grow Mobility, the largest micro-mobility company in Latin America at the time. Before that, I co-founded Flinto, a Y Combinator startup targeting financial inclusion in developing economies. I enjoy reading while walking around strange places, and have tripped more than once.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Paolo D'Amico portrait](../../images/team/Paolo.png)
</div>
</div>
<!--- Lottie Coxon Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Lottie Coxon, Graphic Designer
<div class="team-left-bio" markdown="1">
I am from the UK - so by default I love the pub, marmite and tea (but not all at once, that would be a sin).
I spent my youth trying to master fine art, after my teacher said I was awful and that I should try something else.
In my stubbornness I decided to prove her wrong, and here I am - a designer.
I was quite a weird child. I once ran a race with locked legs (Forest Gump style) because I had a dream the night before that I won by doing so. For those who are wondering, no I did not win. But I would rather be the weird child than the boring one.
I took Graphic Design at university and graduated this summer and instead of a summer of fun, I was faced with a crashing economy, a pandemic and and a collapsing job market. But thankfully, after putting my portfolio on twitter, I was contacted by PostHog a mere 24 hours later.
I am now their Graphic Designer, and spend my days composing layouts for the website, designing the product’s aesthetic, and most importantly drawing hedgehogs with sunglasses on.
On a side note I have decided to move to Senegal (Africa) to be with my boyfriend George. It’s a bold decision really as I cannot speak French, but I will (try) learn.
*French accent* C’est la Vie
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Lottie Coxon portrait](../../images/team/Lottie.png)
</div>
</div>
<!--- Yakko Majuri Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Yakko Majuri, Developer Experience
<div class="team-left-bio" markdown="1">
Often on the move, sometimes by choice, and sometimes by chance, I'm a Brazilian-Finn who has lived in 5 countries across 4 continents.
Passionate about teaching (but far from an academic), I taught an official high school course before graduating high school, became a Visiting Scholar before joining university, and presented my first paper at the European Central Bank during my freshman year (anonymous submission - they thought I had a PhD).
Prior to PostHog, I was a technical consultant for clients which included a Fortune 500 company. A fan of building useful things, I'm a self-taught developer who has worked on an a wide variety of projects, from a travel app, to multiple websites and browser extensions, and even some white-hat hacking. For the past three years, I developed a nice habit of writing about my projects, which led me to a [Medium page](https://yakkomajuri.medium.com) that surpassed 250k views in just 30 days.
When I'm not working, I have been found hitchiking in foreign lands, taking pictures of political demonstrations, and trying to learn Korean after one too many beers. I'll pick playing cards with my grandmother over the club on any Friday night, and my favorite place to spend the Saturday is on top of a mountain.
Oh, and I'm also part of the select group of software developers who have won a dunk contest in their lifetime. If that means anything.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Yakko Majuri portrait](../../images/team/Yakko.png)
</div>
</div>
<!--- Karl Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Karl-Aksel Puulmann, Software Engineer
<div class="team-left-bio" markdown="1">
I spent my childhood in a tiny village in the middle of nowhere (Väätsa, Estonia), playing football, working in construction and driving tractors. I used it buy my own computer, but did not do much more than listen to music, play games and watch anime with it.
Things changed in highschool, where we had a programming class. I started creating my own games, participating in competitions (even going to International Olympiad once) and generally learning and reverse engineering anything I could get my hands on.
Some time has passed since then - I have since been a student, teacher, first engineer at a guitar learning startup, worked in fintech, helped scale a database cluster holding 1PB of data at an analytics company, learned and helped automate manufacturing of stickers, been a CTO in agritech startup and now learning how this open source business works.
In personal life, you can find me in the wilderness looking for geocaches or hiking, buying too many books and recently trying to figure out this parenting thing.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Karl portrait](../../images/team/Karl.png)
</div>
</div>
<!--- Charles Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Charles Cook, Business Operations
<div class="team-left-bio" markdown="1">
Born and raised in the United Arab Emirates, I'm half British, half Lebanese, and lived in a variety of places growing up across the Middle East, Africa and Europe. Now based in London, I live with my wife Steph and son Remy, who was serendipitously born right at the beginning of lockdown here in the UK.
I take care of all things business ops-related at Posthog, across finance, people, legal and basically anything else that doesn't involve actually building the product! Posthog is now my 3rd startup - I was previously COO at [Vitl](https://vitl.com), (personalised nutrition), and before that I was Director of Product at [ROLI](https://roli.com) (electronic music products).
I'm a big fan of terrible jokes, beautifully crafted sandwiches and looking at [designer houses](https://www.themodernhouse.com/) I will never live in. I like to occasionally torment my son with my piano playing and spend more time than is probably reasonable making lists of things, à la [High Fidelity](https://en.wikipedia.org/wiki/High_Fidelity_(film)).
[See my README](/handbook/company/team/charles-cook) on tips for how to work with me.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Charles Cook portrait](../../images/team/Charles.png)
</div>
</div>
<!--- Eltje Lange Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Eltje Lange, People and Talent
<div class="team-left-bio" markdown="1">
Hi, I'm Eltje (_pronounced Elt-ie_), originally from Northern Germany, I moved to the UK in 2017 and I am now based in East London.
Just like James, I used to be a professional cyclist until I realised you can’t make a living as a female cyclist. After a short identity crisis, I started university with the goal to become a management consultant. That never happened, I luckily realised my skills and personality are much better suited in a people (I guess non-startup people call it HR) role.
At PostHog I look after our People and Talent function and my goal is make PostHog THE best company to work for. Previously I worked in very a similar role at a startup called [Farewill](https://farewill.com), who offer services around death (yes, you read right). Prior to that, I worked for a couple of companies later on the scaling journey, like [TransferWise](https://transferwise.com/) and [Xing](https://xing.com).
Outside of work, I am working on my [Masterchef](https://en.wikipedia.org/wiki/MasterChef) skills and you can usually find me outdoors - either on my bike or during a long walk.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Eltje portrait](../../images/team/Eltje.png)
</div>
</div>
<!--- Cory Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Cory Watilo, Lead Designer
<div class="team-left-bio" markdown="1">
As one of the few PostHoggers who never attempted to enter the world of professional cycling, I instead spend much of my free time exploring new coffee shops or wine bars, generally sipping a cold brew iced coffee in the morning and a nice rosé once it hits 5:00 somewhere.
Due to the fact that I generally require both warmth and sunshine to function at any normal capacity, my wife and I bought an RV a couple years ago and hit the road fulltime, our sole requirement being that wherever we travel _must_ have a [UV index](https://www.google.com/search?sxsrf=ALeKk010aYaVBhFgzWm_AysLPp_ytPyFRg:1610376210393&q=What+is+the+best+UV+index+to+tan%3F&sa=X&ved=2ahUKEwjMk-bvjpTuAhXBp1kKHXVtDIwQzmd6BAgTEAU&biw=1080&bih=946&dpr=2) of 6 or greater. (At 45 feet long, our RV is larger by square footage than many apartments in New York or San Francisco!)
Our party of 2 became a party of 3 last year. 🎉 Now that I am officially a dad, I am now legally entitled to make dad jokes. So in light of the rich cycling history of our company, I present the following: "Why couldn't the bicycle stand up by itself? It was two tired."
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Cory portrait](../../images/team/Cory.png)
</div>
</div>
<!--- Kunal Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Kunal Pathak, Growth Engineer
<div class="team-left-bio" markdown="1">
Hi! My name is Kunal. I'm a Bay Area native and a bit of a startup vet.
I love helping teams discover new ways to apply data, product, and engineering to drive business outcomes.
Most recently, I led the growth team at Amplitude and at an education technology startup prior to that.
When I'm not working on growth, you'll find me studying the Mamba Mentality, re-learning guitar chords, or making some ravioli (a lasagna if it's going poorly).
In terms of cycling– a friend once convinced me to go on a bike ride from San Francisco to Mill Valley. We took the ferry home.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Kunal portrait](../../images/team/Kunal.png)
</div>
</div>
<!--- Buddy Williams Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Buddy Williams, Software Engineer
<div class="team-left-bio" markdown="1">
Howdy! I live in Atlanta, Georgia with my amazing partner of five years. I have
two truly wonderful kids, boy-9 and girl-12 who both level up in July. Oh,
geez, I'll have a teenager! I'm a hobbyist: unicycles, juggling,
acroyoga, hiking, cooking, rollerblading, skiing, climbing, and
lifting. My partner and the kids especially love hiking, playing video games,
and performing amazing acroyoga feats for folks in the park.
​
I got started in programming at twelve years old. My grandfather was a
retired FFA engineer with access to old decommissioned hardware. He'd
bring it home for me to play with. My first computer was a TI-99/4A
where you recorded your programs on cassette tapes! I fell in love with
programming because I enjoyed both creative and reason based projects.
From drawing and crafts to math, science, and philosophy. Programming
gave me a big canvas for imaginary worlds, a place for self-expression
I hadn't found anywhere else.
​
I was sixteen when I landed my first programming gig as a frontend engineer
for an agency. Afterwards, I helped co-found a radiology software company who
ensured patients received follow-up care. These patients were slipping
through the cracks, leading to fatal results not to mention expensive legal
settlements. From there I worked in big tech where I learned corporate politics
were no fun. After a few years of exploring I went back to my roots and founded
a tech consultancy. During this time, I had an idea for a revolutionary platform
for designers. So, I built a no-code app platform that allowed creatives to
design applications rather than code them. It was a wild and exhausting ride!
After a few years of catching my breath, I joined up with PostHog to
pursue their mission of making more successful products in the world!
I'm looking forward to all we will accomplish together.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Buddy Williams portrait](../../images/team/Buddy.png)
</div>
</div>
<!--- Li Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Li Yi Yu, Full Stack Engineer
<div class="team-left-bio" markdown="1">
HI! I'm Li from NYC. I fell in love with coding towards the end of college, jumped into a programming bootcamp right after, worked at a healthtech company for two years, and here I am today!
Some things I enjoy: karaoke, Switch/PC/board games, a good movie or series, struggling on hikes because I've spent too much time indoors, and exploring the NYC food scene.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Li portrait](../../images/team/Li.png)
</div>
</div>
<!--- Sam Bio -->
<div class="team-row" markdown="1">
<div class="team-left-text" markdown="1">
### Sam Winslow, Full Stack Engineer
<div class="team-left-bio" markdown="1">
Hi! I’m Sam. I recently graduated from NYU, where I studied the interaction of media, technology & society. My earliest experiences with programming were building games on a TI-83 calculator and teaching myself BASIC at age 10. The first application I made was an MS Paint clone. I have worked in design, marketing, and software engineering since then.
In my free time, I love building hardware projects, reading about logic & philosophy, cycling around NYC, and taking care of my puppy, Louie.
One of the projects I'm most proud of was a social network for sharing music reviews. We had modest success among college students, and the biggest lesson I learned was that I wanted to spend more time coding new features and less time fighting the analytics tools in order to figure out what to build.
I am always at the beginning of my journey to learn.
</div>
</div>
<div class="team-center-space"></div>
<div class="team-right-image" markdown="1">
![Sam portrait](../../images/team/Sam.png)
</div>
</div>
<!--- Contributors Section -->
## Contributors
<div class="contributor-faces">
<a href="https://github.com/bhavish-agarwal"><img src="https://avatars.githubusercontent.com/u/14195048?v=4" title="bhavish-agarwal" width="50" height="50"></a>
<a href="https://github.com/Tannergoods"><img src="https://avatars.githubusercontent.com/u/60791437?v=f" title="Tannergoods" width="50" height="50"></a>
<a href="https://github.com/ungless"><img src="https://avatars.githubusercontent.com/u/8397061?v=4" title="ungless" width="50" height="50"></a>
<a href="https://github.com/gzog"><img src="https://avatars.githubusercontent.com/u/1487006?v=4" title="gzog" width="50" height="50"></a>
<a href="https://github.com/Tmunayyer"><img src="https://avatars.githubusercontent.com/u/29887304?v=4" title="Tmunayyer" width="50" height="50"></a>
<a href="https://github.com/adamb70"><img src="https://avatars.githubusercontent.com/u/11885987?v=4" title="adamb70" width="50" height="50"></a>
<a href="https://github.com/samcaspus"><img src="https://avatars.githubusercontent.com/u/19220113?v=4" title="samcaspus" width="50" height="50"></a>
<a href="https://github.com/SanketDG"><img src="https://avatars.githubusercontent.com/u/8980971?v=4" title="SanketDG" width="50" height="50"></a>
<a href="https://github.com/dependabot[bot]"><img src="https://avatars.githubusercontent.com/in/29110?v=4" title="dependabot[bot]" width="50" height="50"></a>
<a href="https://github.com/J0"><img src="https://avatars.githubusercontent.com/u/8011761?v=4" title="J0" width="50" height="50"></a>
<a href="https://github.com/14MR"><img src="https://avatars.githubusercontent.com/u/5824170?v=4" title="14MR" width="50" height="50"></a>
<a href="https://github.com/03difoha"><img src="https://avatars.githubusercontent.com/u/8876615?v=4" title="03difoha" width="50" height="50"></a>
<a href="https://github.com/ahtik"><img src="https://avatars.githubusercontent.com/u/140952?v=4" title="ahtik" width="50" height="50"></a>
<a href="https://github.com/Algogator"><img src="https://avatars.githubusercontent.com/u/1433469?v=4" title="Algogator" width="50" height="50"></a>
<a href="https://github.com/GalDayan"><img src="https://avatars.githubusercontent.com/u/24251369?v=4" title="GalDayan" width="50" height="50"></a>
<a href="https://github.com/Kacppian"><img src="https://avatars.githubusercontent.com/u/14990078?v=4" title="Kacppian" width="50" height="50"></a>
<a href="https://github.com/FUSAKLA"><img src="https://avatars.githubusercontent.com/u/6112562?v=4" title="FUSAKLA" width="50" height="50"></a>
<a href="https://github.com/iMerica"><img src="https://avatars.githubusercontent.com/u/487897?v=4" title="iMerica" width="50" height="50"></a>
<a href="https://github.com/pedroapfilho"><img src="https://avatars.githubusercontent.com/u/13142568?v=4" title="pedroapfilho" width="50" height="50"></a>
<a href="https://github.com/eLRuLL"><img src="https://avatars.githubusercontent.com/u/1459486?v=4" title="eLRuLL" width="50" height="50"></a>
<a href="https://github.com/stevenphaedonos"><img src="https://avatars.githubusercontent.com/u/12955616?v=4" title="stevenphaedonos" width="50" height="50"></a>
<a href="https://github.com/tapico-weyert"><img src="https://avatars.githubusercontent.com/u/70971917?v=4" title="tapico-weyert" width="50" height="50"></a>
<a href="https://github.com/adamschoenemann"><img src="https://avatars.githubusercontent.com/u/2095226?v=4" title="adamschoenemann" width="50" height="50"></a>
<a href="https://github.com/AlexandreBonaventure"><img src="https://avatars.githubusercontent.com/u/4596409?v=4" title="AlexandreBonaventure" width="50" height="50"></a>
<a href="https://github.com/dan-dr"><img src="https://avatars.githubusercontent.com/u/6669808?v=4" title="dan-dr" width="50" height="50"></a>
<a href="https://github.com/dts"><img src="https://avatars.githubusercontent.com/u/273856?v=4" title="dts" width="50" height="50"></a>
<a href="https://github.com/jamiehaywood"><img src="https://avatars.githubusercontent.com/u/26779712?v=4" title="jamiehaywood" width="50" height="50"></a>
<a href="https://github.com/dependabot-preview[bot]"><img src="https://avatars.githubusercontent.com/in/2141?v=4" title="dependabot-preview[bot]" width="50" height="50"></a>
<a href="https://github.com/rushabhnagda11"><img src="https://avatars.githubusercontent.com/u/3235568?v=4" title="rushabhnagda11" width="50" height="50"></a>
<a href="https://github.com/weyert"><img src="https://avatars.githubusercontent.com/u/7049?v=4" title="weyert" width="50" height="50"></a>
<a href="https://github.com/casio"><img src="https://avatars.githubusercontent.com/u/29784?v=4" title="casio" width="50" height="50"></a>
<a href="https://github.com/Hungsiro506"><img src="https://avatars.githubusercontent.com/u/10346923?v=4" title="Hungsiro506" width="50" height="50"></a>
<a href="https://github.com/bitbreakr"><img src="https://avatars.githubusercontent.com/u/3123986?v=4" title="bitbreakr" width="50" height="50"></a>
<a href="https://github.com/edmorley"><img src="https://avatars.githubusercontent.com/u/501702?v=4" title="edmorley" width="50" height="50"></a>
<a href="https://github.com/wundo"><img src="https://avatars.githubusercontent.com/u/113942?v=4" title="wundo" width="50" height="50"></a>
<a href="https://github.com/andreipopovici"><img src="https://avatars.githubusercontent.com/u/1143417?v=4" title="andreipopovici" width="50" height="50"></a>
<a href="https://github.com/sjmadsen"><img src="https://avatars.githubusercontent.com/u/57522?v=4" title="sjmadsen" width="50" height="50"></a>
<a href="https://github.com/athreyaanand"><img src="https://avatars.githubusercontent.com/u/31478366?v=4" title="athreyaanand" width="50" height="50"></a>
<a href="https://github.com/berntgl"><img src="https://avatars.githubusercontent.com/u/55957336?v=4" title="berntgl" width="50" height="50"></a>
<a href="https://github.com/fakela"><img src="https://avatars.githubusercontent.com/u/39309699?v=4" title="fakela" width="50" height="50"></a>
<a href="https://github.com/corywatilo"><img src="https://avatars.githubusercontent.com/u/154479?v=4" title="corywatilo" width="50" height="50"></a>
<a href="https://github.com/brianetaveras"><img src="https://avatars.githubusercontent.com/u/52111440?v=4" title="brianetaveras" width="50" height="50"></a>
<a href="https://github.com/callumgare"><img src="https://avatars.githubusercontent.com/u/346340?v=4" title="callumgare" width="50" height="50"></a>
<a href="https://github.com/cirdes"><img src="https://avatars.githubusercontent.com/u/727781?v=4" title="cirdes" width="50" height="50"></a>
<a href="https://github.com/DannyBen"><img src="https://avatars.githubusercontent.com/u/2405099?v=4" title="DannyBen" width="50" height="50"></a>
<a href="https://github.com/embishh"><img src="https://avatars.githubusercontent.com/u/26777378?v=4" title="embishh" width="50" height="50"></a>
<a href="https://github.com/Epskampie"><img src="https://avatars.githubusercontent.com/u/1692043?v=4" title="Epskampie" width="50" height="50"></a>
<a href="https://github.com/hgezim"><img src="https://avatars.githubusercontent.com/u/124675?v=4" title="hgezim" width="50" height="50"></a>
<a href="https://github.com/jakemalachowski"><img src="https://avatars.githubusercontent.com/u/5766239?v=4" title="jakemalachowski" width="50" height="50"></a>
<a href="https://github.com/itsjwala"><img src="https://avatars.githubusercontent.com/u/24763310?v=4" title="itsjwala" width="50" height="50"></a>
<a href="https://github.com/jocke45"><img src="https://avatars.githubusercontent.com/u/1652395?v=4" title="jocke45" width="50" height="50"></a>
<a href="https://github.com/sj26"><img src="https://avatars.githubusercontent.com/u/14028?v=4" title="sj26" width="50" height="50"></a>
<a href="https://github.com/paulanunda"><img src="https://avatars.githubusercontent.com/u/155981?v=4" title="paulanunda" width="50" height="50"></a>
<a href="https://github.com/arosales"><img src="https://avatars.githubusercontent.com/u/1707853?v=4" title="arosales" width="50" height="50"></a>
<a href="https://github.com/ChandanSagar"><img src="https://avatars.githubusercontent.com/u/27363164?v=4" title="ChandanSagar" width="50" height="50"></a>
<a href="https://github.com/wadenick"><img src="https://avatars.githubusercontent.com/u/9014043?v=4" title="wadenick" width="50" height="50"></a>
<a href="https://github.com/jgannondo"><img src="https://avatars.githubusercontent.com/u/28159071?v=4" title="jgannondo" width="50" height="50"></a>
<a href="https://github.com/keladhruv"><img src="https://avatars.githubusercontent.com/u/30433468?v=4" title="keladhruv" width="50" height="50"></a>
<a href="https://github.com/grellyd"><img src="https://avatars.githubusercontent.com/u/7812612?v=4" title="grellyd" width="50" height="50"></a>
<a href="https://github.com/rberrelleza"><img src="https://avatars.githubusercontent.com/u/475313?v=4" title="rberrelleza" width="50" height="50"></a>
<a href="https://github.com/annanay25"><img src="https://avatars.githubusercontent.com/u/10982987?v=4" title="annanay25" width="50" height="50"></a>
<a href="https://github.com/cohix"><img src="https://avatars.githubusercontent.com/u/5942370?v=4" title="cohix" width="50" height="50"></a>
<a href="https://github.com/gouthamve"><img src="https://avatars.githubusercontent.com/u/7354143?v=4" title="gouthamve" width="50" height="50"></a>
<a href="https://github.com/alexellis"><img src="https://avatars.githubusercontent.com/u/6358735?v=4" title="alexellis" width="50" height="50"></a>
<a href="https://github.com/prologic"><img src="https://avatars.githubusercontent.com/u/1290234?v=4" title="prologic" width="50" height="50"></a>
<a href="https://github.com/jgustie"><img src="https://avatars.githubusercontent.com/u/883981?v=4" title="jgustie" width="50" height="50"></a>
<a href="https://github.com/kubemq"><img src="https://avatars.githubusercontent.com/u/45835100?v=4" title="kubemq" width="50" height="50"></a>
<a href="https://github.com/vania-pooh"><img src="https://avatars.githubusercontent.com/u/829320?v=4" title="vania-pooh" width="50" height="50"></a>
<a href="https://github.com/irespaldiza"><img src="https://avatars.githubusercontent.com/u/11633327?v=4" title="irespaldiza" width="50" height="50"></a>
<a href="https://github.com/croomes"><img src="https://avatars.githubusercontent.com/u/211994?v=4" title="croomes" width="50" height="50"></a>
<a href="https://github.com/snormore"><img src="https://avatars.githubusercontent.com/u/182290?v=4" title="snormore" width="50" height="50"></a>
<a href="https://github.com/faik"><img src="https://avatars.githubusercontent.com/u/43129?v=4" title="faik" width="50" height="50"></a>
<a href="https://github.com/aandryashin"><img src="https://avatars.githubusercontent.com/u/1412461?v=4" title="aandryashin" width="50" height="50"></a>
<a href="https://github.com/andrewsomething"><img src="https://avatars.githubusercontent.com/u/46943?v=4" title="andrewsomething" width="50" height="50"></a>
<a href="https://github.com/Ferroin"><img src="https://avatars.githubusercontent.com/u/905151?v=4" title="Ferroin" width="50" height="50"></a>
<a href="https://github.com/cpanato"><img src="https://avatars.githubusercontent.com/u/4115580?v=4" title="cpanato" width="50" height="50"></a>
<a href="https://github.com/cakrit"><img src="https://avatars.githubusercontent.com/u/43294513?v=4" title="cakrit" width="50" height="50"></a>
<a href="https://github.com/dkhenry"><img src="https://avatars.githubusercontent.com/u/489643?v=4" title="dkhenry" width="50" height="50"></a>
<a href="https://github.com/oxplot"><img src="https://avatars.githubusercontent.com/u/483682?v=4" title="oxplot" width="50" height="50"></a>
<a href="https://github.com/marc-barry"><img src="https://avatars.githubusercontent.com/u/4965634?v=4" title="marc-barry" width="50" height="50"></a>
<a href="https://github.com/moabu"><img src="https://avatars.githubusercontent.com/u/47318409?v=4" title="moabu" width="50" height="50"></a>
<a href="https://github.com/nawazdhandala"><img src="https://avatars.githubusercontent.com/u/2697338?v=4" title="nawazdhandala" width="50" height="50"></a>
<a href="https://github.com/dar-mehta"><img src="https://avatars.githubusercontent.com/u/10489943?v=4" title="dar-mehta" width="50" height="50"></a>
<a href="https://github.com/gmmorris"><img src="https://avatars.githubusercontent.com/u/386208?v=4" title="gmmorris" width="50" height="50"></a>
<a href="https://github.com/bitdeli-chef"><img src="https://avatars.githubusercontent.com/u/3092978?v=4" title="bitdeli-chef" width="50" height="50"></a>
<a href="https://github.com/nsidartha"><img src="https://avatars.githubusercontent.com/u/26918226?v=4" title="nsidartha" width="50" height="50"></a>
</div>

55
SourceMaterial/people/time-off.md Normal file
View File

@ -0,0 +1,55 @@
---
title: Time off
sidebar: Handbook
showTitle: true
---
PostHog encourages its team to take time off to recharge.
We have a flexible time off policy. Sometimes you need an extra day or two.
We believe people need 20 days off a year plus a sprinkling of national holidays to have meaningful time with their families, to explore or just to relax.
PostHog therefore offer unlimited time off, but with an expectation that you take _at least 25 days off a year_, inclusive of national holidays.
This is to make sure that people can take time off flexibly, whilst not feeling guilty about taking time off.
The reason for this policy is that it's critical for PostHog that we hire people we can trust to be responsible with their time off - enough that they can recharge, but not so much that it means we don't get any work done.
## Permissionless Time Off
You do not need to "clear" time off with your manager.
We care about your results, not how long you work. Whilst no approval is needed, it shouldn't be at the expense of business getting done. For example, having the entire technical team off means we can't be responsive to community issues. Please coordinate with your team.
When you pick a date(s) to have off, please enter it into [CharlieHR](https://posthog.charliehr.com/) and it will be automatically approved and added to the team time off calendar. Remember to set an out of office message on your email.
The same rules as above apply regardless of the vacation length.
You can add the team time off calendar to Google Calendar by following [these instructions](https://intercom.help/charliehr/en/articles/839648-importing-your-time-off-calendar-to-google-calendar) on CharlieHR as well. CharlieHR only refreshes the calendar twice a day, so any changes you make won't be reflected immediately.
## When You Should Have Time Off
### You are sick
If you are sick, you don't need to work and you will be paid. This is assuming you need a day or two off, then just take them.
Please let your manager know if you need to take off due to illness as soon as you are able to.
For extended periods of illness, please speak to us so we can work out a plan. In some countries, we may be required to request a doctor's note from you.
### Jury Duty / Bereavements / Voting / Child Admin Disasters
There are lots of situations where life needs to come first. Please let it - just be communicative with us and fit your work around it as you need.
## Parental Leave
Parental leave is exceptional as it needs to be significantly longer than a typical vacation. Anyone at PostHog, regardless of gender, is able to take parental leave, and regardless of the way you've become a parent - childbirth, adoption or foster care.
If you have been at PostHog for over 1 year, you can take up to 12 weeks off on full pay. You can take a further 4 weeks unpaid leave if you need more time. After this, if you need to stagger your return to work, you can come back at 50% capacity on 50% pay afterwards. If you live in a country where a statutory parental leave benefit is available, you will be required to claim statutory parental leave pay (if you are eligible) and PostHog will supplement any gaps.
If you have been at PostHog for under 1 year, we will pay you according to your local jurisdiction's legal requirements.
Please communicate parental leave to your manager as soon as you feel comfortable doing so, and in any case at least 2 months before it will begin.
We are aware that there are local laws around time off for new parents in every country, and that these may vary. Wherever there is a discrepancy between local regulations and PostHog policy, local laws will override PostHog.

25
SourceMaterial/people/training.md Normal file
View File

@ -0,0 +1,25 @@
---
title: Training
sidebar: Handbook
showTitle: true
---
The better you are at your job, the better PostHog is overall!
## Books
*Everyone* at PostHog is eligible to buy books to help you in your job.
The reason we think books can be more helpful than just Googling stuff, is that the level of quality has to be higher for them to get published.
You may buy a couple of books a month without asking for permission. As a general rule, spending up to \$40/month on books is fine and requires no extra permission.
Books do not have to be tied directly to your area, and they only need be loosely relevant to your work. For example, biographies of leaders can help a manager to learn, and can in fact be more valuable than a tactical book on management. Likewise, if you're an engineer, a book on design can also be particularly valuable for you to read.
## Training budget
We have an annual training budget for every team member, regardless of seniority. The budget can be used for relevant courses, training, formal qualifications, or attending conferences. You do not need approval to spend your budget, but you might want to speak to your manager first, in case they have some useful feedback or pointers to a better idea.
The training budget is \$1000 per calendar year, but this _isn't_ a hard limit - if you want to spend in excess of this, have a chat with your manager. Where the costs are higher than \$1000, please give Charles a heads-up, so he can increase your card limit.
If possible, please share your learnings with the team afterwards!

45
SourceMaterial/strategy/business-model.md Normal file
View File

@ -0,0 +1,45 @@
---
title: Business Model
sidebar: Handbook
showTitle: true
---
<br />
PostHog is a for profit company that balances the need to improve the open source code of PostHog with the need to add source-available features in order to generate income. We will build an open core business model.
## Why would you work on the Community Edition?
A concern could be that given our business model, we'd only work on paid features.
The reality is that paid features can increase our revenue, thus our ability to grow and hire more developers, who we will use on both versions of the product. When we work on the Community Edition, it increases the community size, which means we end up with more features, and thus a better product. This means we get yet more community growth and it also helps with revenue growth since the source-available product will also improve.
At the moment, 100% of our focus is on the Community Edition of the software.
## Promises
1. We won't introduce features into the open source codebase with a delay.
1. We will always release and open source all tests we have for an open source feature.
1. The open source codebase will never contain arbitrary limits (i.e. event volumes, user numbers).
1. The majority of new features made by PostHog will remain open source.
1. The product will always be available for download without leaving an email address or logging in.
1. We will always allow you to [benchmark](https://news.ycombinator.com/item?id=18103162) PostHog.
## What features are paid only?
If the wider community contributes a new feature that isn't already a source-available feature, we aim to nearly always include it into the open source codebase.
When PostHog makes a new feature, we ask ourselves two questions:
1. Who is the likely type buyer of this feature?
1. Would this feature help more users find and use PostHog?
If the likely buyer is an individual contributor, the feature will be open source. Otherwise, if the likely buyer is a manager, director or executive, it will be source available. The exception to this is if the feature will significantly help the community to increase. For example, initially we planned "multiple users" as a feature for the source-available version. However, we decided that having multiple users would help the community to grow, which benefits everyone disproportionately.
## How open source benefits from open core
1. PostHog contributes many new features to the open source version. Having a viable business model makes it easier for us to invest more here.
1. Security fixes.
1. Support until the community can self sustain itself.
1. Performance improvements.
1. Running an upgrade server.

59
SourceMaterial/strategy/investor-updates.md Normal file
View File

@ -0,0 +1,59 @@
---
title: Working with Investors
sidebar: Handbook
showTitle: true
---
<br />
PostHog brings investors on as partners.
There is a lot of value added from investors:
* Financing so we can build a better and more ambitious product, hence growing faster
* Strategic or tactical advice
* Connections to valuable finance partners
* Connections to valuable potential customers
* Help with hiring a world-class team
# Investor Updates
Investor updates are sent on a monthly basis. This keeps news small and actionable, creates discipline, yet isn't so frequent that much time is spent on reporting.
The format is as follows:
```
------------------------------------------------
Thanks
This is to encourage people to be helpful, which is in everyone's interest, and is part of being nice to work with!
------------------------------------------------
Asks
We may need help with connections to people or organizations, with hiring, or troubleshooting / rubber-ducking.
------------------------------------------------
Key metrics
Investors have a right to know how we're doing. Putting up regular numbers keeps our team focused, and makes many problems more obvious so we can tackle them.
------------------------------------------------
Lowlights
We don't want to surprise people, and by raising issues we may have others help us. We will commit to 3 lowlights every month so we have to include something here.
------------------------------------------------
Highlights
We should surface key opportunities or exciting moments so we can aim to grow fast and to keep people excited.
------------------------------------------------
Expectations
What we're planning for the next month. This context increases our chances of getting help from investors.
------------------------------------------------
```
We do not share investor updates publicly. This is because we often need to mention specific clients, legal and finance issues, all of which are in the rare category of being potentially harmful to discuss.

46
SourceMaterial/strategy/investors.md Normal file
View File

@ -0,0 +1,46 @@
---
title: Investors
sidebar: Handbook
showTitle: true
---
PostHog are proud to have many world-class investors.
## Series A
We raised a \$9M Series A round, led by Alphabet’s VC firm GV, with participation from YCombinator's Continuity Fund and Tapas Capital.
We brought on board Jason Warner (CTO GitHub) as an investor.
## Seed
We raised a \$3M seed round, led by YCombinator and 1984 VC.
We are also grateful to work with the support of the following:
* Unusual Ventures
* Liquid2 Ventures
* Kima Ventures
* Sunflower Ventures
* Uncorrelated
* Tapas Capital
* SV Angel
* Twenty Two Ventures
## Angels
We have brought on a brilliant group of angel investors throughout PostHog's life:
* David Buxton (founder of Arachnys)
* Dalton Caldwell (founder of imeem / YC Head of Admissions)
* David Cramer (founder of Sentry)
* Brad Flora (founder of PerfectAudience)
* Adam Goldstein (founder of Hipmunk)
* Solomon Hykes (founder of Docker)
* Rujul Zaparde (founder of FlightCar)
* Many more (add yourself via a pull request!)
## Interested?
If you'd like to talk to us about an investment in PostHog, please drop us a line at [investors@posthog.com](mailto:investors@posthog.com).
If you are a startup and want an introduction or advice, please email us at [hey@posthog.com](mailto:hey@posthog.com). We can get very busy but we'll do our best to at least respond in all cases.

208
SourceMaterial/strategy/prioritization.md Normal file
View File

@ -0,0 +1,208 @@
---
title: Prioritization
sidebar: Handbook
showTitle: true
---
As there is a lot of autonomy at PostHog, it's useful to have a common framework for how to make prioritization decisions.
## Our mission
Our mission is to increase the number of successful products in the world.
To achieve this, we will need revenue to be able to re-invest into making a better product.
## How is our Product-Market Fit?
Below is a table of how we see our product-market fit for various sizes of companies and various job roles.
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Engineers / PMs with technical expertise</td>
<td style="background:var(--success)"></td>
<td style="background:var(--success)"></td>
<td style="background:var(--warning)">Scalability<br />Advanced analytics</td>
<td style="background:var(--warning)">Scalability<br />Advanced analytics</td>
</tr>
<tr>
<td>Non-technical PMs, marketing, sales, business</td>
<td style="background:var(--warning)">Too technical</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
<td style="background:var(--warning)">Too technical<br />Feature set / integrations</td>
</tr>
<tr>
<td>Analysts</td>
<td style="background:var(--success)"></td>
<td style="background:var(--success)"></td>
<td style="background:var(--warning)">Direct SQL access<br />Plugins for data lakes</td>
<td style="background:var(--warning)">Direct SQL access<br />Plugins for data lakes</td>
</tr>
<tr>
<td>Enterprise procurement</td>
<td style="background:var(--muted)"></td>
<td style="background:var(--muted)"></td>
<td style="background:var(--muted)"></td>
<td style="background:var(--warning)">SOC 2<br />VPC</td>
</tr>
</table>
</span>
As you can see, we have good product-market fit with engineers generally, and specifically for enthusiasts and startups.
## Value
Now let's look at how building things for the different size companies helps us achieve our two goals:
1. Increase the number of successful products in the world
2. Increase revenue so we can re-invest in #1
Given scores from 1-5, here's how each type of company stacks up against those two values.
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Successful products</td>
<td>Low (1/5)</td>
<td>Very high (5/5)</td>
<td>High (4/5)</td>
<td>Low (1/5)</td>
</tr>
<tr>
<td>Revenue</td>
<td>Low (1/5)</td>
<td>Mid (2/5)</td>
<td>High (4/5)</td>
<td>Very high (5/5)</td>
</tr>
<tr>
<th>Combined</th>
<th>Low (1/5)</th>
<th>High (3/5)</th>
<th>High (3.5/5)</th>
<th>High (3/5)</th>
</tr>
</table>
</span>
## Putting it together
When thinking of building a new feature, we can combine the product-market fit table and the priority table into one.
We have three options for each box:
- Deprecate: stop supporting
- Maintain: fix bugs but don't introduce new features
- Grow: fix bugs, do marketing and make PostHog easier to get started with but don't build new features.
- Build: all of the above + building new features specifically for these categories
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Engineers</td>
<td style="background:var(--muted)" rowspan="3">Maintain</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
</tr>
<tr>
<td>Non-technical roles</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--muted)">Maintain</td>
</tr>
<tr>
<td>Analysts</td>
<td style="background:var(--muted)">Maintain</td>
<td style="background:var(--success)">Build</td>
<td style="background:var(--success)">Build</td>
</tr>
<tr>
<td>Enterprise procurement</td>
<td style="background:var(--muted)" colspan="3">N/A</td>
<td style="background:var(--success)">Build</td>
</tr>
</table>
</span>
## Comparing features
If you're trying to decide between two things to work on, a useful exercise can be the following:
1. Estimate the number of successful products that could come out of each category globally (example numbers given)
2. Estimate the amount of revenue we could grab from those categories (example numbers given)
3. Estimate how many of the successful products we could create if we had this feature
4. Estimate how much revenue we could get if we had this feature
5. Repeat steps 1-4 for the feature you're trying to compare
For example, for our virtual private cloud feature we came up with the following numbers:
<span class="table-borders">
<table>
<tr>
<td></td>
<td>Enthusiast</td>
<td>Startup</td>
<td>Scaleup</td>
<td>Enterprise</td>
</tr>
<tr>
<td>Global successful products</td>
<td>10m</td>
<td>1m</td>
<td>10k</td>
<td>10k</td>
</tr>
<tr>
<td>Global revenue</td>
<td>$0</td>
<td>$240m</td>
<td>$500m</td>
<td>$4B</td>
</tr>
<tr>
<td>Additional successful products from feature</td>
<td>0%</td>
<td>5%</td>
<td>5%</td>
<td>10%</td>
<th>51.5k</th>
</tr>
<tr>
<td>Additional revenue from feature</td>
<td>0%</td>
<td>15%</td>
<td>15%</td>
<td>30%</td>
<th>$1,311m</th>
</tr>
</table>
</span>
The point of this exercise is not to come up with the 'correct' numbers. The point is to go through a thought exercise that'll help you figure out the impact of what you're working on.
The idea also isn't that you should do this for every feature you build. Instead, you'll now have a framework for how to think about the impact of what you're building.

51
SourceMaterial/strategy/roadmap.md Normal file
View File

@ -0,0 +1,51 @@
---
title: Roadmap
sidebar: Handbook
showTitle: true
---
Our mission is to increase the number of successful products in the world.
Our roadmap for 2021 will do three things:
1. Create a solid core product that's easy to use
2. Ensure the best developer platform for event-based analytics
3. Set PostHog up to service huge volumes
# 1. Core product
PostHog is a product that people love, primarily because it covers 90% of analytics use cases but bundled into one package.
Some examples of the functionality we've built last year:
- Product analytics
- Session recording
- Feature flags
- Heatmaps
- Autocapture
There's plenty of work to be done within those categories to make a product that is especially useful for engineers and other product minded people. To add on to that, this year we want to build:
- A/B testing
- User feedback
- Data pipelines
On top of those new categories we have a lot of work to do to make our product more stable at higher volumes (especially when self-deploying), much easier to get started with and to catch up with other state-of-the-art analytics software.
# 2. Best developer platform
Developers like using PostHog for many reasons. We're open-source at our core, which has helped a huge amount in gaining trust and adoption from the developer community.
It's easy to debug, you can self-host and PostHog is now starting to become extensible.
This year we're going to lean into that last item. We've kept plugins relatively quiet so far, but we believe plugins will be what will make PostHog the default choice for developers.
We see a ton of usecases, like integrating PostHog into an existing data warehouse, pulling in stats from other APIs and pushing data into other services.
There will be work on three main fronts:
- Building plugins ourselves
- Giving our community the tools to create their own
- Promote adoption of these plugins.
# 3. Service huge volumes
We are getting a lot of inbound interest from enterprise customers who want to either have us host PostHog or want to host it themselves.
We are starting to have experience scaling instances, but we'll need to get a lot better at this to service the biggest customers.
This isn't just about one-off scaling challenges. To do this at scale, we'll need to productize the deployment of a large instance of PostHog.

45
SourceMaterial/strategy/strategy.md Normal file
View File

@ -0,0 +1,45 @@
---
title: Strategy overview
sidebar: Handbook
showTitle: true
---
> PostHog's mission is to increase the number of successful products in the world.
## Meet our users, and their problems
Our best users look a little like this:
* They are a founder, product manager or an engineer (often a senior one)
* They may work in a startup, scaleup or enterprise
* Their company builds software, at least in some capacity, and cares about the end users of their software
## How we'll meet their needs
We're consolidating a fragmented set of tools in the market that help software teams understand and act on user behavior. Companies already know why product analytics matter.
Being open source uniquely enables this approach - we're the only team able to build a true platform that others can build on, to accelerate our breadth of tools that we consolidate.
This is generating opportunities to redefine the category by strengthening the integrations between these tools.
Breadth does come at the expense of depth. We do not aim to answer 100% of questions a product manager or engineer may have about user behavior, so making it easy to integrate PostHog with an existing stack of tools (such as data lakes) is important, mainly for larger volume users.
## Traction
We've had ~3,000 deployments since we started.
PostHog helps power products as diverse as those in airlines and banks, to indie gamers making it more fun to protect earth from aliens to underwear startups working on their retention. Across all devices.
## The future
Software is a good chunk through eating the World.
Product led growth is just getting started with eating software. See Figma, Slack, Dropbox, or Google. Incumbent software companies will either become product led or they'll get disrupted.
PostHog today is focused on enabling engineering teams and product teams to work together, better. That gives us the foothold to steer decision making in every team in every company. For product led companies, it all starts from their user behavior.
## What do we need to do next
We have a [strategy project](https://github.com/orgs/PostHog/projects/5), which is visible for PostHog team members.
We have a [prioritization framework](/handbook/strategy/prioritization) to figure out what to work on next.