The map
Read it top to bottom. The left lane manages numbers, the right lane manages people, and the middle is what stops both from rotting into stale documents. The bottom band is where the two lanes literally meet.
One quarter through the machine, at Lawhive
The same map, played as one Lawhive quarter. The goals are our real ones and the squads are ours; which squad owns which number is illustrative, since deciding that is the workshop's job. Press play, or step through with the arrows.
The frame: one org, two axes
Before either loop, the model fixes the org shape. Everyone belongs to two structures at once. Departments group product teams around a business outcome and are accountable for results. Functions group people who share a craft (engineering, product, design, data) and are accountable for talent quality: the Head of Function owns the competency matrices, the hiring process, and mentoring for that craft, usually as an add-on to their day job.
The delivery unit is the product team: 6–10 people, full-stack (engineers, designer, data, ops as needed), led by a Product Owner who is accountable for the product end to end, the playbooks say "like a mini-CEO". Teams are given goals, not roadmaps, and are free to choose their own path to the number. Each layer appeared as a fix for a scaling failure: product teams at ~25 people (functional teams kept blocking each other), departments at ~50 (information silos), functions at ~150 (hiring standards slipped when POs hired under deadline pressure).
| Function ↓ · Team → | LEX | BOS | Platform |
|---|---|---|---|
| Product | Product Owner | Product Owner | Product Owner |
| Engineering | Engineers | Engineers | Engineers |
| Design | Designer | Designer | · |
| Data | Analyst | Analyst | Analyst |
Career progression runs on seniority levels, not job titles. A promotion moves you up a level, raises expectations and pay, and usually changes nothing about your title. The standard ladder:
The goals loop, concept by concept
The unit of the loop is the KPI, and the preferred kind is a database query that updates itself, with an initial value, a current value, a target, an owner, and a weight agreed one level up. Because the value comes from the warehouse, a review meeting argues about causes, never about whose spreadsheet is right.
- Summary
- Cut blended CAC to $20 per user by 31 Dec
- Measured by
SELECT …auto-refreshes at least every 48h, returns a time series- Initial → target
- $30 → $20 (a "decrease" KPI; there are increase, decrease and maintain types)
- Weight
- 40% of the team's quarter, approved by the level above
- Owner
- One named person
- Parent
- The department or company goal it adds up into
Every KPI passes a quality gate before the platform accepts it: an automated checklist scores the definition, and anything under 80% is rejected. The checks are the interesting part, because each one closes a known way of gaming goals:
"Output, not activity" is the check doing the most work: "increase engagement per post by 10%" passes, "publish 10% more posts" fails. The ambition rule of thumb: a target is pitched right if teams reach 70% of it about 90% of the time.
The cascade is the relationship that makes the whole thing an architecture rather than a metrics pile. Company goals split into department goals, those into team KPIs, and ideally the lower levels sum to the level above (teams can also propose bottom-up KPIs). Here it is worked on our shape, tracing one of the four 2026 strategic priorities: Product & Engineering as one department beside the service departments, then down to product squads and service teams. Product teams get automation, cost and revenue goals; service teams get operational ones (SLAs, NPS). Every owner and target is illustrative; the real mapping is the workshop's decision:
Read it as sums: the department row should add up to firm profitability, and each column to its department goal. Compliance, People and the other departments get the same treatment. Note the split: the product squads carry automation and cost goals (cost-to-serve per case is one of the two metrics the town hall said all work serves), while the service teams carry operational ones.
Two more goals-side concepts. A milestone is a department's quarterly pass/fail commitment ("launch X in market Y"), always mapped to the KPI it advances, at most five per quarter. And the locked quarter: once planning closes, the quarter's epic can't be edited, so at review time performance is measured against what was actually committed. Goals are revised downward only in exceptional circumstances.
The cadence that reads the numbers
The meetings are what consume the numbers, and the same few formats run identically at every level: the CEO runs them with Heads of Department, an HoD runs the same ones with Product Owners, a PO with their team.
The business review is review by exception: the dashboards are live, so nobody presents status. The leader double-clicks on red flags only, and the meeting ends when there are no more red flags. A serious one can spawn a Project More: a temporary cross-functional task force with a weekly cadence that attacks one problem and then dissolves.
The product review has a hard entry gate: an item cannot be discussed unless its problem statement carries quantifiable evidence and a numeric target relative to the current value, with comparators for the proposed solutions. It runs two tiers, a low-fidelity round that filters which ideas deserve more design investment, then a high-fidelity round that approves for build. Teams can start building off a lo-fi approval, which is how the model avoids blocking engineering on polished mocks.
The people loop, concept by concept
A role is a bundle of 3–4 skills: a Data Analyst is data analysis + data manipulation + problem solving, wherever they sit. Each skill has a scorecard: a checklist of yes/no statements about observable behaviours, grouped into five levels from Poor to Expert. "Provides recommendations for major business decisions, with demonstrated examples" is a scorecard line; "is a strong analyst" is not. The first statement you can't tick marks your level.
The competency matrix stacks those skills against seniority: the minimum level required per skill, per level. That minimum is the talent bar, and it is the single definition of "good" for the role. The same artifact is used three times: hiring interviews score candidates against it, quarterly reviews score employees against it, and promotion means clearing the next level's bar. Because it is one artifact, what we hire for, what we assess, and what promotion means cannot drift apart.
The quarterly grade, and what hangs off it
Each quarter, the line manager scores every report's proficiency on three dimensions: deliverables (speed, quality and complexity of what they shipped), skills (the role's competency matrix, often scored by the functional manager who actually shares the craft), and culture (a scorecard per company value; a Poor in any single value floors the whole culture score). Employees self-review as input; upward reviews exist but don't move the rating.
Performance is proficiency relative to the bar, never an absolute score, which is what the chart above shows. The distance from the bar buckets everyone into five grades, and the target distribution is enforced:
Calibration is why the distribution holds. Managers grade generously, so the Performance Team challenges outliers and missing data each cycle, and a Remuneration Committee (founders, the head of performance, a board member) signs off final grades, promotions and bonuses. Revolut trialled 360 reviews and dropped them: peers rated each other too generously to be useful.
The grade then drives everything downstream. Promotion is triggered, not requested: a year in the level plus 2 Strong grades in the last 4 reviews (4 of 4 above Mid) and no bad grades makes you eligible; the manager writes 3–5 evidence cases; pay auto-matches the new level's benchmark. Pay reviews are mostly automatic too: promoted and repeatedly-Strong employees get matched to benchmark without negotiating. The bonus multiplier is the deliberately exponential part: 0× below bar, 0.5× above bar, 3× Strong, 5× Exceptional on the individual component, blended with the team's KPI achievement. How hard to turn each of those dials is a values decision, not a mechanical one; that is the question the brief reserves for Pierre.
The spine: one platform, plus police
The playbooks are explicit that none of this survived as documents. It survived because it was operationalised in tooling: PeopleOps, Revolut's internal platform, holds every KPI, scorecard, review and roadmap, pulls KPI values from the data lake, and refuses non-compliant entries (the 80% quality gate is a form validator, not a policy memo). Before PeopleOps existed they used Metabase plus a governance layer, so the tool matters less than the single-source-of-truth property. Revolut People, the product Matt and I trialled, is PeopleOps productised.
This is also where Pierre's telemetry question lands. The load-bearing property is that goal progress is measured from system data, not self-reported. For us that means deciding what v3 must emit as firms onboard, so squad and firm goals can be queries against the warehouse (the dbt → BigQuery layer already carries the company-level numbers) rather than judgement calls in a review meeting.
And the enforcement half: the Performance Team. A handful of high-achieving generalists (Revolut started with three), deliberately outside HR and reporting to the CEO. They run the goal-setting calendar, audit KPI quality in every department with no opt-out, run the review and promotion cycles, and do the calibration analysis. The playbooks' theory of why this works is that performance is treated as a direct CEO priority rather than as a People-team programme.
Where the working group's five decisions land
The brief scopes five decision areas. Each one is a region of the map above, and each comes down to one core question:
The goals loop: cascade levels, KPI standards, quarterly cadence, ownership and weights.
Decide: how many levels we cascade through, who owns each, and what our quality gate checks.
The right half of the people loop: dimensions, grades, calibration, frequency.
Decide: what we assess (goal contribution, competencies, values), who calibrates, and how often.
The spine's single-source-of-truth property: goals measured from real system data.
Decide: what v3 must be instrumented to emit as firms onboard, so goals are queries, not opinions.
The frame: departments × functions, role definitions, seniority levels, competency matrices.
Decide: our function list, our role list, and how deep the ladder goes at our size.
The spine's platform half, plus sequencing.
Decide: whether Revolut People is the vehicle, what the pilot covers, and in what order the pieces land.
Forced-distribution hardness, how exponential comp gets, how fast the Below-bar Choice is offered. The mechanics above work at gentler settings than Revolut ran them.
These are values calls, and the brief reserves them for Pierre.
Going deeper
The working group's curated reading (45–60 min, routes by role) is mirrored in the Notion reading space; the full library is at docs.quantumlightcapital.com. The session plan and scope are in the working-group brief. Session 1 includes a live walkthrough of the trial workspace, which instantiates everything on this page for Product & Engineering: the real org, a goal cascade with owners and weights, scorecards, and a review cycle with calibration.