In December 2025, an autonomous AI agent named ARTEMIS spent ten hours probing Stanford’s live computer science network; roughly 8,000 hosts across twelve subnets. It found nine valid vulnerabilities. It beat nine of the ten OSCP-certified human penetration testers it was benchmarked against.

ARTEMIS is open source. Anyone reading this can have it running in an hour or so. I know, because I have!

The work of finding holes in your network just got cheap, fast, and replicable. That should focus the mind.

A War That Was Always Asymmetric Just Got More So

Cybersecurity has always been an asymmetric game. Attackers need to win once. Defenders need to win every day. The numbers were against the blue team before any of this and they’re now moving in the wrong direction at speed.

In 2025, 48,177 CVEs were assigned. That’s 131 vulnerabilities published every day. CVE submissions are up 263% since 2020, and Q1 2026 is tracking another third higher than Q1 2025. NIST formally gave up trying to enrich every one of them on 15 April 2026 and only fully analyse the ones that intersect CISA’s Known Exploited Vulnerabilities catalogue, federal-government software, or Executive Order 14028 critical software.

Meanwhile, VulnCheck’s State of Exploitation 2026 found that 28.96% of newly exploited vulnerabilities were attacked on or before the day their CVE was published, up from 23.6% in 2024.

What’s your patch cycle? Ninety days? Sixty if you’re disciplined?

Defenders are running on a quarterly cadence; attackers are running daily, and that gap is now actively widening.

The Process Is Already Broken

Most enterprises run vulnerabilities through the same four-step gauntlet: triage, validate, remediate, deploy. Every step is structurally broken.

Triage: most organisations operate at roughly one application security engineer per hundred software engineers. CVSS scoring doesn’t reflect actual exploitability, so the queue gets prioritised by the wrong signal. And the queue is mostly noise: a meaningful share of scanner findings are false positives that eat the team’s day.

Validate: feature delivery beats technical debt every sprint. The CAB process demands extensive documentation before anything moves. Real threats slip past because the developers reviewing them don’t have the security expertise to recognise what they’re looking at.

Remediate: friction between application teams and security teams creates delays. Endless back-and-forth on whether a fix is really a fix. The vulnerability stays live throughout.

Deploy: by the time the patch is in production, the triage backlog has grown faster than it shrank. You’re losing ground every sprint.

A typical enterprise takes weeks from CVE disclosure to production fix.

Non-deterministic Safety Systems

Think about a modern operating theatre. The surgeon brings non-deterministic judgement. Every patient is different, every operation throws up things no textbook fully anticipates. But that judgement is wrapped in deterministic discipline: the pre-op checklist, sterile field protocols, the time-out before incision, the instrument count before closure.

That’s the architecture mature security needs in the AI era. Deterministic policy at the edges. Non-deterministic intelligence in the middle. Deterministic enforcement at the gates.

In practice, that looks like:

• Deterministic policy. Signed commits, software bills of materials, SLSA attestation, mandatory scanning on every pipeline run, codified approval rules, immutable audit trails. None of this is AI. All of it is non-negotiable.

• Non-deterministic intelligence. AI-assisted triage that distinguishes real findings from scanner noise. AI explanation that tells the developer not just what is wrong but why and how to fix it. AI-drafted remediation that produces a merge request, not a ticket. AI prioritisation that uses exploit intelligence rather than raw CVSS.

• Deterministic enforcement. Protected branches, deployment approvals, container and dependency scanning gates that block on policy violation, not on human reviewer availability.

AI in the middle, where judgement helps. Determinism at the edges, where you cannot tolerate ambiguity.

This is how defenders get back to attacker speed; not by adding humans to a broken process, but by replacing the broken process with one that operates at the pace and volume the threat now demands.

You Can’t Out-Hire This. You Have to Out-Architect It.

The asymmetric war isn’t coming. It’s already here. ARTEMIS is on GitHub. Mythos exists. Fable is already banned. Attackers running on daily cadence have AI in their tooling already; that gap with defenders running quarterly will only widen.

You can’t out-hire this. You can’t outspend it on more scanners. And you can’t wait for someone else’s coalition to fix it for you.

What you can do is build a platform where AI accelerates the work that scales, and humans are kept on the work that doesn’t. Where deterministic policy enforces the rules. Where deterministic gates a

bsorb AI’s output safely. Where non-deterministic intelligence operates in the middle, doing the work no team of humans can do at the volume and velocity now required.

The defenders who get this right won’t be the ones with the biggest security teams. They’ll be the ones with the best platform.

On Monday 23rd of February 2026, the IBM share price fell 13.2%. The worst single-day decline since October 2000. The trigger wasn’t an earnings miss or a leadership change. It was a blog post.

That morning, Anthropic published a piece explaining how Claude Code could automate the exploration, dependency mapping, and analysis phases of COBOL modernisation. The thesis, in their own words: “Legacy code modernisation stalled for years because understanding legacy code cost more than rewriting it. AI flips that equation.”

The Someday List Just Got an Honest Price

Every CIO I speak to has the same list. The names change, but the contents don’t; replatform a legacy estate; generate tests for the twenty-year-old codebase nobody dares touch; document the critical system whose architect left in 2019; migrate workloads off some ancient Java version; produce a complete audit trail for the regulator who started asking over a year ago...

All valuable, all on the someday list, but none of it happening.

The hardest part of the business case for any modernisation programme has always been “is it valuable enough to justify the people-hours?”

The cost of a human team doing the work was almost always higher than the value extracted. So the work sat. And sat. Until the next regulator, the next breach, or the next retirement made it urgent enough to fund a one-off project.

Where the Economics Have Shifted

Three categories of work have crossed the business case threshold.

Language migration. Take a COBOL estate you’ve been quietly trying to retire for fifteen years. The first task in any migration is understanding what the system actually does; historically a six-figure consulting engagement before a single line of code gets translated. McKinsey published a case study of one FinTech client with 20,000 lines of COBOL that was estimated at 700 to 800 human hours to migrate properly. After deploying genAI agents, they cut that estimate by 40%. A separate engagement with a top-15 global insurer reported greater than 50% acceleration in modernisation efficiency and testing. Those numbers reframe the conversation entirely.

Major version upgrades. Java 8 to 21. .NET Framework to .NET Core. Spring Boot 2 to 3. These come with release notes the size of a phonebook listing every breaking change. The work has always been mostly mechanical: identify which deprecated APIs are in use, produce the required changes, validate against existing tests. But the mechanical part still took a team of senior engineers six to twelve months. With the help of AI, the bill of materials for a framework upgrade now looks more like a sprint than a programme.

Regulatory uplift. The cadence of new regulation isn’t slowing (DORA, NIS2, EU AI Act). Traditionally, a regulation lands, you get twelve to eighteen months, and someone has to read three hundred pages of legal text, work out which controls apply, then go on a six-month evidence-hunting expedition through your CI logs, ticket system, and seventeen spreadsheets from 2019. AI can now handle much of the heavy lifting of reading the regulation, producing a structured control list, mapping each control to artifacts your platform already produces, and surfacing evidence gaps as engineering tickets. Compliance stops being a quarterly fire drill and becomes a continuous property of the system.

What AI Won’t Do

Agentic AI won’t magically solve all of this. It compresses the analysis, dependency mapping, and translation work that historically consumed the majority of any modernisation budget. Everything else still requires people. The data layer redesign. The runtime translation. The regulatory sign-off cycles that still take twelve to eighteen months in financial services. The organisational change management that determines whether the new system actually gets used.

What’s shifted is the balance of economics. The expensive, low-value toil is now cheap. The expensive, high-value judgement is now where your teams’ time actually goes.

Pick One. Start Small.

Most CIOs are framing AI as a question about new product development. Where can we ship faster? Where can we build something we couldn’t build before?

The highest-ROI AI investments for most enterprises won’t be in greenfield at all. They’ll be in the work you were never going to fund. The modernisations sitting on the someday list. The compliance backlog quietly accruing every quarter. The undocumented systems that have become organisational single points of failure.

Pull the list out. Reprice it. Start with one item; something with clear boundaries, moderate complexity, and a high enough profile that success will be visible but low enough risk that failure won’t take down operations. Use AI to do the analysis and documentation work that always made the business case impossible. Keep your engineers on the architectural, regulatory, and organisational calls because those are still where the value is created and the risks live.

The boring backlog you’ve been postponing for a decade just became the most strategic thing on your desk. Don’t waste it by overestimating what’s been solved, or by underestimating what’s now possible.

Are you doing okay? It feels pretty exhausting to work in the IT industry right now, and I think I know why.

There's a model in personal development circles called "Be, Do, Get". The idea is straightforward: you become something (a baker, an engineer, a leader), you do the work associated with that identity (bake bread, write code, make decisions), and you get the rewards (income, status, purpose). Our entire education and career is built on this model. And, if we're honest, so is most of our self-worth.

The model has worked for centuries, but AI is quietly dismantling the middle step, and with it, a foundational pillar of how we understand ourselves.

When the "doing" disappears

We've all seen the headlines: AI writes code, drafts legal briefs, generates marketing copy, diagnoses medical images. The conversation so far has focused almost entirely on economics: which jobs survive, which don't, and how quickly we need to reskill.

But there's a deeper story here than reskilling.

The World Economic Forum recently identified what it calls an emerging "occupational identity crisis": the loss of purpose, structure, and social belonging that follows when work disappears or fundamentally changes. Researchers at the University of Florida coined the term "AI Replacement Dysfunction" to describe a cluster of symptoms of professional identity loss, anxiety, insomnia, and a creeping sense of purposelessness when facing potential redundancy.

This is about more than “just” unemployment; it's about the slow erosion of feeling necessary. As The Brink put it, the real threat from AI isn't exploitation; it's irrelevance.

The "be" renaissance

If the "do" is increasingly shared, or handed to machines, then "be" becomes the differentiator. Not what you can produce, but how you think, how you relate, how you lead, how you make sense of ambiguity.

The CEO at JPMorgan Chase has been publicly advising people to focus on critical thinking, emotional intelligence, communication, and the ability to work well in collaborative settings. All “be” capabilities.

Who you are is becoming more professionally valuable than what you can do.

That shift prompted me to look beyond the usual tech news and I’ve been reading more psychology and philosophy recently: The Mind is Flat challenged my assumptions about the boundary between human and machine cognition. Man’s Search for Meaning reframed how I think about purpose when the work changes around you. And The Courage to Be gave me a framework for the anxiety that comes with professional reinvention.

The MIT Sloan School says “Philosophy is eating AI”. As a discipline, a dataset, and a sensibility, philosophical thinking increasingly shapes how AI systems reason, generate, and create. Helen Margetts from the Oxford Internet Institute observed that career prospects for philosophers have never looked better… a sentence that would have drawn laughter a decade ago.

We are building machines that need philosophy to function.

What this means for technology leaders

Most organisations are frantically investing in AI literacy and tool adoption. But those are table stakes. The real gap is in the human capabilities that make AI useful. The judgement to know what to build, the empathy to understand who you're building for, the communication skills to align stakeholders, and the ethical reasoning to navigate the tradeoffs that AI surfaces daily.

For most of modern history, we’ve invested perhaps 10% of our energy in “be” and 90% in “do”. The AI era invites (demands?) something closer to the reverse. That’s not a comfortable shift for an industry that prides itself on shipping, but might be the most important thing we build next.

AI is giving us back time that we immediately fill it with more doing. Instead, I’d urge everyone to develop the philosophical muscles that help us ask better questions, rather than just generating faster answers. We must find time to explore ideas that don't have an immediate ROI attached.

I was speaking with a CIO last week about their desire to transform their business away from individual, discrete projects towards something that fosters re-use and greater collaboration across teams. It’s a common ask, so I thought I’d share my notes from that meeting.

Over the past decade, the IT industry has seen developers as the new kingmakers and has done all it can to boost productivity of these teams. A large part of the Agile movement was to empower development teams to choose their own ways of working that will maximise value in their specific environment. Meanwhile, DevOps provided explosion of tooling, much of it solving the same problems in slightly different ways. The problem is that whilst we were optimising these local systems, organisations often lost track of the bigger picture and we now find ourselves with fragmented, “islands of value”.

The challenge presents initially as a tool consolidation exercise. But how do we convince developers who are perfectly happy with what they're doing to coalesce around a central set of tools?

Know where you’re going

Every transformation must begin with its “why”. Before you consolidate anything, you must get alignment on what success actually looks like. What are the benefits to the business? to teams? to individuals? Beyond shallow anecdotes and costs, why should we all go through the pain of migration, learning new tools, and making compromises?

The metrics you choose should map directly to the outcomes the business expects from this change. Typically, those fall into a few categories:

• For delivery speed, DORA metrics are the starting point — deployment frequency, lead time for changes, mean time to recovery, change failure rate. They’re straightforward to implement and widely understood. SPACE is more thorough, but it’s not easy, and “not easy” often means “never actually adopted.” Start where the friction is lowest and adapt from there.

