The conflation of reward and recognition is one of the most consistent sources of talent loss in engineering organisations. The organisation believes it is recognising good work because it pays competitively. The engineer does not feel recognised because nobody has noticed what specifically they contributed. Alternatively, the engineer feels genuinely valued by their manager and team, but when promotion time comes, they discover that their contribution - which was extensively recognised verbally - generated no formal advancement.

Both matter. Neither substitutes for the other. Reward without recognition produces engineers who are paid well but feel invisible. Recognition without reward produces engineers who feel valued but not invested in. The organisations that retain excellent engineers in a competitive market do both, consistently and intentionally.

This section covers what reward and recognition are, why confusing them is costly, what engineers actually value, how to design systems that work, and what the common failure modes look like.

The Distinction That Matters

Reward

Reward is the formal, typically financial or structural, exchange of value for contribution. It includes:

• Base salary and salary increases
• Bonuses and variable compensation
• Equity or profit-sharing
• Promotion to a higher level
• Formal recognition programmes (employee of the year, spot awards with cash value)
• Benefits with financial or structural value (additional leave, flexible working arrangements formalised as policy)

Reward is generally administered through a formal system with criteria, approval processes, and governance. It is relatively infrequent - most reward decisions happen annually or at promotion points. It is consequential - reward decisions affect take-home pay, career level, and financial security.

Recognition

Recognition is the informal, relational, and timely acknowledgement of specific contribution. It includes:

• A manager naming specific good work in a 1:1
• A team lead calling out a contribution in a team meeting
• A peer thanking a colleague publicly in a team channel
• A senior leader mentioning specific work in a company-wide communication
• Being asked to present work to a senior audience because it is valued
• Being given visibility with stakeholders, customers, or the wider organisation

Recognition is generally informal. It happens frequently - or should. It costs little or nothing in financial terms. It is highly personal - the same recognition that is meaningful to one engineer is irrelevant to another.

Why Confusing Them Is Costly

Over-relying on reward as recognition: "We pay above market, that is recognition enough." This creates engineers who are well-compensated but feel invisible. The compensation addresses financial security but does nothing for the human need to be seen, to have contribution noticed, to feel that the work mattered to someone. Engineers who feel invisible leave, even when well-paid.

Over-relying on recognition as reward: "We have a great culture of appreciation, everyone feels valued." This creates engineers who feel genuinely seen but who discover that the appreciation is not translating into progression, compensation, or career advancement. Recognition without reward produces engineers who eventually feel patronised - appreciated but not invested in.

Using recognition to defer reward conversations: A manager who consistently gives warm, specific recognition for excellent work while consistently failing to advance the engineer through the compensation and progression system is extracting value without returning it equitably. This erodes trust over time, often slowly, until the engineer realises the pattern and leaves.

What Engineers Actually Value

Self-determination theory identifies autonomy, mastery, and purpose as the primary intrinsic motivators. These are more predictive of sustained engineering performance than compensation, once compensation reaches a sufficient threshold. Understanding what engineers actually value - rather than what managers assume they value - is the starting point for an effective reward and recognition system.

Autonomy

The degree to which engineers control how they do their work, what they work on, and with whom. Engineers with high autonomy - who are trusted to make technical decisions, who have input into product direction, who can choose their development priorities - are substantially more engaged than those who are told what to do at every step. A reward and recognition system that does not protect and extend autonomy as a career progresses is missing one of the most powerful motivators available.

Signals that autonomy is being respected:

• Senior engineers are trusted to make architectural decisions without approval chains
• Engineers choose their own tools within reasonable constraints
• Development time (time for learning and exploration) is real, not theoretical
• Engineers' opinions on product and technical direction are genuinely solicited and sometimes acted on

Mastery

The drive to get better at things that matter. Engineers who are growing - developing technical depth, expanding their scope, building new capabilities - are more engaged than engineers who are stagnating in work they mastered two years ago. Recognition that notices and supports growth (not just achievement) feeds mastery motivation.

Signals that mastery is being supported:

• Development goals are taken seriously and resourced
• Stretch assignments are offered regularly
• Technical depth is valued and visible, not just delivery throughput
• Learning from failures is explicitly valued rather than punished

Purpose

The sense that the work connects to something meaningful. This varies by engineer - some find meaning in technical excellence, some in user impact, some in the quality of the team they are building, some in the mission of the organisation. Recognition that connects individual contribution to wider purpose is more motivating than recognition that merely notes good work.

