Tag: platform engineering

A Platform Engineering Manifesto

By: Kenneth Henseler, 15-FEB-2026

I’ve spent a lot of time in the trenches of IT Infrastructure. If you’ve been there, you know the drill: The “Ticket Factory.”

Developers need a server? Ticket.

Need a firewall rule? Ticket.

Need a database? Ticket.

For decades, this was the industry standard. It was safe. It was controlled. But in 2026, it’s also a bottleneck that kills velocity. When your smartest engineers spend 60% of their week manually executing repetitive tasks from a queue, you aren’t managing infrastructure—you’re managing a bureaucracy.

That’s why I’m leading a strategic shift in my organization: Moving from IT Service Management (ITSM) to Platform Engineering. We call it Project Polaris.

Here is the philosophy behind the shift, and why “Good IT” isn’t about closing tickets anymore—it’s about building products.

1. The “Ticket Factory” Doesn’t Scale

Traditional IT operations are linear. If you hire 10 more developers, you generate 10x more requests, which means you need 10x more sysadmins to handle the load. That math doesn’t work.

We are moving away from being “Gatekeepers” (who approve and implement) to becoming “Gardeners” (who cultivate the ecosystem).

The goal of our new Platform Engineering model is simple: Self-Service with Guardrails.

We are building an Internal Developer Platform (IDP) that treats our infrastructure as a product. If a developer needs a resource, they shouldn’t have to ask me for permission; they should be able to consume it via API or portal, knowing that the security and compliance checks are already baked in.

2. The “Golden Ratio” of Capacity Planning

One of the hardest lessons in engineering leadership is protecting your team’s time. If you don’t defend it, “keeping the lights on” (KTLO) will eat 100% of your bandwidth.

As part of this restructure, we are implementing a strict capacity model that I call the “Golden Ratio” for our sprints:

• 50% Strategic Enablers: Work that moves the business forward (Building the IDP, new architecture, automation).

• 30% Operational/Support: The inevitable day-to-day reality of running systems.

• 20% Tech Debt Repayment: Mandatory. Non-negotiable.

If you don’t explicitly budget for Tech Debt, you are essentially taking out a high-interest loan on your future stability. Eventually, the interest payments (outages, slow deployments, manual patches) will bankrupt your time.

3. Governance as Code (Safety Without Speed Bumps)

The biggest fear with self-service is usually security. “If we let devs provision their own DBs, won’t they leave them open to the internet?”

In the old world, we stopped this by having a human review every change. In the Platform world, we stop this with Governance as Code.

Instead of a manual approval board, we define our policies in the platform itself.

• You want an S3 bucket? Fine, but the platform automatically enforces encryption and private access policies before it’s even created.

• You need a VM? The image is pre-hardened and automatically patched.

We aren’t removing the rules; we are automating the enforcement. This allows us to say “Yes” faster, without lowering our security posture.

The North Star, Polaris

This transition isn’t easy. It requires a culture shift from “I own this server” to “I own the code that builds this server.”

But the destination is worth it. By treating our platform as a product, we stop being the “Department of No” and start being the accelerator that the business actually needs.

See you in the server room (or the repo).

– Ken