AI and Cloud-Native Documentation Journey with Michael Uzukwu

Gowri: Good day, everyone, and welcome to the Knowledge Base Ninjas podcast. With me today is Michael Uzukwu, a technical writer and software documentation engineer. Hi, Michael — welcome to the podcast. How are you doing?

Michael: Hi, Gowri. I’m doing very well and I’m genuinely happy to be here. These are topics that are close to my heart and that I’m passionate about, so it’s a pleasure to talk with you and everyone listening. Thank you for having me.

Gowri: Thank you for spending your time with us. Seven-plus years in technical writing is no small thing, so I’d love to dig a little deeper into how this became your career — your background, your inspirations. Tell us a bit about yourself.

Michael: Sure. My path into technical writing wasn’t as linear as some people’s. A lot of folks have a clear vision and direction from the start, but I’ve always had wide-ranging interests, so I didn’t go straight into it.

When I finished college, I started out as a Python programmer. I learned the basics — syntax, data structures — and at the time there was a lot of excitement in Nigeria around data analytics and data science, so I got interested in that. I began using Python to solve small problems: retrieving data through web scraping, pulling data from APIs, and analyzing it with libraries like Pandas and NumPy.

But I found I wasn’t really enjoying the analytics work itself. What I was enjoying was writing about my projects — documenting what a project was about, the steps I took, the results, and the conclusions. Some of those write-ups are still on my GitHub. Looking back, the signs were there even earlier: in college I joined the press club, where we wrote editorials and covered what was happening around campus, and I eventually became chief editor of the press club at Skidville International High School. So the communication instinct was there before I even graduated.

The person who really opened my eyes was my elder brother, a DevOps engineer. He always knew I could write — he’d say I wrote better than he did — and one day he simply asked, “Why don’t you go into technical writing?” I asked what that even was, he explained, and I started.

I began with Google’s technical writing course, then moved into a structured mentorship program covering API technical writing and product documentation, where I learned about open-source documentation, docs-as-code workflows, and Git and GitHub. I even led a team of fellow learners on a project — it was a practice project, but our team placed third overall in the program. From there the interest kept building. Breaking down complex technical concepts and making them clear and actionable — that’s what I found I loved, and I’ve never looked back.

Gowri: What a great example of a career shifting direction naturally. I’m curious: which skills from data analytics helped you most in technical writing?

Michael: That’s a wonderful question, because people often don’t realize how transferable skills are between technical fields. Data analytics helped me a lot.

In analytics, I used libraries like Pandas, NumPy, and Matplotlib to structure messy data — cleaning it, organizing it, and shaping it so you can derive insight. That translates directly into technical writing. As a writer, you’re constantly interfacing with product managers and subject-matter experts, who own these projects and understand them deeply. You end up surrounded by information, and your job is to structure it clearly so users can understand and adopt it. That’s essentially information architecture — organizing and structuring knowledge into a logical flow.

You see that structure in most products today: after the hero page you’ll find an overview or introduction, a quick start, the core concepts, then tutorials and advanced topics. That’s information architecture at work.

The second skill is attention to detail. In data, one small mistake — the wrong value, the wrong formula — can throw off an entire analysis. The same is true in documentation: you have to test systems, confirm they actually work, and make sure everything is documented accurately. So structure and attention to detail are the two skills I carried over most.

Gowri: Everyone’s talking about AI right now, but before that — what makes a cloud-native documentation structure fundamentally different from other documentation, and how should users prepare for it?

Michael: Fundamentally, the biggest difference is the target audience. The purpose of documentation is always to help users understand and adopt a product. But with cloud-native documentation, your readers are typically SREs, platform engineers, and architects — people already inside the ecosystem who understand the fundamentals.

Because they already know concepts like Kubernetes, clusters, and pods, you write for them very differently than you would for a general developer. The language in cloud-native docs is more advanced and assumes that baseline.

The other big difference is how fast the tools change. Something like Kubernetes ships new releases very frequently, so in this space you have to keep learning and keep adding tools and skills constantly. That’s where I see the clearest distinction between cloud-native documentation and documentation for more conventional software products.

Gowri: How do you think AI will change open-source documentation?

Michael: This is one of the hottest topics in the field right now. I’d actually go further and say AI has already changed how documentation is designed, consumed, and used — not just how it will in the future.