Signals that purpose is being connected:

• Engineers have visibility into how their work affects users and customers
• The "why" behind decisions is shared, not just the "what"
• Individual contribution to team and organisational goals is made visible
• The mission and values of the organisation are genuine rather than decorative

Belonging

The sense of being part of a team that values them. This is not just about social relationships - it is about being included in important conversations, being trusted with meaningful work, having their contributions acknowledged by people they respect. Recognition that makes an engineer feel genuinely part of the team is among the highest-value things a leader can provide.

Designing Fair Reward Systems

Fair reward systems are not neutral systems. Active design choices are required to prevent the defaults - which in most organisations favour visible, vocal, and socially dominant contributors over quiet, deep, or collaborative ones.

Connecting Contribution to Progression

The most important design principle: the criteria for compensation and promotion decisions should be explicit, consistent, and known in advance. Engineers should not discover what "exceeds expectations" means at the point of assessment. They should know, from the moment they join the team, what the expectations are at their level and what the expectations at the next level look like.

The capability framework is the vehicle for this. When the capability framework is well-designed and genuinely used in promotion conversations, progression decisions become predictable and fair. When progression is based on manager perception and political visibility, it is neither.

Avoiding the "Loud in Meetings" Bias

The engineer who speaks frequently in meetings, who is visible in cross-team discussions, who has a high public profile in the organisation - will tend to be assessed as high-performing regardless of their actual contribution quality. The engineer who does deep, quiet work, who produces excellent code without fanfare, who collaborates asynchronously rather than in meetings - will tend to be underassessed.

This is a systematic bias in most reward systems. Countering it requires:

• Explicitly valuing contributions that are not publicly visible when discussing promotions
• Asking "who contributed to this outcome?" not just "who presented this outcome?"
• Separating communication skill and visibility from technical contribution in capability assessments
• Training managers to notice and name the invisible work in their team

Making Criteria Explicit

The engineer should be able to answer these questions at any point:

• What do I need to demonstrate to be promoted to the next level?
• What does "exceeds expectations" look like in concrete terms?
• How does my compensation compare to others at my level and why?
• What is the process for promotion and who has input into it?

Where these questions cannot be answered, the reward system is opaque. Opaque reward systems produce two outcomes: the engineers who benefit from opacity (those who navigate it well, usually through visibility and advocacy) develop a stake in keeping it opaque; those who do not benefit from it lose trust in the system and eventually the organisation.

Pay Equity and Consistency

Pay gaps that are not explained by role, level, location, or performance are a form of organisational failure. In engineering, market-rate discrepancies mean that engineers who joined in different conditions often earn very different amounts for identical work. Active management of pay equity - understanding where significant unexplained gaps exist and closing them systematically - is both fair and practically necessary for retention.

The manager who advocates for their team's compensation in calibration and budget discussions is performing an important role. The manager who does not advocate, assuming HR will handle it, will find their team underpaid relative to market and relative to peers with advocates.

Recognition That Works

Specific

"Good job on the release" is not recognition. "The rollback plan you put together for the payments migration prevented what would have been a three-hour outage. That kind of preparation is exactly what I want to see more of" is recognition. The difference is specificity - naming what was done, what it prevented or enabled, and what it signals about the person's value.

Specific recognition has two effects the generic version does not: it tells the engineer what to repeat, and it demonstrates that the manager is genuinely paying attention rather than performing appreciation.

Timely

Recognition is most powerful when it is close in time to the contribution being recognised. "The retrospective you facilitated last Tuesday changed the dynamic in that team, and I've been meaning to tell you how much I appreciated it" is better delivered on Wednesday. Waiting until the next 1:1, or the next performance conversation, or the end of the year diminishes the impact substantially.

The manager who has something positive to say should say it when it is true, not bank it for a more formal occasion.

Public Where Appropriate, Private Where Necessary

Public recognition - in a team meeting, in a Slack channel, in a company-wide update - is powerful for some engineers and uncomfortable for others. The instinct should be to default to public for contributions that benefited the team or organisation, and to ask the engineer first if there is any doubt about their preference.

Developmental feedback is almost always better private. The engineer who receives a public correction or a developmental observation in front of their peers is likely to be more focused on the social experience than on the content of the feedback.

Private recognition - given directly and sincerely in a 1:1 - is not lesser recognition. Some engineers find it more meaningful precisely because it is personal rather than performative.

