Ten years in Kubernetes: lessons on community, contribution, and staying relevant

Bart: So, first things first: who are you, what's your role, and where do you work?

Note: While this transcript snippet doesn't contain any specific technical terms that require hyperlinks based on the provided link table, I've reviewed it carefully and found no immediate candidates for linking.

Jorge: My name is Jorge Castro, and I am in developer relations at the Cloud Native Computing Foundation, based in Ann Arbor, Michigan.

Bart: And what's your story? How did you get involved with Kubernetes in the first place?

Jorge: Kubernetes was interesting. I was working at Canonical on the server team, and we were getting involved in Kubernetes. I went to one of the very first SIG cluster lifecycle meetings, where I met a bunch of people who I eventually became good friends with and co-workers.

Eventually, I connected with two of Kubernetes' co-creators, Craig McLuckie and Joe Beda, who were doing a startup called Heptio. They needed a community manager, so I thought it sounded awesome. I did that for a few years, was involved in Kubernetes for several releases, and worked on contributor experience.

I've been around for 10 years already, which I didn't realize. I've been involved all over cloud native - I worked on Cloud Custodian for a while, Kubeflow for a while. Right now, I'm doing a bit of everything. I'm on the projects team, and our job is to help projects stay healthy. We do whatever projects need.

This cycle, I'm focusing more on end users, AI conformance, and various other areas. Actually, my job title doesn't really make sense anymore. I have a new one, but I'm not sure what it is yet.

Bart: And you mentioned a couple of different things in terms of SIGs, contributor experience, something I was a part of as well. But this ecosystem moves very quickly. How do you stay up to date with all the changes that are happening?

Jorge: I mostly focus on the maintainers themselves. When I'm going to a meeting, I'll catch up on the last notes for the SIG. I'm using Notebook LM where I put the SIG's last few talks into AI and say, "Summarize the last five important things that Argo is going through," for example. I'm deferring a lot to AI tools, which is working out pretty well.

I mostly focus on the people. By the time we're talking about things, I don't really read the change logs for Kubernetes anymore. It becomes more of a macro perspective: how do we get AI, APIs, and conformance to become part of Kubernetes? It becomes more about the greater context as opposed to the little details. I hope that makes sense. I have no idea what's going on in Kubernetes.

Bart: You mentioned some of the people that you interacted with early on, like Craig McLuckie and Joe Beda. But who are some people in the Kubernetes community who have helped you level up over the years?

Jorge: That's a good question. I think the first ones, the initial group of people you hang out with in Kubernetes, if you're lucky, becomes a long-term relationship. Your roles in the projects evolve over time. Jeff, Bob, and I worked on Kubernetes, and Christoph Blecker, Josh Berkus, and Harris Pittman were there. We all cycled out but stayed in cloud native. Now three of us are on the projects team. One was on the governing board. Christoph, I think, is the chair of the governing board now.

It's very interesting when, in the early days of your career, you were doing things like managing GitHub permissions for the project. A few years later, you're discussing macro things like funding the maintainer summit for everybody. That's very exciting because we get to stick around. Seeing new people come in doing our old jobs is great because they're not exactly the same jobs we had. They're usually more efficient and have way more energy.

A lot of things are done differently these days, with more focus on sustainability and keeping the long-term vision going. In the early days, we were just growing so fast, trying to keep the ship together. Over the course of the year, I've started to get to know people who were chairs of SIG contributor experience. Mario and I hang out, and I ask, "What's that job like?" It's a little different for him. At the same time, we're working on AI conformance—something we would have never done before we hadn't even gotten Kubernetes conformance out the door.

It's becoming an evolution, and it's honestly really challenging for me because I have to stay relevant and remain useful to the community. I'm always trying to find an angle or something new. By the time you've been around so long, it's about introductions and personal relationships. I'll find an expert who knows how to do something and connect people. That's how we keep the ball rolling around here.

Bart: I think there's a lot to be said for that in the sense that while we are talking about things that are very technical, there's something that's equally or if not more human about all this. In terms of meeting the right people and being connected, for people that might be newcomers in the ecosystem, what are things they can keep in mind to have the best experience possible and really get plugged in? This will help them pay it forward, help others grow, and of course, help themselves.

Jorge: I feel like in 2025 it's all about meat and potatoes these days. Sometimes I go into a problem wanting to make a fancy thing and write a bunch of stuff. But the previous hour, I was looking at things I wrote five years ago, and it was just a long, convoluted thing. I'm very much in efficiency mode lately—focusing on the least amount of things we can do to get people moving.

