Mofongo Jobs
PostHog

Technical Support Engineer

RemoteFull-Time$107,730 - $117,936Mid-Level

Technical Support Engineer

Support Team

  • Location

    Remote

  • Timezone(s)

    GMT +2 to GMT -8

PostHog is your product’s context layer. It ingests and stores your analytics, errors, replays, and business data so you and your agents can query and act on it.

We launched out of Y Combinator's W20 cohort. We've since shipped more than a dozen products, including:

We are:

  1. Product-led. More than 500K organizations have installed PostHog, mostly driven by word-of-mouth. We have intensely strong product-market fit.
  2. Default alive. Revenue is growing incredibly quickly, and we're very efficient. We raise money to push ambition and grow faster, not to keep the lights on.
  3. Well-funded. We've raised more than $180m from some of the world's top investors. We're set up for a long, ambitious journey.

We're focused on building an awesome product for end users, hiring exceptional teammates, shipping fast, and being as weird as possible.

  • Transparency: Everyone can read about our roadmap, how we pay (or even let go of) people, our strategy, and how we work, in our public company handbook. Internally, we share revenue, notes and slides from board meetings, and fundraising plans, so everyone has the context they need to make good decisions.
  • Autonomy: We don’t tell anyone what to do. Everyone chooses what to work on next based on what's going to have the biggest impact on our customers, and what they find interesting and motivating to work on. Engineers lead product teams and make product decisions. Teams are flexible and easy to change when needed.
  • Shipping fast: Why not now? We want to build a lot of products; we can't do that shipping at a normal pace. We've built the company around small teams – autonomous, highly-efficient groups of cracked engineers who can outship much larger companies because they own their products end-to-end.
  • Time for building: Nothing gets shipped in a meeting. We're a natively remote company. We default to async communication – PRs > Issues > Slack. Tuesdays and Thursdays are meeting-free days, and we prioritize heads down building time over perfect coordination. This will be the most productive job you've ever had.
  • Being weird: Weird means redesigning an already world-class website for the 5th time. It means shipping literally every product that relates to customer data. It means building an objectively unnecessary developer toy with dubious shareholder value. Doing weird stuff is a competitive advantage. And it's fun.

We're looking for a Technical Support Engineer who loves helping customers and can't leave a problem alone until it's solved.

You're an engineer who happens to do support. You pick up new things fast and you're comfortable with a problem nobody has seen before. That matters more to us than your previous job title, and people on our team came to support from various backgrounds.

You care about how a customer feels when they leave the conversation, not only whether the ticket closed. You take feedback well, say when you don't know something yet, and learn from anyone on the team.

  • Helping customers across all of PostHog's products, in the app and in shared Slack channels with our bigger customers
  • Owning your tickets from beginning to end, and keeping customers updated along the way
  • Shipping fixes to the PostHog codebase and docs when you find something broken or unclear
  • Becoming the support expert for a product area: owning its queue, working closely with the engineering team behind it, and spotting the patterns that turn into fixes
  • Improving how we do support, including the tooling and workflows we build on PostHog itself
  • Passing customer pain points and feature requests to engineering teams with enough context for them to prioritize

What you won’t be doing

❌ You won't be routing tickets, or forwarding hard questions to engineering because they look hard.

❌ You won't say "that's not my job". If you can't solve something, you find who can and make the connection.

❌ You also won't be pasting AI answers back to customers. We use AI every day, but we expect you to test things out for yourself and write a reply to the customer that's better than the one it would write. Here's more on how we think about that.

How we work

You'll be the face of PostHog for many of our customers. Most of them are engineers, so they want help from someone who understands the technical detail and writes back like a person.

We want support to be part of why people choose PostHog.

We provide support across EU and US time zones, and we're hiring in both. We work in public by default, so you'll ask for help, share what you learn, and discuss problems in team channels rather than DMs.

Read more about how the support team works and our company values.

  • Experience in at least two programming languages, whether from a previous role, side projects, or something else
  • Experience debugging unfamiliar code or systems, and checking your fix works
  • Clear, concise writing that explains a complex fix without burying the customer in options
  • Thorough investigations that don't slow down your reply to the customer
  • Good at prioritizing and context switching across a busy queue that spans many products

Nice to have

  • Experience supporting similar products, e.g. analytics, session replay, feature flags, experiments, or LLM observability
  • A background in support, teaching, product, or another role where you explain technical things to people

