"We're moving to microservices."

Every time I hear this, my first question is: "Why?" And in about half the cases, the answer boils down to "because everyone else is."

Here's what nobody in the microservices evangelism camp tells you: you need a platform to make microservices work. Without one, you're trading one set of problems for a worse set.

GitOps is elegant in theory: Git is the single source of truth, every change is auditable, infrastructure converges to the desired state automatically.

In practice? If your Git hygiene is broken, GitOps just automates the chaos faster.

Two of the most powerful governance tools in Azure, and two of the most confused. I've seen teams use RBAC when they need Policy, and Policy when they need RBAC. Here's the clear distinction.

We spend millions on developer tooling — IDEs, CI/CD, cloud platforms, monitoring. Yet in most organisations, the developer experience is still frustrating.

The gap isn't in the tools. It's in the space BETWEEN the tools.

"We have observability — we use Grafana dashboards."

No. You have monitoring. And there's a critical difference that most teams miss until their first major incident.

"Who owns this service?"

If answering that question requires Slack messages, tribal knowledge, or archaeology through Git blame — you need a service catalogue.

Terraform state is both the most important and most dangerous file in your infrastructure. It's the source of truth for what Terraform manages. Lose it, corrupt it, or let two people modify it simultaneously, and you're in for a very bad day.

Here are the lessons I learned — some of them the hard way.

The "10x engineer" myth is toxic in any discipline. In platform engineering, it's actively harmful.

Platform engineering isn't about one brilliant person writing clever code. It's about making 100 engineers 10% more productive. That's a 10x impact — but it comes from systems, not heroics.

"Should we use AKS or run our own Kubernetes?"

I've had this conversation at least a dozen times. The answer is almost always AKS — but there are legitimate reasons for self-managed. Here's the honest comparison from someone who's run both.

In my current role, I've helped onboard over 90 engineering teams onto a shared platform. Not 90 developers — 90 TEAMS. Each with their own tech stack, their own expectations, and their own definition of "it should just work."

Here's what I learned about doing this at scale.