PostHog

Teams own goals, roadmaps, metrics and user conversations.

How it works

Teams of six or fewer own goals, roadmap, metrics and user conversations together.

Why it is used

Keeps decisions close to information and users.

Trade-off

Risks duplicated solutions and product inconsistency.

Best fit

Organizations with modular product surfaces and strong individual ownership.

The driver is the explicit owner of decisions and progress.

How it works

Each meaningful piece of work has an explicit driver accountable for progress and decisions.

Why it is used

Reduces committee decisions and ambiguous ownership.

Trade-off

Decision quality can fall if the driver does not gather enough context.

Best fit

Work with many contributors but a single final decision owner.

Candidates do paid real work to generate hiring signal.

How it works

Candidates are observed by the team doing paid, work-like tasks.

Why it is used

Produces work signal instead of interview-performance signal.

Trade-off

Costs candidate time and a short sample cannot fully predict long-term performance.

Best fit

Knowledge work where output can be observed in a bounded sample.

Some product inconsistency is accepted in exchange for small-team speed.

How it works

Some integration and consistency debt is accepted to preserve local team speed.

Why it is used

Prevents central coordination from slowing every delivery.

Trade-off

Customer experience can fragment and later require platform investment.

Best fit

During discovery, with clear team boundaries and reversible decisions.

Technical customer-success pay includes a graduated, uncapped quarterly NRR bonus, a first-three-month guarantee and account-transfer rules. The 80/20 split is only a Q3 2026 handbook example.

How it works

Technical CSM pay separates fixed and variable components; a quarterly net revenue retention (NRR) threshold feeds a graduated, uncapped bonus. A first-three-month guarantee and measurement/credit rules for transferred accounts are defined separately. The living handbook gives an 80% base/20% variable split as a Q3 2026 example, not a permanent ratio.

Why it is used

Connects incentives to customer success while providing transition rules for new hires and inherited accounts.

Trade-off

Risks over-weighting revenue and unfairness from differences in account allocation.

Best fit

Technical customer-success teams with measurable quarterly outcomes and clear account ownership.

Engineers scaffold a new skill (a Claude-Code-style agent capability) under `products/{product}/skills/` with `hogli init:skill`, validate it with `hogli lint:skills`, and build it locally with `hogli build:skills`. On merge to master, CI automatically builds `dist/skills.zip` and publishes it to the `PostHog/skills` and `PostHog/ai-plugin` repositories, which PostHog Desktop and PostHog AI consume.

How it works

A skill is scaffolded and linted locally; merging to master triggers CI, which automatically publishes the package to two consumer repositories — there is no separate release step.

Why it is used

Publishing a skill is not a separate release step after code review; it is automatically attached to an ordinary PR merge by CI.

Trade-off

Skill quality depends on human review beyond linting; a poorly written skill can quickly propagate to two dependent products (Desktop, the AI plugin).

Best fit

Companies running their own AI agent/assistant product (a desktop app, an agent plugin) that want to keep extending it continuously.