I've spent the past year talking to developers, startups, and engineering teams across London. I went looking for technical depth. What I found was a systemic problem — one that runs from the hiring pipeline to the architecture, from the boardroom to the codebase.

London is my case study, but this isn't a London problem. It's a global one. New York is no better. The major outsourcing regions haven't invested in developer depth either, so the offshoring escape hatch that companies have relied on for decades isn't the answer. This is an industry-wide crisis in engineering capability, and it's about to collide with a wave of AI-driven change that most organisations aren't remotely prepared for.

The Confidence Gap

Developers in major tech hubs interview brilliantly. They know the terminology. They can whiteboard a microservices architecture. They can tell you why they chose Kafka.

What they often can't do is tell you what happens when Kafka falls over. Or why they chose it over a simple database queue that would have served their 200-user application perfectly well. Or what actually happens between a user clicking a button and a response arriving on screen — the full journey, through the network, the load balancer, the application, the database, and back again.

This isn't an isolated gripe. It's a pattern I've observed across dozens of conversations and technical assessments — at FTSE 250 companies, funded startups, and everything in between. The industry rewards the appearance of expertise. Conference talks, polished GitHub profiles, fluency in the language of distributed systems. But when you push past the surface, the depth isn't there.

How We Got Here

Over the past decade, the tech industry faced a genuine engineering shortage. Boot camps promised to fill it, and numerically, they did. But what they produced was a generation of developers trained to use frameworks, not to understand computing. React instead of JavaScript. Express instead of HTTP. Sequelize instead of SQL. Every layer of abstraction became the floor rather than the ceiling.

This wasn't the boot camp graduates' fault. They were told this was sufficient. The market validated it — a twelve-week React course could land you a well-paid job. Why would anyone go deeper when the industry was rewarding surface-level competence?

Large cities felt the shortage most acutely, so they lowered the bar furthest and fastest. Companies absorbed these developers at scale because they had no alternative. The work needed doing, the pipeline was what it was, and organisational structures — autonomous squads, microservice boundaries, well-defined interface contracts — conveniently hid the depth problem. As long as a team shipped features within their bounded context, nobody interrogated whether the engineers understood the system they were contributing to.

A decade later, those developers have been promoted to senior roles based on tenure and delivery within their narrow slice, not based on systems understanding or architectural reasoning. The titles inflated but the skills didn't. And now these are the people making technical decisions, mentoring the next generation, and setting engineering culture.

The shallow has become self-perpetuating.

What This Looks Like in Practice

I could describe this in the abstract, but the concrete examples tell the story better. These are all real, drawn from my direct experience over the past year.

The monolith inside the microservices. A large company running a mature event-sourced microservices architecture — Go, Kafka, Kubernetes, the full distributed systems toolkit. On paper, impressive. In practice, engineers within that architecture attempted to implement a monolith where a splitting service and fan out would have been the correct pattern. Fan out isn't an advanced concept. It's day one of event-driven systems. But these engineers, working inside a distributed architecture every day, couldn't see it. They'd been compartmentalised into narrow squad ownership, executing tickets within their slice without ever being asked to reason about how services compose or how data flows through the system.

The result? More code than necessary. A codebase that's almost certainly overcomplicated. Poor use of what the architecture was designed to provide. And as long as data comes in and goes out of their service boundary, nobody notices. It only gets looked into when something breaks — and then comes the hero blog post about the massive scaling effort they had to undertake. In reality, a blog post like that is a failure report dressed up as thought leadership. It shows a lack of continuous improvement — a culture of "just do the job until it breaks." That's not acceptable from senior engineers. They might have the title, but they don't have the depth it implies.

The startup that never shipped. A fintech so fixated on being "serverless" that the architecture became an identity rather than a tool. When presented with a simpler starting architecture — something that would actually get them to launch — they couldn't hear it, because it threatened who they thought they were. They rejected the approach because it was "missing the data science piece." Any experienced founder knows you don't build the analytics platform before you have customers generating data to analyse. You ship the core, get users, learn what questions matter, then build the capability. But starting small doesn't sound impressive in a funding round. They failed to launch. The simplest architecture in the world is infinitely more valuable than the most sophisticated one that never ships.