• For productivity, look at DevEx framework. How fast are your feedback loops? How much cognitive effort does it take to get things done? In order for any change to deliver value is that the people involved must perceive improvement.

• For efficiency, you need to look more holistically at a value stream map of the end-to-end flow of work. Organisations are very good at drawing boxes connected by lines, and those within the boxes are generally good at improving things within their four corners. In my experience, the biggest efficiencies are found in the lines, the handoffs between teams.

• For improved security and compliance, track vulnerability trends across the whole portfolio, not team by team. A system breach is rarely one catastrophic failure; it’s typically a chain of seemingly innocuous issues that nobody saw in combination.

Find common ground, not common tools

We all have our preferences on ways of working and the best tool for the job, but compliance can’t be optional, and every team or project must meet a baseline standard, regardless of how individual teams prefer to work. As a business, what are our non-negotiables? What rules are sufficiently steeped in best practice and common sense that nobody can deny them?

I suggest the following as a good guide to SDLC best practice:

• No credentials in code. Accidentally committing secrets to a repository is one of the most common and most damaging security incidents in software development. The fix is automatic scanning that blocks the commit before it lands, not a policy that relies on developers remembering.

• No direct changes to code. Protected branches ensure nothing reaches main without going through a merge request. No exceptions, no shortcuts under delivery pressure.

• Nobody ships without a second pair of eyes. Mandatory code review before anything merges to main is basic engineering hygiene.

• Deployments to production require explicit approval. In highly regulated environments, compliance may require that the person who writes the code cannot be the only person who decides it goes live. This is separate from code review (which is a quality control); this is separation of duties.

• Licence compliance runs automatically. Most teams have no visibility into the licence obligations sitting inside their dependency tree. Flag incompatible licences, block the genuinely problematic ones. A software audit from KPMG is a lot less fun than it sounds.

• Mandatory security vulnerability scanning. Both your code and its third-party dependencies bring risk. Scanning must be automatic and enforceable, not optional per-project configuration that teams can quietly skip. You may additionally agree that code cannot be promoted to production with known vulnerabilities.

• Infrastructure is code and must be treated like it. If teams are writing Terraform, Helm charts, or Kubernetes manifests, a misconfiguration is as dangerous as an application vulnerability. IaC scanning catches overly permissive IAM roles or open security groups before they’re deployed.

• Every project produces a Software Bill of Materials (SBOM). A full inventory of every component in a delivered artefact. You can’t manage what you can’t see, and increasingly, your customers and regulators will demand this.

Making the right thing, the easy thing

Individual teams reinventing the pipeline is waste that accumulates silently. Most organisations have unknowingly invested an enormous amount of engineering time in standard plumbing. Most of the development teams I’ve met would like to think they’re special, but the truth is that the process of building, testing, and deploying software a solved problem.

Platform teams should build components that development teams can adopt and combine to create a “golden path” for software delivery that is faster, easier, and better than anything a team would build on their own.

• Standard project scaffolding means every new project starts from a known-good baseline. Correct structure, pre-wired pipeline, compliant from day one. A developer spins up a new project and it already has scanning, testing, and deployment configured. No tickets, no waiting, no dusty PDFs files to read.

• Reusable pipeline components. Build, test, scan, and deploy solved once, used everywhere. Teams shouldn’t each be independently solving the same CI problems. When the platform team improves a component, every consumer benefits automatically. This is the compound interest of platform thinking.

• Managed, shared CI infrastructure eliminates the overhead of teams maintaining their own runners. Shared, platform-managed compute is more reliable, more efficient, and easier to audit.

• Controlled dependency sources provide a managed, local cache of dependencies, rather than teams pulling directly from the public internet.

The psychology here matters as much as the technology. Golden paths work when they’re genuinely better than the alternative. If the platform offering is slower, more complex, or less capable than what a team can build themselves, adoption will be a constant battle. The platform team has to think like a product team; developers are customers, and will vote with their feet.

Breaking the stalemate

When I walk through this framework with organisations, the most common reaction isn’t disagreement, it’s “we know all this, we just haven’t done it”.

The gap between knowing and doing is almost always organisational, not technical. What's missing is someone able to step above a tool consolidation exercise to define the non-negotiables and hold teams to account. One the “do nothing” option is removed, building re-usable components becomes the obvious answer.

The goal isn’t uniformity for its own sake. It’s giving teams the freedom to focus on what makes their work unique by removing the need to reinvent everything that doesn’t.

What would your engineering organisation look like if every team could focus entirely on their domain, knowing the platform had everything else covered?

Every second post across all my socials right now is about the wonders of ClaudeCode, Ralph, and now Clawdbot Mortbot.

The capabilities are real, and so are the costs. Federico Viticci over at MacStories managed to burn through 180 million API tokens in his first month - roughly $3,600 in API costs.

Platform engineering teams are about to inherit this AI cost problem. Every executive has seen a LinkedIn post about how agentic AI can magically turn ideas from an email into ready-to-deploy production code, and they want it now.

The patterns you’ve built for cloud governance, recharge models, and golden paths are about to become essential for AI too. The question is whether you’ll be ready.

The pricing landscape has shifted beneath everyone’s feet

The costs of large language models shifted significantly in 2025, and things got heated between vendors. In May, Anthropic introduced “Priority Tier”. By August, new weekly rate limits for Claude Pro and Max were added after the company admitted some subscribers were “consuming computing resources worth tens of thousands of dollars monthly”. Fast forward to 2026, Anthropic is at war with third parties and we’ll find out if Elon wins damages after OpenAI dropped its nonprofit mission.

Subscription tiers have proliferated and token limits have become a real constraint. Premium pricing for complex reasoning has emerged as its own category, with extended thinking modes and deep research capabilities commanding higher rates. Users are hitting Claude Code limits mid-session, finding that agentic features burn through allocations faster than anyone anticipated.

What makes this particularly challenging is the unpredictability. Unlike traditional infrastructure costs that scale somewhat linearly, AI spending follows the complexity of the task. A minor change in prompt structure can double inference costs overnight. An agentic workflow that tests well in development can blow through production budgets in hours.

IDC warns of an “AI infrastructure reckoning,” predicting that Global 1000 organisations will underestimate their AI infrastructure costs by 30% through 2027. That’s not a forecasting gap you can explain away in a quarterly review.

This will become a platform engineering problem

Platform teams are being pressured to enable AI capabilities across the SDLC, but nobody’s talking about governance, cost controls, or environmental impact. Execs want the magic they’ve seen in vendor demos, and developers want to replicate that cool thing they saw on Twitter last week. The platform team gets to figure out how to deliver it without creating the next cloud spending crisis.

Everyone is so excited by capability, that nobody is thinking about token economics or model capability tiers. It doesn’t help that most AI tools default to maximum capability and interfaces don’t surface cost information.

But when Opus 4.5 costs five times more than Haiku (that can handles routine tasks just as well) and Opus 4 incurs a 300% markup over the new Opus 4.5 model, that knowledge gap becomes expensive. A developer needing help with a function selects the most capable model, feeds it the entire codebase as context, and moves on unaware they just spent £2 on a £0.10 task. Multiply that by hundreds of developers, thousands of times daily, and you’ll find yourself in a very uncomfortable meeting before the quarter is done.

Platform teams can help close this gap by making cost-aware choices easier.

• Golden paths steer users towards the most efficient model for each task.

• Self-hosted, open source models like DeepSeek, Qwen, and Llama have become viable alternatives for many tasks.

• Context caching can unlock a 90% token discount automatically.

• Semantic code indexing retrieves targeted context instead of including entire code repositories through RAG.

• Batch processing for async workloads halves costs without user intervention.

• Surfacing estimated costs before execution encourages deliberate usage.

• Per-team cost attribution makes spend visible to those who can influence it.

• Quotas, spending limits, and recharge models provide guardrails and allocate costs to the relevant department.

The goal isn’t to slow people down; it’s to make the economical choice the path of least resistance.

The FinOps Sequel: AI Edition

If this feels familiar, it should! Platform engineering exists partly because of what happened during the public cloud boom. Back in 2020, Gartner estimated that 80% of organisations would overshoot their cloud IaaS budgets and today industry surveys still find that up to 32% of enterprise cloud spend is actually just wasted resources.

The organisational response was FinOps—financial operations practices that brought visibility and accountability to cloud spending. Platform teams became central to this work, building the tagging standards, cost allocation mechanisms, and governance frameworks that made cloud economics manageable.

AI spending is following the same trajectory, but compressed. Gartner estimates $644 billion will be spent on generative AI in 2025, with cost management emerging as a core challenge. IDC predicts that by 2027, 75% of organisations will combine GenAI with FinOps processes. The FinOps Foundation has already published frameworks for AI cost management, introducing metrics like cost-per-inference and cost-per-action for agentic systems.

The platform teams that built cloud governance muscle are well-positioned here. The concepts translate: visibility into consumption, allocation to cost centres, guardrails that enable rather than block, self-service within boundaries. The implementation details differ — tokens instead of compute hours, model selection instead of instance types — but the organisational patterns are the same.

What platform teams should do now

The pressure to enable AI capabilities isn’t going to go away. But platform teams have an opportunity to shape how their organisations adopt these capabilities, rather than cleaning up the mess afterward.

Build cost visibility before you need it. Implement token tracking by model, team, project, and use case, before finance comes asking. The organisations that built this infrastructure early in their cloud journeys had enormous advantages over those that retrofitted it later.

Design for vendor agnosticism. The model landscape is evolving too quickly to bet everything on one vendor. Very few organisations now have a single-cloud model. Provide your developers with a consistent interface that lets you change the underlying providers as economics and capabilities shift.

Extend your golden paths to include AI. If your platform provides opinionated, well-supported paths for common development tasks, AI integration should be part of that story. Don’t leave teams to figure out authentication, cost management, and best practices on their own.

Start the finance conversation proactively. Bring your CFO’s team into AI planning early. Establish governance frameworks before they’re urgently needed. Position your platform as the solution to AI cost governance, not just another source of AI capability requests.

Push back on unsustainable requests. Help stakeholders understand the cost implications of their choices and design solutions that balance capability with sustainability.

The AI free lunch was generous while it lasted. Platform teams that prepare now will be positioned to enable AI adoption that actually scales. Those that don’t will spend the next few years in reactive mode, building governance frameworks under pressure while costs spiral.

You’ve done this before with cloud. You know how the story goes.

For more perspectives on platform engineering, AI economics, and the human side of technical transformation, subscribe to The Chief Therapy Officer—monthly insights for technical leaders navigating organisational change.

Platform engineering is, at its core, an interface design problem. How do we provide sufficient abstraction to hide complexity while still giving users meaningful control? How do we make infrastructure consumable without making it feeling overly constrained?

We’ve spent a decade paving golden paths. We’ve built portals, written templates, catalogued services. The friction that once defined infrastructure provisioning has been dramatically reduced.

And yet, there’s always a developer who needs something slightly outside the paved path. Always an edge case that doesn’t fit. Always a troubleshooting session that should follow a known pattern but still demands an engineers’ time.

We’ve smoothed the journey, but we haven’t eliminated the need to travel.

From Golden Path to Preferred Route

MapQuest was one of the first mainstream “killer apps” of the Internet. Before any long journey, you’d use MapQuest to plot the most optimum route, print it off, and do your best to manage a pile of paper without crashing. Miss a turn? You were on your own! The system gave you a path, but no ability to adapt.

Early GPS was a game changer. We could now get turn-by-turn directions that meant you could keep your eyes on the road, but you were still following a predetermined route. The path was fixed at the moment you pressed “Go”.

Modern navigation is fundamentally different. Your phone reroutes dynamically based on traffic conditions, road closures, or your own mistakes. Take a wrong turn and the system simply recalculates. It doesn’t require you to pull over and re-enter your destination, it adapts in real time.

Recently, Apple Maps did something that surprised me. It suggested my “preferred route” to a destination I visit regularly, even though another route was technically a few minutes faster. The system had learned not just where I wanted to go, but how I prefer to get there. It understood my context, not just my destination.

Modern navigation combines real-time awareness of conditions, the ability to change course dynamically, memory of preferences and past journeys, and the intelligence to orchestrate it all.

This is where platform engineering is heading.

Golden paths are our MapQuest printouts - valuable, but static. They assume we know the journey before we start and that nothing will change along the way.

Internal developer platforms are early GPS: more responsive, but still path-centric. They help developers navigate known terrain faster.

But developer teams aren’t taking identical journeys. They’re building different products, serving different customers, operating under different constraints.

What if the platform could navigate terrain, not just provide directions?

Introducing Kagent

Kagent is a recent addition to the CNCF family that provides “an open source programming framework designed for DevOps and platform engineers to run AI agents in Kubernetes”.

