A résumé shows you the rung someone is standing on. It tells you nothing about how fast they are climbing — and only one of those compounds.
On paper, I was rarely the obvious choice. What the people who bet on me saw wasn’t in the résumé — it was leadership: the instinct to reach for a problem a level above the one I’d been handed, and grow into it. The slope was in how I led, not the title I held at the time.
So when I evaluate someone now — for a hire or a promotion — I look for exactly what someone once saw in me. I hire for something a résumé doesn’t show: slope. The rate at which someone climbs, not the rung they happen to be standing on today.
Position is a snapshot. Slope is a trajectory.
Position is where someone is now: title, years, current scope. It is easy to measure, which is exactly why we over-weight it.
Slope is how fast they have been getting better. And unlike position, it compounds. A high-slope engineer two levels “below” a plateaued senior will pass them, often inside a year.
So I try to measure the derivative, not the value.
Hire for slope, not position.
This is not an argument for hiring juniors
It would be an easy misreading — that slope is a licence to bet on inexperience because it is cheaper and more malleable. It is not.
A steep slope on a low base still takes time to cross the line that matters, and some roles have no tolerance for the crossing period. If a system will fail badly at three in the morning, you need someone who can hold it tonight, not someone who will be excellent at holding it in eighteen months.
Position tells you what a person can carry today. Slope tells you what they will be carrying in two years. Both readings are real. The error is not using position — it is using position only, and mistaking a snapshot for a forecast.
You cannot coach someone into a bigger mind. You can hand them a bigger problem.
You do not grow people mainly by giving them more support. You grow them by raising the problem altitude — the height at which a problem forces them to think.
Give someone a problem one level above the mental model they currently hold, and they either build a bigger model or they do not. Support helps them survive the climb. It does not cause it. The altitude does.
And altitude is not workload. More tickets is not a bigger problem; it is the same problem more times, and it produces tiredness rather than growth. Altitude is when the shape of the problem exceeds the model someone is holding — when they cannot solve it by working harder in the way they already work.
Concretely: hand the mid-level engineer the on-call for a system whose failure modes they do not fully understand yet. Let the strong individual contributor own the design review they would normally just attend.
The productive discomfort is the mechanism.
The work you cannot see is the work that matters
When you raise someone’s problem altitude, watch what grows first. It is usually invisible.
Not the visible execution — the code shipped, the ticket closed — but the invisible work underneath it. The sense-making. The anticipation. The quiet “what could go wrong here” that a good engineer does before anyone assigns it.
If a team only ever rewards the visible, it slowly starves the thing that produces it.
The instinct is to fix that by measuring it. Resist that instinct. The moment invisible work becomes a metric it becomes theatre, and you get performances of foresight instead of foresight. You reward it by naming it out loud, specifically, in front of the people whose opinion the person cares about: the reason that launch was uneventful is that you found the failure mode in week two.
Said once, precisely, that does more than a scorecard ever will.
Make the stretch safe: conviction with a review date
Raising problem altitude can sound like throwing people in the deep end. It is not — if you do one thing.
Frame the stretch as a conviction with a review date: “I believe you can own this. Let’s check in three weeks and decide honestly whether it’s working.”
Committed enough to be real. Dated enough to be safe.
The date is not a soft way of hedging the bet. It is what makes the bet payable. Without it, a stretch that is not working has no honest exit — so it either quietly fails for months, or it gets rescued in a way that teaches the person they were never really trusted. The review date lets you both say “this isn’t landing” without it being a verdict on them.
What this means for how you hire and grow
In interviews, probe the change rather than the endpoint. What someone was doing three roles ago against what they are doing now tells you more than the current title — and the gap between those two points is the only slope evidence a CV actually contains.
Then give the assignment that is one level too big, deliberately, and say out loud that it is. People rise into stretch far better when they know it is a stretch and not a test they were expected to already pass.
Name the invisible work when you see it. Attach a review date to every stretch you hand out.
The T in CTO was never only about architecture. It is also about building the people and the operating habits that let good architecture keep getting built long after you have moved on.