Performance and growth
Growing people and handling performance problems are the parts of the manager's job with the biggest effect on someone's life. This lesson gives you a method for both: read a career ladder, build growth plans and reviews from evidence, make fair promotion cases, and handle underperformance early, specifically and supportively.
By the end you can
- Read a career ladder by scope, impact, autonomy and influence, and turn it into a growth plan
- Write a performance review from evidence collected all year, and defend it in calibration
- Build a promotion case that shows work already done at the next level
- Handle underperformance step by step: notice, clarify in writing, find the cause, support, document
- Know when HR and a formal performance improvement plan come in, and why local law matters
The everyday picture
A good youth football coach keeps a small notebook. After every training session she writes two lines about each player: what they did well, what they struggled with. At the end of the season, when she picks who moves up to the older team, she reads the notebook. She doesn't pick the boy who scored twice in the last match. She picks the girl who has been organising the defence for six months, because that is what the older team needs.
When her best striker stops scoring for a month, she doesn't drop him. She asks him what's going on. It turns out the team changed formation and nobody told him he now plays wider. And his grandmother is in hospital. She explains the new position on paper, gives him a few weeks, and checks in after each match. He is scoring again by the end of the month. Evidence over time, clear expectations and a curious first question: that is most of this lesson.
Career ladders: what a level really means
A career ladder (also called a career framework or levelling guide) describes each level of a job. Good engineering ladders describe levels by the reach of a person's work, not by tasks or years. Four dimensions show up in most of them:
- Scope: how big a piece of work the person owns. A task, a feature, a system, several teams' systems.
- Impact: what changes because of their work. Their own work done well, a feature people rely on, the team's outcomes, outcomes across teams.
- Autonomy: how much direction they need. Told how, told what, sets the approach, finds the problems worth solving.
- Influence: whose work gets better because of them. Themselves, peers in the team, the whole team and its neighbours, the wider engineering group.
Here is the ladder Ken's group uses at Mangrove for engineers on both of your teams. QA, data and DevOps engineers use the same four rows with their own examples.
| Row | Junior | Mid-level | Senior | Staff |
|---|---|---|---|---|
| Scope | A task | A feature, end to end | A system or project | Systems across teams |
| Impact | Own work done well | A feature users rely on | The team's outcomes | Outcomes across teams |
| Autonomy | Needs guidance on how | Decides how, asks what | Sets the approach | Finds the right problems |
| Influence | Self, pairing | Peers in the team | Team and neighbours | Engineering group |
Two engineers can write equally good code and sit at different levels, because the difference is in the other rows. Read a ladder row by row, never as one block. A person is rarely at one level on every row; a typical mid-level engineer is mid-level on scope and autonomy, and already senior on influence because she mentors everyone.
A growth plan turns the ladder into action. With the engineer, mark each row: where they are, with evidence. Pick one or two rows to grow this quarter, never all four. For each row, name a real opportunity in the team's work (a stretch assignment), the support you will give, and how you will both know it worked. This builds on delegation from Delegation and mentoring: the stretch assignment is delegated ownership, with you as the safety net. Review the plan every month in your 1:1s (1:1s, feedback and coaching), and rewrite it each quarter.
Above senior, most companies split into two tracks: staff and principal engineers on the individual contributor track, and engineering managers on the management track. Management is a different job (The manager's job), so a growth plan for a strong tech lead like Sam can include a small, safe test of each before he chooses.
Quick check
Hugo and Nell both write clean, well-tested code. Nell is senior and Hugo is mid-level. On the ladder, what most likely separates them?
Levels differ by scope, impact, autonomy and influence, so the gap shows up in what Nell owns and whose work she improves. Volume of code measures activity, not level. Years in the job often go with growth, but a ladder rewards what someone does, not how long they have waited. Knowing more languages is a skill, not a wider reach.