Great…. but what does that actually mean?

A lot of AI tools can answer questions or explain concepts, but they can’t actually do anything. Kagent lets platform engineers build autonomous AI agents that have the ability to query cluster state, check recent deployments, correlate logs with metrics, and use advanced reasoning and iterative planning to autonomously solve complex problems.

That’s certainly useful, but what makes this interesting to me is how it achieves this and what that architecture might enable in the future.

Kagent is Kubernetes-native and declarative. Agents are custom resources that inherit existing RBAC, GitOps workflows, and governance patterns. You can use the machinery you’ve built to control infrastructure to control agents too.

Kagent separates reasoning from action. An agent consists of an LLM with a defined scope that is given access to tools that observe or change infrastructure environments. Kagent ships with an impressive set of tools covering Kubernetes, Istio, Helm, Argo, Prometheus, Grafana, Cilium, and others. Some observe; others effect change. All tools are Kubernetes custom resources (ToolServers) that can be shared across multiple agents. And, because kagent fully supports MCP, you can integrate capabilities from other platforms too.

Where this might lead

Right now, kagent’s users are platform engineers. The developer experience remains unchanged — golden paths, self-service portals, the interfaces we’ve built over the past decade.

But the building blocks kagent puts in place are exactly what we’d need to offer agents as the interface to the platform, not just tools behind it.

The platform’s next user might not be human. We’ve spent years optimising for human users; designing portals, writing documentation, crafting templates. But if agents can navigate infrastructure on behalf of platform engineers today, they could do it on behalf of developers tomorrow. The “user” of your platform might increasingly be an agent acting on someone’s behalf, not the someone themselves.

This changes what good platform design looks like. Clear interfaces matter less than well-described capabilities. Portal UX matters less than API discoverability. Documentation written for humans matters less than context an agent can consume.

From paved roads to terrain-aware guides. Golden paths work brilliantly for known journeys, but platforms serve diverse teams with diverse needs.

An agent doesn’t need a pre-paved path. It needs capabilities and judgment to navigate novel terrain. A golden path says “here’s the route”, but an agent says “I understand where you’re trying to go, and I can figure out how to get there, even if no one has taken this exact journey before”.

Golden paths don’t become obsolete. They become one input among many.

From automation to agency. Traditional automation executes predefined sequences: if X happens, do Y. Powerful, but brittle when reality deviates from expectations.

Agency means reasoning about what sequence is needed. The platform engineer says “this service should be healthy” rather than specifying every check. The agent figures out what healthy means, how to verify it, and what to do if it’s not.

The question for your next strategy session

Every platform team should be asking “which journeys in our current platform exist because a human needs to walk them, versus which exist because we assumed a human was the only option?”

Not every path will transfer to an agent, but it could be more than you expect.

The platform engineering discipline has spent a decade getting very good at paving roads. The next phase might be about training guides who can navigate terrain we haven’t paved yet, and perhaps never will.

There is a fundamental cultural conflict in platform engineering that’s often overlooked.

Platform teams typically approach their work from a perspective of standardisation and reliability. They’ve dealt with the fall-out from inconsistent deployments, security incidents, and audit failures. Their natural response is to reduce variability. A single, perfect, golden path for everyone to follow.

Developers, meanwhile, are optimising for something completely different. They’re focused on solving specific problems in the fastest way possible. Creative autonomy is core. And, any mandate to work in a particular way becomes the problem, separate from the technical merits of what you’ve built.

Individual teams making rational decisions create organisational fragmentation.

A team avoids your centralised platform because their tools are slightly better for their specific workload. When twenty teams make that same choice, you end up with fragmented tooling, inconsistent processes, and knowledge sharing completely evaporates. Each team optimises locally while organisational risk compounds.

Development teams optimise within their local context because that’s what they can see and control. Platform teams operate with organisational visibility, trying to optimise globally. This maps directly to what theorists call “local vs. global rationality”: decisions that make perfect sense at the team level create dysfunction at the system level.

The usual response is to crack down harder; mandate full adoption, close all escape hatches. But this pushes workarounds deeper underground where you have even less visibility.

The better question is: how do we make safety compatible with autonomy?

Guardrails over Gates

The shift that I’ve seen work is distinguishing between what genuinely must be universal and what can be flexible. Guardrails are baseline standards that everyone must meet, regardless of individual requirement or implementation.

You don’t mandate that everyone must drive the same car, but you do require that all cars have functioning brakes. Platform engineering needs this same distinction. The brake isn’t optional, but the vehicle choice is.

Guardrails define the boundary conditions, not the implementation.

I recently worked with a large financial services firm that had spent a significant amount of time and money to build a standard process that nobody would adopt. With some help, we were able to agree on just three non-negotiables: all production deployments must pass security baseline; all services must emit standardised metrics to their observability platform; and all secrets must be retrieved from their secrets management system at runtime.

Everything else became flexible. Teams could structure their repositories however made sense. They could choose their own testing frameworks. They could define their own build steps and use their own tools. Adoption went from 17% to 86% in six months, but more importantly, the platform team’s relationship with developers shifted from adversarial to collaborative.

Every forced choice should have a clear answer to “what organisational risk does allowing flexibility here create?” and when defining a choice, we should ask ourselves “what can we do to offer maximum flexibility whilst mitigating risk?”.

Components over Completeness

Most platform teams think in terms of “the platform” - a single, cohesive offering that teams either use or don’t. Developers think in terms of capabilities they need right now for the problem they’re solving.

Platform-as-product thinking means offering composable building blocks.

The key to modular adoption is treating your platform like a product with APIs, not a prescribed workflow. Your CI/CD pipeline shouldn’t be a monolithic template teams must accept wholesale. Instead, expose capabilities like security scanning, deployment automation, and secrets retrieval as services teams can integrate into their existing processes.

You can, of course, offer an example of how to integrate these together, but teams should have choice on what works best for them. A team building a new service might adopt everything. A team with a legacy application might have existing capabilities that they can more easily adapt to meet guardrail requirements.

This isn’t about letting teams skip your guardrails; those remain universal. It’s about letting them compose their developer experience from your components rather than forcing them into your prescribed workflow.

Consider security scanning. Rather than mandating a specific tool, require that all scans output results in a standard format like SARIF (Static Analysis Results Interchange Format) and that production deployments must have no high or critical level vulnerabilities. Teams can choose Snyk, Semgrep, or SonarQube based on their language and workflow, but they all feed into your centralised security dashboard. You get consistent visibility across the organisation without forcing tool standardisation where it doesn’t create value.

This approach requires verification mechanisms that don’t depend on teams using your specific implementation. Trust, but verify! Shift from process compliance to outcome verification. In the example above, standardised security scanning results can be independently checked. Similarly, you might make certain observability metrics mandatory and perform credential scanning across repositories to ensure other guardrails are being followed correctly.

Making your platform the path of least resistance

Once you’ve established guardrails and modular capabilities, you create new opportunities in how you position your platform to developers.

Developers always have three options. They can build their own solutions from scratch, meeting every guardrail through custom implementation. This is technically possible but requires significant effort on their part. They could selectively consume platform components, using your secrets management to meet that guardrail, building their own deployment pipeline. Or they can adopt the platform fully, getting guardrail compliance baked in plus additional capabilities they didn’t have to build.

The challenge is to make that third option the obvious choice without making it mandatory.

I’ve seen this work when platform teams explicitly communicate the trade-offs. “You can absolutely build your own deployment pipeline. Here’s the security scanning integration you’ll need to implement. Here’s the audit logging format. Here’s where your metrics need to flow. Or, use our pipeline and get all of that plus automated rollbacks, deployment analytics, and integration with our incident management system.”

The message becomes: meeting guardrails is non-negotiable, but we’ve done the work to make that painless if you use our components. The more you adopt, the less undifferentiated heavy lifting you do yourself.

Making room for reality

No matter how well you design your standards, edge cases will emerge. A critical hotfix that needs to skip the usual approval workflow. A legacy system that can’t integrate with your secrets management yet. The worst thing you can do is force developers to break out of your platform entirely when they hit these cases.

I recommend that you build the exception process directly into your platform. One team I worked with implemented a simple exception system in their CI pipelines whereby developers could set an “override_security_scan” flag with a required justification field. The deployment proceeded, but it triggered a notification to the security team and got logged for weekly review. Most overrides turned out to be legitimate edge cases, and the pattern analysis helped the platform team identify where their guardrails needed adjustment.

Building platforms that flex

The framework to building platforms that developers choose to use is straightforward:

• Establish universal guardrails based on genuine organisational risk, not convenience.

• Build modular capabilities that teams can consume independently rather than forcing wholesale adoption.

• Make your platform the path of least resistance by absorbing the complexity of compliance, not by eliminating choice.

• Design exception handling directly into your system so edge cases don’t force teams to abandon you entirely.

Crucially, this approach requires a different relationship with your developer community. Instead of positioning yourself as the gatekeeper of “the right way,” you become the team that makes hard things easy. You’re not eliminating their autonomy; you’re reducing their toil. The platform becomes valuable because it solves real problems, not because leadership mandated its use.

I’ve watched this transformation happen at organisations ranging from 20 to 20,000 engineers. The mechanics vary, but the fundamental shift remains the same: from standardisation through control, to standardisation through attraction.

Like any product, the real measure of a successful platform isn’t adoption, but whether developers would choose your platform even if they weren’t required to.

One size does not fit all, but well-designed guardrails fit everyone.

If you enjoyed this article, you might also want to check out the submissions from other CNCF Content Club members, including:

• Steve’s piece about why making platforms optional forces platform teams to build what developers actually need instead of mandated golden cages.

Want to dive deeper into building platforms that developers actually want to use? Subscribe to The Chief Therapy Officer newsletter, where I share monthly insights from the field on turning platform engineering theory into adoption reality.

Your platform has been live for eight months. You’ve celebrated progress in weekly standups. You’ve walked the CEO through the architecture. You’ve defended the investment to finance. Yet, developers refuse to give up their rickety Jenkins box.

You’ve built everything the platform engineering playbooks recommend. Golden paths, self-service portals, clear standards. Your team has deep technical expertise. But you can’t convince a single development team to voluntarily migrate.

The problem isn’t your engineering. It’s that nobody taught platform engineers what tech sales teams have known for decades.

There’s a pattern in my conversations with hundreds of platform teams over the past four years. Teams struggling with adoption spend roughly 85% of their time building technical capabilities and 15% talking to users. Teams achieving strong adoption reverse those percentages. Technology is rarely the differentiator.

Why Are Developers So Stubborn?

I’ve lost count of the painful conversations I’ve had about platform adoption.

There seems to be a universal assumption that developers will migrate because the new platform is objectively better. Better architecture, better security, better metrics. The logic seems irrefutable. It’s completely disconnected from reality.

Developers are usually happy with their current solutions.

Sure, it’s probably held together with digital duct tape, but they’ve invested time learning those tools and achieved sufficient skills to make them productive. Your platform represents risk, learning curve, and a painful migration that nobody has time to do it. More fundamentally, developers value autonomy and your platform asks them to surrender control and trust your team.

I watched one large enterprise announce a Q3 migration deadline. Six months later, they had moved 4 of 23 teams … and two of those migrations were teams the platform engineer managed directly.

If you want development teams to adopt your platform, you begin by establishing trust. Listen to them. Be curious, not judgemental, about how they operate. Understand their challenges. Find the pains that would be solved by a better solution. Ask them what would influence a change and what might help make that process more smooth.

Sales is often seen a dirty word in technology teams, but that’s exactly what a good sales discovery session looks like! Deep empathy paired with active listening.

What you need to learn from Sales

You don’t need to become a salesperson, but borrowing a few of their methods will make you dramatically more effective at attracting users to your platform.

Question with structure, not just curiosity. Great discovery follows a pattern called SPIN. Situation (understand their current state), Problem (identify what’s broken), Implication (explore what that problem costs them), Need-payoff (help them articulate why solving it matters). Instead of random questions, you might ask “How do you deploy to production today?” (situation), “What elements are the most brittle in that process?” (problem), “How much time does your team lose when it breaks?” (implication), “What could you achieve if you got those hours back each week?” (need-payoff).

Let them discover the pain, don’t tell them. This is called trap setting, though that sounds more manipulative than it is. You’re asking questions that lead people to realise their current state is untenable. “Walk me through your last production incident. How long to detect? How long to fix? How many people involved? What were they working on before they got pulled in?” By the time they’ve talked through it, they’ve convinced themselves there’s a problem worth fixing - which is far more powerful than you telling them.

Connect technical problems to business impact. Sales teams call this building an implication chain. A development team might not think that their rickety Jenkins server is a big problem. Follow the chain: broken builds → developers wait → context switching → reduced productivity → delayed feature delivery → losing competitive advantage→ loss of revenue. Each link helps establish the context of the problem, it’s business impact, and builds urgency.

