Why Are Your Top Engineers So Demotivated?

You have spent millions. The new data centre is built. The SD-WAN is deployed. The Wi-Fi refresh is done. The vendor was excellent. The project closed on time.

And your best engineers are quietly updating their CVs.

After 21 years working inside technology programmes — as an engineer, as an architect, and as an independent consultant brought in when things go wrong — I have seen this pattern more times than I can count. Organisations that invest heavily in technology and almost nothing in the people who run it. Here is what it looks like from the inside.

10% of your engineers are carrying the team. Nobody is acknowledging it.

In almost every network and infrastructure team I have worked with, the same pattern holds. A small number of engineers — usually two or three people — are the ones who actually understand how everything works. They are the ones who get called at 11pm when something breaks. They are the ones who quietly fix the problems that would otherwise become major incidents. They are the ones the vendors call when they need someone who can actually read a packet capture.

The rest of the team ranges from competent to passengers.

This applies equally to architects. The principal architect who has been quietly steering design decisions for three years, preventing failures the business never knew about, is carrying the same invisible weight — and being rewarded the same way.

And every single one of them gets the same annual review. The same pay band. The same token training budget — if there is one at all. The engineers carrying the weight know exactly what they are worth. They also know exactly how they are being treated relative to that worth. The calculation they eventually make is not complicated.

You will spend £50,000 on an external consultant before you spend £5,000 on your own engineers.

I am that external consultant. I have walked into organisations, been briefed by engineers who knew the answer before I arrived, and been paid a significant day rate to confirm what they had already told their manager six months earlier.

The engineers in the room during that briefing said nothing. They had learned that saying it internally got them nowhere. Saying it through someone expensive and external got it heard.

The engineers in the room said nothing. They had learned that saying it internally got them nowhere. Saying it through someone expensive and external got it heard.

The irony is not lost on me. And it should not be lost on you.

Meanwhile, the request for a CCIE training course — £3,000, submitted in January — is still sitting in the approval queue in October. The team away day that would cost less than one day of my rate has been cancelled for the third year running because of budget pressure.

The loudest engineer gets to implement the most interesting projects.

Technical ability and the ability to self-promote are different skills. The projects flow toward the engineers who are most visible in meetings — not necessarily the most capable.

Technical ability and the ability to self-promote are different skills. In most teams, the projects — the migrations, the new deployments, the things that go on a CV — flow toward the engineers who are most visible in meetings. Not necessarily the most capable.

The quiet engineer who fixes things before anyone notices they were broken never gets to present at the all-hands. The engineer who is confident in front of senior stakeholders — regardless of whether their technical judgement is sound — gets sponsorship for the high-profile work.

Over time, the best engineers conclude that technical excellence is not what gets rewarded here. Some of them adapt and become more political. Most of them leave.

You are buying products your engineers told you not to buy.

The vendor came in. The presentation was impressive. The executive sponsor was in the room. The decision was made.

Three engineers raised concerns in the pre-sales process. They were told the business case was already approved. The concerns were noted in a meeting minutes document that nobody read again.

Eighteen months later, you are paying an external consultant to diagnose why the deployment is not performing as the vendor promised. The engineers who raised concerns originally are still on the team. They remember. They have stopped raising concerns.

What this actually costs you

Engineer replacement — recruitment, onboarding, the 6–12 months before someone is genuinely productive in a complex environment — typically costs 1.5 to 2x annual salary. For a senior network engineer that is £80,000 to £120,000 per departure, conservatively.

The training course was £3,000. The away day was £2,000. The pay review that would have retained them was £8,000 a year. The external consultant you will now hire to cover the gap while you recruit is £800 a day.

The cost of losing an engineer is invisible and deferred. The cost of investing in them is visible and immediate. Human beings — including directors and CTOs — are not naturally good at that trade-off.

The maths is not complicated. The problem is that the cost of losing an engineer is invisible and deferred, while the cost of investing in them is visible and immediate. Human beings — including directors and CTOs — are not naturally good at that trade-off.

What to do about it

This is not a call to spend money you do not have. It is a call to spend it differently.

Find out who is actually carrying your team. Ask the engineers — not the managers. Pay them accordingly. Give them the projects that will develop them, not just the ones that are safe to delegate.

Approve the training budget. Not as a reward. As an investment in the infrastructure your entire organisation depends on.

When engineers raise technical concerns about a vendor recommendation or a proposed design — take it seriously. They are closer to the reality than the vendor's sales team. A CCDE or CCIE on your team telling you something will not work is worth more than a vendor's reference architecture telling you it will.

And before you hire the next external consultant — ask yourself whether someone on your team already knows the answer. They probably do. They are just waiting to be asked. And if they do know — if their answer saves you that consultant's fee — reward them for it. A monetary bonus of 20 to 25 percent of what you were about to spend on someone external who knew less. A place at an industry conference. A training course they have been asking for. The form the reward takes matters less than the fact that the reward exists. Engineers remember when their expertise is valued. They also remember when it is not.

At this point, some readers will say: HR policy does not allow ad hoc bonuses. Finance will not approve it. It falls within their existing job responsibilities. If that is your organisation's position, it is worth asking whether those policies were designed for the talent market you are operating in today. The cost of losing the engineer who knows how everything works — and replacing them with someone who does not — rarely appears on the same spreadsheet as the bonus that might have retained them.

One final thought

The engineers keeping your infrastructure running are not demotivated because they are lazy or disengaged. They are demotivated because they are smart enough to see exactly how they are being treated relative to their contribution — and rational enough to act on it eventually.

The ones who stay quiet and keep working despite all of this are not a sign that everything is fine. They are a sign that the exit has not become more attractive than the frustration. Yet.