Engineering Management

Most orgs rename their DevOps team to “Platform Engineering” and call it a strategy. It isn’t.

The Confluence page gets updated. A roadmap appears with “IDP” somewhere in Q3. The team lead gets a new title. Six months later, developers are still filing tickets to get an environment, and the “platform team” is still the bottleneck for every deployment. Nothing changed except the branding.

This is the rebrand problem. And it’s widespread enough that it’s worth being direct about what actually separates a platform team from a DevOps team that got a new name.

Engineers care deeply about observability. We instrument systems, build dashboards, define SLOs, and set up alerts. Because a system you can’t see is a system you can’t improve. We’d never run production infrastructure without telemetry.

Then we run teams with no telemetry at all.

No signal on whether the week moved things forward. No structured way to surface blockers early. No feedback loop that converts experience into better execution. Just meetings, Slack noise, and the vague sense that things are either fine or not fine.

I’ve been an engineering manager for about a month. Everything I think I know about this job comes from books, talks, and watching other managers. Not from doing it.

That’s an uncomfortable thing to write. But it’s accurate, and I’d rather be honest about where I’m starting than write a post that performs experience I don’t have.

I’ve had a personal north star for a while that’s shaped why I wanted this role in the first place: