Friction in a platform is never just a technical problem. It's never just an organizational one either.

I've spent twenty years watching consulting companies and vendors sell products and services that didn't deliver the value promised. Advisory wrapped in a sales cycle. Recommendations shaped by partnerships. Tools presented as solutions before the problem was properly named.

My position is simpler: no vendors to protect, no partnerships to preserve, no implementation team to keep busy. When I tell you something doesn't make sense for your situation, there's nothing behind that opinion except the pattern I've recognised across dozens of similar organisations.

That independence isn't a marketing claim. It's structural. I don't implement, so I have no incentive to make your situation more complex than it is.

A platform decision is never purely technical. But it's also never purely organizational. The engineers see the constraints; the executives see the pressure. Almost nobody sits at the point where those two views converge — and that's where the real decision lives.

Twenty years of implementation work gives me the technical depth to evaluate what's actually possible. Working directly with CTOs and VPs gives me the business context to evaluate what actually matters. The advisory is useful precisely because I don't have to choose which lens to use.

My first job as a Linux engineer, I automated everything I could touch — not because anyone asked me to, but because repetition felt like waste. Manual steps meant waiting, mistakes, and dependency on whoever held the knowledge. That instinct has never left me.

Infrastructure as Code was the first time the industry gave that instinct a name. GitOps was the maturation of it: not just defining infrastructure as code, but managing the entire platform lifecycle — deployments, configuration, policy — through Git, with automated reconciliation. No tickets. No manual steps. No bottlenecks waiting for the right person to approve a change.

The underlying principle is an API-driven, self-service platform. When everything is code, developers don't wait. Changes are reviewed, auditable, and reversible. The platform becomes something teams trust rather than work around.

Most platform adoption problems I see trace back to friction. Teams don't use a platform because using it is harder than not using it. The fix is rarely more tooling — it's removing the manual steps, the tickets, the gates that make the platform feel like an obstacle.

AI has changed what implementation costs. A Kubernetes manifest, a pipeline, a deployment script — these are now seconds away for any engineer. That shifts the real question: not how to build, but what to build, when, and at what architectural cost.

Working closely with AI and seeing its impact across engineering organisations, one thing is clear: the platforms being built today weren't designed for agentic workloads. The gap is structural — access models, audit trails, non-determinism, GitOps-native change management.

Teams that treat AI readiness as a platform architecture problem now will have leverage. Teams that wait until agents are already in production will spend their time on remediation.

The connection to friction is direct: AI agents cannot be fully leveraged on a platform that runs on legacy processes — tickets, manual approvals, undocumented procedures. To get real value from AI, you must first have a platform where everything is defined as code, managed via API, and operable without human intervention at every step. Reduce friction first. Then AI multiplies what you've built.