James Hawkins - co-founder & CEO of PostHog
PostHog reached 100,000 users before hiring dedicated support and now runs eight product teams with fewer than 50 people. James Hawkins credits engineers who notice when the metaphorical hoovering needs doing — then decide what to build themselves.
James Hawkins is the co-founder and CEO of PostHog, the platform for engineers to analyze, test, observe and deploy product changes. In his second appearance, the conversation is mostly about the unconventional way the company operates.
We cover autonomous product teams, a public company handbook, removing default product-management and design handoffs, learning whom to listen to, letting engineers pursue ideas that initially sound wrong, and why fun becomes a serious advantage when you want to build for decades.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does your 'mental workload of hoovering' analogy reveal about hiring?
Doing the hoovering quickly when instructed is different from noticing that it needs doing and taking responsibility for the house. We look for the second mentality. If most people in a growing company independently notice and own what needs attention, the organization can run in a distributed way and founders have space to think about strategy, hiring or fundraising rather than issuing every instruction.
How does the public PostHog handbook help the company operate?
When a specific problem appears, we try to solve the general class of problem. If somebody requests a three-month sabbatical, we do not invent a one-off answer only for them; we decide the company's philosophy and write it down. The next case starts with an established principle, which can still be revised if experience shows it was wrong.
Why are you trying to minimize one-to-ones and other coordination?
Our competitive need is speed. With roughly 47 to 50 people we had eight products, each competing with companies that might have hundreds focused on one. We model each multidisciplinary team as a small startup that can ship without outside permission. Like a YC batch, the ratio of autonomous, intrinsically motivated builders to products can be extraordinarily high when ownership stays close to the work.
How do engineering-led teams avoid building products nobody wants?
We hire product engineers who are comfortable talking with users, and we choose categories where demand has already been proven externally rather than inventing an entirely unfamiliar object. Teams ship private previews, then opt-in previews and gradual releases, using PostHog's own tools to observe them. Engineers handle customer problems directly; we passed 100,000 users before hiring dedicated support and had more than 170,000 with a support team of two.
How did PostHog find its ideal customer profile?
It took years. Open source produced noisy demand from tiny restaurants, international banks, YC startups, marketers and product managers. As cloud quality improved, the answer became developers building new digital products, whether inside a large or small company. Other roles still use PostHog, but developers select and implement the tooling, so pricing, marketing and sales optimize for them instead of trying to serve every observed user equally.
What does it mean that a larger user base lets you 'see around corners'?
Users wanted to export product data to warehouses so they could join it with revenue data. We watched rapidly growing customers go from tiny bills to hundreds, then thousands and in one case roughly $50,000 a month, before leaving for a warehouse. That showed us the customers we most wanted to retain would naturally outgrow us, so we built a warehouse for fast-growing teams. Early-stage questions are existential; later, a large community narrows them to choices such as which SDK to build next.
How did session replay change the company?
An engineer built it during a hackathon even though I thought recordings felt invasive and outside product analytics. Our rule was that if he wanted to build X while I preferred Y, we built X, because enthusiasm produces better work. Usage arrived immediately. When we later priced replay as its own product, customers treated it more seriously, sent harder feedback, and usage, quality and revenue all increased. It revealed that an integrated multi-product platform could be our differentiation.
How do you respond when an engineer proposes something that sounds like a bad idea?
Marius proposed HogQL, a translation layer between the front end and ClickHouse, and heard dozens of reasons it would fail. He stayed up until 3am for three nights, returned with a working version, and after months of production work it transformed how we build visualizations. Organizations default to 'no, but,' exhausting anybody who risks an idea. We try to create a 'yes, and' culture where new ideas do not require consensus to be tried.
Why do you treat fun as part of business strategy?
A coach who had worked with more than twenty unicorn founders told us the people who built the biggest companies actually liked working in them. It takes a long time to create a huge business; if you hate the work, you will stop. Fun creates pride, raises the standard people can sustain and keeps strong colleagues from leaving. It is not required to build a big company, but it may be required to build a huge one.
Links & references
- James Hawkins's X ↗
- PostHog ↗
- The Mental Workload of Hoovering ↗
- Ray Dalio's Principles ↗
- James Hawkins's first Scaling DevTools interview ↗
This episode is brought to you by WorkOS.