Specific to the Contribution, Not the Delivery

"You're amazing at presenting" is recognition of a general trait. "The way you simplified the architecture diagram in the stakeholder session last week made a genuinely complex concept accessible to people without a technical background, and it directly changed the tone of the conversation" is recognition of a specific contribution. The latter is more useful and more credible.

Perverse Incentives

Reward systems that are poorly designed produce behaviour that optimises for the metric rather than for the outcome the metric was intended to proxy. This is the principle of Goodhart's Law applied to performance management, and it plays out consistently in engineering organisations.

Individual Incentives That Undermine Team Performance

Bonus structures tied to individual delivery metrics incentivise engineers to protect their own throughput at the expense of collaborative work. Reviewing a peer's PR, pairing with a more junior colleague, improving shared infrastructure - all of these have high team value and low individual metric value. In a system that rewards individual throughput, rational actors will reduce the collaborative work.

If you have individual performance metrics that determine compensation, you need to measure and reward collaborative contribution explicitly alongside individual delivery. Otherwise you are paying for individual heroism and calling it engineering excellence.

Output Metrics That Kill Quality

Velocity points, ticket count, commit frequency - these are output metrics. They do not measure quality, sustainability, or impact. Teams that are assessed primarily on output metrics will optimise for output: more commits (whether they are necessary or not), more tickets closed (whether they represent meaningful delivery or not), higher velocity (whether the points are honestly sized or not).

The consequence is predictable: more output, lower quality, more technical debt, more production incidents, and eventually lower actual throughput as the debt compounds.

If metrics are part of the reward system, they should measure outcomes (value delivered, problems solved, quality sustained) rather than outputs.

Promotion Criteria That Reward Visibility Over Depth

When promotion decisions are based primarily on visibility - who presented at the all-hands, who had the best stakeholder relationship, who was most vocal in planning discussions - the organisation is promoting communication and political skill over technical excellence and team contribution. Over time, the engineering leadership becomes filled with people who are excellent at being seen to be good rather than at being good.

The capability framework should explicitly value technical depth, team contribution, and invisible work alongside communication and leadership. Where it does not, the invisible work will remain invisible in the reward system.

Recognition Culture

Individual recognition behaviours matter. Team recognition culture matters more. The norms of a team - whether recognition is common or rare, specific or vague, bidirectional or only top-down - determine whether individual recognition practices can take root.

What Leaders Model

The team lead who regularly gives specific, public recognition for good work signals that this is a norm. The team lead who never mentions colleagues' contributions, or who gives generic praise, or who only recognises the same highly visible people repeatedly - is modelling a norm that will be replicated.

Specific leader behaviours that build recognition culture:

• Naming specific contributions by specific engineers in team channels and meetings
• Asking "who should we thank for this?" when reviewing successful outcomes
• Recognising the quiet work - the documentation, the code review, the mentoring, the incident response
• Making it normal for engineers to recognise each other, by doing it themselves

Peer Recognition

In a healthy recognition culture, recognition is not only top-down. Peers recognise each other. A tool or channel that makes peer recognition easy (without requiring effort) lowers the activation energy sufficiently that it happens. Slack kudos channels, team retrospective "shoutouts," peer nominations for recognition awards - all of these are vehicles for peer recognition that work if the culture is present to use them.

Peer recognition that is genuine and specific is often more motivating than manager recognition, because it comes from someone who directly experienced the contribution rather than heard about it.

What Gets in the Way

Normalisation of excellence. Teams where good work is consistently expected can fall into the trap of not recognising it because "that is just the standard." This is a mistake. The standard is maintained and raised partly through recognition that it is being met. Engineers who consistently meet a high standard and receive no acknowledgment eventually stop finding the standard motivating.

The recognise-the-same-people trap. In most teams, a small number of people are recognised repeatedly. The visible, vocal, senior engineers receive the kudos. The quieter contributors do not. Over time, this teaches the team that recognition goes to people who are already recognised - a self-reinforcing pattern that drives out the engineers who are not in the visible group.

Recognition as a managed activity. Recognition programmes that require forms, approvals, and quarterly nominations are not recognition - they are bureaucracy. Recognition needs to be easy enough to happen in the moment. If the process for giving recognition is more effortful than doing the work being recognised, it will not happen.

Connecting Recognition to Career Progression

