Skin In The Game

A note to self 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. It’s a role that changes a lot from company to company, and in my experience it even changes 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.

There’s a downside though, or at least there has been one 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 an example of a business case during a talk for example. When I explore a new Kubernetes architecture or a genuinely interesting developer tool, I find myself falling 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.

I work for MetalBear, the company behind mirrord, a tool that fundamentally changes how developers work with Kubernetes. It lets your local process interact with real systems, real traffic, real dependencies in a remote kubernetes environment, without having to containerize or trigger CI/CD. And 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 tools designed for complex, high stakes environments.

At times, it’s made me feel less like a practitioner and more like a historical tour guide, passively explaining how things work, how others use them, 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?

What I want now is simple, I want to be a DevRel with a bias for action.

If for no other reason than timing, this feels like the moment to do it. 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 it’s ever been.

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, deal with 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, it’s having actual skin in the game. It’s using the tools I talk about every day in pursuit of something useful to someone that actually could exist.

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 shoehorn 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, improve my capacity for real empathy, and it’ll force clarity. If I want to understand developers better, the best way forward isn’t more explanations, it’s shared experience.

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!