Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed!
You are now subscribed
Your newsletter sign-up was successful
Join the club
Get full access to premium articles, exclusive features and a growing list of member rewards.
We’d love to call the UK a global leader in AI, fintech, and digital innovation. But the truth is: we’re straining the very engineers we need to deliver on that ambition.
Instead of enabling our technical talent to innovate, too many organizations are exhausting them with firefighting and patching work.
A staggering 66% of UK developers say they now spend more time maintaining code than building anything new. Another 81% say they’re simply too stretched to make space for creative or innovative work.
Article continues belowTechnical Engineering Lead EMEA at Chainguard.
What we're asking of engineers right now is the equivalent of asking Formula 1 drivers to build their own cars mid-race, and then blaming them when they lose.
You don't need to be an engineer to understand the implications.
It’s time to talk about the productivity tax on engineers
Whether we admit it or not, we’ve normalized a working culture where developers are constantly stuck in reactive mode: battling backlogs, triaging vulnerabilities, or trying to unravel legacy spaghetti code. These are problems they didn’t create, yet are somehow responsible for fixing.
Unsurprisingly, developer burnout is spiking. More than one-third (35%) of engineers say burnout is the top barrier to a positive work experience, while two-thirds of engineering leaders now worry about retaining talent under these conditions.
Sign up to the TechRadar Pro newsletter to get all the top news, opinion, features and guidance your business needs to succeed!
What’s worse, all this toil comes at the cost of innovation. Now, engineers only spend 16% of their time actually building new features, even though 93% say it’s the most energizing part of their role.
Every time a new CVE drops, or another vendor announces a zero-day cybersecurity exploit, it’s developers who get pulled away from meaningful product work to patch problems. This isn’t a niche frustration; it’s a widespread failure of process.
If we want to build business apps secure by default, we need to shift the burden away from individual engineers and embed security earlier in the development lifecycle. That means less reactive patching and more secure-by-design tooling.
Engineers don’t want another tool. They want time back.
The balance between risk and innovation
Open source now underpins 90% of all software, and while it has allowed organizations to move and innovate quickly, it has also introduced risk in the software supply chain: Code from unknown maintainers, unverified binaries, and no provenance.
The UK’s new Software Security Code of Practice is a welcome first step – it calls for secure software development and open source governance. But it doesn’t yet tackle the root problem: we’re fueling innovation with untrusted code, and developers are the ones left firefighting.
If the UK wants to lead on AI, it needs to stop treating software supply chain security as a patch management job. Make security a developer-first concern.
Start with minimal, trusted base images, signed SBOMs, and hardened components from the first line of code – not as an afterthought at deploy time.
Give developers default access to signed packages, vulnerability-free base images, and verified libraries as part of their everyday toolchain.
Organizations like Snowflake are already embedding hardened images, secure defaults, and automated build tooling into their developer workflows.
The UK can’t win the tech race without its builders. Want to compete in the AI era? Start by giving your engineers the space to engineer.
Technical Engineering Lead EMEA at Chainguard.
You must confirm your public display name before commenting
Please logout and then login again, you will then be prompted to enter your display name.