If you have a disability, please let us know if there's any way we can make the interview process better for you - we're happy to accommodate!

Meet the Support Team

We make sure users have the information they need to be successful with PostHog and deliver it in a way which sparks joy

Team members

Does pineapple belong on pizza?

54% say YES!

We have a set system for compensation as part of being transparent. Salary varies based on location and level of experience.

Learn more about compensation

Location

(based on market rates)

Country

Region

Level

Step

Salary calculator

  1. Benchmark (Puerto Rico - All) $113,400
  2. Level modifier 1
  3. Step modifier 0.95 - 1.04

Salary $107,730 - $117,936+ significant equity

  • Generous, transparent compensation & equityGenerous, transparent compensation & equity
  • Unlimited vacation (with a minimum!)Unlimited vacation (with a minimum!)
  • Two meeting-free days per weekTwo meeting-free days per week
  • Home officeHome office
  • Coworking creditCoworking credit
  • Private health, dental, and vision insurance.Private health, dental, and vision insurance.
  • Training budgetTraining budget
  • Access to our Hedge HouseAccess to our Hedge House
  • Carbon offsettingCarbon offsetting
  • Pension & 401k contributionsPension & 401k contributions
  • We hire and pay locallyWe hire and pay locally
  • Company offsitesCompany offsites

Get more details about all our benefits on the Careers page.

Make sure customers have what they need to be successful with PostHog and deliver information in a way which sparks joy.

Q4 2026

This quarter we're grouping into three squads by the overall direction of the quarterly goal: humans working around AI, removing the points where customers get stuck, and solving problems once so we don't solve them again and again.

Human in the loop

Understand the quality of support customers get from PostHog AI (Christiaan Hendriksen and Luke Belton)

  • Rationale: PostHog AI is already acting as first-line support, but it's a black box. We don't know how much support it's doing, the quality of those customer interactions, or where they're getting stuck.
  • What we'll ship: A plan for what to capture (how many conversations are support questions, common topics, wrong or suboptimal recommendations, tickets caused by earlier AI advice, frustrated conversations, etc), run a time-boxed 2–3 week deep dive once the new PostHog AI harness is live, then use the findings to decide what ownership should look like.
  • We'll know we're successful when: We have a way of surfacing analysis and customer-related feedback from AI conversations, and gaps are reaching SMEs as skill and docs fixes.

Deslop the Slop Before It Slops (Phillip Ramirez)

  • Rationale: AI agents draft and file tickets on a customer's behalf with no guidance on what a useful ticket contains, or how to make one readable by a human.
  • What we'll ship: guidance and a skill that AI agents can use while drafting a ticket. We'll look to tackle verbosity in AI tickets by outlining an ideal ticket structure, steer agents to obtain information we might need (like links, errors, etc), and specific information (like what the user asked for, what they tried, and why they are asking support for help)
  • We'll know we're successful when: tickets submitted by AI agents are concise and useful, without needing to ask for more information as a first step.

Use AI to make AI-written tickets less tiring to read (Ben Haynes)

  • Rationale: Plenty of the tickets we receive are AI-written text pasted into the support sidebar: long, with unnecessary questions or statements, missing error messages, product areas or repro steps. Reading them all day is slow and wears the team down.
  • What we'll ship: Tooling in HogDesk that uses AI to cut received slop tickets down to what the customer actually needs, and flag what's missing.
  • We'll know we're successful when: The team spends less time and energy reading AI-written tickets.

Let customers show us the problem with feedback recordings (Luke Belton)

  • Rationale: AI fatigue is growing, and customers respond well to a human conversation. A recording tells us more than an AI summary.
  • What we'll ship: A way for customers to record and attach a short Loom-style video of their problem when raising a ticket.
  • We'll know we're successful when: we are receiving tickets from customers with recordings showing us their issues.

No dead ends

Stop customers getting ignored: fewer SLA breaches, especially on escalations (Abigail Richardson)

  • Rationale: Q3 SLA attainment dropped to 81.2%, enterprise first response went from ~7 hours to 29 hours, and a number of escalated tickets have been left too long. Some of this will be due to the change from Zendesk - but we need to do better.
  • What we'll ship: Team notifications for upcoming SLA breaches, call out teams with the tickets that are breached by the longest, a way of pulling breached escalated tickets back into the support queue so that the team can follow up, and a way of flagging tickets where customers are checking in on the ticket with no reply.
  • We'll know we're successful when: SLA attainment for Q4 is better than SLA attainment for Q3, response times for top customers are improving, and the average length of breached tickets is decreasing.