The reinvented message bus. A startup with very junior engineers in leadership positions alongside highly academic PhD engineers. Instead of having downstream services consume messages from a bus — the standard, battle-tested pattern — they required consumers to call an API and register a callback. The reasoning? "In case we want to change the message format." The solution to that problem already exists. It's called schema evolution, message versioning, and well-defined bounded contexts with a ubiquitous language. Protobuf handles it. Avro handles it. Every mature message bus in production handles it. Instead, they built a bespoke callback registration system that introduced an entirely new class of problems: callback state management, delivery guarantees, retry logic, timeout handling. They replaced loose coupling with tight coupling and called it an improvement. More code, more moving parts, more bugs — and the bottleneck wasn't eliminated, just relocated.

Three organisations. Three different scales. The same underlying problem: engineers operating machinery they don't understand, enabled by management structures that can't tell the difference.

The Consulting Industry Made It Worse

This depth problem didn't develop in isolation. The consulting industry has actively perpetuated it — and profited from it — for decades.

I've spoken to a former leader at one of the major consulting firms who was refreshingly candid about the model. They described how the firm invented roles specifically to create billing positions. Not because the client needed them. Because the engagement needed headcount to justify the fee. This isn't an aberration — it's the business model. The incentive is to expand scope, create dependency, and maximise billable hours. Delivering a clean, simple solution that the client can maintain independently is the worst possible outcome for a consultancy's revenue.

The pattern is predictable. A consultancy comes in, builds a system that's slightly — or significantly — beyond the in-house team's ability to maintain, then leaves. The in-house team, staffed from the same shallow pipeline, can operate the system but can't evolve it. Entropy accumulates. Eighteen months later, the consultancy returns for a lucrative rewrite. The client thinks they're buying expertise. What they're actually buying is a recurring dependency.

They're the cowboy builders of the software industry. Build it just well enough to look right, but not well enough to last. Come back when the plumbing leaks and charge double.

And the track record speaks for itself. These aren't fringe operators — they're the most prestigious firms in the world, and the failures are staggering. McKinsey paid $650 million in December 2024 to settle federal criminal and civil charges for advising Purdue Pharma on how to "turbocharge" OxyContin sales while simultaneously consulting for the FDA on drug safety — the first time a management consulting firm has been held criminally responsible for advice that led to client crimes.¹ In 2025, Deloitte Australia was forced to partially refund $290,000 paid by the Australian government after a report on welfare compliance was found to be riddled with AI-generated fabrications — fake academic references, non-existent footnotes, and a fabricated quote attributed to a federal court judge. An Australian senator described it as something "a first-year university student would be in deep trouble for."² The UK's Financial Reporting Council fined the Big Four more than £100 million over five years for audit failures, including KPMG's role in the Carillion collapse that cost almost 3,000 jobs and left £2 billion in unpaid bills.³

If these are the standards at the top of the consulting industry, imagine what's happening further down the chain in technology consulting — where the outputs are harder to audit, the failures are slower to surface, and the clients have even less ability to evaluate what they've been given.

The boot camp pipeline feeds directly into this cycle. The consultancy builds the system, hands it to a team trained on frameworks rather than fundamentals, those developers can't maintain or evolve it properly, and the consultancy gets the callback. It doesn't even require malice — the consultancy just needs to build something marginally beyond the in-house team's depth, which given the state of the talent pipeline isn't difficult.

Engineering Is Not a Cost Centre

There's a deeper cultural problem that enables all of this, and it starts in the boardroom.

Most business leaders are comfortable working closely with sales and marketing. They understand those functions intuitively — the language, the metrics, the levers. They see them as revenue drivers, as enablers of business outcomes.

Engineering, by contrast, is treated as a cost centre. Something you spend on reluctantly, manage at arm's length, and measure by output volume rather than outcome quality. This creates a dynamic where engineering is organisationally isolated from the business decisions it exists to serve. Leaders don't engage with engineering the way they engage with sales. They don't understand the trade-offs, can't evaluate the decisions, and default to trusting titles and process over substance.

This is backwards. Engineering is not a cost centre — it's an enabler of outcomes. The systems your engineers build are your competitive advantage. They determine how fast you can move, how quickly you can adapt, how reliably you can serve your customers. Every business outcome flows through the technology that delivers it.

