The Work of Building for Other Engineers: Platform & SRE Mindset

Recently, I’ve seen this thread on subreddit:

What do you wish someone told you when you became a SRE/Platform/DevOps engineer?

(…expanded a long list of cloud tools, container orchestrators and CI/CD stacks to learn.)

I found myself commenting this:

DevOps/SRE highly depends on what organizations need. Whatever that is, focus on giving people the right tools, automations, and platforms to do their job faster, easier, and safer —on their own.

In this post, I expand on that idea through practical stories from my experience.

How it started for me

I’ve been a software engineer who builds for others my whole career. 

In my first job as a fresh graduate, my title was “Cloud System Engineer,” though I didn’t really know much of what that meant. I was working on a telco cloud; using Python and Ansible to orchestrate a custom OpenStack cluster and make it deployable on different sites.

I took on the dreaded major upgrade of Ansible. The work was to learn it deeper and make it work better for our specific needs.

Later, excited of what we'd achieved, I gave a couple of talks about it. I realize now that those talks weren't exactly about Ansible itself. They focused on fundamental principles like idempotency, avoiding housekeeping after using tools, and replacing risky sudo commands with actual modules. Way more essential principles than the tool itself.

I believe that our job as engineers isn’t about the tools, it is about finding the most effective ways (within the constraints/tools we have) to solve a problem.

As I started wearing the SRE hat after my first role, I kept learning this: platform-minded engineering is about scaling solutions in ways that empower the people who use them.

Photo by Volodymyr Dobrovolskyy on Unsplash

The Work of an SRE (or any Platform-Minded Engineer)

We all started with DevOps. Then read the Google SRE book, tried things that didn't exactly fit our organizations, and eventually settled on what actually works for us. 

If your role involves providing people in your organization with a platform—whether it’s Compute, CI/CD, or Production Readiness—I’m writing this for you. Because I'm thinking about your role, regardless of what your title happens to be.

Day to day, your job might look like:

• Scripting to automate repetitive tasks

• Creating fast paths for developers

• Setting up on-call rotations

• Jumping into incidents

• Helping people debug gnarly issues

• Writing docs to save others from getting stuck

• Improving retry logic in a shared library

• Making CI pipelines faster

• Building safety rails so no one deletes production by accident

You’re probably also running a busy Slack channel where folks ask questions about your tools/expertise.

However it looks on the surface, your job was never to learn how set up a bunch of tools and babysit them.

Your actual job is to help others deliver business value faster, easier and safer, on their own.

You’re a multiplier. Someone who understands how work flows from idea to user, and shapes that path to be smooth, resilient, and empowering.

Here are 3 ways to think about how to become the multiplier you are meant to be. 

1. Spend the Time to Co-Create with Your Users

You can’t solve problems that matter without talking to people.

You’re building platforms for others, not only for yourself. So yes, have opinions, use them to guide your work and bake them into your systems. But always keep your users close. Very close.

I remember one project at my last company where we wanted to improve our incident report template because people had hard time writing. As SREs, of course we had opinions on what a good incident report should look like. But we weren’t the only ones writing them. Most reports came from engineers outside our team.

We sent out a survey to the entire org and asked:

• On a scale from 0–10, how confident and at ease do you feel writing incident reports?

• What makes writing an incident report frustrating?

• What would make them easier to write?

• What would make them more fun and enlightening to read?

Based on this feedback, we built a new version. We added clearer guidance and examples. We formed small reading group and invited volunteers from across the org.

Every Monday, at least ten of us would sit down and read incident reports together. Whenever someone struggled, we asked guiding questions to spark new insights. And, reached out to authors to help them bring the most out of their experience after an incident.

The goal wasn’t to produce a “perfect” document though. It was to make reflection easier, and to invite people into the process, so they could do what’s needed with more clarity and confidence.

Because when people feel like co-authors of change, they’re far more ready to embrace it.

You’re working with smart, capable engineers. Your job is to make it easy, and rewarding for them to do the right thing.

Veluwemeer Aqueduct in Netherlands -Googlemaps

2. Find What’s in the Way, and Remove It

Friction slows everyone down. And, our job is to smooth the path with whatever tools and context you have.

That doesn’t always mean solving the biggest, flashiest problems. Sometimes, it means noticing where people quietly get stuck and doing something about it.

One of my favorite early-career hackathon projects was about publishing blog posts.

At our company then, we wanted more engineers to share their achievements and interesting challenges on our tech blog. It was fully managed by us —the engineering teams. People liked writing but the issue was, we were too slow to review, support and publish them.

We used Hugo to generate our static site as GitHub pages. People open a PR with their article, but they had no easy way to preview their post outside their local environment. This made reviews hard and caused anxiety for authors who wanted fast, clear feedback.

So we built a staging environment for our tech blog.

Now, whenever someone pushed their article to GitHub on a branch, it automatically deployed to staging, generating a unique human-readable preview URL. They could easily share it with reviewers and confidently merge when ready.

This project involved Jenkins pipeline, containers running on Nomad. I learned a lot but most importantly, we made people feel confident to publish on their own.

It’s a small example, but I still remember the reward of seeing how happy people were when it launched. We published more, celebrated more, and proudly showcased our engineering culture externally.

Sometimes the biggest impact comes from the smallest friction you remove.

3. Enable Autonomy, and Make It Safe

All of us want autonomy. It makes us feel capable, and gives us that exhilarating sense of ownership. Naturally, you want to offer that through the work you build. You want to enable people move fast, experiment freely, and do what they need without relying on you.

But autonomy without safety isn’t freedom.

Once, our technical sales engineer accidentally deleted a Kubernetes namespace in production. Because we'd given people lots of flexibility to switch clusters and own their part of the stack.

Switching clusters happened rather implicitly through your terminal’s kubeconfig setup. Without proper RBAC and clear roles, someone could unintentionally run destructive commands in prod.

This person thought they were working in a sandbox, but they weren’t. Even worse, that namespace wasn't supposed to have anything critical but it did. That incident exposed multiple gaps: gaps in our safety measures, leftover migration projects, and unmet needs from users we hadn’t heard from.

The solution is never to scold people, introduce fancy terminals, or restrict experimentation. Those aren’t safety measures.

Instead, you tighten RBAC on namespaces, audit long-forgotten projects, and build in clear feedback loops when people take risky actions.

Autonomy should always come with clear, short-loop feedback and solid guardrails. Without these, you aren’t empowering people, you’re setting them up to fall.

A former colleague I loved working with dearly, Laura de Vesine, gave a talk recently at SREcon, “Dude, You Forgot the Feedback: How Your Open Loop Control Planes Are Causing Outages.”

It's insightful, entertaining, and highlights exactly how easy it is to overlook essential, simple safety measures. I highly recommend giving it a watch.

Closing Thoughts

This started as a post about SRE, but really, it’s about something broader: the mindset of building for others. That mindset gives you immense potential to make a real difference.

You’re not just helping people build reliable systems. You’re creating the conditions where they want to build reliable systems. Where they feel safe, capable, and proud to do the right thing even when no one’s demanding.

Use that power intentionally. Empower others. Remove friction. Co-create solutions. Keep safety central, not to slow people down, but to help them move faster with confidence.

Whether you're an engineer doing this work, or a leader shaping the environment around it, I hope this gave you something useful to carry into your own work.