Surface objections early. Ask “What concerns you about changing your current setup?” in your first conversation, not your tenth. You’ll hear the real blockers: “We tried something similar before and it failed”, “The team doesn’t have time to migrate”, or “We need to keep our autonomy”. Don’t argue or dismiss - dig deeper. “That previous platform failed - tell me what happened. Was it the technology, the support model, or something else?” If they say “no time to migrate,” that’s actually “I don’t trust the ROI justifies the disruption.” The objection reveals what really matters. Now you’re having the right conversation.

Know what you still don’t know. After each discovery conversation, do a gap analysis. What critical information is missing? Who else needs to be in the conversation? What assumptions need validation? Sales teams track this obsessively because deals die from unknown unknowns. Platform adoptions do too - usually because you didn’t talk to the decision makers, or know about the re-org happening next quarter.

Start With One Conversation

Your first discovery conversation doesn’t need to be perfect. Pick one team next week. Ask about their last production incident. Follow the implication chain. Surface their concerns early. Take notes on what you still don’t know.

That platform team with 4 of 23 migrations after six months? Three months after they started running structured discovery, they hit 18 teams. Same technology. Different approach.

The rickety Jenkins box isn’t your competition. The pain of change is. Discovery helps you understand whether the pain of staying put exceeds the pain of switching. Once you know that, you know whether you have a product worth adopting.

Last month, I sat across from a platform engineering director starting a new role at a major retail company. She'd just been informed that her budget would not be increased to cover the company’s ever growing public cloud costs. "Our developers treat compute like it's free" she said. "They spin up environments without thinking about the costs".

Sound familiar? I've had this conversation dozens of times. Platform teams work hard to abstract away infrastructure complexity, but in making resources feel effortless to consume, an unintended consequence is that developers have lost any connection between their decisions and the costs they generate.

The Psychology of Free Resources

When platform resources feel free, teams over-provision by default. They leave staging environments running indefinitely. They choose premium services for experiments that could run perfectly well on basic infrastructure. They architect systems that are easy to develop but are cost inefficient at scale.

It's not malicious, it's human nature. Without price signals, we lose the feedback loop that naturally moderates consumption. The challenge isn't that engineers don't care about costs; they simply have no mechanism to understand the relationship between their technical choices and financial impact. We've optimised for developer experience but eliminated cost consciousness in the process.

Free Compute Creates Expensive Problems

I witnessed this dynamic play out dramatically at a large US media company. They'd secured substantial capex to build an internal cloud platform; millions invested in servers, storage, and networking to give their development teams fast, reliable compute resources. The promise was simple: product teams could provision what they needed without constraints or delays.

Initially, it worked beautifully. The infrastructure was fast, responsive, and developers loved the experience. But three years later, the story had changed. The Finance team had been progressively reluctant to approve new hardware spend. As utilisation grew and servers became oversubscribed, performance degraded. Provisioning requests started queuing. What had been a competitive advantage became a source of daily frustration and the cloud team were under fire from all directions.

When I asked the CTO about their approach and suggested that an internal cost recharge mechanism is necessary, his response was "IT shouldn't constrain the business” - delivered with conviction, as if it represented enlightened technology leadership.

The dangerous part isn't the aspiration. Nobody wants to hold back innovation, but when we provide platform services for free, we're not eliminating constraints, we're making them invisible until they inevitably explode into crisis points further down the line.

Building an Internal Marketplace

What if your platform worked more like an internal marketplace? If that media company had implemented internal cross-charging, teams working on a new service projected to generate £2M in annual revenue could easily justify paying £50K annually for the compute resources they needed. The cost becomes a line item in their business case, just like staffing costs or external software licenses.

Like any business, cross-charging ensures innovation is backed by solid financial foundations. Teams that can't justify their platform costs need to consider the viability of their project.

While the benefits of internal cross-charging are compelling, the implementation challenges in large enterprises are substantial. Putting cultural change to one side, there are significant operational overheads for developers, platform engineers, as well as legal and finance teams:

• Development teams must take on the additional budgeting work, including cost estimations as their project scales or experiences usage fluctuations.

• Platform teams must provide timely, accurate and reliable consumption data to consumers - which is often lacking from off-the-shelf software.

• Legal and Finance teams must play an integral part in ensuring that any proposed cross-charge mechanism is lawful. This can be particularly challenging where platform teams serve teams across different legal entities or countries.

The most successful implementations I've seen start with simple “t-shirt sized” pricing models, rather than precise usage billing. The key is to recognise that perfect, to-the-penny cost attribution isn't the goal; it’s about creating cost awareness and accountability.

Even imperfect cross-charging systems generate better resource decisions than no financial visibility at all.

Gentle Nudges Can Make a Big Impact

Given the complexities of formal chargeback systems, many organisations find surprisingly good results from simpler “showback” systems that show teams the cost of their consumption to the business, even though they're not directly billed.

Behavioural economists call these "nudges" - gentle design choices that guide better decisions without creating friction.

“Showback” provides cost transparency through dashboards, reports, and interfaces that show teams what their platform usage costs, even though they're not directly billed. It's the middle ground between completely free resources and full financial accountability; teams see the impact of their decisions without the operational overhead of internal billing systems.

Simple examples work best: monthly dashboards that show each teams’ platform spending trends, environment provisioning forms that display "This configuration costs approximately £x per month," or service catalogs that highlight cost-effective alternatives alongside premium options. One customer managed to reduce platform consumption by 42% after analysing server utilisation and suggesting right-sized configurations alongside the estimated cost saving for the company.

The psychology is powerful. When teams can see that their experimental environment costs £500 monthly while sitting idle, they naturally develop cleanup habits. When they discover that premium database instances cost 3x more than standard ones, they start questioning whether every workload truly needs premium performance or implement a caching system.

Showback succeeds because it preserves autonomy while creating awareness. Teams make their own decisions about trade-offs between cost, performance, and convenience, but they're making those decisions with full information rather than blind assumptions about "free" resources.

Beyond Cost Control to Cost Intelligence

Teams that understand the financial impact of their technical decisions make better architectural choices, implement more thoughtful resource management, and collaborate more effectively with business stakeholders.

This approach scales platform engineering in ways that pure technical solutions cannot. When engineers become conscious consumers of platform services, they naturally drive demand toward the most valuable offerings while reducing waste on peripheral resources.

The platform team's role evolves from infrastructure provider to product manager, continuously improving services based on usage patterns, cost feedback, and customer success metrics.

Your Next Steps

If you're seeing platform costs grow faster than platform value, consider starting with simple cost visibility. Create a monthly dashboard that shows platform spending by team or project. Share it widely and observe what questions emerge.

Then ask your teams: "What would change about your platform usage if you could see the cost of each service at the point of provisioning?" Their answers will guide your next moves toward cost-conscious platform culture.

The goal isn't cheaper platform engineering—it's more intentional platform engineering where cost awareness enhances rather than constrains innovation.

This article topic was suggested by the content club set up by the CNCF Platforms Community. Each month we choose a topic and invite anyone to contribute articles, videos, podcasts or commentary. If you enjoyed it, you might also like the follow related articles from other platform engineering practitioners. If you’d like to take part, come visit us on our #content-club Slack channel.

• Abz shared the method he follows to bring infrastructure costs down. He highlights that “the real work isn’t just technical - it’s keeping teams aligned on business value, impact, and outcomes”.

• Graziano highlights how the efficiencies from improving developer experience can also lead to positive business outcomes.

I get asked a lot about my opinions on AI and its future. As technologists, I feel we spend so much time looking forward that we forget to look at what stood before. There’s plenty of hyperbole out there, but my views tend to be more grounded; shaped by what I’ve seen play out in the past.

History shows us that truly disruptive technologies tend to follow a similar trajectory. From cloud computing to mobile to AI, the pattern repeats, with each stage setting the foundation for the next.

So, here’s my view of where we’re at, where we’ve been, and what might lie ahead for us in the dizzying world Artificial Intelligence.

Breakthrough

A breakthrough occurs when a technical achievement suddenly becomes visible and accessible to the public. For AI, this was the arrival of tools like ChatGPT, DALL·E, and Midjourney. They weren’t just new apps, they were cultural events that captured imagination and gave non-experts access to something that previously lived in research labs.

Competition

Once the potential is clear, the gold rush begins. Multiple players rush in to stake their claim, each racing to build better, faster, or cheaper versions. We see rapid improvements as vendors compete for mindshare and market relevance; even if most of them are solving the same problem in slightly different ways.

Commoditisation

Eventually, the core tech stabilises and a few platforms emerge as dominant. Differentiation slows. Instead of trying to beat the top players (like OpenAI or Anthropic), others shift their energy to building on top of them. Creative momentum returns. The focus moves to solving real problems, building useful products, and designing better experiences. Trust, governance, and alignment start to matter more: which platform should you bet on?

Integration

With little room left to compete on raw capability, providers look for new ways to maintain market share. AI becomes an embedded feature of other products. It shows up everywhere … in email, customer service platforms, productivity apps, design tools, and more. It’s no longer just a product; it’s a vital ingredient.

Networking

As the ecosystem explodes, a new problem emerges: fragmentation. Users love having access to powerful tools, but hate their siloed nature. They demand interoperability. Over time, vendors respond with protocols, APIs, or standardised runtimes that allow technologies to connect, delegate, and collaborate. In the cloud world, when Google was losing ground to AWS, they released Kubernetes as a common, unifying layer. We’re seeing similar moves in AI now with initiatives like A2A and Model Context Protocol (MCP).

Specialisation

Over time, the once eye-watering costs begin to drop and efficiency improves. The technology becomes portable, cheaper, and more flexible. It becomes viable in industries or environments that previously couldn’t support it. We start to see domain-specific solutions emerge; tailored versions optimised for healthcare, finance, manufacturing, education, etc. What began as general-purpose evolves into specialised vertical stacks. Each one kicking off its own inner loop of innovation.

Recomposition

Eventually, we start seeing new, innovative uses of the technology that reimagine existing markets. Uber didn’t just make a taxi app; they combined GPS, mobile payments, and real-time coordination to create something game-changing. With AI, we’re starting to see the same: novel combinations of capabilities that disrupt existing markets, often in subtle but powerful ways.

Adjacency

The final phase is the least predictable, and arguably the most exciting. Entirely new products, industries, or behaviours emerge that weren’t previously possible. It took a combination of disparate innovations and cultural shifts for YouTube to create something new. We don’t know yet what AI’s adjacent industries will look like, but they won’t be improved versions of what we see today; they’ll be something entirely new, enabled by AI, not defined by it.

Final Thoughts

This cycle isn’t unique to AI. We’ve seen it with the internet, mobile, and cloud. Each time, the phases might play out slightly differently, but the core pattern holds. Hopefully, understanding where we are in that journey can help you cut through the noise and focus on what really matters next.

Gather round everyone, and let me tell you about the time I built "the cloud" in a weekend.

Okay, not the cloud in the AWS/GCP/Azure sense—there was no Kubernetes, no infrastructure-as-code, no auto-scaling groups or global edge networks. Just a simple portal, a few email templates, and a bunch of humans having slightly better conversations with each other. But in the eyes of the people using it? It was the cloud. It gave them what they needed. And more importantly, it helped a team reframe what they were already doing in a way that made them feel proud and appreciated.

This all happened many years ago while I was consulting, and it's one of those stories that sticks with me because it highlights a theme I see again and again in platform engineering: most of the really gnarly problems aren’t technical; they’re human.

The Setup

I was invited to speak with a mid-sized company where the executive had some internal conflict on how they could “adopt the cloud”. Their internal IT team said it couldn’t be done because of security and lack of budget. Tensions were high because some of the exec had been hearing from their peers at other firms of how great their cloud projects were going.

At first glance, it seemed like a familiar standoff. Leadership wanted agility and modernity. IT was stuck in risk mitigation and operational realities. Both sides had solid reasons, but they were talking past each other.

So I started digging—not into the network diagrams or IAM policies, but into what people were actually trying to achieve. And what I discovered was that leadership didn’t really want “the cloud”. They wanted the experience they associated with cloud.

They wanted self-service. Speed. Simplicity. A nice portal where someone could click a few buttons and get a virtual machine without waiting weeks.

That wasn’t a technical problem. That was a perception problem.

The Real Ask

I sat down with the IT team and asked: “What are the three most common virtual machine requests you get?”

They squirmed. They weren’t used to thinking in terms of patterns or products. They were used to handling one-off tickets. One request said 4GB RAM. Another wanted 6GB. One person asked for “whatever is fastest,” while another just forwarded an email chain with 17 contradictory replies.

When I suggested we boil things down to small (2GB), medium (4GB) and large (8GB), they immediately pushed back. “What if someone needs 6GB?” they asked. “Or 3.5?”

They were stuck on precision. But the users? They were just trying to get work done. They didn’t want perfection—they wanted something that worked.

