Chisom Uma is a documentation engineer and technical writer whose work sits at the intersection of storytelling, developer experience, and product adoption. With roots in frontend development and a long-standing background in creative writing, Chisom brings narrative clarity to technical documentation—treating docs not as static text, but as a guided journey designed around real developer intent.
Across roles at companies like GBG, he has shown how well-structured, outcome-driven documentation can drive measurable impact, scaling daily active users from 2,000 to 10,000 by prioritising usability, audience segmentation, and time-to-value. Passionate about strengthening technical communication across Africa’s tech ecosystem, Chisom advocates for documentation as a competitive advantage, a growth lever, and a core part of product engineering—not an afterthought.
In this exclusive conversation, Chisom Uma unpacks his journey from frontend development and creative writing into documentation engineering, revealing how storytelling, audience empathy, and product thinking can transform documentation into a powerful driver of adoption and growth. He shares hard-won lessons from scaling developer engagement, explains why documentation must be treated as core infrastructure, and offers a compelling vision for how African technical writers can stay globally competitive in an AI-first world.
You started out as a frontend developer before moving into technical writing. What moment made you realise writing could be more than a side skill?
Initially, I had been a writer before getting into frontend development. I wrote songs, poems, blog posts, and even books. Shortly after I started front-end development, building web applications, I learnt about an opportunity that required me to write about front-end development topics and get paid. That was the moment I realised writing is more than a side skill. Now, I could do the thing I love most, “writing,” while still being at the forefront of technology, building web apps. Only this time, I get to teach about what I am building or learning through writing.
How did your early blogging and storytelling background shape the way you approach documentation today?
My early blogging and storytelling background taught me that technical content doesn’t have to be dry or robotic. When I write songs, poems, or blog posts, I’m always thinking about the reader’s journey, how to keep them engaged, how to make complex ideas relatable, and how to create a narrative that flows naturally.
I bring that same mindset to technical documentation. I’ve learned that good documentation is really just good storytelling. You need to understand your audience, anticipate their questions, and guide them from point A to point B in a way that feels intuitive. My storytelling experience also taught me the power of examples and real-world scenarios, just like a good story needs vivid scenes, good documentation needs concrete examples that developers can connect with.
Was there any resistance—internally or externally—when you transitioned from engineering into documentation-focused roles?
There wasn’t any particular resistance; my transition was pretty smooth because I had clear guidance from my brother, who had already started on this path.
At GBG, you scaled the documentation daily active users from 2,000 to 10,000. What was the biggest insight that unlocked that growth?
The biggest insight was realising that developers don’t just need documentation, they need the right documentation at the right moment in their journey.
When I analysed our analytics and user feedback, I discovered that most developers were landing on our docs with specific problems to solve, but they were getting lost in dense, reference-heavy content. They needed quick wins and clear paths forward, not encyclopedic information dumps.
So we restructured everything around user intent. We created distinct content types: quick-start guides for developers who wanted to get running in minutes, step-by-step tutorials for common use cases, and then deeper reference material for those who needed it. We also improved our search functionality and information architecture so developers could find answers faster.
But the real game-changer was making the documentation interactive and outcome-focused. We added code snippets that developers could copy and run immediately, included troubleshooting sections based on actual support tickets, and built feedback loops directly into the docs so we could continuously improve based on what users were struggling with.
The growth from 2,000 to 10,000 daily active users wasn’t just about having more content; it was about having more useful content that met developers where they were and helped them succeed quickly.
Many companies still see documentation as a cost center. How did you make the case for docs as a revenue and adoption driver?
I made the case by connecting documentation directly to metrics that leadership actually cares about: customer acquisition, retention, and support costs.
First, I tracked the correlation between documentation usage and product adoption. We found that developers who engaged with our docs in their first week were 3x more likely to complete integration and become active users.
Second, I worked with our support team to quantify how good documentation reduced support tickets. We tagged incoming tickets by topic and compared them against our documentation coverage. When we improved docs for high-ticket areas, we saw support volume drop by 30-40% in those categories. That translated directly to cost savings and freed up our support engineers to focus on more complex issues.
Third, I demonstrated that documentation was actually a growth lever. Good docs lower the barrier to entry for developers evaluating our product. In developer tools, especially, documentation quality often determines whether someone chooses your solution or a competitor’s. We started tracking “docs-assisted conversions” trials that started after significant documentation engagement, and the numbers were compelling.
I also showed leadership examples from companies like Stripe and Twilio, where exceptional documentation became a competitive advantage and a key driver of their developer ecosystems.
Can you walk us through how audience segmentation (developers vs business users) changed user behaviour?
The audience segmentation was a turning point because we realised we were trying to serve two completely different personas with the same content, and we were failing both.
Developers would land on our docs looking for API endpoints, code examples, and technical specifications, but they’d have to wade through business-focused content about use cases and ROI. Meanwhile, business users trying to understand what our product could do for them were getting overwhelmed by technical jargon and implementation details. Our bounce rates were high, and time-on-page was low for both groups.
To solve this, I created two distinct documentation paths from the landing homepage. A path for developers, which included technical documentation with API references, integration guides, code samples, and troubleshooting, and a different path for business users, which included product guides, use case documentation, feature overviews, and workflow explanations in plain language.
After implementing segmentation, engagement skyrocketed, developers spent 60% more time on technical docs without having to filter through irrelevant business content, and business users finally started reading the user guides designed for them.
How do you define “documentation engineering” for people who still think docs are just text files?
Documentation engineering is the art of building documentation websites from scratch and creating custom UI components using code. It also involves managing the end-to-end lifecycle of documentation, from planning to writing to publishing, and building custom components that help improve developer experience.
It involves treating documentation as a product that requires the same engineering rigor as any other software. This means creating interactive elements, automation, and tooling that make information more accessible and useful for developers, rather than just maintaining static text files.
What mistakes do SaaS startups commonly make when structuring their documentation?
The biggest mistake is treating documentation as an afterthought rather than a core product feature. Startups often dump everything into a single section without clear information architecture, making it impossible for users to distinguish between getting started guides, API references, and advanced tutorials. They write for themselves using internal terminology instead of thinking about the user’s journey, and they skip fundamental topics like authentication and basic setup while focusing on advanced features.
Another common problem is the lack of maintenance and feedback loops. Documentation gets written once at launch and then neglected as the product evolves, leading to outdated content that erodes trust. Many startups also try to serve developers, business users, and administrators with one-size-fits-all documentation, which ends up serving no one well. The solution is to structure docs around user needs from day one, segment content by audience, and establish processes for continuous updates based on user feedback.
How closely should documentation teams work with product and engineering, in your view?
Documentation teams should be embedded directly in the product development cycle, not working as a separate function that gets looped in at the end. In my experience, the best documentation comes from being in sprint planning meetings, reviewing PRs, and understanding why features are being built, not just what they do.
When you’re involved early, you can influence product decisions from a usability perspective, catch confusing workflows before they ship, and have documentation ready on launch day instead of scrambling weeks later.
You’re vocal about improving technical communication in Africa’s tech ecosystem. Where do you think we’re getting it wrong today?
I think the biggest issue is that we’re undervaluing technical communication as a core skill and treating it as something anyone can do on the side. In Africa’s tech ecosystem, you’ll find brilliant engineers building incredible products, but the documentation, if it exists at all, is often an afterthought, poorly structured, or inaccessible to the very developers who need it most.
We’re also not investing in building technical writing talent locally. Many African startups and tech companies either don’t have dedicated technical writers or outsource documentation to people who don’t understand the local context, use cases, or challenges our developers face. This creates a gap where products are powerful but underutilised because people can’t figure out how to use them effectively.
Another problem is that we’re not creating enough learning resources and career pathways for technical writers in Africa. Unlike software engineering, where there are bootcamps, communities, and clear career progression, technical writing remains an ambiguous field that people stumble into rather than deliberately pursue. We need more visibility, more training programs, and more advocacy for technical communication as a legitimate and valuable career path.
Finally, I think we need to shift the narrative from “documentation is a cost” to “documentation is a competitive advantage.” The startups and companies that will win in Africa’s growing tech ecosystem will be those that make their products accessible and easy to use through excellent documentation. If we want African tech to scale globally, we need to communicate as well as we code.
How important is open-source contribution to building a strong documentation culture on the continent?
Open-source contribution is absolutely important to building a strong documentation culture in Africa. It’s one of the most accessible ways for aspiring technical writers to gain real-world experience, build their portfolios, and learn from global best practices all without needing formal employment or expensive training.
When African developers and writers contribute to open-source documentation, they’re not just helping projects; they’re developing skills that translate directly to professional work. They learn how to write for diverse audiences, work with version control, collaborate with global teams, and understand what good documentation looks like. These are exactly the skills our ecosystem needs more of.
Open-source also democratizes learning. Someone in Lagos or Nairobi can contribute to the same projects as someone in San Francisco, get feedback from experienced maintainers, and build credibility that opens doors to opportunities. I’ve seen people land documentation roles simply because they had strong open-source contributions that demonstrated their ability.
Beyond individual growth, open-source contributions help normalise documentation as essential work. When African developers see documentation treated with the same importance as code in open-source projects, it shifts mindsets about its importance. We need more African voices in these spaces, not just consuming open-source tools, but actively improving and documenting them. That’s how we build a culture where great documentation becomes the standard, not the exception.
What does the next generation of African technical writers need to focus on to stay globally competitive?
The next generation needs to become documentation engineers, not just writers. That means combining strong writing skills with technical abilities, for example, learning to code, understanding APIs, working with developer tools, and building interactive documentation experiences. The market is moving beyond static text files, and writers who can build, deploy, and maintain documentation systems will have a massive advantage.
They also need to embrace AI as a tool, not a threat. AI can handle basic documentation tasks, which means human writers need to focus on what AI can’t do well: understanding user context, creating narrative structure, designing information architecture, and building documentation strategies. The writers who thrive will be those who use AI to accelerate their work while focusing their energy on high-value, strategic contributions.
Finally, they need to build in public and contribute to global communities. Write blog posts, contribute to open-source projects, share knowledge on social media, and engage with the global technical writing community. The beauty of documentation work is that it’s often remote-friendly, which means African writers can compete for opportunities anywhere in the world.
But that requires visibility, showing your work, demonstrating your expertise, and building a reputation that transcends geography. The technical writers who do this consistently will not only stay competitive; they’ll help put Africa on the map as a hub for world-class technical communication talent.
What’s the best piece of feedback you’ve ever received about your work?
The best feedback came from a developer who told me, “Your docs just saved me three hours of frustration.” It sounds simple, but that comment crystallised everything for me.
Thank you for sharing your thoughts on documentation with us
Thank you for having me
