Member of the Technical Writing Staff

WHO WE’RE LOOKING FOR AND WHY NOW?

A great writer who gets technical stuff – and loves figuring out how to explain it to other people.

We have a strong writing culture, and writing as marketing has worked ridiculously well for us. We have a newsletter with over 100k subscribers, active social accounts, and real SEO and AEO authority. Hundreds of thousands of people visit our website every day. If you join, you won't spend a year building an audience before anyone reads you.

We can and like to be opinionated https://newsletter.posthog.com/p/collaboration-sucks about what we think best practice is and thousands of developers look to us to provide them opinion.

The problem is we're at capacity, and there's a long list of content we're neglecting because of it. We used to do more tutorials. Use case guides people keep asking us for.

Overall, we have a lot to write about. PostHog has grown from product analytics into a broad platform for engineers, and we're building everything from AI agents and error tracking to data infrastructure at huge scale. We're also open by default, so we're unusually happy to share what we've learned along the way.

We want someone who can turn all of that into genuinely useful technical content.

Simply put, you're a writer. You care about the craft, have opinions about what makes technical content actually great, and have a portfolio that proves it.

WHAT YOU’LL BE DOING

You'll research and explain use cases, technical concepts, and how things actually work. One day that might mean digging into how our engineers rebuilt part of our data warehouse. Another could be explaining the difference between logs and traces, writing a tutorial for a PostHog use case, or figuring out the best way to explain what a context warehouse is.

You'll need to be comfortable getting into technical details, but you don't need to be an engineer. The important bit is that you're curious enough to understand technical concepts properly and a good enough writer to explain them simply.

Day to day, it looks like

- Writing content that helps people and agents use PostHog better. Use case guides, tutorials, technical explainers, engineering posts. The stuff we know is valuable and haven't had the capacity to do as much as we want to.

- Researching and explaining hard things. Technical details, engineering processes, and concepts that most people gloss over. Going deep enough that a builder actually learns something.

- Figuring out what to write. Looking at what we are shipping as a company, what our priorities are, and what's interesting to decide yourself. There isn't going to be someone telling you what to write all the time.

- Choosing the right format for the idea. Sometimes that's an engineering blog. Sometimes it's an SEO explainer. Sometimes it's a thread on X.

- Working with engineers and other marketers. Getting the story of what they built, why it matters, and what's interesting about it for normal builders. You might edit their blog posts too.

Some examples of the sort of things you might work on

- 10,000 PRs a month is easy: How devex is evolving at PostHog https://posthog.com/blog/10k-prs-a-month

- What is a context warehouse? https://posthog.com/blog/what-is-a-context-warehouse

- Why we rebuilt our data warehouse on DuckDB over ClickHouse https://posthog.com/blog/why-we-rebuilt-our-data-warehouse

- What is a Scout? A technical deep dive https://posthog.com/blog/what-is-a-scout

- What is distributed tracing? (A guide for engineers) https://posthog.com/product-engineers/what-is-distributed-tracing

- Validating what you ship: Did anyone use it? Did it work? https://posthog.com/tutorials/validating-what-you-ship

- How to set up embedded analytics https://posthog.com/tutorials/embedded-analytics

WHAT YOU WON’T BE DOING

❌ Churning out generic SEO content to hit a publishing quota.

❌ Spending most of your time writing social posts, newsletters, ads, video scripts, or marketing copy.