So, over a weekend, I built a simple, stylish website and created some html-formatted email templates. Users could pick a size, enter their details, and click submit. That sent a basic email to the IT team with desired build spec and contact details. The IT team still did the build manually, but when they were finished, they’d use the fancy email template to inform the user their machine was ready. The template included useful info like how to login, how to request additional software, and how to raise a support ticket if needed.

All stuff they were already doing, just now packaged nicely and predictably.

The Result

By Monday morning, the team had their new “cloud portal”. Users were thrilled. Leadership was thrilled. And the IT team, initially skeptical, started getting praise from across the company. Not for being faster (they were doing the same work as before), but for feeling more responsive and easy to work with.

That shift in perception? Huge. As a result, the IT team were given additional funds to improve automation and begin to think about “real” cloud adoption.

The Takeaway

There’s a lot of talk in platform engineering about how we build better systems. But we often forget that platforms are as much about people and perceptions as they are about code. What I did that weekend wasn’t about technology, it was about translation.

Leadership wanted agility but didn’t have the words for it. IT wanted to do a good job but lacked a product mindset. The introduction of a tiny bit of design thinking—a simple interface, some basic defaults, and clearer comms—was enough to bridge that gap.

It's about clarifying intent, designing for humans, and making the invisible work visible.

We throw around words like "Developer Experience" a lot these days. But the best platform work often starts by asking: what do people actually need? Not just users, but the teams building and maintaining the systems too.

This article topic was suggested by the content club set up by the CNCF Platforms Community. Each month we choose a topic and invite anyone to contribute articles, videos, podcasts or commentary. If you enjoyed it, you might also like the follow related articles from other platform engineering practitioners. If you’d like to take part, come visit us on our #content-club Slack channel.

• Atul discusses the broader organizational and cultural readiness required for successful platform adoption, emphasizing that platform engineering is as much about people and processes as it is about tools.

• Graziano’s “13 Atomic Habits Playbook for Platform Engineers” breaks down reproducible, small-scale practices that platform teams can adopt to improve consistency, collaboration, and impact.

• Kalle’s video explores the often-overlooked non-technical dimensions of platform success—such as effective communication, team alignment, and habit formation—through the lens of real-world engineering leadership.

The most dangerous moment for your platform engineering initiative isn't launch day—it's the day it becomes successful. When your platform shifts from 'innovative project' to 'daily operations,' everything changes.

A Platform Engineering Director recently shared: "We spent 18 months building our CI/CD platform, each month celebrating dramatic improvements in deployment frequency, but we eventually found ourselves defending our headcount in budget meetings".

I’ve seen this same scenario play out across large companies across Europe as the first wave of platform engineering initiatives transitions from revolutionary to routine.

The real challenge isn't building a platform, it's sustaining and evolving it once the initial excitement fades.

Shifting Sands

The skills that build successful platforms aren't the same as those that sustain them. Early platform teams thrive with revolutionaries who challenge conventions. As platforms mature, they also need team members focused on reliability, documentation, and user experience.

New platforms are primarily judged on the capabilities they provide, and their audience of innovators and early adopters are eager to experiment, overcome challenges, and willing to overlook shortcomings. The platform team can focus their efforts on the joy of building new features and pushing them out to users with limited risk. There is limited operational overhead because the platform is simple, and the user base broadly content. This honeymoon period ends all too soon.

As the user base grows, so too do their expectations and the need for user support. This new breed of early and late majority users are less forgiving of poor user experience and frown at failure. The team must shift their efforts from building new features to making them easier to use and operate more reliably.

Leaders must continually assess the shape of their team and how they allocate work. There’s no faster way to lose senior engineers than to feed them exclusively on a diet of bug fixes and incremental improvement. Equally, it’s vital to ensure that the platform and its codebase remains accessible to allow new engineers joining the team.

Where Good Tools Go To Die

Once a platform has a healthy community of users that grow dependent on the platform for their day-to-day work, more consideration is needed of how change is rolled out safely. It’s difficult to promote an ethos of “move fast and break things” after causing your third major production issue.

Unreliability is a death sentence for platforms. Users will quickly lose trust and find another solution if your platform causes more frustration than it intends to solve. But your platform was most likely founded on the principles of moving faster, so it can be equally challenging to manage expectations as you implement more controls on how change is made to your platform.

In enterprise environments, silence gets interpreted as stagnation. Stakeholders will assume "if I'm not hearing about progress, there probably isn't any” - and they’re usually right! This isn't cynicism; it's pattern recognition honed from watching “strategic initiatives” quietly slide to "legacy system someone keeps running" as teams (and budgets) get pulled toward The Next Big Thing. To avoid the same fate, it’s critical that platform teams provide regular updates to demonstrate that things are moving forward and signpost future developments.

The New Normal

When platforms first launch, value demonstration is straightforward: you're replacing manual, error-prone processes with automated, reliable ones. Early wins are dramatic and visible. Deployment frequency jumps from monthly to daily and lead times shrink from weeks to hours.

Platform teams can be kept busy for a number of years solving these types of problems, particularly in highly regulated environments like Banking where manual processes have accumulated like sedimentary rock layers. Users celebrate each new platform feature, executives quote your metrics in board meetings, and budget conversations are refreshingly brief.

Eventually, a “new normal” begins to form and perceptions change. As your improvements become standard practice, the baseline expectations reset. What once seemed miraculous, now feels unremarkable. The slow, painful "before times" fade from organisational memory.

Successful platforms face a fundamental paradox: the better they work, the less remarkable they appear. Excellence in platform engineering means hiding complexity, eliminating friction, and making the difficult look effortless. Your platform becomes digital plumbing; absolutely essential, but invisible until something breaks.

This invisibility becomes dangerous during budget season. Finance teams see headcount costs for "maintaining existing systems" rather differently than "driving business transformation".

Platforms must continue to demonstrate real-world business value. The most successful platform leaders hunt down specific business outcomes their platform enabled. They don't just track deployment frequency, they find the product team that shipped a critical retention feature two weeks ahead of competitors, preventing £3M in churn. They connect how compressed validation cycles helped avoid regulatory fines. Technical excellence becomes irrelevant if it can't be translated into revenue protection, cost avoidance, or competitive advantage.

Launch to Legacy

The true test of platform engineering isn't the initial launch but the sustained evolution that follows.

The question isn't whether your platform works today, it's whether it can evolve to meet tomorrow's challenges. The organisations extracting real value from platform investments are those planning for Act Two from Day One. They build teams that can both innovate and operate. They establish metrics that connect technical capabilities to business outcomes. They communicate progress even when the work feels routine.

Is your platform built to evolve or just to launch?

If you enjoyed this article, you might also want to check out the submissions from other CNCF Content Club members, including:

• Graziano’s great post that echoes many of my thoughts above.

• Abby’s great blog post about what we can learn from over-the-air car updates and the dangers of “pets wearing cattle costumes”! 🐮

• This video from Kalle that offers a mix of insights and great scenery.

By now, we’ve all grown tired of yet another bullshit AI demo that doesn’t reflect the real-world challenges we’re trying to solve, whilst ChatGPT confidently tells us that glue would make a delicious pizza topping.

The problem is that Large language models (LLMs) today are incredibly smart in a vacuum, but we struggle to find value in them beyond the confines of their training data.

In this article, we’ll explore the technology advancements that promise to overcome the two challenges AI faces to be of any use in the real world:

• Context. An AI Agent must understand the specific environment it’s operating in. It needs to tailor is responses to reflect the specifics of your company policies; runbooks; and knowledge bases.

• Integration. We need AI Agents to be able to take action. It must be able to integrate and interact with other tools within our environment.

RAG

The capability and extent of AI tooling we have today is impressive, but those models have no idea about how your specific CI pipeline works, what standards your company expects, or even what “prod-east-legacy” means in your org.

Retrieval-Augmented Generation (RAG) is a way to change that. You can provide the system with knowledge about your environment, that it can use as a reference later. When asked a question, a RAG system uses a vector search to find relevant chunks of text from documents you’ve supplied — things like run-books, platform docs, or even Slack threads — and passes those to the model as extra context. Vector search doesn’t rely on exact matches; it works by comparing meaning. If an engineer asks, “How do I deploy to staging?”, RAG might surface a doc titled “Promoting services to the integration cluster”—even if the word “staging” isn’t in the file.

The nice thing is, you don’t need to train a new model to make this work. With RAG, all you need is a model that knows how to read, and a way to feed it the right information when the time comes. That combination of retrieval + generation is where the magic happens.

For platform teams, that opens up some really practical doors:

• Engineers can ask environment specific questions and get answers that reflect the policies, best practices, and operating practices of your organisation.

• Onboarding new employees become much easier by making it much easier to find answers, without having to wade through reams of documentation that sits across different platforms or teams.

MCP

If RAG enables AI to be contextually aware, then Model Context Protocol (MCP) is what helps it interact with the world around it in order do something useful.

MCP is a protocol to enable AI agents to discover, connect to, and interact with external tools - whether that’s querying a database or calling an API. It gives models a way to operate beyond their static training data, making them more adaptable and useful in real-world applications.

MCP is a new open standard that’s gaining traction, fast! Originally created by Anthropic in Nov 2024, it lets AI tools connect to real-world systems in a predictable, secure, and structured way.

Most AI tools today are still pretty passive. They respond to questions, but they can’t take action without custom code written for each use case. MCP flips that by giving LLMs a standardised, “plug and play” way to understand and interact with APIs, tools, and data sources.

Under the hood, MCP defines a few key concepts:

• Resources – the stuff your AI can read from or write to (like a Git repo, a Kubernetes cluster, or an internal API)

• Tools – the actions your AI is allowed to take (like “restart a pod” or “create a ticket”)

• Prompts – the instructions that help the AI understand what’s going on and what it can do

MCP doesn’t require special model training. Instead, it gives the model access to structured metadata that describes how things work—what tools are available, what inputs they take, what responses they return. The AI doesn’t magically “know” how to use your CLI—it learns in real time, because MCP tells it everything it needs.

There is already a ton of MCP implementations available, including GitHub, GitLab, Slack, Kubernetes, Terraform, PostgreSQL, and many more. As you might expect, we’re yet to standardise on single marketplace, but in the meantime, check out https://mcpmarket.com/, https://mcp.so/, and https://cline.bot/mcp-marketplace.

This is a HUGE step forward for AI, allowing it to go far beyond search and summarisation. It can take action—safely and predictably—within the boundaries you define.

It’s still early days, but this is the direction things are headed. If RAG makes AI helpful, MCP makes it capable.

This article is my contribution towards the Content Club initiative where some of my fellow CNCF working group colleagues sharing their thoughts on a given topic each month. If you’d like to join us, pop by the #content-club CNCF Slack channel.

Some of the other contributions include:

• Colin Lacy shared a short-form video to describe his vision of a platform enabled LLM.

• Kalle Sirkesalo created a long-form video where explores how autonomous agents are becoming more capable through retrieval-based memory, open source frameworks, and improved reasoning.

• Graziano Casto explains how GenAI can help developers navigate complex internal platforms by reducing cognitive load and easing tool fatigue.

Other contributions in this series that you might like include:

• Kalle Sirkesalo takes a walk and shares his journey with metrics, from discovering how easily bonus-tied metrics get gamed, to learning how to set effective metrics that influence desired behaviours.

• Graziano Casto shares his view against blindly adopting frameworks like DORA in favour of tailoring metrics to outcomes specific to your business.

"What gets measured, gets managed" is one of those business quotes that's both painfully obvious and profoundly important. Every platform team I've worked with eventually faces the same question from leadership: "How do we know if this is working?"

It's a fair question. Platform Engineering is balanced precariously at the top of the Gartner hype curve and leadership is understandably keen to see evidence that all their investment hasn’t gone to waste.

But what does “better” even look like?

“Can you say DevOps?”

The first challenge I see teams have is that they often don’t know what to measure, so they begin to research what other companies have done. The most common metrics framework I see organisations adopt is DORA. Developed by the DevOps Research and Assessment Team and popularised by the release of the book Accelerate in 2018, it distills a large body of research into four prescriptive metrics:

• Deployment Frequency - frequent, smaller deployments are often less risky and beneficial for business agility.

• Lead Time for Changes - how long it takes a code commit to reach production.

• Change Failure Rate - the percentage of changes that result in a production failure.

• Mean Time To Recover - the time taken to recover from a production failure.

What makes DORA particularly valuable is the balance it strikes between speed (the first two metrics) and stability (the second two). Contrary to what those in Silicon Valley might tell you, the goal for most companies is to “move faster, without breaking things”.

Companies gravitate towards DORA because it provides a sensible baseline for “performance” in a minimal set of prescriptive metrics that are easy to collect. Contrast this with more nuanced frameworks like SPACE or DX Core 4 that require deeper consideration of what success looks like, and include metrics that are a little more challenging to collect.

