Rewards and recognition: the lever with a budget, and the one you actually hold

A reward is agreed in advance and paid for meeting a stated condition. Recognition is retrospective: it names a contribution after it has happened, and nobody was promised anything. The distinction matters on a project because the first requires a budget and an authority most project managers do not have, and the second does not.

One is agreed in advance, the other is noticed afterwards

The vocabulary is used loosely, and the looseness hides the only line worth drawing. Incentive, reward, bonus, recognition and award all get used for each other, usually by people describing schemes they did not design.

The CIPD’s evidence review on incentives and recognition draws the line by timing. Incentives are forward looking, set in advance on condition of hitting something. Rewards are more often retrospective. Recognition is defined there as personal non-monetary rewards given to acknowledge and reinforce effort, behaviour or achievement, usually set retrospectively, so unexpected, relational and unconditional. Three words in that definition carry the whole difference: unexpected, relational, unconditional.

The consequence is practical rather than semantic. A reward creates an expectation, and an expectation once created has to be honoured or explained, so every reward introduced is a commitment still being managed eighteen months later. Recognition creates no expectation, which is why it can be given as often as the work deserves and stopped without anybody being owed. The cheap lever is also the flexible one.

The lever with the budget is rarely yours

Most published advice on rewarding a team is written for somebody who employs it, and read as a project manager the mismatch is immediate.

On the great majority of projects the team is borrowed. Salary, bonus pot, promotion, the annual appraisal and the decision about who gets developed sit with line managers and with whoever owns the reward policy. A project manager controls none of them, and the things they do control, a team lunch or a small budget for an away day, are the least consequential on the list.

What the role does control is a different set entirely: what gets noticed, who hears about it, what the person gets to do next, and who they get to do it in front of. PM Network asked practising project managers how they actually reward people for difficult work, and the striking thing about the answers is how few of them cost anything. One respondent argues that the highest form of praise is a reward that benefits the exposure and career development of the team member, giving conference attendance and training as the example. Another describes walking to somebody’s desk when a hard task lands, telling them why it mattered and how it moved the project.

What a completion bonus actually pays for

A completion bonus is the most common reward attached to a project, and it is worth being precise about what it purchases, because it is not what people assume.

It purchases presence at the end. The condition is that the work reaches a defined state and that the person is still there when it does. Nothing in that structure measures contribution, and nothing in it distinguishes the person who carried the hardest month from the person who joined for the last sprint. As a retention device through a difficult tail it is genuinely effective, and retention through the tail is a real problem worth spending money on. As a motivator it is weak, because the connection between what somebody does on a Tuesday in March and a payment in November is too long and too diluted to change the Tuesday.

Device	Agreed when	What it actually buys
Completion bonus	In advance	Presence at the end
Milestone payment	In advance	Arrival at a date
Spot award	Afterwards	One act, once
Recognition	Not at all	The behaviour, repeatedly

There is a sharper problem, and the same CIPD review names it. Where the link between reward and performance is not made, that is, where rewards are handed out for simply completing a task, incentives and recognition are actually likely to harm work performance. A completion bonus is the purest available form of a reward for completing a task. It is entirely defensible as a payment for staying, and a team told that a completion payment rewards excellent work can see perfectly well that it was paid to everyone still on the payroll.

The timing compounds it. By the point a project reaches closure, much of the team has left. Specialists roll off at handover, contractors finish at their end dates, and whoever solved the worst problems in the middle is often on something else by the time anybody hands out anything.

The loop that breaks when recognition arrives late

Recognition works as a loop rather than as an event. Somebody contributes. Somebody notices. The contribution is named, out loud, to an audience that means something to the person who made it. And because it was named, the behaviour is more likely to happen again.

Delay is the ordinary failure. The thanks arrives at the next steering meeting or at the end of the phase, by which time nobody can reconstruct what specifically was good, so the wording goes generic. Generic praise is not a weaker version of specific praise. It is a different message, and the message is that nobody was watching.

Misdirection is the expensive failure, and it is a failure of the system rather than of manners. Attention flows to visible repair. Somebody works through a Saturday to recover a broken environment and everyone knows their name on Monday. The engineer whose careful sequencing meant no environment broke at all produced an absence, and absences are not on anybody’s status report. Recognise the first without ever finding the second and you have taught a competent team, over about two quarters, that the rewarding move is to be the one holding the fire hose.

The correction is not a scheme. It is a habit of asking, when something goes suspiciously smoothly, who made it go that way, and then saying so by name. That question is answerable on almost every project, and almost nobody asks it.

Recognition that leaves the room

Recognition that stays inside the project team expires with the project. It is pleasant while it lasts and it leaves no trace anywhere that affects the person’s year.

The version that compounds is the version that travels. A short note to somebody’s line manager, describing one specific thing they did and why it mattered, takes five minutes and lands in the only conversation that actually determines their rating, their pay and their next move. It costs the project nothing and it is the single highest leverage thing on the list, largely because so few people bother.

There is a second route worth building, which is peer recognition. Recognition that only ever flows down the management line carries an implicit claim that the manager saw everything, which is never true on a project of any size. Colleagues see the work you do not: who unblocked whom, who answered the question at nine on a Friday evening. A standing minute at the end of a review where anyone can name somebody else costs nothing and surfaces contributions no reporting line would ever have caught.

That logic runs outwards, which is why this sits beside the other two stakeholder pieces rather than in a chapter about people. A line manager who keeps hearing their person is doing well on your project acquires a reason to keep them there, which moves their engagement level in the direction you want at no cost. The sequence across the three is deliberate: the salience model tells you whose claim commands attention, the engagement assessment matrix tells you how engaged each one is against how engaged the work needs them, and recognition is one of the few instruments you hold for closing the gap on rows that involve people lending you their staff.

Where recognition does damage

Recognition is not free of consequence just because it is free, and the failure modes are specific.

The first is envy. The same CIPD review reports that singling out a team member, especially one seen as central, can lift the whole team through a spillover effect, and also reports evidence running the other way: public recognition of individuals can foster envy and resentment among colleagues and demotivate teams. Both findings are real, which means the outcome turns on framing rather than on whether you do it. Explaining what was recognised and why, and setting it against the team’s work rather than above it, is the difference between the two results.

The second is the scheme. A habit that works becomes a programme, the programme acquires nominations and a monthly winner, and recognition has quietly become a competition with one victor and a field of losers. Skip a month because everybody is busy and a signal has been sent that nobody intended. Anything on a rota also stops being unexpected, and unexpected was one of the three words that made this work.

The third is the substitution, and it is the one that causes real damage. Recognition offered in place of something the person is owed reads as an insult, and it reads that way immediately. Thanking a team warmly for a weekend they should never have had to work is not recognition, it is an admission of a planning failure dressed as generosity. Neither is a certificate an answer to a salary that has fallen behind the market, and everyone in the room can do that arithmetic faster than you can.

Which is the honest limit of the whole subject. Recognition is powerful, cheap and almost universally underused, and it cannot pay a mortgage, cannot fix a schedule built on a fiction, and cannot compensate anybody for being managed badly. It works on top of decent conditions and it collapses as a replacement for them. The project managers who get the most out of it are the ones who understand exactly which of those two things they are doing.