merging in material that will be folded in
This commit is contained in:
61
SourceMaterial/people/benefits.md
Normal file
61
SourceMaterial/people/benefits.md
Normal 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
141
SourceMaterial/people/compensation.mdx
Normal 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
97
SourceMaterial/people/feedback.md
Normal 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
244
SourceMaterial/people/hiring-process.md
Normal 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
109
SourceMaterial/people/offboarding.md
Normal 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
141
SourceMaterial/people/onboarding.md
Normal 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
23
SourceMaterial/people/side-gigs.md
Normal 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
167
SourceMaterial/people/spending-money.md
Normal 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
23
SourceMaterial/people/team-structure/_team_template.md
Normal 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
39
SourceMaterial/people/team-structure/core-experience.md
Normal 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
41
SourceMaterial/people/team-structure/design.md
Normal 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
59
SourceMaterial/people/team-structure/extensibility.md
Normal 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
62
SourceMaterial/people/team-structure/growth-engineering.md
Normal 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
73
SourceMaterial/people/team-structure/infrastructure.md
Normal file
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Team Infrastructure & Deployments
|
||||
sidebar: Handbook
|
||||
showTitle: true
|
||||
hideAnchor: 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
36
SourceMaterial/people/team-structure/marketing.md
Normal 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
45
SourceMaterial/people/team-structure/people.md
Normal 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
48
SourceMaterial/people/team-structure/team-structure.md
Normal 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
110
SourceMaterial/people/team-structure/why-small-teams.md
Normal 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
710
SourceMaterial/people/team.md
Normal 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">
|
||||
|
||||

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

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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">
|
||||
|
||||

|
||||
|
||||
</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
55
SourceMaterial/people/time-off.md
Normal 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
25
SourceMaterial/people/training.md
Normal 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!
|
Reference in New Issue
Block a user