Olasupo Funke is a technical writer and documentation specialist whose path into developer communication was shaped by hands-on engineering and deep community involvement. With a foundation in backend engineering, her early experiences teaching peers and leading student engineering groups revealed a critical insight: technology only scales when it is clearly understood. That realization redirected her focus from writing code alone to building clarity, context, and usability into how developers interact with products.
From documenting real-world backend problems on platforms like Dev.to and Hashnode to contributing to open-source initiatives through Google Season of Docs, Funke has consistently approached documentation as a product in its own right. Her work spans API and OpenAPI documentation, developer onboarding, and structured, machine-readable knowledge systems, all anchored in real workflows rather than theoretical completeness. At RocketChat, she expanded this approach by pairing written documentation with concise, targeted video guides and restructuring content to reduce friction, improve adoption, and lower support demand—while also preparing documentation to serve as a reliable source for AI-driven tools.
In this exclusive conversation, Funke unpacks how documentation has evolved from a supporting asset into core infrastructure, why modern developer experience must account for both human and AI consumers, and how clear, empathetic documentation can determine whether a product is adopted, trusted, or abandoned.
Describe your professional journey into technical writing and documentation, and the key experiences that shaped your approach to developer communication.
My path into technical writing grew naturally from my background as a backend engineer and my involvement in developer communities. While studying Computer Science, I helped lead a student engineering group where I both learned and taught core web technologies. Teaching peers made one thing clear early on: understanding a concept isn’t enough. What matters is explaining it in a way that is clear, contextual, and immediately useful. That experience fundamentally shaped how I approach developer communication today.
As a junior backend engineer, I found myself repeatedly explaining backend concepts, tooling decisions, and implementation details to teammates and community members. To reduce repetition and improve clarity, I began documenting real problems I was solving through technical articles on platforms like Dev.to and Hashnode. This led to my first paid technical writing role with Honeybadger and later opportunities through guest author programs and independent blogging. In 2022, I was selected for Google Season of Docs with Open Food Facts, where I worked on OpenAPI documentation and gained a deeper appreciation for documentation as a product that requires research, iteration, and alignment with real developer workflows. I later joined Rocket.Chat as a full-time Technical Writer, applying my engineering background to create documentation.
At Rocket.Chat, I became more intentional about reducing friction in how developers and users consume information about our products. Modern developers are not impatient by choice but they need fast, focused answers. Recognising this, I complemented written documentation with short, targeted videos designed to answer one specific question at a time. This approach led to strong adoption, positive feedback, and fewer support tickets. Alongside this, I’ve worked on making documentation more structured and machine-readable, acknowledging that LLMs are increasingly the first consumers of docs. Across text, visuals, and interactive tools, my approach is consistent: prioritise usefulness over completeness, clarity over volume, and empathy over assumptions.
Identify a defining project or moment in your career that changed how you think about documentation and developer experience.
A defining shift in my career occurred when I realized that developers were increasingly using LLMs, like ChatGPT, as their primary entry point for technical questions about our product. This led me to advocate for Generative Engine Optimization (GEO) in our documentation. I recognized that if our content wasn’t structured as a clean data source for machines, these tools would provide developers with hallucinations or outdated information. My role evolved from simply writing for humans to architecting information that serves both the developer and the AI tools they rely on. The experience redefined my view of developer experience: it no longer starts and ends on the documentation site. It now includes how accurately your product is represented in AI-generated answers and ensures that the information developers receive is reliable, actionable, and friction-free.
Explain why documentation should be treated as core infrastructure in technology products rather than a supporting asset.
Oh, I’d love to answer that! It’s been a long-standing debate. Documentation should be treated as core infrastructure because it directly enables how a product is understood, adopted, integrated, and scaled. I strongly believe documentation should be a required checkpoint in the product release pipeline. When docs are accurate and current, they reduce support load, speed up onboarding for users and internal teams, and enable faster incident response. Treated this way, documentation becomes an automated support system that continues to deliver value long after a feature ships. Furthermore, it also captures product intent. It explains not just how a system works, but why it works the way it does. When treated as infrastructure, docs evolve alongside the product and remain trustworthy over time. When treated as an afterthought, they quickly drift out of sync with real developer needs.
Based on your experience in open-source projects, outline the role documentation plays in driving adoption, contribution, and long-term sustainability.
In open source, documentation is the primary driver of adoption because it may be the only “onboarding team” a user ever meets. If developers can’t achieve the simplest win within minutes, they will move on to an alternative. By providing clear setup instructions and use cases, docs reduce the friction and build the confidence a user needs to choose your tool.
To move beyond just users and into a thriving community, documentation must also lower the barrier to contribution. Many developers hesitate to contribute due to imposter syndrome or the complexity of a new codebase. Well-maintained contribution guides, architectural overviews, and good first issue templates serve as a roadmap that transforms passive users into active collaborators.
Ultimately, documentation ensures a project’s long-term sustainability by preventing burnout and decentralizing knowledge. When institutional knowledge lives only in the heads of a few core maintainers, it creates a single point of failure. By building a robust knowledge base and documenting design decisions, we automate the support layer and free maintainers to focus on innovation. In this way, documentation becomes a shared responsibility that allows a project to outlast its original creators and continue to grow healthily.
Discuss how AI technologies such as RAG are changing how documentation is created, accessed, and maintained.
Traditionally, technical writers spent months drafting comprehensive manuals. With RAG, the focus has evolved to include structuring data for machine consumption. Writers now focus more on how information is chunked (broken into bite-sized, logical pieces) so that an AI retriever can find it easily. Just as we once optimised for Google Search, we now optimise content for AI retrieval by ensuring high semantic clarity and clear metadata.
RAG has also effectively outrun the “static search bar.” Users no longer have to guess the right keywords for search bars, but they can ask documentation questions in plain language. This is the power of conversational search. RAG doesn’t just return a list of links but also retrieves the 3 or 4 most relevant snippets from across the docs and synthesises a custom answer for the user. If a developer is working in Python, the RAG-enabled docs can automatically prioritise Python code snippets and context in their responses.
Highlight the key risks of deploying AI in documentation workflows without a clear strategy or understanding of user needs.
The biggest risk of deploying AI without a strategy is the illusion of completeness, where a system generates volumes of text that look professional but are subtly incorrect or outdated. When an AI isn’t properly grounded in a live, accurate data source, it defaults to hallucinations or obsolete patterns. For a developer, there is nothing more frustrating than following an AI-generated code snippet only to find it doesn’t work. Once that trust is broken, the documentation stops being a helpful resource and becomes a liability that increases the load on your support team. Furthermore, when AI is used to generate or summarise documentation without grounding it in actual user needs, the output often prioritises surface-level explanations over actionable guidance. This results in documentation that looks complete but fails to help developers solve real problems, increasing frustration and support load rather than reducing it.
Define the core components of strong developer experience (DX) and explain where documentation fits within that ecosystem.
Developer experience is about how a developer feels while building a product, and strong DX is the result of an ecosystem designed to reduce friction at every stage. At its core are predictable APIs and abstractions that follow familiar conventions, clear onboarding paths that shorten time to first win, and fast feedback loops through meaningful error messages and logs. Support and community also play a role by reinforcing best practices and providing confidence that help is available when edge cases arise.
Documentation is the central hub that gives this entire ecosystem meaning. It gives context to APIs, explains the intent behind design decisions, and connects onboarding, errors, and support into a coherent experience. Good documentation acts as the first layer of support, scaling the team by helping developers solve problems independently. Every time a developer finds an answer in the docs, you’ve solved a problem without a support ticket or a meeting. Ultimately, high-quality documentation is what transforms a collection of technical features into a trustworthy product that developers will actually enjoy using.
Explain how you design documentation that serves both technical and non-technical users within the same product.
I design documentation as separate but connected experiences because technical and non-technical users approach the same product with very different goals. Developer documentation focuses on APIs, SDKs, and integrations, with practical guides that let engineers interact with the product logic quickly, often through live or sandboxed examples. Non-technical documentation, on the other hand, is outcome-driven. It explains how features work through the UI, why they exist, and the impact they have, so stakeholders can also make informed decisions without needing to understand the underlying implementation. What connects both experiences is a shared source of truth and a strong emphasis on clarity. I use visuals only when they meaningfully reduce ambiguity, such as flow diagrams or annotated screenshots. , and I never document what I haven’t personally tested.
Finally, the most dangerous thing in documentation is an untested instruction. I believe you cannot effectively teach what you haven’t personally experienced. Before I document a feature, I build with it. I run the code, trigger the errors, and go through the onboarding flow myself. This way, I can personally experience what I’m explaining whether it’s navigating the UI, or walking through a feature end-to-end.
Assess the role of templates in technical documentation and when structure helps versus when it limits clarity or usability.
I approach documentation templates as scaffolding, not a mold. They are powerful when used intentionally, and damaging when treated as rigid rules. This tension is exactly what I explored in my talk on templates becoming either a tool or a trap during OSCAFEST 2025 based on the work I’ve been doing, contributing to documentation templates at the GoodDocsProject.
When used effectively, templates are a powerful tool for scaling consistency and reducing decision fatigue for writers. By creating predictable reading patterns, they help developers scan for information quickly and ensure that institutional knowledge (like edge cases and assumptions) isn’t forgotten as teams change. In multi-author or open-source environments, a good template often sets a clear standard that lowers the barrier for new contributors.
However, templates become a liability when they prioritize filling space over adding value. When every section is mandatory, writers often include repetitive or fluff content just to satisfy the structure, which forces the reader to work harder to find the signal in the noise. Furthermore, when templates are too rigid, they can oversimplify complex systems and hide important details. My philosophy is that templates must remain flexible enough to serve the reader’s comprehension, and when the process becomes more important than the message, the template has become a trap.
Identify the most effective ways organisations can measure the impact of documentation on product adoption and user success.
To measure documentation’s impact, organisations should prioritise time-to-success over traditional metrics like time-on-page. A successful doc helps a user complete their task faster, rather than leaving them stuck on a page for minutes. We can validate this by treating support data as a feedback loop. As documentation improves, the volume of how-to tickets should drop, shifting support conversations away from basic setup and toward advanced edge cases. This shift proves that the documentation is successfully handling the heavy lifting of user education.
We should also look at how well our content aligns with actual user intent through search patterns and AI accuracy. Repeated searches, zero-result queries, or quick exits highlight where documentation structure or language doesn’t match how users think. In an AI-first environment, organisations should also measure how accurately LLMs surface answers from their documentation. When AI tools can reliably guide users through real workflows using your docs, it’s a strong signal that the product is easier to adopt and succeed with.
Analyse the current state of documentation and technical writing within the African tech ecosystem, including challenges and opportunities.
The African tech ecosystem is at a strategic inflexion point where documentation is moving from a post-launch luxury to a competitive necessity. While the continent has seen an explosion in venture capital and engineering talent, many startups still struggle with knowledge silos and high technical debt. They default to asking developers to write their own docs, often resulting in content that is technically accurate but inaccessible to the average user.
In a crowded fintech landscape, Product A and Product B might have identical features, but the one with the superior Developer Experience (DX) will win the market. By investing in documentation early, African startups can lower developers’ switching costs. When your API is the easiest to integrate, you become the default choice for the next generation of African builders.
Describe how community involvement and open-source advocacy influence your work as a technical writer.
Community involvement has shaped how I think about documentation as a form of teaching at scale. Organising study jams, bootcamps, and structured learning programs trained me to break complex ideas into clear, learnable steps and anticipate where people struggle. I treat documentation as asynchronous mentorship, designed to guide someone forward even when I’m not there to explain it. As a result, I write with empathy for first-time readers, prioritising clarity and context over assumptions or unnecessary complexity.
Open-source advocacy has also pushed me to write with contribution in mind, not just consumption. I constantly evaluate whether my documentation makes it easy for someone new to understand the system, spot gaps, and contribute without fear. Working in open communities has made me deeply aware of differences in skill levels and resource constraints, which reinforces my commitment to plain language and inclusive design. For me, good documentation isn’t about demonstrating expertise but reducing friction and making the path to success as clear and accessible as possible for whoever comes next.
Explain practical ways non-engineers can contribute meaningfully to open-source projects.
Starting with technical writers, we can make a huge impact in open source through documentation and knowledge translation. If you’re a new contributor, you’re well-positioned to spot missing steps, unclear assumptions, or jargon-heavy explanations that experienced contributors may overlook. Improving READMEs, setup guides, FAQs, translations, or writing user guides that communicate a project’s value can significantly improve adoption, retention, and long-term sustainability.
Open-source projects also rely heavily on community engagements, QAs, designers, marketers, and project managers. Non-engineers can support this by moderating forums, organising meetups or co-work sessions, improving design and usability, or advocating for the project within their networks. Testing features from a user’s perspective, filing clear bug reports, triaging issues, or helping with release coordination and roadmap tracking are all meaningful contributions that keep projects healthy and moving forward, even without touching the code.
Provide actionable advice for individuals looking to build a career in technical writing today.
If you already have technical knowledge in areas like engineering, cloud, data, or design, the fastest way is to start writing about what you know and explaining it clearly for others. If you don’t yet have a technical background, pick a technical skill and learn the basics.
Then, document your learning journey as you go. Publish consistently on platforms like Medium, Hashnode, or Dev.to, and actively seek feedback from engineers and experienced writers. Iteration matters more than perfection, and early feedback will sharpen both your technical understanding and your communication skills.
As you grow, focus on building depth and credibility. Learn from strong resources like the Google Technical Writing Course. You can also contribute to open-source documentation through READMEs, onboarding guides, blog posts, or explanation guides. Over time, specialise by developing skills in API documentation, docs-as-code workflows, and tooling automation.
Describe how you maintain creativity, focus, and clarity outside of professional work.
I attend events that align with my current learning goals, which helps me stay curious, exposed to new ideas, and grounded in what’s happening beyond my immediate work. I also make time to meet with colleagues and peers. These conversations often spark fresh perspectives, challenge my thinking, and restore motivation in ways solitary work can’t.
Finally, I stay involved in community work as much as I can. Organising major conferences, managing communities, leading programs and events, and speaking at events. Seeing the impact of changed lives and careers is incredibly fulfilling and provides a sense of purpose that refuels my clarity and drive.
Share your perspective on how the role of technical writers will evolve over the next five years.
Over the next five years, the role of the technical writer will evolve from drafting manuals alone to engineering-grounded knowledge. We will spend less time writing from scratch and more time mastering concepts like GEO and RAG to ensure that AI agents provide accurate, context-aware answers. Accuracy, structure, and consistency will matter more than volume because unclear documentation will amplify errors faster in AI-driven environments.
At the same time, the role will expand beyond text. Technical writers will curate multi-modal experiences that combine concise writing, visual guidance, interactive examples, and conversational interfaces into a single learning journey. As the lines between product and documentation continue to blur, writers will work closely with product teams to deliver just-in-time help directly in the UI. As a result, technical writers will increasingly own documentation infrastructure, treating docs as a system to be designed, automated, and maintained, not just content to be written.
Thank you for talking to us
It’s a pleasure sharing my perspective on your platform