The DORA Disconnect

I've lost count of how many organisations I've seen enthusiastically adopt DORA, only to misunderstand its purpose and constraints.

At their core, DORA metrics are a deliberately simplified lens focused on system delivery performance. They don’t account for team context, product complexity, or technical debt. Deploying a change to a website and rolling out new firmware to ten million set-top boxes are very different propositions. Likewise, DORA doesn’t measure human factors such as developer experience or cognitive load. I've met plenty of "high-performing" teams who were miserable, burning out, and planning their exit interviews.

In my experience, organisations make two fundamental mistakes when adopting DORA:

• The first is that correlation is not causation; organisations who are considered "high performing" in the research are not high performing because they focussed on the DORA metrics, but instead focussed on delivering value to users.

• Although Goodhart’s Law taught us many years ago that “when a measure becomes a target, it ceases to be a good measure”, it hasn’t stopped countless leadership teams weaponising DORA as a means to compare performance across teams.

Both relate to the “cargo cult” obsession we have in the IT world of emulating the behaviour of others, irrespective of context. Your company does not share many traits or challenges with Facebook. It took Netflix over seven years to migrate to the cloud and still had private data centres up until 2016. Amazon made 90% cost reductions in video quality monitoring by moving from a serverless architecture back to a monolith.

Measure What Matters

When I’m asked to consult on the topic of metrics, my first question to the team is “what is the behaviour you want to influence?”

There should be a purpose for metrics, beyond idle curiosity. Metrics should be chosen deliberately to reinforce your platform's goals, not just because they're easy to measure or everyone else is using them. If your goal is to improve developer experience, measure that as directly as possible.

Borrow ideas from frameworks like DORA, but don't copy them wholesale. Take what's useful, discard what isn't, and adapt everything to your specific context. Blend hard metrics with human metrics. Deployment frequency matters, but so does developer satisfaction. The best platform teams I've worked with survey their users regularly and treat that feedback as seriously as they do technical metrics.

Start small and iterate. Begin with just 2-3 metrics that directly relate to your most pressing concerns. Add more only when you've established a healthy relationship with the initial set.

Be transparent about what you're measuring, why you're measuring it, and what the results mean. When teams understand the purpose behind metrics, they're less likely to game them and more likely to use them constructively. Equally though, understand that all metrics eventually become a target of sorts, explicitly or subliminally; it’s one of the reasons why simply measuring something regularly can help you manage it better.

Beyond The Numbers

The most successful platform teams I've worked with recognise that metrics are tools, not outcomes. They use data to inform decisions, not dictate them. They balance quantitative measures with qualitative feedback.

A platform's success isn't found in a dashboard or spreadsheet—it's found in the experiences of the people who use it every day. Measure what matters, and create the space for success that can't be captured in a spreadsheet.

Other contributions in this series that you might like include:

• Steve Fenton wrote this great piece about his real-world experiences of applying Team Topologies in a Product & Data team.

• Matt Menzenski explores the parallels between Team Topologies and Deep Work (two excellent books) and shares his

• Graziano Casto reminds us that while technical advances are important, the key to successful software development lies in how we organize and enable teams to work together effectively.

• Dipesh Patel wrote this fun piece comparing platform engineering to the worlds best Christmas movie.

• Ricardo Bemfica shows how Livelo applies Team Topologies principles by using developer experience surveys to shape platform strategy, ensuring teams are empowered through data-informed collaboration.

What is Team Topologies?

If The Pheonix Project was the book that brought DevOps to life, then Team Topologies is the book you need to truly understand Platform Engineering. Rather than organising teams around technology or business function, Matthew Skelton and co-author Manual Pais advocate for team patterns that optimise for the flow of change and minimise cognitive burden. The book introduces four fundamental team types: Stream-aligned, Platform, Enabling, and Complicated Subsystem teams.

In this article, we’re going to take a closer look at the role of the Platform Team and I’ll share my observations from working with organisations from across industries, highlighting the good, the bad and the ugly!

The Purpose of Platforms

The core purpose of the Platform Team is very simple: enable stream-aligned teams (e.g. developers) to deliver faster by reducing their cognitive load. Platform team should absorb the complexity that would otherwise burden development teams, reducing cognitive load.

This is achieved by providing a set of internal self-service capabilities (i.e. an Internal Developer Platform) that can be consumed by other teams, without needing to understand the implementation details. The platform team is user-centric, listening carefully and curating feedback to improve the platform in ways that deliver the most improvement for users.

Having a great platform is very similar to running a successful restaurant. The platform team brings in ingredients from various suppliers, mixes them together into something tasty, and provides an environment to enhance the customers consumption. You could try making the same dish at home, but it’ll take you longer, won’t taste quite as good, and you’re left with a pile of dishes to do afterwards!

Of course, the trouble is that technology teams have a tendency to see all problems through the lens of technology. A restaurant could have the best ingredients, but can fail if nobody likes the menu or the service is crummy. I wrote about this a few months ago in one of my most popular articles that posed the question is Platform Engineering in Danger? Whether it is Agile, DevOps, SRE, or some other new innovative way of working, we inevitably seem to get distracted by tooling and forget that these advancements are about helping people work better together.

Three Signs Your Platform Team Has Lost Its Way

I’ve had the honour of working with some of the innovative companies across the UK and Europe, giving me a front-row seat to see how different organisations have approached the same challenges. What’s evident to me is that when things aren’t going well, technology is rarely the problem, and most problems can be attributed to the same three common human factors.

1. Misaligned Priorities

In most of the organisations I’ve worked with, the platform team will generally report up through the CIO or CTO. Meanwhile, development teams that are expected to use the platform report through various business-related functions. An Internal Developer Platform is an ideal solution to help bridge that gap, but it’s important to recognise that development and platform teams will often be pulled in different directions by their leadership teams.

This problem is particularly prevalent in organisations where the funding for IT is accounted for centrally, rather than cross-charged to departments based on their usage. And it gets worse where the use of specific platforms is mandated.

When platform usage is mandated and costs are centralised, platform teams lose the most crucial feedback mechanism any product team needs - the voice of the customer expressed through their choices.

Platform teams can have a difficult time convincing their management of the importance of developer experience, instead being pushed toward traditional governance and control measures. While these measures might satisfy IT audit requirements, they can severely impact development team velocity. The result is predictable: development teams, under pressure to deliver business outcomes quickly, create workarounds or turn to "shadow IT" solutions.

Breaking this cycle requires platform teams to stay laser-focussed on the needs of their “customers”. They must find new and innovative ways of implementing sufficient safeguards to meet governance requirements that don’t unnecessarily impede velocity. E.g. if a manual approval step rarely results in rejection, then what value does it serve, and could it be replaced by automation or converted into a retrospective review process instead.

2. Communication Breakdown

I’m not sure why, but technology teams seem to have an inherit fear of speaking with people that specialise in another discipline. Team Topologies goes into great detail about social cohesion and group dynamics, noting that natural tribalism can lead into “communication silos” where teams become hesitant to interact with other disciplines, develop their own jargon and practices, and begin to form a "them" and "us" mentality.

When I start working with a platform team, the first question I ask is how they prioritise their work and what mechanisms they have in place to collect feedback. It’s depressingly unusual for platform teams to have regular feedback sessions, a “voice of the developer” program to influence platform roadmaps, or a clear set of business objectives that tie platform team success to developer team outcomes.

The business impact of a platform team is directly proportionate to the quality of their user feedback loops.

One my most favourite parts of the Team Topologies book was the authors opinions on what platform teams should be called. Experience has shown that subtle changes in language can have a profound effect on how we communicate. Many of the platform teams I encounter are centred around the platform that they intend to build, often surrounded by language that implies some level of power or control - e.g. “Core Platform Team”, “Central Platform Services”, etc.

These terms unconsciously promote a sense of hierarch or importance that works against the service-provider / product mindset that platforms should adopt. Instead, Skelton and Pais suggest “outcome-orientated naming” that reflect the desired outcomes and reinforce that the platform team exists to serve and enable others - e.g. “Developer Experience Team”, “Developer Enablement Platform”, etc.

Similarly, in this article you will see that I often refer to the users of a platform as “customers”. It was a topic of some contention when I led platform engineering at Sky TV, but it had an immediate and significant change in the way my teams thought about and communicated with users of the platform.

3. Poor Developer Experience

I said earlier that a restaurant could serve the best food in town, but the business will fail if service is slow or the front of house staff are rude. When I’ve been hired to help a platform team struggling to grow their adoption, it is very rarely a lack of technical capability. The problem is that using their platform isn’t fun.

Developer experience is about understanding that every interaction with your platform either adds to or reduces a developer's cognitive load.

Platform teams often focus heavily on what their services do, building feature-rich solutions that tick all the technical boxes. However, how these services work from a developer's perspective is equally, if not more, important.

Platform Engineering is about making the complex appear simple, about turning what could be a hundred small decisions into a handful of meaningful choices. Great platform teams obsess over error messages that guide rather than confuse, documentation that answers questions before they're asked, and interfaces that feel natural and intuitive. They understand that their success isn't measured by the complexity they can build, but by the complexity they can hide.

Get Your Platform Back On Track

The success of a platform team isn't measured by the sophistication of their technology stack or the number of features they deliver - it's measured by how effectively they enable other teams to deliver business value. Team Topologies provides a clear framework for understanding this relationship, emphasising that platform teams exist to reduce cognitive load and accelerate delivery across the organisation.

My top tips to level up your platform team:

• 🎯 Measure your success by developer velocity and platform adoption.

• 🤝 Every feature should have a customer champion.

• 🚀 Make the right way the easy way.

What makes Team Topologies particularly powerful is its recognition that technical excellence alone isn't enough. The book's insights about team interaction patterns, cognitive load management, and organisational dynamics provide a blueprint for building platforms that truly serve their users. Whether you're just starting your platform engineering journey or looking to improve an existing platform, Team Topologies offers invaluable guidance on creating team structures that optimize for flow, reduce cognitive load, and enable fast and reliable software delivery.

In short, go read the damn book, alright! You can thank me later!

At this point, it's clear that AI isn't going anywhere. Like a runaway diesel engine, the hype machine is still running at full throttle, even though we’re all choking on the black soot of disillusionment and an inherent fear that we’re losing trust in what we see and hear.

Earlier this year, I wrote about my concern that GenAI is a bubble that's about to burst. Like the dot-com days before it, however, that doesn’t mean the concept isn’t valuable; it just means investors have all gotten a little too excited.

But behind all the hype and fear-mongering, the simple truth is that large language models have been an effective force multiplier in several use cases and they’ll have a long-lasting impact on how we interact with technology.

In this article, I want to give practical advice on where it makes sense to deploy AI in your Internal Developer Platform for 2025.

My Robot Army: More Roomba than Terminator

I bought my first robotic vacuum cleaner in 2020, and it quickly became one of my favourite appliances … if you can have such a thing. With three kids and a busy household, “Jenkins” spins into action every night to help keep our house clean.

I also own robotic lawnmowers, and they do a phenomenal job, but I love them a little less. You see, I actually quite enjoy the catharsis of mowing the lawn! But, it is time consuming and I recognise that my little robot army enables me to crack on with other jobs - albeit ones that I don’t like as much.

There are many parts of my life where I don’t want any help, though. Amongst other things, I don’t want robots to walk my dog, drive my car, or entertain my kids.

Yet, when I speak with IT leaders about artificial intelligence in the workplace, all I seem to get asked is what LLM is capable of producing the best code. The problem is that writing good software is a beautiful symphony of interpretation, logic, creativity, and iteration. You might get something by guessing the next word from a catalogue of all the code snippets ever published, but it will never be great.

I’m also pretty sure developers enjoy writing code - it’s why they trained to become developers. Sure, they might appreciate some help with it, but I know there are a bunch of other jobs they don’t enjoy that we should maybe automate first!

So, my first and most important lesson is that you should look at AI as a tool. We should use tools to help us spend less time doing the things we don’t enjoy, or that we’re not very good at.

Example #1: Why Did My Build Fail?

Ever scrolled through thousands of lines of verbose CI pipeline output, trying to figure out why a build failed? You lean into the screen, quickly scanning the text for anything that doesn’t look right. After a while, you eventually find an error message, but it’s not very helpful, so you then spend the next ten minutes trying to work out what went wrong.

The most annoying thing about build failures is that they’re usually caused by simple, silly, mistakes: a missed semicolon from a Dockerfile; an extra space in a YAML file; or just a simple typo. Of course, just because they’re easy to fix, doesn’t make them easy to find!

This is exactly the kind of task where AI shines. It can scan through verbose logs in milliseconds and identify anomalies in well structured text very easily. My colleagues Rutvik and Michael gave a great example of GitLab’s Root Cause Analysis feature, which saves developers and engineers wasted time. In many of the organisations I work with, this one feature alone was able to single-handedly demonstrate the ROI for adding AI features to their subscription.

