1. The Limits of the 10x Engineer Myth

• Core message: Even the fastest rocket misses its target if it's pointed in the wrong direction. Product development is no different. "If a rocket is aimed the wrong way, no amount of speed will get it to the destination. The same is true for a product — and the team behind it."

• The 10x engineer is idealized for raw technical ability, but focusing on the wrong problem doesn't multiply your chances of product success by 10x.

• At PostHog, engineers define the product's direction. "We're structured so that engineers set the roadmap and goals themselves, and own them end to end."

2. The Topic: What PostHog Looks for in a Product Engineer

2-1. A Bias for Shipping and Iterating

• PostHog prefers shipping and improving over planning and polishing.
• Engineers need to be comfortable with:
  • Building MVPs (minimum viable products) and prototypes
  • Shipping before things feel ready
  • Collecting user feedback and fixing problems
  • Killing or pivoting features that aren't working

"It's more important to ship and iterate than to polish a feature to perfection."

• In other words, engineers need full-stack breadth — infrastructure, scalability, usability, design — to take a product from zero to done.
• Because PostHog doesn't have dedicated PMs or designers by default, engineers must operate autonomously across all of these dimensions.

Real example: Robbie Coomber's web analytics tool

• The first version was extremely simple, but "He then went on to add proper visualizations, automatic scroll-depth capture, user feedback, query performance optimization, sampling tests, and more."

"It started out really simple, but reaching beta required full-stack capability across the entire stack."

• Key concepts: MVP, fast shipping, user feedback, full-stack breadth, autonomy

2-2. Writing and Async Communication Skills

• PostHog is a remote, async-first company, so most communication happens in writing.
• Why writing matters:
  • Writing issues before new features, and documenting afterward
  • Writing clear PR descriptions and review comments
  • Using RFCs (Requests for Comments) to debate big decisions
  • Recording processes in the handbook

"Good writing shows clear thinking, documents what matters, cuts down on meetings, and keeps things moving fast."

Real example: Team Pipeline's RFC

• Ted led discussion on a complex, multi-team issue (event splitting, data quality improvements, etc.) with two RFCs over 1,500 words each and comments over 2,000 words.

"When you're making decisions this complex, you need people who can communicate clearly in writing."

• Key concepts: async, writing, documentation, RFC, clear communication

2-3. What Drives You: Money vs. Mission

• Engineers broadly fall into two camps:

  1. Those who work for money
  2. Those who are passionate about the work itself and the mission

• PostHog wants the second type.

  • "We want drivers, not passengers. We look for people who generate ideas themselves and see them through."
  • "We want people who want to be part of the journey and seize the opportunity."

• Key concepts: initiative, mission-driven, intrinsic motivation, side projects, open-source contributions

2-4. User Obsession and the Ability to Find Problems

• Product engineers interact with users far more often than typical engineers.
  • User interviews
  • Recruiting testers and collecting feedback
  • Customer support and issue response

Real example: Eric's data warehouse

• Eric set his goal not as feature count or usage numbers, but as securing 5 reference customers.

• "He went directly to potential customers to understand their needs, and used a survey to select the initial connectors (Stripe, Hubspot, Postgres)."

• What to avoid:

  • "Being fixated on having the right answer, or sticking only to the way things have always been done. So is endlessly researching and planning while delaying the actual launch."

"Customer obsession is what ensures we build products that real people actually want."

• Key concepts: user interviews, customer obsession, problem discovery, fast iteration

2-5. Seeing the Big Picture and Making Data-Driven Decisions

• Teams autonomously decide their roadmap, goals, and how to implement.
• Skills needed to make the best decisions:
  • Analyzing feedback, usage data, and benchmarks
  • Competitive analysis (features, pricing, etc.)
  • Choosing the right success metrics
  • Understanding infrastructure and scalability

Real example: Manoel and Paul's mobile replay

• They researched competitors and collected feedback, then wrote a detailed spec covering client lifecycle, API requests, data structures, rrweb compatibility, and more.

"Seeing the big picture enables better long-term decisions. A narrow view leads to missed opportunities and problems down the road."

• Key concepts: data-driven, competitive analysis, systems thinking, long-term vision

2-6. Being Easy to Work With and Bringing Positive Energy

• PostHog operates with high autonomy and a lot of peer feedback, so "being easy to work with" matters enormously.
• What to avoid:
  • Self-promoters who job-hop every year just to pad their resume.

Real example: Collaboration through PRs

• "At other companies, people hand work off to others. Here, we solve things ourselves and open a PR. It's okay to be wrong — it's much easier to revise a PR than to build from scratch."

"Someone who's difficult to work with creates tension and conflict, and can have an outsized negative impact on everyone around them."

• Key concepts: collaboration, positive attitude, self-driven, teamwork, receptive to feedback

3. Why PostHog Looks for This — and What It Produces

• Hard to find, but worth it.

  • "We can optimize for speed with small, autonomous teams."
  • "With minimal hierarchy and management overhead, everyone can focus on the highest-value work."
  • "4x growth last year, with only 3 new hires."

• "We believe talent compounds. Finding someone with both top-tier technical skills and all of these traits is harder — but it's worth it."

4. Further Reading

• Andrew Bosworth (Facebook CTO), Traits I Value: Ownership, bias toward action, scalability, and more — a lot of overlap with what PostHog looks for.

• Abi Noda, What Separates Great Software Engineers: Beyond coding ability: maximizing present value, making good decisions, and continuously learning.

• Charles Cook, What Startup Recruiters Actually Look At: PostHog received 9,000 applicants in a single year — here's how they evaluate candidates and what sets people apart.

5. Conclusion

• The engineer PostHog is looking for isn't simply a "10x engineer" — they're someone who combines:
  • Speed and iteration,
  • Writing and communication,
  • Passion for the mission,
  • User obsession,
  • The ability to see the big picture,
  • And being genuinely easy to work with.

"Our culture and our growth are themselves proof that finding people like this is worth the effort."

Summary by: Ian Vanagas (someone who really loves writing) ✍️