Growth Kernel
The performance review cycle produces a development plan for every person, every quarter: where you stand, the target, the gaps, and dated outcomes. That instrument is right most of the time, and it should stay the default.
It has one failure mode. When the same growth target survives two plans without moving, the plan was never the problem, and writing a third one with sharper deadlines does not help. The repair is not more planning. It is going back to the diagnosis, which is the part that got skipped, because it is the only part that requires admitting something is not working.
This page is that instrument: a development plan built as Rumelt’s kernel, a diagnosis, a guiding policy, and coherent action. It is narrower and more expensive than the routine plan. Use it when you need it, not by default.
Which plan to reach for#
They are not rivals. One is the breadth instrument and one is the depth instrument, and the second usually starts life as a single row of the first.
| Development plan (review cycle) | Growth kernel (this page) | |
|---|---|---|
| When | Every review, every person | When one gap is blocking something concrete and has not moved |
| Scope | All seven attributes | One crux |
| Driven by | The self-versus-actual calibration | A diagnosis of why the gap persists |
| Asks | Where do you grow next? | Why is this not changing, and what would change it? |
| Output | Targets with dates | An approach that rules things out, plus actions that reinforce |
| Cost | Routine | A real piece of thinking, usually with the person’s lead |
The two tells that you need the kernel version:
- You can name what the gap is blocking. Not “they should be more senior” but “their lead cannot think long term because they are still the answer to every short-term question.” A blocked outcome is what makes a diagnosis findable, because you can ask why that specific thing is not happening.
- The same target has appeared twice without moving. Two quarters of “grow critical thinking” with no change is not a motivation problem and it is rarely an effort problem. It means nobody worked out why it was not moving, and a third round of the same target will produce the same result.
Neither tell is about how serious the situation is. This is not the escalation before an improvement plan; that is a different instrument with a different purpose. A growth kernel is for someone worth investing real thought in.
The gap is not the diagnosis#
This is the mistake that makes these plans useless, and it is easy to make because the two sound alike.
The gap is the distance between the two boxes. The diagnosis is underneath: an account of why that distance has not closed by itself, given that the person has been working here for months and nobody has been stopping them.
The test. If your diagnosis can be rewritten as “they lack X,” it is the gap wearing a diagnosis costume. Push one level down and ask why X has never been acquired. Usually the answer is that nothing in how they currently work has ever required X, which means the gap is self-sustaining and will not respond to being pointed at again.
- Not a diagnosis: “They do not have enough context on the system.” That is the gap.
- A diagnosis: “Nothing in how they work requires the context, so they have never had to build it. Tickets close without tracing the flow, and questions route to their lead, so the cost of not knowing is paid by someone else.”
The second one is useful because it tells you what to change: the routing, not the person.
Say which of the three it is, and say what the evidence is. Capability (they cannot yet), context (they have not been given the exposure), or appetite (they do not want the scope). These need completely different plans, and assuming the wrong one wastes a quarter. Most reads default to capability when the evidence only supports context.
Expect the diagnosis to implicate you. A genuine one often lands on the system rather than the person: the routing, the queue, the review turnaround, a norm nobody wrote down. If every diagnosis you write is located entirely inside the other person, you are probably not finding them, you are describing them.
The policy has to rule something out#
A guiding policy is the approach you have chosen. If every reasonable action is still allowed after reading it, no choice was made and you have written a slogan.
So write the exclusions explicitly, and include at least one thing you stop doing. That is usually the load-bearing exclusion, because the reason a gap persists is often that someone senior keeps absorbing its cost. If the lead keeps answering the questions, keeps pre-triaging the queue, keeps rewriting the doc at the last minute, the person never meets the problem the plan is about.
“What the lead stops doing” gets its own section in the template for exactly that reason. A plan where the person collects five commitments and the lead collects none has not been thought through.
Actions have to reinforce, not coexist#
Take any two actions and ask whether doing both makes each one more effective, or whether they merely both make sense. Coexisting is normal. Reinforcing is the point.
The quick check is subtraction: remove one action and see whether another one breaks. If you can delete any action without weakening the rest, it was a to-do item, not part of a strategy.
Name what would prove it wrong#
A real plan contains a claim about the world that could turn out to be false, and writing that claim down in advance is what stops the plan from being unfalsifiable encouragement. Name the observable, name the date, and name what you would conclude instead.
If the check fires, go back to the diagnosis rather than adding actions. Adding actions to a wrong diagnosis is how a plan becomes a list.
The four ways these go wrong#
Rumelt’s signatures, applied to people:
- Fluff. “Increase ownership mindset and drive proactive engagement.” Delete it and nothing is lost, which is how you know.
- Failure to face the challenge. The plan never says what is actually hard. It cannot be wrong, so it cannot be right either.
- Mistaking goals for strategy. “Reach senior by Q4” is a goal. The strategy is the part explaining why senior is available to them and how.
- Bad objectives. Eight growth areas, which means nothing was chosen. Choosing is the work, and a long list is how people avoid it.
The template#
Copy this into a doc per person. Keep it unlisted or private: it names someone and assesses them.
# Development Plan: [name] **Lead:** [name] · **Period:** [quarter] · **Drafted by:** [name], with [lead] **Status:** draft, to be shaped with [name] before it is final --- ## 1. Where they are What they do reliably, and where the boundary sits. Observed, with evidence, not adjectives. - ## 2. Where they need to be Defined by what it unlocks, not by a title. > [The thing that is blocked today, in one line.] - ## 3. The gap The difference, plainly. What they can do only once someone else has done a part for them. ## 4. Diagnosis _Why the gap is still here. Not what the gap is._ **[The load-bearing fact, one sentence.]** [Why it persists: what in the current setup is fully satisfied without ever closing the gap.] - **Capability, context, or appetite?** [Which, and the evidence for it.] - **Is it self-sustaining?** [Name the loop that keeps it in place.] ## 5. Guiding policy **[The approach, one sentence.]** What this rules out: - - - ## 6. Coherent action | # | Action | Owner | By | |---|--------|-------|-----| | 1 | | | | | 2 | | | | | 3 | | | | **Why these reinforce each other:** [Take any two. Does doing both make each more effective? Remove one: does another break?] ## 7. What [lead] stops doing - ## 8. Proximate objective **[One concrete outcome, with a date.]** [What "owns it" means here.] Checkpoints: - **[date]:** - **[date]:** ## 9. What would prove this wrong - If by [date] [observable], the diagnosis was wrong and the real issue is [the alternative]. - ## 10. Open before this is final - [name] has not been in the room yet. This is our read and it gets shaped with them, not delivered at them. -
A worked example#
An engineer’s PRs keep bouncing in review: too large, too many concerns at once. It has been the growth target for two quarters.
The gap is that they do not split work into small slices. The tempting diagnosis is that they do not know how, so the plan says “practise decomposition,” and two quarters later nothing has changed.
The actual diagnosis: review turnaround is two days, so batching is the rational response. Every small PR costs them the same two-day wait as a large one, so they hold work until it feels complete in order to pay that toll once. Nothing about their skill is load-bearing here. The incentive is.
The guiding policy: make the small slice cheaper than the batch. That rules out decomposition coaching as the primary move, rules out “split it if it gets big” as a rule of thumb, and rules out the lead reviewing in batches.
The coherent actions: the lead guarantees same-day review, they cap PRs at one concern behind a flag, and they pair on the first three splits. These reinforce: the guarantee is what makes the cap survivable, and the pairing is what makes the first cap achievable. Remove the guarantee and the cap is a punishment.
What would prove it wrong: if review turnaround drops to same-day for a month and the PRs stay large, the incentive story was wrong and decomposition skill is genuinely the issue. Then it needs a different plan, not a louder version of this one.
Notice where the diagnosis landed. It was not in the engineer.
Related: Rumelt’s Kernel, Performance Review Cycle, Leading People, Growing Your Reports, Diagnosis, Expectations