Managers and management

A manager at PostHog has a short list of responsibilities:

1. Setting the right context for your direct reports to do their jobs
2. Making sure your direct reports are happy and productive
3. Acting as the hiring manager for new roles in your team
4. Creating good plans for new person onboarding and small team offsites
5. Collaborating with execs on team performance concerns that need early intervention

That's it.

A manager at PostHog is _not_ responsible for:

1. Deciding compensation - we have a compensation calculator and the process is managed by the exec team
2. Setting tasks for your direct reports - that is not how small teams work
3. Providing a career progression plan for your team
4. Figuring out team structure - today that is all handled by the exec team
5. "Approving," whether that's projects, expenses, days off, or accounts - people should have admin access by default to most things
6. Dealing with HR issues - you should escalate these to Fraser or Charles
7. Anything legal-related, e.g. someone wants to quit or thinks they did something illegal - route this to the exec team
8. Deciding to hire or fire people - the exec team do this

This guidance applies to all teams, irrespective of whether you manage an engineering or non-engineering team.

Part-time managers

Because of the relatively short list of tasks that managers have, management at PostHog is a part-time job. That means nearly everyone still spends the majority of their time on practising what they do best. For most managers, this isn't actually management!

As an engineer, you want the opinion of someone who can actually code. As a designer, you really want your manager to have an eye for design. As an operator, you want to be managed by someone who has scaled a business. That's why it's important for managers to keep practising their craft.

However, management tasks do come _first_, as giving context to your team tends to have a multiplying effect vs. getting one more PR out. After that though, it's back to work.

Management is intentionally spread thin at PostHog. This is a forcing function for making sure that teams and ICs continue to have high levels of autonomy. Bored managers are micromanagers. By working across several teams, people like #team-blitzscale and product managers are forced to only give their attention where it's truly needed, and give space & autonomy everywhere else.

You'll sometimes hear us use the term "team lead". A team lead is the leader of a small team. By default they also manage the individuals that are part of their team, though very occasionally they don't, such as when a new small team has just been created.

How do I set context?

At PostHog, we hire highly experienced people for 99% of roles. That means managers won't need to spend time telling their direct reports what to do.

However, for those people to make the best decisions, they need context. The things a manager can do to set context include:

• Creating a roadmap that the team can work towards
• Helping the team level-up their understanding of your target customer and the problem space you are working in (eg by encouraging them to talk to users, and doing so yourself)
• Helping someone figure out who else to talk to within PostHog
• Enabling or encouraging the team to measure their impact
• Improving the process in which a team works (things like standups, reviews etc.)
• Organizing a team offsite or other meetup to work in person

Pitfalls to avoid

The biggest difference between PostHog and other places is that in the end it is up to the _individual_ to make the decisions. All you can do as a manager is set context. From there, you'll have to trust that we've made the right hiring decisions and that the individual is able to execute on that. If they can't, we have a generous severance policy.

Decisions aren't just about buying a piece of software or choosing a color for a button. It's also about what to work on, what to invest time in, or where to take entire parts of our product.

As a manager, it's tempting to see yourself as the sole owner of all the information, and give it out sparingly. People will come to you often with questions (because they don't have the context) and when they do you'll get more validation that holding all the context yourself makes you an Important Person. What managers should aim for at PostHog is to make themselves obsolete. Share as much context as possible, in written form and in a public channel. That way everyone will be able to do their best work.

Ways to burn yourself out:

• Become the sole point of communication between your team and others. Instead, connect the right people together directly.
• Take sole responsibility for writing up the detailed plan for your team. Instead, set the vision/roadmap, then encourage your team to contribute objectives too.
• Move from IC to manager and just add the management on top of your existing work. Instead, you should cut your IC work down slightly to make room.
• Be the only person on your team who talks to customers. Instead, encourage everyone to do this - this starts at onboarding!

How do I make sure my direct reports are happy and productive?

First, make sure you are setting the right context. Next, the most useful thing you can do here is to schedule regular 1-1s. Typically we find that you should have higher frequency 1-1s with your reports when they join PostHog and reduced frequency over time as they settle in. There are some types that we've found useful:

• When they start schedule a longer 1-1 to get to know each other and set expectations on each other
• During their probation period have weekly 1-1s as a regular check in (this is an important time to be giving clear feedback about how they are doing)
• After their probation have bi-weekly or monthly 1-1s to discuss how they are doing outside of the regular day-to-day context

The key thing here is to be pragmatic - 1-1s should feel useful and not like a waste of time. Everyone should see it as their own responsibility to raise important feedback or issues as they happen and not wait unnecessarily for a scheduled meeting.

Talking about long-term career goals every now and again is also important but easy to let slip when things get busy. If you can help people achieve long term goals while at the same time hitting PostHog's short term needs - whether at PostHog or not - you'll get people's best work!

We have a set of handy templates to use - feel free to adapt these for each team member. These are not to be followed strictly if you don't want to - this is to just save you having to create something from scratch.

Performance