Example #2: Nobody Likes Writing Unit Tests

Developers may love writing code, but I’m yet to meet anyone that enjoys writing unit tests! You are writing unit tests for all your code, right … ?

A unit test is a small piece of code that checks if a specific part of your program, like a function or method, works correctly in isolation. This not only saves you time in the long run by catching bugs sooner, but also helps you understand and verify the logic of your code better, to improve overall code quality and reliability.

Much like summarising a long report, Large Language Models (LLMs) are particularly adept at writing unit tests. They can quickly understand the structure and purpose of existing code, which enables them to create relevant tests without needing to write new logic from scratch. The test cases themselves are very simple by nature, and follow a consistent style.

Humans generally find simple, and repetitive tasks like this very boring. We either avoid doing the task, or don’t do it very well. In a recent article, GitLab gave a sneak peek of how they use GitLab Duo Chat internally to write unit tests.

Example #3: Code Reviews Without The Bottleneck

Another area that often lacks focus is Code Reviews. Reading someone else’s code just isn’t as mentally engaging as writing your own, and we’ve already spoken about how bad humans are at spotting small mistakes. A good code review needs someone very experienced, that is familiar with the part of the code base that’s being changed. Those individuals are often in short supply, and generally have a long list of other things they need to do.

Retrieval Augmented Generation (RAG) is a technique that allows AI to pull in relevant context from your existing documentation when performing tasks. In this case, you might give the LLM visibility of your company policies, best practices, naming standards, or other project-specific documentation before asking it to review code.

I don’t think AI can provide all the valuable insights a junior developer might get from a human review, but it seems obvious that they could provide a “first pass” to help reduce the workload for senior developers.

Good Practice as a Foundation for AI

So before you get too excited about AI generating your next microservice, it's worth remembering that even the fanciest robot vacuum cleaner won't help if your house is in chaos. The same principle applies to software development - AI tools are most effective when built on top of solid engineering practices.

The examples I've shared aren't about replacing developers or magically creating new applications. Instead, they focus on strengthening the foundational practices that make good software development possible: reliable builds, comprehensive testing, and thorough code reviews.

If your CI/CD pipeline is unreliable, test coverage is patchy, or you lack a robust code review process, then AI code generation is just going to amplify these problems (and more!).

In 2025, the real power of AI in software development isn't about replacing developers - it's about making good development practices more achievable and sustainable. And that is something worth getting excited about! 🥳

Well done everyone, we made it! Another year on the crazy rollercoaster that is technology! People wearing strange digital ski masks were found wandering around in an augmented reality bubble. Space X caught 275 metric tons of Super Heavy with a pair of oversized chopsticks.

We watched a simple software update cause the largest global IT outage, and then just a week later, an outage of both Microsoft and Amazon cloud services on the same day. There was a bit of chatter about AI that you might have missed? And, all this whilst the Great Tech Reset made us all question why we continue to ride this rollercoaster.

This year, I have been tremendously honoured to speak with engineers, developers and IT leaders across a broad spectrum of industries and geographies. It's my favourite and the most rewarding part of my job, but it can also be frustrating. In these conversations, I've noticed a common thread—we in tech have a tendency to see every challenge through the lens of technology, searching for technical solutions to what are often fundamentally human problems.

Twenty years ago, I learned perhaps the most important lesson of my IT career.

What I learned from Larry The Cow

When mastering my craft as a system administrator, I became fascinated with speed and efficiency. Disenfranchised by the bloat and opinionated builds of CentOS and RHEL, I followed Larry the Cow down the path of enlightenment and decided all the servers at our little SaaS start up should be running Gentoo Linux! For those not in the know, Gentoo is like Linux the Hard Way. I spent weeks tweaking, tailoring and compiling the worlds most perfect Linux server.

It felt amazing. I was able to exercise all my skills to build something awesome.

Pride, Performance, and a Humbling 8%

The problem came when it was time to expand our team. I interviewed countless engineers, but none had the skills I needed to maintain and improve what I had built. It took longer than I’d like to admit before I began to think about what the real problem might be. Sure, what I had built was awesome … but how awesome was it? Was the performance improvements worth it?

My co-founder and life-long friend, Gavin Brown, helped formulate a bake off… one of my zero-fat, uber-optimised, Gentoo Linux servers versus his default install of CentOS running CUPS and god knows what other stuff we didn’t need. To this day, I still don’t understand why a single daemon triggers me so much, but I spent a week tweaking each compiler argument to the specific cpu instruction set and waited patiently for many, many hours while every component was compiled from scratch.

The day of the big race, I wasn’t disappointed … my Gentoo box out-performed the competition on every benchmark that Gavin could throw at it! Success! Vindication! Relief! Pride.

Those feelings were short-lived though. Sure, it was faster … by a whopping eight percent. That afternoon, I rebuilt our entire environment with stock CentOS installs, following all the standard, documented practices. We were able to easily find and hire engineers with RHCE qualifications and I continued to guide the team to favour simplicity over perfection.

The Most Complex System is People

We all strive in our own way to prove to ourselves, and others, that we’re good at something. In the IT industry in particular, there is a tendency for us to believe that what we’re doing is really hard and others just don’t understand how important it is to get it right. Meanwhile, we wonder why teams from other disciplines are struggling - it can’t be that hard, right?

The true measure of technical excellence isn't just in what we can build—it's in how we can empower others to succeed. The most valuable skill I've developed didn’t come from a reference manual; it was recognising that success in technology isn't about building the perfect system, it's about building systems that help people work together more effectively.

I could write a book on this topic, but let me instead leave you with a few thoughts.

• Being good at something isn’t about what you can do; it’s how you can help others. It might not always feel like it, but Corporate is a team sport.

• We all need to feel useful and appreciated. There’s lots of ways to achieve that; not all of them obvious. Helping makes you happy.

• I don’t like stereotypes, but “communication” generally isn’t a strength in most IT departments. Research suggests neurodiversity in tech is as high as 50%. We could all benefit from understanding more about the symptoms of ADHD or Autism, particularly those in the high-functioning category.

In my role, I interact with platform teams across industries, from small startups to large enterprises. A common issue I encounter is the lack of awareness around the onboarding process for new users—and the significant impact this can have on adoption.

In a 2021 survey by Sitel Group looking at the importance of customer experience, they found that “a third of consumers considered severing ties with a brand because of a poor experience”. If your team embraces the platform-as-a-product mindset, there are crucial lessons to draw from this.

Why is the onboarding journey so important?

I’ve spoken before about the Diffusion of Innovation and challenge of elevating the adoption of a platform from being a niche solution to one that is ubiquitous within an organisation. In his book, Crossing the Chasm, Moore explains that innovators and early adopters—representing about 16% of an organisation—are often willing to tolerate rough edges, motivated by novelty or vision. The early majority, comprising 34%, is key to ‘going mainstream.’ They prioritize proven reliability, a clear value proposition, and ease of use. This shift in expectation catches many platform teams out.

What’s in a name?

A users’ journey often begins by hearing the name of your platform. When naming your platform, you want something that is unique in your organisation, is easy to spell, and isn’t too specific in terms of its function or the technologies that it uses.

The biggest red flags when it comes to naming are:

• Your platform has a version number: if this is “platform 2” or “platform 3”, that signposts that you’ve been previously been unsuccessful, and will have users wondering if this latest version will follow the same path.

• Your platform is a forgettable “TLA”: businesses love a three letter acronym, but that means there are so many that they immediately become forgettable. Worst still, the first letter is usually wasted by referencing the company name.

• Your platform is named after a technology: there is no faster way to show that you value technology over people by including the name of a technology, or worse, a technology vendor, in the name of your platform.

You need a landing page

Once a prospective user has heard about your platform, they’re next step is to learn more about it. But where should they look? I’m always dismayed at how big a challenge “discovery” is within large or even medium-sized businesses.

I’ve written before about the benefits of having a simple product website for your platform to act as a landing zone for new and existing users. In my experience, this is the single best improvement you make to improve your onboarding journey and boost adoption for your platform.

The purpose of the landing page is to deliver your “elevator pitch” to prospective customers. You want to clearly articulate a few key pieces of information in a succinct and visually appealing format:

• what problem does the platform solve?

• what are the top five capabilities that your platform provides?

• where can they get more information?

You don’t need a professional website design company to do this for you, there are plenty of templates available online, or even if you don’t have any technical skills, Canva have a great tutorial that steps you through how to create one using their platform.

Your documentation sucks

Whilst many teams might see documentation as a necessary evil, I believe the art of intentionally recording your knowledge is one of the most selfless and positive changes you can make in a business. Writing good documentation is hard though!

I’m sure we’ve all read through instructions that have proven to be more frustrating than if there were none at all. Maybe it’s too long to find what you’re looking for? Or you can’t make sense of the language? Or it’s peppered with links to other website you need to read first? Maybe there’s steps missing? Or maybe you just couldn’t get the simplest of examples working. You try your best to work through it, but in the end, you give up and search for a different solution.

I could dedicate a whole article to this one subject, but my top tips are:

• Focus on the goal of making simple things easy, and hard things feel possible.

• Write for your audience. Write for your audience. Most documentation assumes the reader has too much prior knowledge. Remember, others might want to learn about your platform too—executives, finance teams, compliance officers, and more. Don’t leave them behind.

• Use simple language and avoid technical jargon where possible. It’s reported that 54% of U.S. adults read below a sixth-grade level. Metaphors and visuals are a great way to convey complex concepts in a more digestible format.

• Have a dedicated Getting Started guide written specifically for new users, that gives a high level explanation of the platform and provides some simple “hello world” type examples.

• Ensure your documentation is organised into logical, modular sections that are self-contained. I recommend aligning these to user intent, rather than functional area. The Kubernetes documentation is a good example of this.

• Provide simple, worked examples. People learn by doing, and enabling them to get even the most simple example up and running will give them confidence in their ability to use your platform to solve more complex problems.

• Have someone outside your team review your documentation and test your examples. As someone working with the platform, it’s easy for your to assume too much from your reader, or miss a step in an example.

• Keep your documentation up to date. If getting people to write documentation is hard, getting them to keep it up to date is near impossible! Companies will often assign a Directly Responsible Individual, but I find it more helpful to measure user engagement with documentation to help identify what pages are most read; which are viewed for short periods of time; and what are people searching for that we might not have a page for.

Why does it need to be so difficult?

Teams will often agonise over the implementation of a specific platform features, but it baffles me why it feels like minimal effort is put into making it quick and easy for people to get access to the platform in the first place!

I think the most simple answer is that those building platforms never go through the onboarding experience themselves. This is compounded by the IKEA effect, where we put too much value into something we had a hand in creating, making it difficult for us to listen to negative feedback from others.

I’ve seen lots of examples of this on my travels, working with organisations of all sizes, across every industry:

• The irony of a manual onboarding process being needed to gain access to a self-service platform. If you can’t fully automate the process, then do your best to fake it, by carrying out any human-in-the-loop tasks asynchronously.

• Time-consuming approval steps or other barriers are sometimes necessary where there is a business cost involved with onboarding. One great solution to this is to offer immediate temporary access to your platform for free for 30 days. This is long enough for someone to decide if your platform helps them, and raise the necessary request to gain full access.

• Most recently, I’ve seen organisations demand that employees complete mandatory training on security policies or artificial intelligence guidelines. Such things may be necessary, but they should be required within a period of joining the platform rather than a pre-requisite.

The vibes are off

First impressions are often visual, and aesthetics play a much bigger role in adoption than many platform teams give them credit for. Your platform’s look and feel sends a powerful message about its quality, care, and user-centricity.

If your platform interface looks outdated or inconsistent, it can deter users—even if the functionality is excellent. Is the branding cohesive? Are the color schemes visually appealing? Is the tone of your messaging welcoming and approachable? These details might seem trivial, but they set the tone for user engagement.

Beyond appearances, the wording you use is just as critical. We might be building automation robots, but we don’t need to sound like one! Does your copy feel clear and human? A user-friendly tone can make your platform feel approachable to a broader audience, from engineers to executives. Remember, a little polish goes a long way in making people feel confident about engaging with your platform.

Please hold, your call is important to us

Even the best platforms need support systems, but nothing erodes trust faster than unresponsive or ineffective help channels. The ease and speed with which they can get help will significantly impact their perception of your platform.

Building an effective support framework starts with understanding the communication mediums that users are likely to use, along with the advantages and disadvantages of each of them.

Support Tickets provide accountability

• Support tickets are universally hated, but they do provide a record of the request, and are often integrated into other systems to aid collaboration across teams.

• Use support tickets to record outages, defects, or anything else that is likely going to require follow up.

Email is great for clarity

• I generally suggest avoiding email communication, but it’s the most ubiquitous, compatible message format available that remains the primary communication tool for some teams.