Recognition that exists only in the moment and generates no record has limited career value. Recognition that feeds into the evidence base for promotion and compensation decisions has compounding value.

Making Visible Work Count

The most important thing a manager can do for an engineer's career is ensure that their contributions are visible to the people who make promotion and compensation decisions. This means:

• Naming specific contributions when discussing the engineer in talent reviews and calibration sessions
• Ensuring that the engineer's work is presented to senior stakeholders where appropriate, and credited to them specifically
• Creating opportunities for the engineer to demonstrate their capability beyond their immediate manager
• Including specific examples of contribution in promotion documentation, not just generalised assessments

The engineer who is excellent but invisible will be outpaced by the engineer who is good but visible. This is unfair and a waste of talent. Making excellent invisible work visible is a manager responsibility.

Recognition as Evidence

When a manager gives specific recognition - in a 1:1, in a team channel, in a meeting - and that recognition is documented, it becomes evidence. Evidence of specific contribution, specific impact, specific behaviour that meets or exceeds expectations. This evidence feeds promotion cases.

The promotion case that consists of specific examples ("in Q2, she designed the data migration approach that allowed us to decommission the legacy system six weeks ahead of schedule and without a data incident") is substantially stronger than the promotion case that consists of general assessments ("she is an excellent engineer who consistently exceeds expectations").

Managers should be connecting recognition to evidence from the moment they give it - not waiting until promotion time to construct the case retrospectively.

The Promotion Conversation

The promotion conversation should not be the first time an engineer hears whether they are being considered for advancement. If promotion is on the horizon, the manager should be signalling it - naming the gap between current performance and next-level expectations, identifying specific development areas, and confirming when and under what conditions the promotion conversation is likely to happen.

Promotion as a surprise (in the positive direction) is less disruptive than the negative equivalent, but it still indicates that the career conversation has not been happening regularly. An engineer who is promoted having had no idea it was coming has not been getting the career development conversation they deserved.

Common Failures

Generic "Great Job" Recognition

"Great job on the sprint." "Well done this week." "You are killing it."

These are the recognition equivalents of nodding. They cost nothing, they mean nothing, and they teach the engineer that recognition is a social ritual rather than a genuine acknowledgement. If a manager cannot name specifically what was great about the sprint, they should not offer the generic version as a substitute.

Reward Systems Nobody Understands

Compensation structures, bonus formulae, promotion criteria that are opaque, complicated, or inconsistently applied produce engineers who do not trust the system. When engineers cannot understand why they were paid what they were paid or why they were not promoted when they believed they should have been, they conclude (often correctly) that the system is arbitrary. Arbitrary systems cannot be optimised for - you cannot focus your development on the things that will advance you if you do not know what those things are.

Simplicity and transparency in reward systems are engineering values applied to people management.

Recognising the Same Visible People Repeatedly

The same five names appearing in every all-hands shoutout, every award, every kudos channel. This is a signal that recognition is tracking visibility rather than contribution, and it is discouraging to the engineers who are contributing at least as much without the same visibility. Actively audit recognition patterns: who is being recognised, for what, by whom, and who is absent from the pattern. Absence is informative.

Recognition Used as Compensation Substitute

"We do not pay as well as the market, but we have a great recognition culture." This is not a trade-off most engineers will accept for long. Recognition is not a substitute for fair compensation. Both are needed. The manager who uses recognition to deflect compensation conversations is borrowing time at a very high interest rate.

End-of-Year Recognition Stacking

Saving up all recognition for the annual review or year-end process converts recognition from a motivation tool into an annual ritual. By the time the recognition is delivered, the work being recognised is six to eleven months old. The engineer has no idea what they did that merited it, and the connection between the contribution and the recognition is too distant to reinforce the behaviour.

Connection to Your Operating Model

Reward and recognition connect to every other element of the talent and performance system:

Performance management. Reward decisions are informed by performance conversations. Without a credible performance management system, reward decisions are based on impressions and visibility - which is unfair and inaccurate. The annual review that leads to a compensation decision needs to be a synthesis of an ongoing performance record, not a snapshot of recent memory.

Talent reviews and calibration. Promotion decisions made in calibration sessions should reflect the same evidence base that recognition conversations have been building throughout the year. A promotion case that appears only in a calibration session, without supporting evidence from ongoing recognition and development conversations, is weaker and more vulnerable to political counter-arguments.

