The architecture was clean, well structured, and built by capable engineers. It had also been designed for a different company.
The team that built it were good at what they did. But they were delivering an established, standardised approach into a business with its own context, constraints, and way of operating, and a technically correct solution is not always the right one for the company adopting it.
The implementation was sound. The assumptions behind it were not. Without enough business context, historical knowledge, or reliable documentation, it is easy to fall back on industry-standard patterns where no meaningful standard exists. The result was infrastructure built on best effort: reliable in principle, but disconnected from the company it was meant to serve.
The first weeks
A few years ago I joined a fast-growing company at a critical stage of its development. The product was already in the market, customers were actively using it, revenue was increasing, and the engineering team was small but ambitious. The organisation needed to scale without losing the speed and flexibility that had supported its early growth.
On paper, my responsibility was simple: own the platform. In practice, that meant understanding not only the infrastructure that had been built, but also the business context, operational constraints, and historical decisions that had shaped it.
An external consultancy had already established the cloud architecture, deployment pipelines, and most of the operational foundations. The technical implementation was already in place, but the reasoning, constraints, and historical context behind many of those decisions were not always visible.
A conventional first step would have been to review the Terraform modules, Kubernetes manifests, and CI/CD pipelines.
I chose not to start there.
For the first few weeks I barely touched the infrastructure. Before changing anything, I needed to understand the organisation around it: how developers worked, how product decisions were made, how engineering and product communicated, what created friction in their daily work, what the founders expected, and where time was being lost.
Most importantly, I wanted to understand the reasoning behind the decisions that had already been made. Without that historical and operational context, it would have been easy to mistake deliberate trade-offs for technical mistakes, or to replace one set of assumptions with another.
Building reliable infrastructure without understanding the organisation is like building on sand. The structure may look impressive and technically sound, but without the right foundation it will eventually fail under pressure.
Infrastructure without context is just configuration.
Built for a different company
The architecture was technically sound. It had been designed with future scale in mind: large Kubernetes clusters, oversized databases, multiple layers of abstraction, and operational patterns that would have made sense for an organisation with hundreds of engineers.
We were not hundreds of engineers.
We were a small team that needed to move quickly, learn continuously, and adapt without unnecessary friction. Nothing was technically incorrect, but almost every part of the platform was heavier, more complex, and more expensive to operate than the business required.
The platform had been implemented correctly. The failure had occurred earlier, when assumptions about future scale replaced an understanding of the company that actually existed.
Architecture does not become ineffective because the implementation is technically flawed. It becomes ineffective when it no longer reflects the scale, constraints, priorities, and operating reality of the business it is meant to support.
The easiest thing to blame
A few weeks later, production issues began to emerge, and almost every discussion followed the same pattern:
It must be the infrastructure.
We investigated. The root cause was not Kubernetes, Azure, or networking. It was a Java garbage-collection configuration.
Infrastructure had become the easiest component to blame because it was the least visible and least understood part of the system. When teams lack full observability across applications, dependencies, and runtime behaviour, the platform often becomes the default explanation for any failure.
That experience changed how I approach platform problems. Whenever someone says the platform is the problem, my first question is not how we should change the infrastructure. It is: what evidence do we actually have?
In that case, the assumption had already consumed more time than the investigation itself.
Learning to say no
One of the most common misconceptions about platform engineering is that its primary purpose is to introduce new technology.
Sometimes, the most valuable decision is not to introduce anything at all.
Requests regularly came from outside the engineering team: new tools, additional platform capabilities, and new architectural patterns. Some were genuinely interesting, and many were proposed with good intentions. However, technical appeal alone was not enough to justify their adoption.
Whenever someone proposed a new technology, my first question was not how we would implement it. It was: what problem are we trying to solve?
If there was no clear problem, measurable benefit, or accountable owner, the discussion stopped there.
Every dependency creates a future maintenance obligation. Every abstraction introduces additional complexity. Every platform capability carries an operational cost that someone will eventually have to own, support, and justify.
Learning to say no was not about resisting innovation. It was about protecting the organisation from unnecessary complexity and ensuring that every technical decision served a real business need.
Giving ownership back to developers
One issue became clear early on: developers were uncomfortable with deployments. Platform engineers owned production, development teams waited for changes to be released, and platform gradually became a bottleneck.
We changed the ownership model. Technical leads took responsibility for deployments, platform provided the guardrails, and development teams owned delivery.
The transition was uncomfortable at first, but deployments gradually became part of the development lifecycle rather than a request handed to another team.
The purpose of a platform is not to centralise responsibility. It is to make responsibility safe to distribute.
My own mistake
Not every lesson came from other people's decisions. Some came from mine.
Earlier in my career, I had worked at larger organisations and, without realising it, carried some of those habits with me. I assumed that because an approach had worked in one environment, it would work just as well in another.
I over-engineered parts of the observability stack and introduced processes that made sense for organisations with dedicated platform teams. In a smaller company, however, they created unnecessary operational overhead and added complexity without solving an immediate problem.
I was preparing for challenges the company did not yet have, using solutions designed for an organisation it was not.
Looking back, the mistake was not choosing the wrong technology. It was copying architecture without fully understanding the reasoning, scale, and context behind it.
Today, I try to follow one principle: never copy architecture. Understand and improve the reasoning behind it.
What platform engineering actually is
The best platform engineers I have worked with tend to share the same habits. They observe before they build, understand the business before proposing solutions, earn trust before changing systems, and challenge assumptions before introducing new technology.
Most importantly, they remain humble. Technology evolves constantly, but humility remains essential.
AI can already generate Terraform, build pipelines, and explain Kubernetes. What it still cannot replace is judgement, and judgement comes from understanding people, business context, constraints, trade-offs, and consequences.
Looking back
Years later, I barely remember the Terraform modules I wrote, the Kubernetes upgrades I completed, or the deployment pipelines I built.
What I remember are the conversations, the difficult decisions, the moments when saying no protected the engineering team, and the times when simplifying something had a greater impact than building something new.
I also remember the trust that developed over time, because people knew that every technical decision began with the same question: do we actually need this?
Technology will always change. The clusters we build today will eventually disappear, the pipelines will be rewritten, the cloud provider may change, and even the programming languages will be different.
But twenty years from now, people will not remember the infrastructure we built. They will remember whether they trusted our judgement.
In the end, that is what engineering is really about.
Principles reinforced