From Shadow to Release Docs Lead: My Journey with Kubernetes v1.35
When Kubernetes released version 1.35, it wasn’t just another version bump for me.
It was personal.
I started contributing to Kubernetes from version 1.33. Back then, I was learning the ropes — understanding how one of the world’s largest open-source ecosystems operates under the umbrella of the Cloud Native Computing Foundation.
Fast forward to v1.35, and I had the incredible opportunity to lead the Release Documentation Team.
- Exciting? Absolutely.
- Overwhelming? Without a doubt.
Stepping Into Leadership (With Equal Parts Excitement & Fear)
Kubernetes is not just a project. It’s a global collaboration of thousands of contributors across time zones, cultures, and expertise domains.
When I got the opportunity to lead the Release Docs Team, I was thrilled. But I was also asking myself:
- Am I ready for this responsibility?
- Can I do justice to the role?
- Will I be able to support the team effectively?
Leadership in open source is different. You don’t “manage” people. You earn trust, enable collaboration, and create clarity.
And this was my first time leading a team in such a massive ecosystem.
Leading Shadows: A Learning Experience
As Release Docs Lead for v1.35, I had five shadows working alongside me.
For those unfamiliar, shadows are contributors who assist the lead while learning the release process hands-on. It’s a beautiful system — mentorship built directly into execution.
But onboarding them was one of the biggest challenges.
When people from different parts of the world come together:
- They have different communication styles
- Different technical strengths
- Different comfort levels in open discussions
- And often, they’ve never met before
So my first priority wasn’t documentation.
It was people.
Building Team Comfort Before Building Documentation
Before diving deep into tasks, I scheduled calls to:
- ✅ Introduce everyone properly
- ✅ Help people share their backgrounds and strengths
- ✅ Create a safe space for questions
Because I strongly believe:
A team performs best when people feel safe to speak.
If contributors are comfortable:
- They raise blockers early
- They suggest improvements
- They challenge ideas constructively
That psychological safety changed everything.
Structuring the Chaos: The Responsibility Sheet
Kubernetes releases are not linear. There are:
- 🟢 Light periods
- 🔴 Extremely heavy and hectic windows
- 🔄 Tight coordination with multiple SIGs and feature owners
To avoid confusion, I introduced something simple but powerful:
A Clear Responsibility Sheet
Once everyone was onboarded and comfortable, I created a detailed responsibility tracker that included:
| Element | Purpose |
|---|---|
| Ownership assignments | Everyone knows who is doing it |
| Timelines | Everyone knows when it’s due |
| Dependencies | Everyone knows what blocks what |
| Voluntary ownership | Everyone chose their responsibilities |
The result?
- ✅ Clear accountability
- ✅ No task ambiguity
- ✅ Smooth coordination
- ✅ Fewer last-minute surprises
This single structured step made our release cycle significantly more efficient.
Encouraging Open Blockers (No Matter How Small)
One important lesson I learned:
There’s no such thing as a “small” blocker.
I always encouraged the team to drop their blockers in the group chat — no hesitation.
Because when someone shares a problem publicly:
- The whole team learns
- Someone else might already have a solution
- Collective intelligence kicks in
It strengthened team morale and improved transparency.
Open-source thrives on openness — even in struggles.
Being Open to Ideas
Another key takeaway:
When you lead, you don’t need to have all the answers.
Each shadow brought unique perspectives:
- Different domain experiences
- Different tooling approaches
- Different thought processes
Instead of sticking to “how things were done before,” I kept myself open to new ideas.
And some of our smoothest workflows came from shadow suggestions.
Leadership isn’t about control. It’s about creating space for contribution.
What v1.35 Taught Me
Leading the Kubernetes v1.35 Release Docs Team taught me:
- Structure reduces stress — Clear plans prevent panic
- Early clarity prevents late chaos — Set expectations upfront
- Psychological safety boosts productivity — People do their best work when they feel safe
- Open blockers improve collaboration — Transparency builds trust
- Leadership is about service, not authority — Enable, don’t control
Most importantly, I learned that I am capable of more responsibility than I initially believed.
The hesitation I felt at the beginning? It transformed into confidence — not because everything was perfect, but because the team moved together.
What’s Next?
My journey with Kubernetes doesn’t stop here.
From contributor in v1.33 to Release Docs Lead in v1.35, the growth has been exponential — both technically and personally.
And this is just the beginning.
Open source doesn’t just build software. It builds people.
If you’re thinking about contributing to Kubernetes or any open-source project — just start. The community is welcoming, the learning is immense, and the growth is real.