• Email is a good platform where you want to convey a complex topic with clarity. It allows you to put a lot of information in one place, as well as including diagrams, etc.

• Setup an email alias for your platform that is easy to remember. When a user has a problem, they don’t want the additional problem of trying to work out what overly complicated name for your distribution list might be. Strongly encourage users to use the alias and not to contact individuals directly.

• It can be useful to set up an auto-responder to acknowledge receipt of the email immediately and advise the user on the likely response times. This is a good opportunity to direct them to raise a ticket for something important, or to seek support in chat for quick resolution of simple problems.

Chat is built for responsiveness at scale

Chat systems like Slack or Teams are likely the most communication tool used amongst developers and engineers.

• It’s not uncommon to find competing chat tools in an organisation. It is vital that your team is present wherever your user base is - even if that’s not your platform of choice.

• Chat is ideal for solving simple queries quickly. This is phenomenally important when users are “in the flow” and would get frustrated if they need to wait hours or days for an answer by email or support ticket.

• Chat moves quickly, your team should aim to answer queries within 30-60 minutes. It’s a very bad look if various people are chatting in realtime about your product and your team are nowhere to be seen.

• Chat is a fantastic way of building a relationship with your users. Unfortunately, it’s just as easy to permanently ruin any credibility you’ve built up! Think of it like a “public” customer service platform. I strongly encourage platform teams to have a separate “internal” channel where they can discuss and debate topics. Users shouldn’t see “how the sausage is made”.

• It’s often tempting to solve matters in private, but engineers should always update the chat platform with the outcome. Not only does this help users find solutions in future searches for similar problems, but any prospective users visiting the channel will see things being followed up. Seeing a problem reported and then no solution is not a good look.

Platforms fail for all sorts of reasons. Imagine a rusted-out bus, once gleaming and full of promise, now abandoned on the side of the road—its wheels frozen, its purpose forgotten. Like that bus, platform engineering initiatives often begin with grand ambitions to serve the entire organisation but get abandoned due to missteps and overlooked challenges. From false starts to silent failures, too many teams find themselves on the path to obsolescence before they’ve even had a chance to deliver. This article explores the most common reasons why platform engineering efforts stall—and how to keep yours from breaking down.

Check Engine: The False Starts of Platform Engineering

Many platform engineering teams stumble before they ever gain momentum, often due to preventable missteps. One of the most common pitfalls is failing to establish a solid business case. Without a compelling narrative that clearly articulates the platform’s value, it’s nearly impossible to secure the buy-in and resources needed to succeed.

Equally problematic is the lack of a strong stakeholder network. Without early collaboration, especially with a dedicated launch partner, teams miss out on crucial feedback that can shape the platform’s development. Misalignment among stakeholders often leads to a muddled vision, which results in stalled progress.

Executive sponsorship is another critical element. Without high-level backing, platforms can easily get bogged down in organizational inertia, lacking the visibility and authority to push through roadblocks. A champion at the executive level provides the resources and support needed to sustain momentum.

Lastly, many teams fall into the trap of over-engineering. Trying to solve every potential problem from the start—often referred to as “boiling the ocean”—leads to endless design phases with little to show for it. Starting small and iterating is a more practical approach.

Perfectionism also plays a role in false starts. Teams often aim to automate everything, rather than recognizing the value of launching early with some manual processes in place. The obsession with a flawless product delays the platform’s ability to deliver value—and prevents essential learning from real-world use.

Empty Seats: Solutions in Search of Problems

Platform engineering teams often fall into the trap of building impressive solutions that solve the wrong problems—or worse, no problems at all. One key misstep is failing to identify a core group of initial users. Without these early adopters to guide development, the platform risks becoming disconnected from real business needs, drifting into irrelevance.

An unclear understanding of the business problems at hand further compounds this issue. Teams that jump into development without fully grasping the value stream often focus on the wrong areas, delivering platforms that might be technically sound but provide little practical value.

Another common mistake is prioritizing technology over people. Treating the platform like a science experiment, rather than a product designed for users, leaves critical insights on the table. Engaging with users early and often ensures that the platform aligns with actual needs rather than theoretical possibilities.

Speed is also crucial. Platforms that don’t deliver incremental value early on risk losing user engagement. When teams take too long to show tangible benefits, users may lose patience and build their own ad hoc solutions, splintering efforts and wasting resources.

Lastly, the “Not-Invented-Here” syndrome can be a silent killer. When teams dismiss existing off-the-shelf solutions in favor of building everything from scratch, they waste time and resources reinventing the wheel. Instead, leveraging proven tools can free up teams to focus on creating unique value.

Are We There Yet? When Communication Breaks Down

One of the most insidious ways platform engineering efforts fail is through silent breakdowns in communication. Without a clear, evolving narrative or compelling metrics that demonstrate the platform’s value, it’s easy for stakeholders to lose interest.

Frequent progress updates are crucial to maintaining engagement. When teams fail to provide them, stakeholders often drift away, leading to fragmented efforts as different groups start building their own solutions—resulting in wasted time and duplicated work. The damage is more than a waste of resources; it fragments the focus and energy needed to drive change in large businesses.

Advocacy is essential to counteract Fear, Uncertainty, and Doubt (FUD) within the business. Without champions promoting the platform’s benefits, skepticism can grow unchecked. Moreover, a poor user experience, often due to insufficient documentation and lack of support, can quickly tarnish the platform’s reputation.

Finally, platforms that neglect marketing and community-building efforts risk fading into obscurity. Even a well-designed system can fail if no one knows how to use it or understands its benefits. By engaging users early, delivering clear value, and creating advocates, teams can avoid these silent failures and keep their platform on a path to success.

Maintenance Matters: Avoiding Flat Tires on the Road to Growth

After the initial launch, platform engineering teams often face new challenges as they try to scale. One common issue is misaligned priorities. Teams that fail to adapt as the platform grows may continue focusing on early-stage needs, neglecting the broader user base required for long-term success. On the flip side, listening too much to user feedback can lead to over-engineered, overly complex solutions—what some call “Homer’s car,” a product designed to please everyone but satisfies no one.

Adapting priorities is essential to maintaining momentum. Without flexibility, teams risk missing out on the critical majority needed for widespread adoption, often described in the diffusion of innovation curve. A platform that only serves early adopters will struggle to gain mass acceptance without strategic adjustments.

Aggressive change tactics, which may have worked initially, can become counterproductive as the platform scales. Teams that push changes too hard without collaboration often create resistance and friction within the organization. Sustainable growth requires working with stakeholders, not against them.

Lastly, successful scaling isn’t just about technical improvements; it also involves organizational and cultural shifts. Transitioning from siloed teams to a centrally managed platform requires a rethinking of how teams collaborate. Without addressing these broader changes, even the most advanced platform can falter.

The Journey of a Thousand Miles

As platform engineering teams move beyond their first year, the initial excitement fades, and what were once groundbreaking benefits become the new normal.

One of the biggest threats at this stage is being overwhelmed by your own success. Without a sustainable funding model beyond the initial project phase, maintaining momentum becomes increasingly difficult.

A surge of new demands and mounting technical debt can slow progress to a crawl, making it difficult for the team to keep delivering value. If not actively managed, technical debt becomes a roadblock, stalling progress or leading to critical failures that erode trust in the platform.

Platform teams themselves can also lose trust in the platform too. Poor task or team management may go unnoticed when engineers are working on new, exciting features. New challenges emerge for managers though when the day-to-day efforts begin to centre around user support and bug fixes. Engineers must continue to feel a sense of forward momentum to remain engaged.

Without the right support, burnout becomes inevitable, threatening the platform’s long-term viability.

It seems that every time a new and innovative way of working comes along—whether it’s Agile, DevOps, or now Platform Engineering—enterprises manage to take something promising and drain the life out of it. Why? Because true cultural change is hard, and organizations seem content to slap on new job titles and subtly tweak processes, instead of committing to meaningful transformation. In the end, they create bureaucratic systems that suffocate innovation, leaving us with the same old problems under shiny new labels.

The Rise and Fall of Agile

Agile was born out of a desire to improve software development. It emphasised customer collaboration over contract negotiation, responding to change over following a rigid plan, and delivering working software frequently. Its foundation rested on individuals and interactions rather than processes and tools. In theory, Agile was a game changer—a framework that allowed teams to adapt quickly, fostering both innovation and efficiency.

Yet, in the corporate world, Agile became something else. Instead of embracing its principles, companies wanted a system to follow—ironically the exact opposite of what the Agile manifesto stood for. Agile was supposed to be flexible, but as enterprises tried to standardise it, we saw the rise of prescriptive frameworks like Scrum. Suddenly, Agile meant endless meetings—daily stand-ups, sprint planning sessions, retrospectives, and grooming sessions that seemed to prioritise procedure over productivity.

Things only worsened with SAFe (Scaled Agile Framework), which promised to bring Agile to large organisations but instead turned into a bureaucratic nightmare. Companies were more concerned with adhering to the framework than delivering value. It became another checklist, void of the creativity and adaptability that Agile was supposed to foster.

Adding to the mess, Lean practices, typically used in manufacturing, became twisted into cost-cutting exercises that drained creativity from teams. IT departments became obsessed with eliminating anything deemed “waste,” leaving little room for innovation or experimentation.

Agile, once noble in its intent, became just another set of rigid procedures in the enterprise world—a far cry from its original vision.

DevOps: A Rebranding of the Status Quo

We sadly saw a similar story unfold with DevOps, once heralded as the solution to the age-old tension between development and operations. Its promise was simple: by tearing down the silos between these two groups, organisations could deliver software faster, with fewer errors and more reliability. The idea was sound. A cultural shift was needed—one that emphasised business value, customer focus, collaboration, and shared responsibility.

Instead, in many large enterprises, what we got was a rebranding exercise. Operations teams learned to install a few open-source tools, and suddenly declared themselves "DevOps". But the silos remained. DevOps was supposed to unify development and operations, but too often, the cultural change required for this integration was overlooked because, well, cultural change is hard. It’s much easier to change the names on org charts than to foster genuine collaboration between teams that historically never worked well together.

Many companies drank the Kool-Aid of tooling. Open-source tools flooded the market, and engineers jumped on them as a way to avoid the difficult work of fostering cultural change. But DevOps is about more than tools. It’s about bridging the gap between development and operations in a way that aligns with business objectives. Large enterprises, however, seemed more concerned with ticking off “DevOps” on their digital transformation checklist than implementing the real changes needed for success.

Will Platform Engineering Suffer the Same Fate?

Which brings us to Platform Engineering, the latest buzzword in the tech world. On paper, it’s about creating internal platforms that serve developers, making their work easier and more efficient. Done right, it’s customer-centric, focused on delivering business value, and guided by constant feedback. But if history tells us anything, it’s that Platform Engineering is in danger of suffering the same fate as Agile and DevOps.

I’m already seeing many enterprise infrastructure teams being rebranded as “Platform Teams”, without the necessary shift to a product mindset. Instead of focusing on developer enablement and feedback loops, I’ve seen teams become obsessed with the platform itself. As my good friend, Coté, once said that “Kubernetes is great, but it’s been a 7 year distraction”. Such teams build what they assume developers want, and are surprised when their offering is ignored.

“At the heart of the problem is that many infrastructure teams struggle to accept that their job is primarily to serve the needs of developers.”

When speaking with a new “developer focussed” team, one of my favourite questions to ask is “what IDE do your developers primarily use?” Eyes quickly dart around the room until one brave soul answers as best they can, but the mood changes when I joyfully ask how they’re devs are finding it, or what the most used plugins are. The truth is that infrastructure teams very rarely spend any time worrying or discussing with developers what their average day actually looks like.

It’s a sociotechnical problem that we’re trying to solve, and so, unsurprisingly, communication is at its core. Mel Conway is the OG of developer experience, and his work highlights how important it is for platform engineers to have strong feedback loops with developers; if they don’t, then they risk building systems that bear no resemblance of the needs of those who actually use their platforms.

Successful Platform Engineering requires a broad skill set that blends technical expertise with business acumen, customer empathy, and even marketing savvy. It demands people who can identify opportunities, understand customer needs, and innovate accordingly—a far cry from the typical ops role, and what engineers are likely to learn through any Computer Science degree or formal IT training.

Culture Eats Innovation for Breakfast

At its core, the problem is that enterprises are hesitant to embrace the cultural changes necessary for these movements to succeed. It’s a long journey of introspection and iterative change, not something that can be bought or copied from somewhere else.

Agile, DevOps, and Platform Engineering is about people, not tools.

Cultural change requires effort, introspection, and a bravery to rethink old habits. Without it, every new idea—whether Agile, DevOps, or Platform Engineering—will continue to be stifled by bureaucracy and corporate inertia. In the end, it’s not the methodologies themselves that fail, but the enterprise’s unwillingness to do the hard work of real change.