Career and capability framework. The framework defines the expectations at each level and the expectations for progression. Reward and recognition decisions that are not anchored to the framework are arbitrary. The framework gives engineers and managers a shared reference point for what progression means and what it requires.

Feedback systems. Recognition is a form of positive feedback. The feedback principles apply: be specific, be timely, name the behaviour and the impact. Vague positive recognition has the same limitations as vague developmental feedback - it does not tell the recipient what to repeat.

Psychological safety. Engineers in psychologically safe environments are more willing to take the risks that lead to the outcomes worth recognising - trying new approaches, raising difficult problems, admitting uncertainty, learning from failures visibly. Recognition that celebrates these behaviours reinforces the safety. Recognition that only acknowledges successful outcomes discourages the risk-taking that leads to excellent outcomes over time.

This section connects directly to: Modern Performance Management, Talent Reviews and Calibration, PDPs and PIPs, the Career and Capability framework, and the Role Archetypes.

Implementing a Reward and Recognition System

The following guidance covers implementation for organisations building or rebuilding their approach to reward and recognition. It addresses the common failure modes and provides a practical pathway.

Starting With Transparency

The first and most impactful thing most organisations can do is make their reward criteria transparent. This does not mean making everyone's salary visible (though some organisations do this with positive effects). It means:

• Publishing the capability framework and connecting it explicitly to compensation bands
• Publishing the criteria for promotion decisions
• Making the process for compensation review visible - when does it happen, who is involved, what inputs are considered
• Being willing to explain compensation decisions to individuals, not just deliver them

Transparency is uncomfortable for organisations that have historically rewarded on the basis of relationships and advocacy, because it makes the informal system visible and challengeable. That is the point. If the informal system produces better outcomes than a transparent one, make it formal. If it produces worse outcomes, fix it.

Auditing Current Recognition Patterns

Before designing a new recognition system, audit the existing one:

• Who has been recognised publicly in the last six months? What are the demographic and seniority patterns?
• What types of contribution have been recognised? Is the invisible work (code review, documentation, mentoring, incident response) present?
• How specific has the recognition been? Is it "great job" or "specifically X produced Y outcome"?
• What is the frequency? Is recognition happening at all, or is it reserved for exceptional moments?

The audit will almost always reveal that recognition is concentrated among a small number of visible people, that invisible work is systematically absent from public recognition, and that the specificity of recognition is much lower than it should be. These findings are the starting point for a targeted improvement programme.

Compensation Band Transparency

Compensation bands - the salary ranges associated with each level in the capability framework - should be visible to all engineers. The argument against transparency (people will be upset about differences within a band) is real but manageable. The consequences of opacity - engineers discovering they are significantly below market rate or below peers only when they have already decided to leave - are substantially worse.

Within a compensation band, differences should be explainable by:

• Time in role or level
• Market rate adjustment (different skills command different market rates)
• Geographic cost-of-living adjustment (if applicable)
• Explicit performance premium (a consistent track record of exceeding expectations at the top of the band)

Differences that cannot be explained by these factors should be investigated and addressed. Pay equity is not an aspiration - it is a legal requirement in many jurisdictions and an ethical requirement in all of them.

Recognition for Different Engineer Types

Different engineers respond to different forms of recognition. A well-designed recognition approach does not apply the same mechanism to all engineers and expect equal results. The following typology is not exhaustive, but covers the most common patterns:

The Deep Technical Contributor

What they value: being seen as excellent at their craft. Having their technical work taken seriously. Being asked for their technical opinion by people they respect.

Recognition that lands: specific praise for technical quality from a peer or leader whose technical opinion they value. Being asked to review or advise on technically complex work. Having their architectural or technical decisions acknowledged as good judgement.

Recognition that does not land: public shoutouts in non-technical contexts. Management appreciation that cannot distinguish between their work and mediocre work. Visibility opportunities that require presenting to non-technical audiences about technical work.

The Collaborative Multiplier

What they value: seeing the team succeed. Contributing to others' growth. Being recognised as someone who makes the team better.

Recognition that lands: explicit acknowledgement that the team's success was enabled by their collaborative contribution. Being described as a multiplier. Seeing the people they have helped succeed visibly.

Recognition that does not land: individual delivery metrics. Competitive frameworks. Being asked to optimise for their own output rather than team output.

The Ambitious Progression-Focused Engineer

What they value: advancement, challenge, and clarity about the path forward.