Give logged-out users a better support experience (Eleftheria Trivyzaki)

  • Rationale: Customers who can't log in get a preview of our reply and a button that makes them log in, which doesn't help if logging in is the problem.
  • What we'll ship: A logged-out experience where customers can read and reply without logging in, likely by using cross-channel replies so a ticket raised in one channel can be answered from another (i.e. widget to email).
  • We'll know we're successful when: Logged-out customers can get help end-to-end without logging in, and the feedback about it stops.

Make data deletion and retention tickets go away (Ben Lea)

  • Rationale: Deletion and retention are one of our biggest ticket sources, self-serve deletion doesn't work well.
  • What we'll ship: Ben will own the deletion and retention tickets. We will provide input into the owning team's self-serve deletion work, and make sure we have clear answers on the new retention model.
  • We'll know we're successful when: Deletion and retention tickets drop, and customers can delete their own data without us doing it for them.

Improve incident handling for support and experience for Slack customers (Chris Shine)

  • Rationale: More efficient incident handling makes customers more happy.
  • What we'll ship: Better automatic identification and tagging for tickets related to an ongoing incident. An easy way to bulk assign incident tickets (or maybe auto-assign to the watcher), create a standard response draft for all tickets related to the incident, link out to the incident Slack channel, and look into syncing the support watcher with incident.io. Look into the use of Sherlock and HogDesk.
  • We'll know we're successful when: Incident tickets are tagged automatically and accurately, anyone can find and easily answer them from one place, and Slack customers understand when an outage would affect raising tickets.

Improve docs from a support perspective (Alin-emanuel Cîciu)

  • Rationale: We've put in several docs updates recently where the information was wrong or out of date, and customers' AI agents rely on our docs to help them. We also lost support's feedback loop into docs when we moved from Zendesk to PostHog support.
  • What we'll ship: fixes and improvements to the docs and the workflows/processes that update them. We need an understanding of what's allowing docs to get out of date, and a way to comb through the docs and find where they're now wrong. We'll also look to reinstate support feedback into the docs team, and consider self-driving docs updates off the back of support tickets.
  • We'll know we're successful when: We know which docs are wrong and why, support feedback reaches the docs team again, and tickets caused by outdated docs go down.

Solve it once

Spot data sync issues and tell customers before they write in (Kyle Swank)

  • Rationale: The warehouse sources team already spots sync issues and Tom's bot raises PRs for them, but nobody tells the affected customers.
  • What we'll ship: A way to pick up detected sync issues, find the affected customers, and either make it clearer in-app and/or raise proactive tickets on the customer's behalf.
  • We'll know we're successful when: We let customers know about sync issues before they contact us, and inbound sync tickets go down.

Let customers debug their own replays with PostHog AI (Christian Rafferty)

  • Rationale: customers frequently ask why their replay looks incorrect. This involves us inspecting the customer's website or tracing through their JSON by hand, which could be automated.
  • What we'll ship: A "Debug this replay" button that opens PostHog AI with the replay's JSON attached, new skills to read the JSON effectively, and the diagnosis is saved back to the replay to help all users in the project. We'll do a flagged rollout starting with ourselves.
  • We'll know we're successful when: customers are using this functionality and Replay ticket numbers are reduced.

Build a PostHog CLI for support (Xander Jones)

  • Rationale: There are repeated tasks that support perform which are currently being done via MCP, as a one-off script, or via an AI session. A deterministic, tested CLI would be faster, do the same thing reliably every time, and save us tokens.
  • What we'll ship: Xander's existing CLI tooling made generic, with robust testing, so the team can add targeted tools to it, starting with bulk property pruning and smoother impersonation.
  • We'll know we're successful when: The team uses it for repeat tasks instead of scripts or AI sessions

