Technical Support Engineer
Support Team
Location
Remote
Timezone(s)
GMT -8:00 to GMT +2:00
About PostHog
We’re equipping every developer to build successful products by giving them a suite of products to analyze, test, observe, and deploy new features. We currently offer product and web analytics, session replay, feature flags, experiments, a CDP, SQL access, a data warehouse, and LLM observability… and there’s plenty more to come.
PostHog was created as an open-source project during Y Combinator's W20 cohort. We had the most successful B2B software launch on HackerNews since 2012 with a product that was just 4 weeks old. Since then, more than 100,000 companies have installed the platform. We've had huge success with our paid upgrades, raised bags of money from some of the world's top investors, and have extremely strong product-led growth – 97% driven by word of mouth.
We're growing quickly, but sustainably. We're also default alive, averaging 10% monthly revenue growth and with more than $20m ARR. We're staying focused on building an awesome product for end users, hiring a handful of exceptional team members, and seeing fantastic growth as a result.
What we value
We are open source - building a huge community around a free-for-life product is key to PostHog's strategy.
We aim to become the most transparent company, ever. In order to enable teams to make great decisions, we share as much information as we can. In our public handbook everyone can read about our roadmap, how we pay (or even let go of) people, what our strategy is, and who we have raised money from.
Working autonomously and maximizing impact - we don’t tell anyone what to do. Everyone chooses what to work on next based on what is going to have the biggest impact on our customers.
Solve big problems - we haven't built our defining feature yet. We are all about shipping fast, talking to users, and iterating.
Who we’re looking for
To put it simply, we’re looking for a Support Engineer who loves talking to customers and helping them solve their problems. Answering tickets is important, but we want someone who can also build out our support tooling at the same time.
You’ll be the face of PostHog for many of our customers, so you’ll need to be extremely helpful and engaging. This isn’t a support agent role - you’ll be resolving most issues directly yourself, and only escalating the more complex ones directly to the relevant engineering team.
What you’ll be doing
Improving the way we do support - we’re growing rapidly so need to make sure we are set up for future success. This means better tooling, automation, reporting, and more.
With your knowledge of PostHog, you’ll be answering the majority of tickets yourself across our products, ensuring that customers are able to use the platform without blockers.
You’ll also be working closely with the product teams to ensure that they are aware of any issues requiring product development work, helping them prioritize requests based on customer profile.
You’ll be working closely with the rest of the Customer Success team to ensure that we are meeting our internal targets for support ticket response.
What you won’t be doing
❌ Acting solely as a first line support agent - we expect you to be able to diagnose and fix issues themselves, escalating to the appropriate team when development work is needed.
Requirements
SDK experience — specifically JS and NextJS
Strong customer focus - you need to help our users and remove any blockers to them using PostHog effectively.
Good at prioritizing and context switching - we have a high volume of tickets across various product areas.
Engineering background - the majority of our users are engineers and as such need help from someone equally as technical.
Able to build solutions yourself - we are also responsible for Support and Customer Success tooling so need to take ownership of improvements.
Nice to have
Experience providing support for similar products, ie. analytics, session replay, feature flags, A/B testing, data warehouses, CDP etc.
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!
Generous, transparent compensation & equity
Unlimited vacation (with a minimum!)
Two meeting-free days per week
Home office
Coworking credit
Private health, dental, and vision insurance.
Training budget
Access to our Hedge House
Carbon offsetting
Pension & 401k contributions
We hire and pay locally
Company 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.
Implement two way sync for community questions with Zendesk
- Owner:
Christian RaffertyChristian Rafferty - Rationale: A centralised tool for managing both community and non-community tickets will give the support team full visibility into all customer questions without splitting focus across multiple platforms. This also creates the groundwork for being able to offer some level of support to free customers.
- What we'll ship: When a community question is posted, ensure that it is raised in Zendesk and assigned to the correct agent group. When follow up replies are posted on the community question thread, ensure that these are posted onto the Zendesk ticket and the ticket status changes appropriately. Allow agents to post their reply in Zendesk as a public comment which will be posted to the community thread (internal comments will remain only in Zendesk). Ensure that the desired behaivour is achieved relative to existing triggers and automations that exist in Zendesk.
- We'll know we're successful when: All community tickets and their replies are tracked in Zendesk, community tickets follow the same status rules as non-community tickets, and we are able to start considering target response times for community questions.
- Stretch Goal: Set the
Org plan levelon the ticket.
Create a reliable way to surface if we are experiencing a customer facing incident
- Owner:
Joshua OrdehiJoshua Ordehi - Rationale: Being able to surface incidents faster means that we as a company can jump on those incidents and fix them sooner.
- What we'll ship: Improvements to the existing reporting and alerting that Joshua has created which looks at support tickets created from customer facing errors. The goal is to make the detection more accurate (considering both specific product areas and being able to identify cross-functional issues) and less noisy. The next stage of implementation will also look at the related error tracking issue to discover if more customers are experiencing this error/incident (within a specific timeframe) but aren't reporting it in support tickets.
- We'll know we're successful when: We feel confident enough in the accuracy of the incident identification to put the alert into #tell-posthog-anything.
Make it more obvious how to submit tickets during the login workflow
- Owner:
Eleftheria TrivyzakiEleftheria Trivyzaki - Rationale: Prevent customer frustration and improve support experience by making it more obvious how to submit tickets during the login workflow.
- What we'll ship: Implement a more obvious prompt to the user for how to submit a support ticket.
- We'll know we're successful when: Fewer tickets with the
email-closedtag that have been created due to issues encountered during the login workflow.
Develop a framework that will give us confidence in how Max is being used as a support tool
- Owner:
Luke BeltonLuke Belton - Rationale: Max is being used as a support tool and we don't really know what the quality of that support is. We want to ensure that users are receiving the best support experience and that Max is monitored with that in mind. If Max gives bad support advice then we will confuse our customers and worst case leave them looking for solutions from PostHog alternatives.
- What we'll ship: This is a research piece that will outline a future framework for evaluating Max as a member of the support team.
- We'll know we're successful when: We have a clear route forwards on how we want to be testing Max's support output. We'll have a good understanding of how to feedback Max's performance on support and iterate to improve him.
Get SDK Doctor into active beta and collecting feedback from users
- Owner:
Steven ShultsSteven Shults - Rationale: Getting SDK doctor into active beta will help our customers understand if they are staying up to date with the latest version of our SDKs or if they are trying to call feature flags too soon. Having this in active beta will allow us to see how users respond (and address some feedback) before extending the functionality of SDK doctor.
- What we'll ship: We'll complete all beta prep including creating public documentation, getting the code reviewed by engineering, tightening up and extending our test cases, and generally shipping SDK doctor into an active beta state. We can also implement any feedback we receive from customers that we think is reasonable.
- We'll know we're successful when: SDK doctor is in active beta and feedback tickets about SDK Doctor are coming into Zendesk from customers.
Investigate and design a tool that will become our omnisearch and source of knowledge that we use while solving tickets
- Owner:
Ben LeaBen Lea, 
Ben HaynesBen Haynes - Rationale: Having better AI tooling and search ability for support engineers makes us more efficient in diagnosing issues and answering support tickets.
- What we'll ship: Do investigation into approaches we can take to create this tool (whether we use a third party or something homegrown). Design and implement a minimum prototype of this tool that can be used by the support team.
- We'll know we're successful when: We have a design for this tool and have a prototype we can build on.
Design a tool that helps us to troubleshoot customer implementations of PostHog
- Owner:
Kyle SwankKyle Swank - Rationale: Having better tooling for support engineers makes us more efficient in diagnosing issues and answering support tickets.
- What we'll ship: Design a tool (we'll consider browser extensions, using the toolbar, implementations in PostHog, etc) which helps support engineers to more easily troubleshoot customer's implementations of PostHog. Consider two of the most common things we as support engineers need to surface from a customer's implementation when troubleshooting, and design a tool which can more easily surface these things.
- We'll know we're successful when: We have a design for this tool and have begun implementing a minimum functioning version of it.
Things 
Abigail RichardsonAbigail Richardson is focusing on this quarter:
- Implementing Support Zero weeks to enable the team to reach more of our quarterly goals
- Outlining a strategy for SMEs and how we get there to enable the team to deal with the rising complexity in tickets
- Outlining a strategy for products coming out of beta and into support
- Outlining a strategy for community support
- Hiring and onboarding to improve support coverage
- Improving reporting, especially on coverage and where tickets come from