.png)
I find it ironic that I officially hold the title of DevOps Engineer, because I’ve always believed DevOps wasn’t meant to be a job title.
DevOps is a philosophy. It’s a culture of collaboration, shared ownership, and breaking down silos, not building new ones. Putting it on a business card was always a little counterintuitive to me.
That distinction shapes a lot of how I think about this kind of work.
The technical part is only half of it
Platform engineering, SRE, DevOps, whatever you want to call it, the technical work matters. But so does the people and process side. In my experience that part is often underestimated. If the real problem is process, fix the process. Don’t engineer around it.
When someone on your team can’t get what they need to do their job, that’s worth a closer look. Is it a genuine security or compliance constraint? Totally valid, keep it. Is it unnecessary friction that could be removed? That’s a choice someone made, and it can be unmade.
When enabling becomes gatekeeping
Sometimes though, the role can slide into something else. This is especially common in mid to large sized companies where a separate team controls access to tools and systems. What starts as a reasonable org structure can quietly turn into unnecessary approval layers, access that takes weeks to get, and people feeling like they need to justify their technical decisions to someone outside their team.
Picture this: a developer puts in a request for access to a tool they need to do their job. Instead of getting what they need, they find themselves defending their entire technical approach. Why are you doing it this way? Have you considered doing it that way instead? A simple request turns into an unsolicited code review from someone who likely doesn’t have the full picture.
A better approach is curiosity. When a request doesn’t make sense, ask questions to understand the full picture before forming an opinion. There’s usually context that isn’t immediately visible. Listen, learn, then collaborate on the best path forward. The teams are different, but the goals are the same. Different function, not a higher one.
If a developer’s technical decisions are consistently missing the mark after feedback has been given, that’s a conversation for their people manager to have, not a reason to build walls around everyone else’s work.
You get to choose how you show up
The best version of these roles is an enabler. Someone who clears the path, reduces unnecessary friction, and makes it easier for teammates to do their best work. Someone who treats good practices as something worth spreading across the whole team, not something to gatekeep.
I love the outdoor principle of leaving the trail better than you found it. Don’t make it harder for the next person. If you see something that needs fixing, fix it.
Your job isn’t to stand at the trailhead checking credentials. It’s to make sure the trail is clear. That’s a human centric approach to technical work, and in my opinion it’s what separates the good ones from the great ones.