Give our support agents a memory of tickets (Steven Shults)

  • Rationale: Our agents learn things on every ticket, but they write to sandboxes that get wiped on restart, so knowledge never builds up and the same mistakes repeat across agents. Giving them more shared context means fewer iterations, and faster resolution, even if the investigation is continued by a different team member.
  • What we'll ship: A shared, persistent ticket memory. Notes would be stored alongside each ticket, corrections that every agent learns from, and personal preferences per engineer, as well as notes stored in a shared place for knowledge that can be applied to later tickets.
  • We'll know we're successful when: AI agents build on earlier investigations and corrections instead of repeating them, and the team spends less time iterating with agents on each ticket.

Previous goals

Q3 2026

The big shift this quarter is the switchover from Zendesk to conversations, so every goal below assumes we are working in conversations. SLA attainment will be harder to measure and easy to let slip, so our overriding aim is to protect the customer experience through the transition: hold response times and SLA attainment as steady as we can, and keep CSAT high. Success this quarter looks like customers barely noticing the switchover.

1. Improve the proactive and in-app support customers get

Surface why a replay won't play (Christian Rafferty)

  • Rationale: reduce number of replay tickets by providing more context around our most asked question: "why is my replay not playing / infinitely buffering?"
  • What we'll ship: our events already carry debug information to be able to answer this. We will use that information and surface it in a way that customers can self-solve rather than needing to raise a ticket.
  • We'll know we're successful when: fewer "replay won't play" tickets reach the ticket queue.

Build out experiments ticket investigation skill (Phillip Ramirez)

  • Rationale: we receive a number of common questions around experiments that we can help customers to self-serve the answers to. The plan here is to reduce the number of these tickets we recieve.
  • What we'll ship: we'll build a skill that defines how experiments tickets can be investigated. This can be a skill to be used internally and we can even consider making this a customer-facing skill.
  • We'll know we're successful when: we've shipped at least one troubleshooting skill for experiments and can see those recurring tickets reducing.

Improve the experience of getting support via PostHog AI (Christiaan Hendriksen)

  • Rationale: we want customers to receive correct and reliable information via PostHog AI and we want them to be able to seamlessly raise tickets from wherever they are, without having to switch to the PostHog sidebar.
  • What we'll ship: collect and build data analysis of support quality via PostHog AI. Ship improvements to the way that AI hands-off to support tickets and ship ways for customers to raise tickets via the AI.
  • We'll know we're successful when: we have a data-backed picture of AI support quality and customers can raise tickets via AI.

Define signals for proactive support (Luke Belton)

  • Rationale: if we spot something customers might need help with before they do, we can create a ticket and reach out to them - creating a support experience that sparks joy and prevents churn in a very proactive way.
  • What we'll ship: define a set of data-backed signals we could use to proactively help customers. This should be based on churn data, information from tickets where customers are getting stuck, changes in customer usage, or ways that we can determine something is not right in the customer's set up.
  • We'll know we're successful when: we have a set of concrete signals we could use to create proactive tickets from.

2. Make support faster and smarter in the Support product

Bring valuable HogDesk features into the Support product (Xander Jones)

  • Rationale: the Support product is our new home for support, and as a team using it every day we're well placed to make it better.
  • What we'll ship: ship two features we find most valuable in HogDesk and bring them across into the Support product - getting it right for ourselves as much as for our customers.
  • We'll know we're successful when: our productivity in conversations is improved by these new features

Tidy up the customer support experience and sidebar (Ben Lea)

  • Rationale: we want it to be easy for customers to raise tickets with us (from the sidebar, from error messages, as feature feedback), and be able to see what ongoing tickets they have open. At the moment the sidebar is a long, unwieldy scroll of tickets that needs fixing.
  • What we'll ship: ship changes to the ticket sidebar so that customers don't see all of their tickets at once - resolved tickets can be hidden or available somewhere else. Ship changes so that conversations tickets are raised from error messages and feature feedback.
  • We'll know we're successful when: customers have a clearer, faster experience raising and following up on tickets.

Better information captured on tickets (Kyle Swank)

  • Rationale: the more information we can capture at ticket creation time, the quicker it is for us to investigate a ticket and get solutions to our customers
  • What we'll ship: we'll create a skill that is invoked when a ticket is created to gather additional information and helps the customer submit a better ticket for us to investigate
  • We'll know we're successful when: we are receiving better constructed tickets and more immediate context on tickets

