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.

Inspired by an excellent article on the relevance of blogs for platform engineering teams by my long-time friend, Ben Neise, I wanted to share my thoughts on how a team blog fits into a comprehensive communications strategy for such teams.

I’ve had the opportunity to work with platform engineering teams from across the industry and, in my experience, if you don’t have a plan for how your team will communicate with others, you’re going to fail.

There are some reasons for this:

• Customer centricity is a core tenet of platform engineering. Your success is measured not only on what capabilities your team provides, but how they execute them.

• Your comms plan includes the outcomes you would like to see. This is an important part of explaining its importance to your team. It will likely include building awareness of capability, growing user adoption, maintaining user satisfaction, reducing support tickets, and avoiding fallout after changes.

• The act of communicating is often more important than the content of the communication. In busy enterprise environments, it’s surprisingly easy to forget how great a team is, or if they still exist, unless you’re receiving regular signals of momentum.

• Communication is needed at all levels, whether that is to demonstrate value to leadership, reassure other teams that changes you make can be positive for them, or simply to ensure your customers know about the latest new feature or an important upcoming change.

• Communication doesn’t necessarily come naturally to everyone. Many engineers may feel uncomfortable with the premise that they must “serve” customers. As a leader, you must empower your team and help them navigate a potentially large personal change in culture.

In this article, I’ll outline the communication channels that I’ve seen and how the most innovative, mature, and highly successful teams employ them.

The Communications Blueprint

1. Product Website

A simple, one-page product website could be the single best improvement you make for the visibility of your team. With a friendly URL, it acts as an attractive landing zone for both new and existing platform users. Engineers often shy away from sales or marketing, but the truth is that in their own lives, they’ll quickly judge the quality of a product based on the vendors’ website.

Your product website should be visually attractive and only needs to answer three simple questions: “what problem does the product solve?”, “What benefits can developers expect?”, and “Where can they find out more?”.

I should stress that your product website needs to be visually attractive - your goal is to provide prospective users a level of polish that they expect from external companies. You don’t need to be a professional web design either; there are plenty of templates available for as little as $10 that you can customize to your needs. Also, your product webpage shouldn’t change much because it’s purpose is to simply be a landing zone for users, where they can follow links to find the information they need.

2. Team Blog

As per the post that inspired this article, creating a blog for your platform engineering team is an excellent way to share additional detail or context with your user base.

Blog posts are incredibly practical. You’ll often be limited in how much you can share on other mediums like email or Slack, but blog posts provide a practical way to share detailed information, engaging users with diagrams, screenshots, or videos. They can also be updated with clarifications and FAQs, enhancing user engagement and transparency.

Blog posts are also brilliant for user engagement. There’s huge value to be had in using your team blog to give users a “look behind the curtain”, as to how your team or platform operates. There’s so many great benefits to doing this! The more knowledgable users become about your platform, the more likely they are to become advocates of it. Your engineers also get an opportunity to practice outreach in safe environment before tackling the more daunting task of presenting at conferences. And, by demonstrating some transparency, you build trust and loyalty with users which can be vital come the day that you have outage.

3. Health Dashboard

I’m always disappointed by both the lack and quality of most product health dashboards. When a user experiences a problem with your product, your duty is to minimize their frustration and fix their problem as quickly as you can. The quickest way to infuriate a user is to not respond to their pleas for help. Of course, if you have an outage affecting all users, it’s unreasonable to assume that you’ll somehow be able to help everyone independently.

A health dashboard gives users a fast, convenient way of working out if a problem is already known about, and if so, get progress updates towards its resolution. It gives your team an ability to communicate with everyone in an efficient manner. Users are generally much more forgiving if they know what the problem is, that someone is looking at it, and they know when they can expect a further update.

Users need to able to trust the dashboard though. If the platform is known to be having a problem and the dashboard is all green, then nobody will look at it ever again. Likewise, if problems are reported but then no fix is ever posted, it leaves users with an uneasy feeling about the quality of the platform.

It’s worth noting that new, prospective users will often look at a health dashboard to determine how reliable a platform is. Of course, they’ll be interested to see if you’ve had any big outages, but also in how you handled such events. There are plenty of examples where vendors have been applauded after a major incident, rather than chastised, simply because they were open, honest and timely in their updates.

4. Documentation

I believe that great documentation is the secret to a well-run business. Whilst many teams might see it as a necessary evil, I believe the art of intentionally recording your knowledge is one of the most selfless and positive change you can make in a team.

