Skin In The Game

Source: Dev.to

Why I Write This

A note to myself to stop explaining technology and start building with it. I’m a pretty lucky guy. Curiosity has put me in incredible situations throughout my life. I’ve learned languages, lived in interesting places, and about six years ago I decided I wanted to learn how the internet worked. That curiosity grew into a career in DevOps, cloud, and Kubernetes that I’m really proud of.

Today, as a DevRel, curiosity drives everything I do. The role changes a lot from company to company, and even week to week. One week I’m preparing a new use case for a blog post or conference talk; the next I’m collaborating with colleagues on webinars and content initiatives, or acting as a bridge between marketing, product, and customer success. It’s a job where curious people thrive, and that’s been my experience too.

The Gap Between Explanation and Building

There’s a downside, at least for me. My career didn’t include a long, distinct “developer phase.” I didn’t spend years building products from scratch, shipping them, breaking them, and living with the consequences. That’s not a prerequisite for a meaningful career in tech, but it is a gap I’ve become increasingly aware of.

As my curiosity about infrastructure, Kubernetes, and cloud‑native tooling deepened, so did my awareness of the limits of my perspective. I could explain systems, patterns, and trade‑offs, but I wasn’t always the one feeling them. I was close to the work, but not always inside it.

That gap becomes most obvious when I need a business case during a talk. When I explore a new Kubernetes architecture or an interesting developer tool, I fall back on the same safe demos—a todo list, a polling app, a habit tracker. They’re familiar, low‑risk, and easy to explain, but they’re also uninteresting and far too theoretical.

MetalBear and mirrord

I work for MetalBear, the company behind mirrord, a tool that fundamentally changes how developers work with Kubernetes. It lets a local process interact with real systems, real traffic, and real dependencies in a remote Kubernetes environment—without having to containerize or trigger CI/CD. Yet, too often I demonstrate it using those same tired stock applications. Adding dark mode to a simple polling app doesn’t do justice to a tool designed for complex, high‑stakes environments.

At times, this makes me feel less like a practitioner and more like a historical tour guide, passively explaining how things work, how others use them, and what could be built—without actively shaping what exists today. And honestly, who wants to be a historian of something that happened last week when you can help influence what happens next?

A Bias for Action

What I want now is simple: I want to be a DevRel with a bias for action. With the sheer volume of information, resources, and AI tools available today, the distance between an idea and a working project has never been smaller. Feedback loops are tighter, tooling is better, and the cost of trying and failing is lower than ever.

I want to stop talking about Kubernetes and cloud‑native tooling purely as a commentator and start engaging with them as someone who has skin in the game. Not just as a developer, but as someone responsible for identifying a real problem, articulating a solution, choosing the right tools, and seeing the entire process through from idea to delivery. I want to build projects that don’t just stand up in a conference talk, but stand up to real users, real constraints, and real trade‑offs.

Some of those projects will fail. Some will stall. Some might accidentally work. That’s fine. The point isn’t success; it’s participation, having actual skin in the game, and using the tools I talk about every day in pursuit of something useful to someone that could actually exist.

Building in Public

It won’t be easy to fully inhabit the skin of a developer or a product owner, and that’s exactly the point. I won’t just shoe‑horn a given tool or tech stack into a project because a conference calls for it. I’ll come at it from the maker perspective and determine the best way forward for any given project.

I don’t particularly care what label this puts on me—Developer, DevRel, DevOps engineer. None of that matters much. What matters is choosing to act, to build things that matter to someone, to put ideas into the world before they’re fully polished, and to learn by being exposed to reality rather than protected from it.

Building in public feels like the most honest way to do that. It raises the stakes, improves my capacity for real empathy, and forces clarity. If I want to understand developers better, the best way forward isn’t more explanations; it’s shared experience.

Call to Action

I plan to share this journey openly and regularly: what I’m building, what works, what doesn’t, and what I learn along the way. If this resonates with you, I’d genuinely love to hear from you. If you’re also feeling the pull toward doing more and talking less, tell me what you’re thinking about building. What are you trying to validate, and what kind of value are you hoping to put into the world?

Happy 2026 everyone!