Creating a product engineering culture

You can't plug product engineers into a traditional corporate environment and expect them to transform your company. It just doesn't work. In fact, they'll hate it, and everyone else will find them impossible to work with. Everyone loses.

That's why product engineers are most common at startups and scale ups – companies that have built their culture around moving fast, and giving product engineers the things they need to thrive.

Whether you're building a new company, or trying to change an existing one, here are some ways to help product engineers flourish that we've adopted at PostHog.

1. Create time to build

Products don't get shipped in meetings, so the most important thing a product engineer needs is time to build.

A product engineer's calendar should look like this:

In many ways, everything we do at PostHog is designed to reduce the need for meetings, but there are a handful of specific things here:

• Two meeting-free days a week: Every Tuesday and Thursday at PostHog is a mandated meeting-free day. Only in exceptional circumstances, such as quarterly planning sessions, will we book a meeting on these days. Recurring meetings should never happen on a meeting-free day.

• Defaulting to async comms: Most big product decisions can be made asynchronously, and a meeting should only happen when everyone involved has contributed to an RFC, given their feedback, and have done their thinking beforehand. This makes the meeting purely about making a decision where everyone has the necessary context.

• Part-time managers: Managers at PostHog are individual contributors first and managers second. We generally encourage people to have fewer 1:1s with their manager, skip them when they're not required, since 1:1s tend to proliferate as companies grow.

2. Maintain a high bar for hiring

There's nothing more motivating for a great product engineer than being surrounded by similarly talented, intrinsically motivated engineers. The opposite is also true.

Needless to say, this is hard, but hiring well is the most important thing any company can do, so it pays to think deeply about what you want here. The rot begins the moment you compromise and hire someone who isn't a "hell, yes!"

You can avoid many problems, and solve them too, simply by nailing hiring 99% of the time. Our default assumption is we should only hire people who either meet or exceed the bar of the existing team, or have an obviously high ceiling.

If we're not excited by the prospect of working with someone and the work they could do, it's a no.

3. Give product engineers autonomy

You have to resist your urge to control product engineers.

This is why product managers at PostHog don't manage product teams, or engineers. It's also why individual product teams have a large degree of latitude in what they build, provided they're taking user needs and larger goals of the company into account.

Will this go wrong? Sometimes, but you'll learn more by shipping fast and iterating than creating a bunch of processes to control what product engineers work on.

If a product engineer is struggling to deliver, it may just mean they're not ideally suited to this kind of role. This is fine and normal. Not everyone needs to be a product engineer, and many great developers may prefer a more structured environment.

4. Eliminate arbitrary deadlines and approval processes

Most companies love to set artificial deadlines because they’re the easiest way to “increase urgency,” but they have a nasty habit of manifesting into meaningful deadlines. Deadlines that generate mountains of debt and slow you down over time.

Instead, we ask product engineers a simple question: why not now? And, provided the "why not" doesn't include some kind of critical problem (security, compliance, privacy, etc) the default should be to always ship something as early as possible.

We always prefer to give feedback on work someone has done than require approval to do it. This doesn't mean engineers "yolo merge" to prod with no code review. It does mean trusting product engineers to make decisions about what to build and how to build it, and creating tight and regular feedback loops, so they keep learning.

Ultimately, autonomy requires trust, and trust requires regular feedback to help people when they need it. You can't have one without the other. We do this by having lots of rituals for forcing transparent feedback, such as 360-degree feedback sessions at off sites, and keeper tests.

5. Be very honest about performance

Part of giving people autonomy and regular feedback is being honest about performance, and when someone is underperforming.

Sometimes this happens because someone is a bad fit for the role, sometimes it's because they're actually performing well but in the wrong direction. Whatever the reason, it's important to give prompt and direct feedback when someone needs it, and act decisively.

To understand why, consider this subjective math:

• The 20% of your team who are underperforming will take up 80% of your effort, and drag higher performers down.

• You may be able to get an underperformer’s output from 4/10 to 6/10 if you work hard with them, but 6/10 work won't delight your users.

• In contrast, the 9/10 work of your best performers will delight your users, and anything (or anyone) that drags that down will make your product worse.

When we let people go for performance reasons, we share the reasons with everyone in the business, so it's clear why we make these choices.

This brings us neatly to our next point...

6. Embrace transparency

Transparency, both internally and externally, is a core principle for us and an important part of what a product engineer needs to be successful.

Why? Because it's where product engineers get the context they need to make good decisions. The context they need to work autonomously.

We take this to a greater extreme than most. We're open source, so anyone can contrinute to our code and docs. We also have a public handbook where we share things like our strategy and priorities, how we work, how we hire, and so on.

These are just the basics, though. Internally, we also share things like:

• Revenue, growth, and churn for all products
• Financial reports (operating costs, burn rate, cash in the bank, etc.)
• Fundraising plans
• Team changes
• Why we let people go
• Board meeting notes and slides
• Exec team sprint meeting notes
• All product team sprints and RFCs

By sharing all this context, some of it sensitive, everyone (not just product engineers) are equipped with the context they need to make decisions on their own.

This also helps reduce meetings, since important context isn't siloed within meetings where it's lost or needs to be requested. Hoarding information is an anti-pattern.

7. Adopt a small team structure

All the above is much easier if you build your company around small teams, which we define as teams of six people or fewer.

Small teams don't require a bunch of coordination and process to keep them aligned, reducing the need for meetings and processes, and it's easier for them to quickly change direction when needed.

An effective small team should have one leader, be able to ship and make decisions autonomously with minimal dependencies on other teams, and have their own mission, long-term goals, key metrics, and target customers.

At the time of writing this, PostHog is 187 people organized into 47 teams with an average team size of 4.2 people. Each team lead reports to a member of our exec team, keeping our company structure flat and our teams tight, fast moving, and autonomous.

Next chapter: Antipatterns for product engineers