Well written documentation is unfortunately rare to find out in the field; it’s either a handful of pages hidden in a darkened corner, or an absolute glut of poorly organised pages of outdated technical instructions that assume you already know everything.

The issue is that documentation tends to be written from the perspective of the author, not the reader. Like any good product, Great documentation is user-centric, organized around the user’s journey, with a clear ‘Getting Started’ guide that demonstrates how a simple use case is ludicrously easy to accomplish and a comprehensive ‘Knowledge Base’ giving the user confidence that there is support available for more challenging applications.

5. Email Updates

Emails are universally hated, but they remain one of the most efficient mediums for communicating asynchronously across a large number of people. Most people have overflowing inboxes, so email updates are best kept for non-urgent, fairly infrequent updates - I’d suggest monthly at most.

Unlike some of the other mediums in this article where users are seeking information, email updates are a team’s opportunity to initiate comms with users. They are a phenomenal way of signposting that your team have been hard at work, adding features and fixing bugs. Bear in mind, however, that people on average spend just 3-5 seconds skimming the content of an email before deciding if they should bin it. You can greatly improve your chances by using nicely formatted html - as always, there are templates available for as little as $10 you can tailor to your needs.

That said, it’s not actually important if people read your email update. Its primary purpose is simply to remind people that you exist and you’re moving forward. As a company director once explained to me as a young engineer, “communicating change is as important as the change itself”. He added, “if people don’t see evidence of movement, they assume stagnation”. Wise words that I’ve passed on to every business I’ve worked with over the past five years.

6. Messaging / Chat

Messaging or chat systems like Slack or Teams are now ubiquitous across the business world. Indeed, it’s not uncommon to find both within a single organization, although that could change if the EU have their way. My advice would be that it is vital that your team is present wherever your user base is - even if that’s not your platform of choice.

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. There are few golden rules I advise teams to follow:

• 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 should be thought of as a “public” customer service platform. I strongly encourage platform teams to have a separate “internal” channel where they can discuss and debate topics. A user should never see two engineers debating with one another - they both lose credibility.

• 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.

• Chat is great for adhoc queries, but anything bigger should be tracked in issue management software. Nobody likes to be told to “open a ticket”, so ensure your engineers can do this on behalf of the user.

Conclusion

In conclusion, effective communication is a cornerstone of successful platform engineering teams. By leveraging a combination of these communication channels, teams can ensure they are not only delivering valuable capabilities but also maintaining strong relationships with their users. Each communication channel plays a unique role in building awareness, fostering user adoption, and ensuring ongoing satisfaction. By adopting a customer-centric approach and empowering team members to communicate effectively, platform engineering teams can build trust, demonstrate transparency, and ultimately achieve greater success in their initiatives. Remember, in the messy world of enterprise environments, it’s not just about the changes you implement but also about how well you communicate those changes that truly drives your team forward.

Last week Gartner published the first edition of the Gartner Hype Cycle for Platform Engineering. Most in the community were pleased to see such recognition, but some were disappointed to see that IDPs, AI-Augmented Software Engineering, DevOps Platforms and even GitOps all gained a spot in the dreaded “Peak of Inflated Expectations” phase.

What is the Hype Cycle?

The Gartner Hype Cycle maps out the lifecycle of new technologies. It’s like a tech rollercoaster that starts with the initial hype, dips into the “Trough of Disillusionment” when the tech doesn’t meet sky-high expectations, and then climbs to a more realistic “Plateau of Productivity” as it matures and proves its worth.

Knowing where a technology stands on this curve helps businesses decide when to invest. Jumping in too early can mean wasted resources on immature tech, while getting in at the right time can give you a competitive edge without the headache of early bugs and inefficiencies.

What’s the problem with it?

One of the main benefits of the Gartner Hype Cycle is that it’s an incredibly simple graph that will often feel relatable - things that dominate the media will likely appear at the top of the hype curve. And that is also where Gartner draws the most criticism; is there credible research behind it, or are we just looking at a graph depicting how popular a set of loosely related buzzwords happen to be?

The big issue for me is that many decision makers, particularly those in large enterprise, will make assumptions about how useful or valuable a technology is based on its position on the graph. They’ll likely see the graph posted on social media, but never get round to reading the (paywalled) analytical report that accompanies it. As a result, those in large organisation who are innovating and seeing value will waste valuable effort re-iterating why what they’re doing is important. Worse, they’ll likely face harsh criticism from people with limited experience in subject.