Sometimes you want and feel like you need consensus so badly that you'll sit on something for too long. Our team is finding that sometimes it's better to not ask for permissions: just go for it, and you'll get consensus as you're doing it. Instead of design, stop, get approval, just go. It's like, "Look, I've heard anybody. If it fails, let's just go for it." It might be a little rough, but then tweak and iterate.

We're focusing on putting more irons in the fire to be ready. Some will be ready quickly, some will take a long time. Some you'll realize will take a year to get data on. But you have to keep an eye on it; you can't just table it.

The trick becomes making sure you're writing things down, especially when it's production-ready. The other thing is don't focus on the tech as much as the process and the people you're working with. It's more about how the team executes than how we solve the problem. Obviously, you always want to solve the problem, but also consider: if I had this team and had to solve five more problems, would the second one be way easier than the first?

Bart: A question that we're asking everybody in this series is, "What is Kubernetes"? There are many different answers out there, depending on who we ask. And there are many right answers. But if someone asks you, "What is Kubernetes for you?"

Jorge: I'm not going to say it's just five components. The way I explain it is distributed computing. I've tried to explain this to my family many times, and most people who don't work in tech don't understand it. The important thing to remember is that it's distributed computing, and that has to do with people.

I'm obviously the people guy, but it's about how we scale to solve problems. On the software side, that's Kubernetes. On the community side, it's also Kubernetes. We like to empower people and don't prefer hierarchical, top-down structures. We're spread out, and I like to think we're like the Borg.

When I look at other open-source projects, Kubernetes is different. We are very flat compared to others. To outside observers, it might look chaotic. If you go to the maintainer summit, you don't really know who's in charge unless you're at the first session. But during day-to-day operations, there are people in charge of certain parts, yet they're all generally marching in the same direction.

I like to think we're more like an ant colony than a pack of wolves with a rigid structure.

Bart: I'm kind of the ecosystem nerd, so I tend to use animal. It works for me. Thinking about that, if someone is new and arrives at the CNCF, you've helped a lot of these people get onboarded. What are the biggest challenges that newcomers face in shaping their path?

Jorge: Imposter syndrome is real. I also have no idea what I'm doing. Many people still feel intimidated. I feel intimidated when I go to the summit and hear people talking—I have no idea what they mean, even if they're using the same words.

Don't sweat that. We have to organize meetings, whether you understand the technology or not. Running a well-organized meeting is a skill. Sometimes I go to a Kubernetes meeting that's very technical but disorganized—that's where someone with project management skills might excel.

By the time you get here, someone saw something in you. Maybe you brought energy to a local meetup, or someone recognized your potential. You're there for a reason, even if you don't know exactly where you'll fit. At first, you might feel like a weirdo, but then you realize the entire project is just a bunch of people who aren't sure where they belong.

People eventually align where they can contribute. You might help with a release for a bit, realize scheduling isn't your thing, and instead focus on organizing your local meetup. You can bring back information and share knowledge—like knowing which GitHub page to watch or which Slack channels to join.

The vibe between projects differs. At work, you might be asked to adopt new tech as the "cloud native person." Learn where to look: check their Slack channels, readme files, and YouTube channels. The CNCF YouTube has every talk from the past 10 years.

Sometimes, it's about knowing who to ask and how to ask. Even senior engineers sometimes need help finding resources. My job is often just teaching people where to look.

Consider finding a mentor or joining a shadow program. I shadowed the release team for a long time. Sometimes, just listening to meetings can help you become better at your job. Look for positions with lower deliverable pressure where you can observe and learn the subtle things no one talks about.

Many people in these projects do quiet, necessary work without grandiose titles. Some people's goal is simply to help someone on Slack once a day. There's plenty of work to do if you're creative.

Bart: Not at all. This is very helpful and leads to the next question. In terms of the things you mentioned that people do behind the scenes and different ways people get plugged in depending on their skillset, can you share a success story of someone who built confidence in a role through steady contributions?

Jorge: Other than me? I think of many people who might end up on the chain. Kaslin Fields is probably one of the classic examples. When she started, she was a Kubernetes ambassador doing small things. Eventually, she got more involved in Kubernetes. When my generation cycled out, her generation came in, and she became a sig lead.

While I was off doing things, I would walk by the Kubernetes contributor summit and see they were doing similar things we did before—maybe with different outfits and themes. I would check in and find they would build on previous work, trying to get more shadows involved so they eventually become contributors.

The other day, I saw her on a keynote for Google Cloud in front of millions of people, and I thought, "I remember when we started." But you have to remember there are many people who chose not to continue or might have cycled out of cloud native.

