Were we over-promised?

In this lightning talk from DevOps Days Zurich 2025 I took five minutes to share my observations, experiences and grievances of working with product teams and specifically DevOps, highlighting the fact that while we were being ‘sold’ feature-delivery nirvana, in practice, platform building can often be more of a hindrance than an enabler of value delivery.

1 From chaos to control and enlightenment(?)

The provocation I want to posit is, that, based on my experiences as a product manager, but also from speaking to colleagues in the industry including DevOps engineers, the promise of that DevOps ‘made’ is an empty one:

Evolving from a 90s and early 2000s approach to software delivery where we either had a no-process, free-for-all, mess that certainly wasn’t scalable or an overly constrained bureaucratic approach that was, yes, controlled, but painful, inflexible and slow, we – and I am hugely simplifying here, eventually got enlightenment in the form of CI/CD, infrastructure as code, automation, evolutionary architecture, etc.

The promise: this would give us reliable, efficient value delivery at pace and ease.

2 A promise not delivered?

This promise, from where I am standing, is not always delivered. Too frequently, am I seeing startups messing, fixing, fiddling, f****ing about with their platform, when, in fact, they really should be delivering features, and in turn value.

Like this startup that burned through it’s entire VC funding, building the most beautiful microservices platform, to then run out of money, go bust, without ever having delivered a single microservice.

Or this enterprise continuously missing contractual milestones for feature delivery to their clients while happily building infrastructure for a level of cloud agnosticity they are likely to never need and will likely not be able to maintain or operate.

Or this public sector organisation that distracted a team into building an enterprise level platform for an innovation product, at a stage when they desperately needed pace to be first to market, and feature delivery to attract customers, validate the product and secure continued funding.

What I am saying is not that all DevOps efforts are bad, but that too frequently, there is a lack of focus what really matters (now).

3 Where do we go wrong?

From my own observations but also from talking to DevOps engineers, we can see a number of anti-patterns that contribute to this problem. Some of the most commonly named ones are:

Cloudnative Cargoculting

We opt for Kubernetes, Microservies or Lambdas without considering if they’re truly needed, often because they’re trendy, fashionable, strategically safe, or “Google uses them.” One of my colleagues working for a startup suggested that being to obsessed with K8S in an interview with him, is a red flag.

Hypedriven Leadership & CV-driven development

Leadership and  engineers alike sometimes chose esoteric frameworks or languages, implement blockchain based logging, or pursue event-driven architectures— telling us these provide benefits, while in fact we want to explore these technologies and have them on our CV.

Bikeshedding

Sometimes we fixate on small details or quite irrelevant details —like naming conventions or tool choices—because this procrastination is easier and more comfortable  than deciding on critical architectural choices or solving actual domain problems. As a product and change consultant I have seen Bikeshedding across literally every discipline and at every type of organisation and maturity stage…

Building by Default & Goldplating

We default to building (because that’s what we do) when we should be buying. We justify this by pointing to the future, overlooking that such adding of complexity or premature optimisation is not only a waste of time and effort now, but that the added complexity will be an issue now and bite us in the future.

Of course, there are more such anti-patterns, but you get the gist.

4 The reason: misunderstood purpose

I strongly believe that, human nature aside, the root cause is misunderstood purpose of what we are supposed to do, and, consequently bad goals and incentives.

Let’s take a step back: what are we supposed to do?

Turning ideas in people’s minds into features in the hands of users. And do so sufficiently reliably, at pace, with tight feedback loops. Everything else is just a means to this end.

If we do this well, then we have built our platform / pipeline as an enabler for value delivery.

If we do this exceedingly well

Done exceedingly well, our platform / pipeline becomes competitive advantage. Like in the case of one of my MedTech clients who were able to automate regulatory concerns as part of their pipeline, cutting regulatory deployment cycles from six months to two days, and consequently having one of the industry’s most successful IPOs.

I have outlined why your pipeline matters as strategic asset, that it needs to be managed like a product and this MedTech example in great detail here.

5 How do we fix this?

So how do we get ‘back’  on track? One colleague said to me: to know great CI/CD you’ll have seen it. Point being, it’s hard and possibly counter-intuitive. However, here are three suggestions that I believe are vital:

Focus on Outcomes not Tools

Your platform, DevOps is not a technical playground. It is all about supporting value delivery. This means building platforms, but the right one.

Mind your Context

One size doesn’t fit all—find your organisation’s sweet spot in terms of what they need from their platform and what they can support.

Think Thinnest sufficiently reliable Platform

Keep it lean. Focus on flow. Build the thinnest sufficiently reliable platform. Then evolve iteratively and incrementally as you would any other product.

Again, there is much more detail about this, here.

Also, I highly recommend Matteo Bianchi’s excellent talk Platform Engineering’s Inferno with more thoughts on this.

5 Where does that leave you?

If you’re shipping features fast, learning continuously, and delivering real value sufficiently reliably—you’re doing DevOps right.

If, on the other hand your PM is whining, shouting and bitching at you, maybe it’s time to review your approach.

Further thoughts…

Posts, talks and playbooks podcasts might find interesting related to this