PostHog Handbook Library / People

1,508 words. Estimated reading time: 7 min.

# Feedback

Auto TL;DR

## At a Glance

This long page covers these main areas. The list is generated from the article headings, so it updates with every handbook rebuild.

1. Feedback at PostHog
2. Keeper tests are not a substitute for direct feedback
3. Full team feedback sessions
4. Ground rules
5. How to give good feedback
6. How to receive feedback well
7. README sessions
8. Team surveys

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

'Open and honest' doesn't mean '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.

#### Keeper tests are not a substitute for direct feedback

Keeper tests are not designed to replace direct feedback, and the responses are not made visible to the person being assessed in the ops platform. We've always wanted people to give direct feedback to each other, across teams and in all directions – keeper tests do not replace the art and process of giving continual, direct, and 360 feedback.

The keeper test forms exist for a few specific reasons:

- To surface feedback to the relevant Blitzscale team member so they can help where necessary.
- To keep a record of feedback given, in case the person moves team or the team lead changes.

We also want people to fill these forms out totally unfiltered, rather than through the lens of "will this person see this feedback". If you have feedback for someone, give it to them directly – don't rely on the keeper test to do it for you.

### Full team feedback sessions

We run full team 360-degree feedback session as part of every offsite. Some teams will do them during their own small team offsite, while others choose to do them as part of the whole company offsite. The session gives everyone the opportunity to give and receive feedback to everyone else. If your team works closely with another or is very small, you may combine with another team (but keep attendees to <8 if you can).

#### Ground rules

- Everybody participates! You should have a think and write up your notes in advance – don't try and wing it on the day.

- Preparation includes reading our handbook about how to be a good feedback giver and receiver.

- As a guide the mix of positive and constructive feedback will vary. You should spend more time talking over the constructive even if you have a long list of positive things to share – 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 2 min 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).

- What is discussed is for the benefit of those present and does not need to be shared with others who were not present. It is ok to follow up with anyone on feedback you received or gave after the session.

- Use a notebook, or worst case keep notes on your phone. You will be much less present if you use your laptop, so we generally discourage these.

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

### README sessions

At small team offsites we may also run README sessions in addition to 360 feedback sessions. Typically we find it useful to run these README sessions as early as possible during the offsite and before 360 feedback, as they are a great way to get to know your team.

README sessions are an opportunity for you to help others understand more about your background, communication style, and interests. You can share as much or as little as you feel is appropriate. Some things which you may wish to consider include:

- What you’re good at
- What you’re bad at
- What you like
- What you don’t like
- How best to work with/help you

It's OK to ask short, clarifying questions when someone has finished, but sessions shouldn't become Q&As.

### Team surveys

We run team surveys every 6 months using the _Pulse Surveys by Deel_ Slack app. These are set up to run automatically, including reminder messages in Slack, so you don't need to chase people manually. Charles and Coua have admin access to the surveys in Slack.

The questions are based on the ones used by Culture Amp and cover categories such as Company Confidence, Culture, Growth etc. on a 1 ('strongly disagree') to 5 ('strongly agree') scale. The benchmark used is against Culture Amp’s ‘new tech’ companies with less than 200 people. We then take the average score out of 5 and multiple it by 20 to get a % number. A bit rough, but close enough so we can compare with the benchmark.

Only the People & Ops and Exec teams have access to the full list of responses, which are not anonymous.

We follow a template to report a summary of the results in an Issue. You can view the latest survey results here - just copy the formatting every time.

#### Current list of questions

- I understand PostHog's goals and can see how my work contributes to them. (1 to 5)
- At PostHog, we have open and honest two-way communication. (1 to 5)
- I receive appropriate recognition for my work at PostHog. (1 to 5)
- I believe that my total compensation (salary + equity + benefits) is fair, relative to similar roles at other companies. (1 to 5)
- The leaders at PostHog keep people informed about what is happening. (1 to 5)
- If you were to leave PostHog, what would be the reason? (Free text field)
- PostHog is in a position to really succeed over the next three years. (1 to 5)
- What motivates you right now? (Free text field)
- My manager and team around me genuinely care about my wellbeing. (1 to 5)
- I feel like I am learning and growing at PostHog. (1 to 5)
- Generally, I believe my workload is reasonable for my role and I am able to arrange time out from work when I need it. (1 to 5)
- The support I am receiving and processes we have in place allow me to do my best possible work. (1 to 5)
- I would recommend PostHog as a great place to work. (1 to 5)
- I see myself still working at PostHog in two years' time. (1 to 5)

Canonical URL: https://posthog.com/handbook/people/feedback

GitHub source: contents/handbook/people/feedback.md

Content hash: `0f22b05c51f09244`

Static reader notes

- `MDX_COMPONENT_STATIC_ADAPTER`: Adapted interactive MDX components for static reading: PrivateLink.