Sometimes I've had really good friends I thought would be in cloud native forever, and then they leave—or might come back. I left for a while and returned. I focus on whether they carry the community with them when they leave. Do they think fondly of us when they've moved on in their career?

We should recognize that many people in our community will move on. The number of people who stick around for a decade is small compared to those who attend just one event. Maybe they helped in a tiny way, like moving coffee tables when there weren't enough staff. I told someone, "If it wasn't for you, we would have had to delay by 15 minutes." There's a cascading effect most people don't consider.

Many get wrapped up thinking, "I'm not Kelsey, so I must not be helping." But even small things matter—like helping someone find a session at KubeCon Cloud NativeCon when the map is complicated. It's about creating a culture of helping, where every little thing contributes to the community's vibe.

I went to a KCD in Hungary this year, and it felt just like KubeCon—same culture, even though I'd never been to a KubeCon there. When I went to KubeCon in Hong Kong, it was different, but still had a common thread.

The key is: don't go in thinking everyone knows everything except you. That mindset defeats you, and it's really hard to overcome.

Bart: And nobody wants that. That's not what the ecosystem is about at all.

Jorge: If we go and you're struggling with an external factor, I can help you. But if you're going into the situation, I don't even think I'm supposed to be here. Then it's tough to give you guidance. I'll give you a pep talk. We'll do it. That's why there's more than one of us.

Bart: It's an ecosystem that can be very intense. That's why starting out with shadow programs or mentoring can be a way to ease into it. What habits or mindsets help avoid burnout while staying active in such a fast-moving ecosystem?

Jorge: The pressure is on. Let's assume this is my first KubeCon. I want to chill out at the Project Pavilion and learn, but I also have deliverables my boss wants. It's all around open source. All of us sitting there being friendly and trying to help are also under pressure to deliver. That's the consequence of running everything.

We have to take the project seriously. We must move forward, ensure technical debt is addressed, and make the project sustainable. But we can't have maintainers crashing and burning. We have to support each other in a way that's conducive to learning.

We don't want a high-stress environment because we're already in a high-stress tech world. I like to think of this as a productive bubble where you can relax. Certain senior people always put my mind in the right place. Tim Hockin never panics. Tim St. Clair never panics. They're even-keeled but passionate, showing that tackling hard problems quickly leads to a longer, happier path.

I like to prototype and discuss potential issues. I often ask in meetings, "Is somebody going to suffer in nine months because of this decision?" We must also help new people, especially those experiencing their first KubeCon and learning how to run a booth.

I observe how others manage booths to learn their approach. The first day can drain your energy for the entire week if you're not planning carefully. I try to manage audience energy, bounce ideas off coworkers, and take care of myself: take breaks, drink water, wear comfortable shoes.

I recommend getting to know the people at neighboring booths. We're all going through similar experiences. I've maintained relationships with "booth people" I've met at conferences. Connecting with others helps take the stress off and helps everyone find their groove.

Bart: That's tough. For newcomers, whether it's with booths or just getting into the Kubernetes ecosystem in general, if you could give them one North Star question to guide their Kubernetes journey, what would it be?

Jorge: Keep going. Follow the crowd, though it seems counterintuitive. I would say set goals of where you want to be. When going to a conference, especially if it's your first one, enjoy the experience. Get the most out of it and understand why people are having such a good time.

Try to set specific goals for yourself. For example, aim to meet at least three people in leadership positions or attend three talks about topics you're interested in. Consider what's important for your work and what value you can bring back to your organization.

If your work paid for you to attend, start building a professional network. This web will be valuable to both you and your employer. Disseminate the information you learn to your co-workers to demonstrate your value. For instance, share insights like booth conversations about project roadmaps or reference architectures from end-user sections.

Take advantage of resources and learn from successful companies. Find organizations similar to yours in size or stage of development. Understand their lifecycle and challenges. This can help you anticipate and prepare for future technological shifts.

You might focus on a specific technology like Kubernetes one year, and then explore the ecosystem around it the next. The key is to have a plan. Don't just wander around aimlessly—you could spend an entire week learning nothing without a strategic approach.

Bart: Taking the time to set a couple of objectives and make sure you're focused on them will help you have something meaningful to take away when the event is over.

Jorge: What you don't want to do is go home with homework. If this is your job, you want to go home having learned about three important things. This gives you something to do between KubeCons. When you go into your next KubeCon, you'll know exactly what you're looking for or at least understand that the things you looked at the first time were not what you wanted. That's way better than going into it blind. That's my recommendation.