PSHE — Problem, Solution, How, Execution
Level people by how much of the problem-to-execution chain they own, not by scope.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 92%
PSHE is a talent-evaluation ladder built to replace scope as the leveling axis. Junior people are handed the problem, the solution and the how, and are judged only on execution. As people grow, ownership moves left along the chain until, at the top, they tell you which problem is worth solving. It works for product managers, engineers, designers and salespeople alike.
Origin
The PSHE acronym comes from Mehrotra's old boss at Microsoft (referred to in the transcript as 'Button Clark'). Mehrotra revived and codified it at Google in 2011, after Larry Page reorganised Google from functions into eight product units and the product-management function was at risk of losing a shared definition of quality. Mehrotra was elected to lead the effort and had to write the calibration-committee speech previously given by Jonathan Rosenberg.
Core principles
- 01Scope is an input, not an output — you gave the person that scope, so judging them on it judges you.
- 02Scope isn't comparable across teams (Search is one product; Ads has dozens of P&L'd SKUs).
- 03A scope-only ladder actively disincentivises your best people from taking risky, cancellable, creative bets.
- 04Growth is not linear: early careers grow on scope, late careers grow on scope again, but the middle is all PSHE.
- 05A level 3 and a level 7 may do the exact same job — the difference is how they do it.
- 06P-thinkers (problem-spotters) are strongly correlated with eigen-question ability.
- 07PSHE is role-agnostic; the same ladder applies to sales, engineering and design.
How to run it
- 1
Define the four rungs explicitly
E — given problem, solution and how, execute the playbook with precision. H — given problem and rough solution, own the how: milestones, org, go-to-market, meetings, rituals. S — given the problem, generate the solutions; judged on creativity and effectiveness. P — bring the problems: 'you told me to work on activation, but I think our real issue is brand.'
- 2
Plot people on two axes: scope and PSHE
Draw scope on one axis and PSHE on the other and place your team. The curve is not a straight line — early careers move mostly along scope at the E level, late careers move mostly along scope at the P level.
- 3
Name the middle of the curve — the trough — and manage it deliberately
In the middle, the slope changes and evaluation stops being about scope. This is confusing for the employee (everything since high school has rewarded scope) and confusing for the calibrator. Say so out loud, and give both sides the PSHE language for what is now being measured.
Pro tip Explicitly tell people in the trough: 'we're no longer judging you on how big your thing is; we're judging you on how much of P-S-H-E you own.'
Watch out Leaving this transition unnamed is the single biggest source of confusion and perceived unfairness in calibration.
- 4
State your company's preference order — internally
Mehrotra values P over S over H over E. But the order is a choice: some industries and cultures legitimately want E-weighted people who execute a given job superbly. Pick it consciously and let it drive hiring, promotion and role design.
Watch out Never reveal your preference order to a reference or a candidate. If they know you value P, they'll tell you the person is a P.
- 5
Apply the ladder to non-product roles
Test it on sales. Quota attainment is a poor signal — it mostly measures how well someone negotiated their quota and picked their territory. Ask the sales team who is actually best and they describe a P/S thinker: 'she can sell anything, growing region or shrinking, new product or old.'
Pro tip Whenever a role has a convenient headline metric, assume that metric is an input someone negotiated, and re-derive the judgement in PSHE terms.
In the wild
Mehrotra printed Google's PM level guide, cut it into one slice per level, removed the titles and numbers, and handed the slices to the eight product leaders asking them to reverse-identify which level each was. Nobody could. The guide had accreted whatever each era wanted to incentivise — 'manages a medium-sized project', 'interviews at least three people a week', 'sends notes out on time', 'expense reports are always fine'. Laid side by side, the only statement that ordered them cleanly was scope.
→ They standardised on scope (feature → group of features → sub-area → multiple sub-areas → product → product line) and it failed within two weeks: Search vs Ads made scope incomparable, scope turned out to be an input not an output, and the best people on risky projects had odd scope and were being penalised. That failure produced PSHE, which stuck and is still the leveling basis at Coda.
A common profile: a product manager whose counterparts adore them. Meetings run beautifully, communication is always clear, everything is buttoned up, sales and the market always know what's happening. In a reference check you then ask: when you're deciding which problem to solve, who leads that? When there's a hard problem, who reliably has the best solution?
→ A surprising number of references answer 'actually the designer picks the problems' or 'the CEO tells us what to do' — revealing a strong H who is neither a P nor an S. Not a disqualification, but it is what you're actually hiring, and it is nearly impossible to detect in an interview and nearly trivial to detect in a reference check.
Common mistakes
Leveling on scope
Scope is an input you handed the person, it isn't comparable across teams, and rewarding it punishes anyone on a risky, unproven project — which is usually where your best people are.
Letting the level guide accrete whatever you currently want to incentivise
Google's guide ended up mixing 'manages a medium-sized project' with 'expense reports are on time'. The result was a document from which nobody could reverse-identify a level.
Mistaking a great H for a great P
Efficient meetings, clean comms and a well-run process are highly visible and highly praised, which makes an H look like the strongest person on the team. Test explicitly for who picks the problems and who cracks the hard ones.
Is it for you?
Best for
Company or function leaders building a leveling ladder or calibration process, especially where scope-based promotion is causing turf disputes or penalising risky bets.
Not ideal for
Highly proceduralised industries where deviation is a hazard and the job genuinely is to execute a given playbook flawlessly — there, an E-weighted ladder is the right one.
From the transcript
“it stands for problem solution how execution”
“you get handed a problem you get handed a solution you can handle the how”
“at some point you're senior enough that you tell us the problems”
“the second issue was they said the scope is actually an input not an output”
“in the middle the the slope changes and all of a sudden it's not really about scope it's about psat”
“by the way i will say i value p over s over h over e”
From the episode
The rituals of great teams
Shishir Mehrotra of Coda, YouTube, Microsoft