We care about having a consistent, transparent, and fair way to handle recurring performance issues. We don’t want this to be a source of stress for you - it’s not your core responsibility as a team lead, and we want you to feel supported. The People & Ops team will prompt you to consider performance within your team at key moments to make this easy and straightforward, but you should proactively give feedback and raise concerns with your exec as they arise.

• We expect you to regularly give proactive, actionable feedback to everyone on your team - it’s the most direct way to help troubleshoot issues upstream. This is particularly important at the 30-day, 60-day and 80-day check-ins after a new starter joins.
• The team lead will be asked to consider the following questions that are aligned with our values:

i. Is the person a driver or a passenger? ii. Does this person get things done proactively? iii. Are they optimistic by default?

• We expect you to actively raise performance issues with your exec.
• Once you do, your exec will take the lead on the process. You’ll likely deliver feedback directly to the employee, but your exec will support and coach you through those conversations.
• Your exec will look after the process and make any decisions required.
• If it ever comes to someone leaving, your exec will work with the People team to handle it carefully, sensitively and fairly.

The keeper test

As PostHog grows, it's increasingly important that all team leads help us keep the bar for performance high - we can't centralize this with the founders. To help us scale this, each team lead will be asked to do a keeper test on their team members throughout the year, this will be sent in an automated form, by Deel, through Slack. The format is as follows:

1. Ask the team lead 'if X was leaving for a similar role at another company, would you try to keep them?' - the answers should be derived from our values, similar to the questions above.
2. Dig in where the answer is 'no' - what would it take for this to be a 'yes'? Is this just temporary, or is there a deeper issue to resolve?
3. Make sure the manager is sharing all of this feedback with their team to help them improve.

That form will be shared with the relevant team Blitzscale member, so they can help where necessary.

Side note: anyone can ask their manager 'how hard would you work to change my mind if I were thinking of leaving?'. It's a great way to solicit valuable feedback!

Weave

We use a tool called Weave to collect stats for engineers. Engineers can log in to see their numbers and those of other engineers.

We understand that all the work an engineer does can't be properly represented in a tool that just looks at PR output. Data in Weave is _not_ the decision-maker for whether someone is succeeding in their role at PostHog. It can be, however, a part of the conversation.

We use Weave to:

• Look for outliers in the company in terms of output (both high and low - sometimes unexpected people are rising to the top!)
• Watch for issues with overall team productivity to identify possible blockers
• Start conversations with team leads

We don't use Weave to:

• Make a decision to let someone go - if and when this happens, it only follows detailed discussion with and recommendation from the team lead
• Monitor your PRs - our management layer is stretched way too thin to micromanage this
• Creep on your use of AI - we don't care how or if you use AI to get a job done, as long as it gets done
• Make a call on how valuable someone is - some people with low PR output are very valuable to the company, and we're 100% aware that things like heavy support load can impact output

We have compared statistics in Weave against other (imperfect!) metrics that can be used to gauge productivity, such as number of commits, number of PRs, total github activity, etc, and see similar patterns amongst them. Weave gives us more detail and a nice UI for evaluating output across all the engineers we have, which we don't have any other good interface for. In addition, it gives engineers access to the same information we have about them, so using it increases transparency.

What does being a hiring manager entail?

Two things:

• You will conduct the technical interview by default. You'll also kick off the SuperDay with candidates, and be their main point of contact in Slack. Please help us keep hiring moving by giving feedback quickly!
• If you think your team needs someone, make a new hire request. The exec and people team are generally on top of hiring for all teams, but this is a good approach if you think something has been missed. You'll also be asked to do one of these anyway if we're hiring for a new type of role.

See the #technical-interviewers channel for more info here.

What you can expect as a manager

Management roles at PostHog are often (but not always) temporary. That's because as the company changes, our needs for different people in different roles will change as well. Because all of our managers are also strong ICs (individual contributors), sometimes putting someone back into an IC role makes sense if that's what's best for the company. This has happened many times with people at PostHog, some who have gone back and forth between being a manager and not being a manager multiple times (hi Marius Andra!).

As such, management roles are paid on the same pay scale as other ICs. Becoming a manager does not mean you get a pay raise, and going from a manager role back to an IC role does not mean you get a pay decrease.

Management is a skill of its own, and it's not any more important than any other skills that make someone a great IC. It's possible that you may be a manager for a short time, but it becomes clear that your strengths lie primarily in the other skills that are involved with being an IC. In this case we might move you back to a pure IC position, where your skills can really shine, and move someone else from your team or from around the company into the manager / team lead role.

Additionally, managers who are excelling with their teams may have limited interaction with their own manager. This is because, as discussed above, management is intentionally spread thin. If you feel like your manager is mostly ignoring you, this isn't necessarily a bad thing and usually means you and your team are doing a fine job!

Recommended reading

These have been recommended by multiple managers on the team:

• The Making of a Manager: What to Do When Everyone Looks to You by Julie Zhuo (great for first time managers)
• High Growth Handbook by Elad Gil (covers a lot of ground beyond management)

Engineering-specific:

• The Manager's Path by Camille Fournier
• An Elegant Puzzle: Systems of Engineering Management by Will Larson