An engineer has spent nine months on the control software for a client's machine. The hardware is late, the client has changed an interface twice, and nothing has shipped. At appraisal time her manager has no demo to show and writes that she is average. She had quietly built the simulator that kept the whole team working.
Long projects with few visible milestones are hard to appraise. This guide shows a delivery head how to set goals that still mean something when the end is far away.
Why the usual annual goal fails here
A yearly goal such as deliver module X by March works when modules ship. On a long programme the module may not ship in the year at all. Product engineering firms see this often, as described on the product engineering companies page. If the goal is the delivery date, people are rated on factors like client decisions and hardware supply, which they do not control.
Choose proof points, not just deadlines
A proof point is a visible result that shows real progress before the final delivery. It should be something a colleague can check. It should also sit within the person's control or close to it.
- A subsystem that passes its integration test against the simulator.
- An interface document that the client has signed off.
- A test harness the team now uses every day.
- A design review closed with all major comments answered.
- A risk that was open at the start and is now retired with evidence.
Each engineer should have three to five proof points for the year, placed across the quarters. Spread them so that no quarter is empty.
Add leading signals the reviewer can read
Between proof points, look at signals that show whether work is healthy. Do not turn these into targets, since people will then chase the number. Use them as conversation prompts.
- Quality and clarity of code or design reviews, given and received.
- Defects found early versus late in the programme.
- Whether risks are raised in writing, with options.
- How well the person documents decisions for others.
- Help given to colleagues on the programme.
A simple routine for the year
- 1
Set the proof points in the first month
Write them together with the engineer. Say what is in their control, what depends on the client and what depends on other teams.
- 2
Hold a short monthly check-in
Fifteen to twenty minutes. Ask what moved, what is stuck, what the person needs, and whether a proof point must change.
- 3
Write one paragraph after each check-in
Date, progress, blockers and any change to the plan. Share it with the engineer so that both hold the same record.
- 4
Run a mid-year reset
Review proof points against the real programme plan. Drop, move or add one, and record why.
- 5
Build the year-end review from the notes
Quote the paragraphs. The rating then rests on what happened and not on the last month.
Date and programme phase.
Proof points moved since last check-in.
Proof points at risk and the reason (own work, client, other team, supply).
Decisions the engineer made and how they were documented.
Help the engineer needs from me.
Change to goals, if any, and who agreed it.
One thing done well this month.Separate what was in their control
When the client changes scope or hardware arrives late, the plan moves. The review should say so plainly. Write a line for each major disruption and its effect. Without this line, the reviewer later reads a slow year as a weak year. A fair note does not excuse poor work. It shows the reader the context.
Team goals and the quiet contributor
The engineer who builds the simulator, the build scripts or the documentation often looks idle in a status meeting. Include a shared team goal for each quarter and name the supporting work in it. Ask the team at the check-in whose work made theirs easier. This catches the person who keeps the programme moving.
An example year for one engineer
Take an engineer on a long controls programme. In the first quarter her proof point is a working simulator that the team can use. In the second, an interface document signed off by the client. In the third, a subsystem passing its integration tests. In the fourth, a risk retired, such as a timing problem under load. Between those points, her monthly notes record the late hardware, two client changes and her help to a new joiner.
At review time, her manager has four checkable results, twelve short notes and a clear list of disruptions. The conversation is about what she did and what she should do next, not about whether the project shipped. That is the purpose of this method.
Share the method with the whole programme in a single short session. Engineers accept goals they helped shape, and they tend to write better notes when they know the notes will be used fairly. Ask them what would make a proof point hard to reach, and adjust the wording in the first month.
Where this fits in your wider process
Goal cycles, review forms and rating rules should match, whatever the project length. If your firm needs a framework, our performance management process page describes how we design one. If you also hold labs and client prototypes, read the lab and device access rules post, because the same long programmes tend to hold the most sensitive hardware.
