Development plans
What we are working on, and from where.
A development-plan item names a dimension, carries the evidence it came from and the exercises to address it, and freezes the metric baseline at the moment it was created. Improvement is then measured against that frozen starting point rather than a number that moves under you.
How it works
Two axes that never touch, and an original that is never lost
The commonest failure in a coaching tool is conflating “the AI suggested it” with “the manager agreed to it”.
The manager axis
Active, completed, archived. This is the work: what is being coached right now, what has been finished, what has been put down.
The confirmation axis
Separately: unconfirmed, confirmed, edited, overridden or dismissed. An unconfirmed AI suggestion is never shown to the rep. It is a proposal until a human says otherwise.
The original is kept
Whenever a manager edits or overrides a suggestion, the original is preserved permanently alongside it and every change is appended to a history. You can always see what was proposed and what was actually agreed.
The baseline records why it is absent
Freezing a baseline is not one column. An item carries the metric it is judged against, the value at creation, the window that value came from, the sample size behind it, whether that sample was below the floor, whether the rep was ramping, and the version of the metric catalog in force at the time. Where there is no baseline at all the item says so and records the reason. That is what makes an item without a number still honest rather than merely empty — and it is why a later change to how a metric is defined cannot silently restate where somebody started.
In the product
A plan a rep can see, and a trail a manager can defend.
The mechanism
Two axes, nine baseline columns, and a loop written as it happens
The commonest failure in a coaching tool is conflating “the AI suggested it” with “the manager agreed to it”. Keeping those apart is the first decision here, and most of the others follow from it.
The axes are independent, and the rep has a third field of their own
One axis is the manager’s work: active, completed, archived. The other is the confirmation state: unconfirmed, confirmed, edited, overridden or dismissed, with hand-created items marked manual. They do not interact. An unconfirmed suggestion is never shown to the rep at all — it is a proposal until a person says otherwise.
Rep progress lives in its own field and never touches either manager axis. A rep saying they are getting somewhere while a manager still has the item active is not a contradiction for the software to resolve; it is the conversation, and flattening the two into one status would delete it.
Freezing a baseline is not freezing one number
An item records the metric it is judged against, the value at creation, the window that value came from, the date of the snapshot, the sample size behind it, whether that sample was below the floor, whether the rep was ramping at the time, and the version of the metric catalog in force. Where there is no baseline at all, the item records that fact and the reason for it.
- A below-floor baseline is marked as such, so improvement against it is known to be weak evidence rather than assumed solid
- A ramping rep is flagged, because a new starter’s starting point means something different
- The catalog version travels with it, so redefining a metric later cannot silently restate where somebody began
- An absent baseline has a stated reason, which is what keeps an item without a number honest rather than merely empty
The original is kept, permanently
Whenever a manager edits or overrides a suggestion, the original is preserved alongside it and every change is appended to a history. You can always see what was proposed and what was actually agreed — which is the record that matters if an item is ever cited in a decision about somebody’s job. Where a suggestion names a metric that does not belong to that role, the metric link is dropped and the item survives without it, with the baseline recording that the metric was off-role.
The closed loop is written when it moves, not reconstructed later
A nightly process records each item’s progress through the loop: identified, coached, then improved or not landing, then sustained or regressed. Each move is written as its own row at the moment it happens, on the path where the move actually occurs — never inferred at read time by a service reading an item’s current state backwards.
Those rows are immutable at both layers: the model refuses an update or a delete, and an unconditional database trigger closes the query-builder route round it. A correction is a new transition. That the system once believed something else is part of the record rather than something tidied out of it. They are ordered by when the move happened rather than when the row was written, so a backfill or an import does not reshuffle somebody’s history.
Who it is for
For development that survives a manager change
A plan that lives in one manager’s head does not survive them moving team.
- Managers running structured development rather than ad-hoc advice
- Reps who want visibility of what they are being measured against
- HR and leadership who need a defensible record
Questions
The things people actually ask.
What if the AI suggests a metric that does not apply to that role?
The metric link is dropped and the item survives without it, with the baseline recording that the metric was off-role. Judging a BDR against an AE metric would be worse than judging them against nothing.
Can a rep record their own progress?
Yes, in their own field, which is separate from the manager status and never overwrites it. Both views coexist rather than competing. A rep saying they are getting somewhere and a manager saying the item is still active are not a contradiction to be resolved by the software; they are the conversation.
How do we know whether an item worked?
A nightly process records the loop for each item: identified, coached, then improved or not landing, then sustained or regressed. Each move is written as its own row at the moment it happens, rather than being reconstructed later by reading the item’s current state backwards, and those rows cannot be edited or deleted at either the application or the database layer. A correction is a new transition. That the system once believed something else is part of the record rather than something tidied out of it, and the rows are ordered by when the move happened rather than when it was written down, so a backfill does not reshuffle somebody’s history.
Do managers have development plans too?
Yes. Manager-level items exist with the same structure, and the owner can coach managers through them.
Make the plan something both people can see.
A development plan the rep has never read is an appraisal note with a friendlier heading.