Feedback recordings in the Support product ticket flow (Luke Belton)

  • Rationale: customers being able to submit recordings with their ticket will allow them to show us exactly what they think is going wrong. This makes it easier for customers to raise a ticket and gives us richer context up front.
  • What we'll ship: the ability for customers to submit a recording with their ticket.
  • We'll know we're successful when: we are receiving tickets from customers with recordings showing us their issues.

More efficient impersonation (Steven Shults)

  • Rationale: we want account impersonation to be fast and seamless so that we don't lose time while investigating tickets.
  • What we'll ship: Steven Shults will add MCP impersonation to HogDesk - if time allows, we will extend this to conversations and PostHog code. Xander Jones will ship the ability to switch between impersonated users in the same org.
  • We'll know we're successful when: when engineers can get into an impersonated MCP session with a less clunky re-auth than the impersonation-toolkit steps, and switching users is quicker.

Surface ticket trends and potential incidents (Ben Haynes)

  • Rationale: spotting ticket patterns and trends helps us to identify incidents and prominent bugs faster, leading to faster fixes.
  • What we'll ship: implement functionality in conversations that identifies ticket trends and surfaces potential incidents.
  • We'll know we're successful when: we are alerted of prominent bugs and possible incidents from conversations tickets, rather than relying on one person to spot them.

Complete the move to the Support product and retire Zendesk (Abigail Richardson)

  • Rationale: move 100% into conversations for all of our support. This helps us to give feedback into our own product and help it grow.
  • What we'll ship: handbook updates, workflows and notifications in place, and reporting and CSAT working again
  • We'll know we're successful when: support tickets are entirely in conversations, Zendesk is retired, and reporting is in place for conversations

3. Billing and legal self-serve

Make the BAA process self-serve for startup-plan customers (Eleftheria Trivyzaki)

  • Rationale: BAAs require the Boost add-on, but startup credits don’t cover BAAs. Startups on credits shouldn’t be able to sign a BAA in-app without a separate subscription. We also don't currently track BAAs for startup customers or have a defined process, so handling is ad hoc.
  • What we'll ship: a self-serve path for startup plan customers to request Boost and get a BAA, plus a documented process for handling these requests. Nice to have: visibility into how many existing startup plan customers already have a BAA in place without a separate subscription.
  • We'll know we're successful when: startup plan customers can resolve the BAA/Boost limitation on their own, we have a repeatable process for handling these requests, and we can report on BAA coverage across the startup plan.

Q2 2026This quarter we're driving SLA attainment and response times in one direction: up. We want consistent week-on-week improvement, with our Q2 average beating Q1. Every goal below is pointed at making that happen — through deeper product knowledge, faster investigations, and fewer tickets raised in the first place. #### 1. Deepen SME expertise and reduce ticket friction A core focus this quarter is turning our SMEs into genuine product experts — people who can spot patterns, advocate for fixes, and proactively prevent tickets before they're raised. ##### Objectives - Identify most common investigation steps that could be surfaced onto tickets automatically - Identify proactive interventions (e.g. docs, in-app prompts, automatic checks) that could prevent recurring tickets - Identify top user pain points or bugs and feed these back to the relevant engineering teams - Begin establishing an SME for analytics products ##### Owners - Replay SME depth: Ben Haynes- Data SME depth: Luke Belton- AI & Observability SME depth: Christiaan Hendriksen- Flags SME depth: Phillip Ramirez- Analytics SME launch: Xander Jones#### 2. Ship improvements that make support faster and smarter ##### 2.1 SDK health improvements **Owner:** Steven Shults**Objective:** Add a couple of additional features to the SDK health check - including alerts, and understanding how PostHog is being initialised. Implement a couple of fixes for existing known issues. If we have time we will look into doing tasks to get the SDK health check into GA. ##### 2.2 Surface useful context for support investigations **Owner:** Kyle Swank**Objective:** Start by enhancing information captured at the bottom of Zendesk tickets with additional context and information that could help the support engineer during the investigation of the ticket. We will also investigate what the future of this should look like, considering things like enhancing the health overview. The intention with the investigation is to understand what this should look like for us internally as we start to use different tools, and then later consider how we might be able to make this diagnostic information available to users to proactively help them. ##### 2.3 Surface information about the state of replay capture from events **Owner:** Christian Rafferty**Objective:** Currently we store properties on events which provide information about the state of replay capture at the time of the event. These properties are frequently used when trying to diagnose reco

Please let PostHog know you found the job on Mofongo Jobs. This helps us grow!