For me as a technical writer, AI is a tool, not a replacement. A lot of writers fear it’s coming for their jobs, but I don’t see it that way. It’s here, and writers should embrace it — especially for repetitive tasks, first drafts, and spotting what isn’t working. The caveat is that AI hallucinates: it can present false information with complete confidence.

There’s also a bigger shift happening around retrieval-augmented generation — AI agents crawling documentation. This changes how docs should be designed. Increasingly, developers don’t just read documentation to learn and then implement; they prompt an AI, and the AI searches across many docs and pulls the relevant information back for them. If your documentation isn’t structured in a way that AI can parse and retrieve from, that information won’t surface in those results. So AI has genuinely changed how we structure content.

At the same time, AI can generate drafts, handle repetitive work, and flag incomplete documentation. But there’s an essential caveat: the human is still the chief validator. Because AI hallucinates, we — the engineers and documentation engineers — have to review and validate the output. Otherwise we risk shipping incorrect docs. So AI’s influence is significant and growing, but it doesn’t remove the human from the loop.

Gowri: Very detailed — thank you.

Gowri: My last question before the rapid-fire round: can you explain what an LFX mentorship is? I saw it on your profile and thought it was worth unpacking.

Michael: LFX stands for Linux Foundation. The LFX mentorship is a collaboration between the Linux Foundation and the Cloud Native Computing Foundation (CNCF). It gives contributors and maintainers the opportunity to work on real-world, sponsored documentation projects.

These are genuine projects, not exercises. The Linux Foundation and CNCF sponsor them and pay stipends to mentees. You apply much like any job application, go through a review, and if you’re selected you get to work on some really exciting work. I applied for the kgateway project and was selected to work on documentation improvements around OpenID Connect and JSON Web Token integrations — essentially the security documentation for kgateway.

It’s a great way to learn on real projects without the intense pressure that new writers and documentation engineers often face. It’s well structured, and the priority is genuinely learning. I’d been contributing to kgateway for a while, and I was fortunate to be selected this time around.

Gowri: That gives us a great perspective. Shall we move to the rapid-fire round?

Michael: Yes, happy to.

Gowri: Given how thoroughly you’ve answered, I’m sure you read a lot of documentation resources. Any you’d recommend to our audience?

Michael: A few. First, a platform called Write the Docs. I’m active in their Slack channel, and anyone can join. It’s a great place to learn about conferences, new tooling and directions in the field, upcoming events, and even job openings. Most valuably, people share technical-writing blogs, ideas, and new ways of communicating and working. It’s a strong community for both new and experienced writers.

Second, if you’re interested in cloud-native tooling, start with the Kubernetes documentation and its reference docs. Read through it to understand what Kubernetes is, how clusters work, and how to configure and deploy it. Most cloud-native tools — kgateway, Linkerd, Volcano — are built on Kubernetes, so you need to understand it before you can document those tools well.

Gowri: One word that comes to mind when you hear “documentation”?

Michael: Clarity. It’s so important in documentation.

Gowri: A piece of advice you’d give your 20-year-old self?

Michael: Don’t wait until you feel you have every skill in the world before you start. A lot of young people think they have to reach a certain level before they can make an impact. If you want to make an impact, just start and do something. And keep writing — even when your structure or language isn’t perfect. The act of writing builds the habit and the instinct for communication. Put your thoughts out there. People will correct you, and that’s fine. Staying back because you don’t feel ready is not the way to go.

Gowri: Very well said. Anything I missed that you’d like to share?

Michael: Just this: going into documentation — especially documentation engineering — is not a mistake. It can look simple, even ordinary, next to roles like software or DevOps engineering, but technical writers play a genuinely important role in a product’s success. If you have a passion for it but worry it lacks prestige, don’t. You can build a great career from technical writing — you just have to be good at what you do. It’s an excellent way to break into tech.

Gowri: Wonderful. I wish you all the best with your future projects and your work speaking at conferences.

Michael: Thank you — though one quick clarification. I’ve actually finished my contract with Armtech; that was short-term. I’m now the lead technical writer at Opsimate, an open-source startup that’s gradually coming up, and an LFX 2026 mentee for kgateway. Happy to send those details over for when you write about this.

Gowri: That’s great to know — thank you. I learned a lot from this conversation. All the best, and good luck.

Michael: Thank you for having me. I’d love to do this again sometime. Take care.