The truth is that all innovations inevitably go through the fives stages, and its position on the Hype Cycle has little correlation with how much value your organisation can expect from implementing it.

What else was in the report?

The report that accompanies the graph is over 100 pages long and delves into Gartner’s analysis of each technology on the curve, as well as providing recommendations of where organisations should accelerate their efforts.

In addition to providing a definition and reasoning as to the benefits of each technology, Gartner also provides estimates on market penetration, drivers and obstacles, as well as a set of recommendations, sample vendors and additional reading for those that would like to learn more.

I won’t go too deep into Gartner’s recommendations, given its commercial property, but I can share where their research echoes my own experience. If you’re a busy IT leader, there’s a reason why Garner’s services are held in high regard.

It’s clear that three main pushes in the industry just now are around Developer Experience, producing software that’s Secure by Design, and building product-centric delivery models described in Team Topologies.

Developer Experience

Kate over on team RedMonk recently wrote a great piece on why developers are the new kingmakers, acknowledging the unique impact they can have within an organisation. I’ve seen the same change out in field, ever since the Covid pandemic, where the survival of many firms was reliant on the quality of customers’ digital journey. It seems naturally that top-tier developer talent find themselves in a strong position, able to choose between a raft of companies. IT Leaders must find ways to enable developers to be effective in their role and not held back by layers of crusty bureaucracy. If it is perceived to be too difficult to effect change within an organisation, developers will simply go elsewhere.

Secure by Design

Of course, it’s never that simple though. Whilst enabling developers, organisations are under increasing pressure to build quality software that is resistant to attack. The IBM Cost of a Data Breach Report continues to show that whilst we have more awareness of security and tooling to support, there is a steady increase in both the probability and severity of a security breach resulting in the theft of sensitive customer data. The main message I hear from organisations is that after a period of accelerated innovation and development as a result of the pandemic, they now want to normalise ways of working across development teams, rationalise an eclectic mix of duplicate tooling, and bring a new wave of simplicity to their software delivery lifecycle.

Team Topologies

And finally, it’s refreshing to see the most innovative of brands recognising that such change requires more than tooling; it needs an appreciation of human psychology and a desire to architect culture alongside technology. Since it’s publication in 2019, Team Topologies has become the go-to handbook for those wishing to understand how organisational structure, communication paths, and culture can work in harmony with technology to effect sustainable change. This is reflected by Gartner by its inclusion within the Slope of Enlightenment.

Summary

Gartner rightly receives a lot of attention when they release snippets from their reports, be that the coveted Gartner Magic Quadrant or the Hype Cycle. It’s important for the industry to appreciate that there is significant research behind these that is necessary to understand the full picture. With the Hype Cycle in particular, it’s important to recognise that the rating of a technology within the graph does not directly reflect the value a business might see or whether it’s an area that they should invest.

You’re no doubt sick of reading about artificial intelligence as every tech writer, product manager and CEO seems ever insistent that the latest generative AI model is going to change the world. It’s estimated that there are 70,717 AI startups worldwide, including 214 unicorns (privately owned startups valued at over US$1 billion). Forecasts say that the AI market is expected to reach $184 billion by the end of 2024 and could reach $826.70 billion by 2030. But is it realistic for this brand new market to sustain nearly 30% growth, year on year, for five years?

As someone who is frequently asked about the role of AI and its future, I've started to question whether we might be witnessing the inflation of a dot-com-like bubble, poised to burst. While the advancements in LLMs are undeniably impressive, it's essential to scrutinise the sustainability and long-term impact of these technologies.

Spectacular, Yet Incremental Advances

The performance of LLMs, such as OpenAI's GPT series, is nothing short of remarkable. These models can generate coherent text, translate languages, and even write code. But how do they work? Have we created artificial intelligence or just an auto-correct on steroids?

My concern is that much of the science behind LLMs reminds me of my time as a Computer Science student. I won’t dive into the details here, but Sean Trott and Timothy Lee wrote a great primer that I can highly recommend for the casual reader. As the pair describe, much of the research around LLMs has been around for decades. The fundamental change in recent generative aI news is mostly a story of scale.

The magnitude of modern generative AI models is simply breathtaking. In February 2019, OpenAI released the GPT-2 model that used 1.5 billion parameters. In June 2020, GPT-3 followed with a staggering 175 billion parameters and training data exceeding 500 billion words. If leaked news is to be believed, GPT-4 has more than a trillion parameters and was trained on roughly 10 trillion words.