In the past, this message got confused and became a licence for over-engineering. "Engineering is important" was misinterpreted as "engineers should build whatever they find interesting." That's not what this means. The code itself has never been the critical thing. It is, and has always been, the outcome. The code is the mechanism by which outcomes are delivered — and like any mechanism, it should be as simple, reliable, and maintainable as the job requires. Not simpler. Not more complex. Fit for purpose.

Business leaders need to engage with engineering the same way they engage with sales and marketing — as a core function that drives competitive advantage. And engineering needs to know its place too. It's not an ivory tower. It's not a playground for architectural experimentation. It's the engine that delivers business outcomes, and it should be held to that standard.

When both sides get this right — when leaders understand technology as a strategic asset and engineers understand their role as outcome delivery — you get organisations that move fast, build well, and adapt quickly. When they don't, you get the mess I've been describing.

The AI Reckoning

Here's where the depth crisis becomes existential.

If an engineer's job is "receive ticket, write code within a narrow slice, make data come in and go out, don't think about the broader system" — that is exactly the kind of work that AI agents are already getting good at. Bounded context, clear inputs and outputs, no architectural reasoning required. An agent with access to the codebase and a well-defined interface contract can do that. Faster, cheaper, and without the inflated salary.

The engineers who've spent a decade inside autonomous squads, executing within their bounded context without understanding the broader system, have been unwittingly training for their own obsolescence. The compartmentalisation that hid their lack of depth is the same compartmentalisation that makes their role automatable. They're not designing systems — they're implementing tickets within a predefined architecture they don't fully understand. That's a prompt, not a profession.

These are cosplay developers. They look like engineers. They have the titles, the GitHub profiles, the conference talks about event sourcing. But when you put a real problem in front of them — fan out, guard clauses, "should this be a monolith or a set of services and why" — the depth isn't behind it.

AI holds the potential for us to achieve outcomes at speeds that were unimaginable even two years ago. A competent architect working with AI tools can now reason about, design, and implement systems at a pace that would have required a team of ten. The engineers who survive — and thrive — are the ones who operate at the design level. The ones who understand systems holistically, make architectural trade-offs, and can direct AI agents toward the right solutions. Experienced, well-rounded developers who can drive a business forward, not just execute within a predefined slice of it.

But here's the dark side. Most organisations aren't set up to benefit from this. They'll amplify the mess they've already been living with, not escape it.

A decade of shallow engineering decisions — monoliths hiding inside microservice boundaries, reinvented patterns, unnecessary complexity, inconsistent approaches across squads — creates codebases that agents can't reason about reliably. The documentation is sparse or misleading. The architecture doesn't match the diagrams. The patterns are inconsistent. An agent dropped into that environment will produce solutions that look plausible but break in production because the codebase doesn't follow the conventions the agent expects.

Without getting the foundations right first — the architecture clean, the patterns consistent, the codebase structured for agents to reason about — introducing AI tooling will only generate more of the wrong code, faster. You'll automate the dysfunction.

The Copycat Threat

This creates an opening that should concern every incumbent with a messy codebase and a shallow engineering team.

The copycat threat has always existed in theory, but execution speed was the moat. It took too long to rebuild something complex from scratch. AI is collapsing that timeline.

A competent architect — someone who genuinely understands distributed systems, service decomposition, data flow, and the trade-offs involved — working with AI tools can now build in months what took incumbents years. And they can do it better, because they're starting from sound principles rather than retrofitting them onto a decade of accumulated shallow decisions.

A lean startup can look at what an incumbent is doing, understand the core product, and rebuild it with a clean architecture, proper patterns, and AI-assisted development. They move faster because they're not carrying technical debt. They operate leaner because their engineers understand the system end to end. They iterate more quickly because their codebase is designed for change rather than accidentally resistant to it.

This isn't theoretical. And the companies most vulnerable are exactly the ones with the problem we've been describing: sophisticated architectures operated by engineers who don't understand them, overseen by leaders who can't tell the difference.

What Taking Ownership Actually Looks Like

The way out isn't complicated. It's just uncomfortable.

Organisations need to properly take ownership of their systems. See them not as a cost to be minimised but as a means to competitive advantage. Invest in engineering depth, not just engineering headcount. Engage with technology decisions at the leadership level with the same rigour applied to sales strategy and market positioning.