Recognition that lands: clear signals of progression possibility and timeline. Being given work that stretches them toward the next level. Being told specifically that their development trajectory is strong.

Recognition that does not land: positive feedback about current performance without any signal about future progression. "You're doing great" without "and here's what the next step looks like."

The Delivery-Focused Engineer

What they value: shipping things. Solving problems. Making commitments and meeting them.

Recognition that lands: acknowledgement of what was delivered and its impact. Being trusted to make delivery decisions. Being given the autonomy to own outcomes.

Recognition that does not land: process compliance. Recognition that focuses on how they worked rather than what they shipped.

Understanding which type of engineer you are working with - and adapting recognition accordingly - is a management skill that significantly amplifies the impact of the recognition effort.

Promotion Processes That Work

The promotion decision is the highest-stakes reward decision most managers make. It is frequently made on the basis of incomplete evidence, influenced by recency, and inconsistently calibrated across managers. The following principles produce fairer and more accurate promotion decisions.

Evidence-Based Promotion Cases

A promotion case should be built from specific evidence collected over time, not from a general impression assembled at the point of the promotion conversation. The capability framework defines the requirements of each level. The promotion case should demonstrate, with specific examples, that the engineer is consistently meeting those requirements.

A promotion case that says "she is an excellent engineer and ready for the next level" is not a promotion case. A promotion case that says:

"In Q1, she designed the data migration approach for the payments modernisation project, coordinating with three other engineering teams to align on the interface contract. The migration completed without data loss and three weeks ahead of schedule. This is a level 4 expectation for technical leadership in a cross-team context.

In Q2, she identified that the authentication service had a subtle race condition that would have caused session corruption under specific load conditions. She diagnosed the root cause independently, proposed two approaches, and implemented the agreed solution with full test coverage. This is a level 4 expectation for independent problem-solving.

In Q3, she onboarded two new engineers to the payments domain, produced architectural documentation that has subsequently been used by three other engineers as the reference for domain understanding, and ran a knowledge-sharing session that addressed a gap the whole team had identified in retrospective. This is a level 4 expectation for team knowledge sharing and contribution to team capability.

She is consistently operating at level 4 across the core technical and collaboration dimensions. The calibration group agreed that her promotion to level 4 is appropriate."

• this is a promotion case.

The Promotion Conversation

The promotion conversation itself should not be a surprise. If an engineer is not expecting to be promoted, one of two things has gone wrong: either the manager has not been transparent enough about where they stand, or the promotion decision is not well-founded.

The promotion conversation should include:

• The decision and the effective date
• The specific evidence that informed the decision
• The expectations of the new level - what will be different
• Any areas for continued development even at the new level

A promotion decision that is announced without context is less useful than one that explains the reasoning. The engineer who knows specifically what they did that merited the promotion knows what to keep doing.

When Promotion Is Not Possible

When an engineer is ready for promotion but the role or budget does not support it, the conversation must be honest. "You are ready for the next level. I want to be transparent that there are constraints on promotion decisions this cycle that mean I cannot advance you now. Here is what those constraints are, here is what I am doing to advocate for you, and here is my best estimate of the timeline."

This conversation is difficult but essential. The alternative - not having it until the engineer raises the topic - allows the engineer to draw their own conclusions (usually more negative than the reality) and to begin looking externally for the progression the organisation is not providing.

Reference: Recognition Quality Framework

Use this framework to assess whether a recognition practice meets a minimum quality standard:

An organisation where most recognition falls in the "weak" column on most dimensions is not running a recognition programme. It is running a recognition performance - the appearance of appreciation without the substance. The practical effect on retention and engagement is roughly the same as having no recognition at all, and significantly worse in some respects because it creates cynicism.

Reference: Recognition Frequency Benchmark

Managers frequently underestimate how often they give specific positive recognition. The following benchmark is based on what high-performing teams report:

These frequencies are not targets to be hit mechanically. They are a calibration tool. A manager who looks at this list and realises they have not given a specific piece of positive recognition to any member of their team in three weeks has identified a gap worth addressing.

The most common reason managers underrecognise is not that they do not notice good work - it is that they assume the engineer knows it is good, or that saying so feels unnecessary, or that other demands crowd out the moment. None of these explanations change the impact of the underrecognition. The engineer who is never specifically praised will, over time, assume their work is adequate at best, will reduce the investment they are making in quality and craft, and will begin looking for an environment where their work is more visible.