The Real Reason I Ran the Kubernetes Seminar Was Selfish

A technology only you know can't go to production — how I spread a new technology to my team as a junior engineer

Let me say this up front: that seminar wasn’t held for the team.

I was around three years in. The company was starting to move to a Kubernetes-based deployment environment. Kubernetes is the default now, but back then most servers ran on physical machines. Adding a single machine took ages. And the feature I’d just been handed was the exact opposite of that model. It was an event-style feature, quiet most of the time, with traffic surging all at once for a moment. We couldn’t keep machines sitting around for those few minutes, so it had to scale out, adding servers only when needed. The reason we needed Kubernetes was clear.

The team’s mood was half worry, half anticipation. Nobody said it out loud, but I could feel the look that said “you think you can pull this off?”

It became a technology only I knew on the team

The problem was that it was early days. Documentation was thin, and there were practically no references in-house. There was a separate infrastructure org leading the Kubernetes rollout, but they weren’t people I could lean over and ask. When an error hit, I changed settings one at a time and learned by feel what was wrong. I worked a lot of overtime. For things I absolutely couldn’t crack, I compiled the error logs, sent them over, and got coached.

After rolling around like that for a good while, I found myself in a strange situation. I was the only person on the team who knew this technology.

A technology only you know can’t go to production

To be honest, the decision to run a seminar wasn’t for the team.

The more I used Kubernetes, the more certain I became. This technology was going to become the mainstream, no question. I was still junior, I had an anxiety about not knowing new technologies, and I wanted to become a better developer on this team.

But a technology only you know can’t be used in production. No matter how well I handled it, I couldn’t put a technology into a service that no one else on the team could operate. If only I know it, it’s a side project. Only once the whole team can use it does it truly become my technology.

So I ran the seminar. Even thinking about it now, it wasn’t something I did for the team.

Making them follow along

The seminar gathered a dozen or so team members and ran over several sessions.

I didn’t want a seminar where people just listened and left. So instead of explaining concepts with slides, I actually brought up the tools together and had them follow exactly what I was doing. The things I’d learned through trial and error I wrote up as documents and handed over with it. Concepts come up in a search anyway. What the team needed was the experience of deploying in our environment with their own hands.

Making it run without me

As time passed, the environment changed and material to reinforce piled up. So this time I reorganized the content together with the team members and ran a second seminar. I shrank my share, and team members led the more important parts.

For the first seminar, the urgent thing was eliminating the state of “a technology only I know.” By the time I was preparing the second, my ambition had changed. Now I wanted it to keep rolling even if I stepped away.

So what changed

By the time I left the team, Kubernetes had become the default for deployment. Only a handful of physical machines remained, and the team members who’d given me that “you think you can pull this off?” look were each deploying on their own.

This experience led to a good performance review too. And there was something that lasted longer than that. Even after changing jobs, this experience carried over as an asset. The technology itself can be learned anywhere, but the experience of landing a new technology in a team was rare.

If there’s a technology only you know

If you’re holding a technology right now that only you know on your team, try setting up a seminar first. You don’t need a grand justification. I started from the selfish wish to get to use that technology myself.