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