“Any sufficiently advanced technology is indistinguishable from magic.” - Arthur C. Clarke

Unsurprisingly, it is developments in GPU technology that has made much of the advancements in artificial intelligence possible. With the ability to process ever increasing libraries of training data, GenAI is able to amaze users with human-like responses to almost any query.

But how long can we continue to feed the machine?

The Scarcity of Quality Data

High-quality training data is a critical component for LLMs, yet it is surprisingly scarce. A recent study indicates only 50% of internet traffic comes from humans, that 32% comes from "bad" bots, and 18% from "good" bots. This bot-generated content risks contaminating the training datasets, leading to AI models that amplify misinformation and low-quality data. As a result, there have been several instances where companies have been accused of using unethical or illegal means to harvest data for the purpose of training AI models.

OpenAI themselves have found themselves in deepening legal hot water, with legal proceedings raised by a number of news outlets over the harvesting of copyright material to train GPT models. Indeed, in a submission to the House of Lords communications and digital select committee, OpenAI said it would be impossible to train today’s leading AI models without using copyright materials.

The problem is such that Adobe is reportedly buying video content for $3 per minute to help build it’s AI models.

Companies that historically relied on advertising are now securing lucrative deals to sell customer data to those training AI models. In February 2024, Reddit reportedly made a $60 million deal with Google, followed by Reddit stocks surging 14% in May after similar news of a deal with OpenAI.

As data becomes increasingly valuable, organisations are revising their privacy policies to monetise their information assets. It’s no surprise then that end users are increasingly sensitive to how their data might be used when consuming AI and other SaaS offerings - beautifully highlighted by the recent Twitter thunderstorm after Adobe made some questionable changes to its T&Cs.

Financial Viability of AI Investments

Research indicates that as LLMs grow, the amount of additional data required to achieve marginal improvements increases significantly. This trend suggests that LLMs will eventually reach a plateau, where the cost and effort to enhance performance will outweigh the benefits. This scenario challenges the prevailing belief that AI will continuously improve until it reaches near-perfect accuracy.

Dario Amodei, cofounder of Anthropic says the AI models currently in development will cost $1bn to train, and the 2025 and 2026 models might be $5bn or $10bn!

Other economic considerations further complicate the AI narrative. Sequoia Capital estimates that the AI industry has invested $50 billion to generate a mere $3 billion in revenue. This stark imbalance underscores the financial risks associated with AI development. If AI advancements do not transcend beyond being sophisticated assistants, the financial implications could be dire.

I was recently talking with some smart people in the medical sciences world, where machine learning has long proven its tremendous abilities at assisting experts in finding anomalies in health data. When it comes to generative AI though, they have a similar challenge to everyone else … so called “hallucinations”.

Where machine learning models work on a principle of probabilities, generative AI will happily answer any query with the blind, unshakeable confidence of a teenager.

The question remains whether generative AI will ever attain a level of reliability where its output can be entirely trusted, allowing humans to truly delegate tasks. Until then, it remains just a somewhat helpful virtual assistant that can help.

And, assuming we can find and afford the data necessary to train such a model, what else might we need to consider?

The Ecological Cost of AI

The media has begun to shed light on the substantial ecological footprint of training LLMs, paralleling the eventual scrutiny faced by crypto-mining.

Researchers estimated that creating GPT-3 consumed 1,287 megawatt hours of electricity - the equivalent annual consumption of over 350 UK homes - and was responsible for over 550 tons of carbon dioxide.

Unfortunately, the story doesn’t get much better after the model is trained. Some sources claim that ChatGPT consumes around 60 times more energy per query than a conventional Google search.

According to the International Energy Agency’s Electricity 2024 report, data centres, cryptocurrencies, and artificial intelligence consumed about 460TWh of electricity worldwide in 2022, accounting for almost 2% of total global electricity demand and 2.5% to 3.7% of global emissions - surpassing the aviation industry’s 2.4%.

Conclusion

Much like the dot-com bubble of past, it’s undeniable that generative AI and Large Language Models will have an immense impact on how we interact with computers, but it feels unrealistic that the everything needs or will benefit from AI.

For those use cases that can truly benefit from the technology, the potential environmental costs, data scarcity, diminishing returns, and economic viability all pose significant challenges that must be reviewed carefully.

My hope is that we can navigate these new challenges more adeptly than the early 2000’s.