Simple, well-built systems. That's the goal. Not the simplest possible — simple enough to be understood, maintained, and evolved by the team that owns them. Simple enough for AI agents to reason about when the time comes. Simple enough to move fast, which is what actually matters.

This means hiring differently — for depth and breadth rather than framework familiarity. It means promoting differently — for systems understanding rather than tenure. It means structuring teams differently — ensuring engineers have visibility beyond their immediate bounded context. And it means engaging with your engineering function the way you engage with every other part of the business that drives outcomes.

The organisations that get this right will be the ones that benefit from AI. Their engineers will direct agents effectively because they understand the systems those agents operate in. Their codebases will be agent-friendly because they were built on sound principles. Their teams will move faster because the foundation supports speed rather than fighting it.

The organisations that don't will watch leaner, smarter competitors eat their lunch.

Where We Stand

uRadical was born from anger and frustration at the cycle I've described. The shallow pipelines, the cowboy consultancies, the over-engineered systems built by people who don't understand the basics, the business leaders who can't tell the difference.

We're a Belfast-based consultancy that builds distributed systems and provides genuine technical partnership. We work as founding engineers at SafeOps365 in energy sector safety regulation. We built and run Music Bingo Live, a real-time entertainment platform serving thousands of concurrent users. We develop and maintain MyWelcomeBook, a multi-tenant SaaS platform for the hospitality industry. We lead Belfast Gophers, the largest Go user group in Ireland, and we maintain open-source tools used in production.

Our philosophy is simple: understand the system end to end, start simple, iterate, and never introduce complexity you can't justify. Every engagement starts with the outcome. Not the technology, not the architecture, not the framework — the business outcome the client needs to achieve. We work backwards from there, breaking the problem into small, validatable chunks so we can confirm the path is correct and the outcome is still on target at every step. It's agile without the ceremony — no rituals for the sake of process, just continuous validation that what we're building is the right thing and we're building it the right way. When we work with clients, we build capability alongside software. When we leave, the organisation is stronger than when we arrived.

We're based in Belfast because Northern Ireland produces the kind of engineers this industry actually needs. Smaller teams mean broader skills — when there's no platform team to page at 2am, you learn the full stack properly, not just the framework on top. Less job-hopping means engineers live with the consequences of their decisions, and that feedback loop is where real architectural intuition comes from. Tighter budgets mean better architectural choices — when every pound of infrastructure spend matters, you learn to build simply and scale deliberately rather than throwing Kubernetes at fifty users and hoping for the best. The ecosystem here — supported by Invest Northern Ireland, anchored by strong university programmes at Queen's and Ulster, and validated by the global companies that chose to base R&D operations here — produces developers with the depth and pragmatism that the boot camp pipeline failed to deliver.

Belfast is the number one city in the UK for US R&D investment.⁴ The region's tech sector is valued at £3.4 billion.⁵ And the engineering talent costs roughly 40-45% less than London while delivering, in our experience, significantly more depth and capability. That's not a cost argument — it's a value argument.

Now, as AI reshapes what's possible, we help organisations get their engineering foundations in order before they introduce AI tooling — because without that foundation, AI will only amplify existing problems. The companies that thrive in the next decade won't be the ones that adopted AI fastest. They'll be the ones whose architecture, codebases, and engineering culture were ready for it.

We can't help every organisation. We've walked away from engagements where the gap was too wide or the willingness to change wasn't there. But where there's genuine intent to build a strong engineering foundation — to treat systems as competitive advantage and engineering as an enabler of outcomes — that's where we do our best work.

An Invitation

If you're a business leader paying premium rates for shallow engineering and wondering why your systems keep breaking, we should talk.

If you're a developer anywhere who shares this philosophy — pragmatic, depth-first, outcome-oriented, suspicious of unnecessary complexity — we want to know you.

And if you're part of the ecosystem supporting Northern Ireland's tech sector, know that the foundation here is stronger than the headlines suggest. The talent exists. The ecosystem is maturing. The opportunity — to build the kind of engineering capability that the global pipeline has failed to produce — is real and urgent.

The only thing missing is more people willing to say it out loud.