Funke Olasupo's unexpected journey from aspiring backend engineer to a technical writer highlights the crucial role of documentation in technology.
Funke Olasupo did not set out to become a technical writer. While at Ondo State University of Science and Technology, where she studied computer science, she was on the familiar path of many young technical talents in Nigeria, already active in developer communities and building toward becoming a backend engineer. Somewhere in that process, she discovered writing, a skill that came most naturally to her. Instead of building systems, she enjoyed explaining them better. This discovery did not happen in theory. It happened in practice when Olasupo started teaching in the same developer community where she had once been a learner; she realised writing was a more effective way to help people learn. “I realised that it can be hard explaining something multiple times, so I started writing our processes.” What began as a simple learning aid gradually grew into a career, leading her into technical writing roles at companies like Twilio and Rocket.Chat, where her work has shaped how users understand products, solve problems, and move from confusion to confidence. From Twilio to Rocket.Chat, she isn’t just impressed by the big names she has worked with, but by the impact her contribution has had on the communities she has helped build. Her work has shaped how people interact with technology. Recognised by the quality of her work, she shared, “Recently, I was on a call with a senior colleague who mentioned a technical author from Canonical pointed out my work on Rocket.Chat as a standout example of great API documentation he has seen.” However, becoming a great technical writer does not come easy, especially in the AI age. Olasupo’s journey is one shaped by intense growth, the kind that requires speed and focus. Her story matters because technical writing is often misunderstood as a soft extension of engineering work, when in reality it sits much closer to product infrastructure. Good documentation is one of the clearest expressions of whether a company actually understands its own product well enough to make it usable. It affects onboarding, support volume, activation, adoption, and the long-term trust users place in a platform. In developer tools companies, especially, documentation is often the product before the product. Victoria Fakiya – Senior Writer Techpoint Digest Stop struggling to find your tech career path Discover in-demand tech skills and build a standout portfolio in this FREE 5-day email course Google’s own technical writing training opens with a blunt 50%: “Every engineer is also a writer,” a reminder that documentation is not peripheral to technical work but central to how technical work scales. Writing is only 30% of the Job If Olasupo were to define it, she would likely describe it as the process of understanding complex systems deeply enough to guide others through them clearly, combining research, hands-on testing, and structured communication tailored to a specific audience. But when she breaks down what the job actually involves, it becomes clear that technical writing is more about learning and understanding than writing itself. As she puts it, “the truth is, writing is only 30% of the job.” The remaining 70% is a rigorous process of understanding how something works, sometimes as well as, or even better than, the person who built it. This is what she describes as knowledge gathering. She notes that much of her recent work has involved documenting cloud infrastructure, an area she initially knew nothing about and had to first master before she could explain it well. “In the last few years, I have documented a lot of things around cloud infrastructure, which I had zero idea about, so I had to learn first.” That detail is worth dwelling on because it reveals something essential about serious technical writing; it is less about wording than comprehension. After learning comes rigorous testing. She uses the product like the target user, which means understanding who that user is and anticipating every possible use case. The best technical writers do not merely simplify complexity; they interrogate it. They look for the points where understanding breaks down. They design a reader journey, not just a document. “You don’t want to give people a half-baked journey. The idea is that you put yourself in the reader’s journey.” This entire process is then documented in a way that is not only clear to users but also optimised for search engines and AI tools. Documentation is not complete because a page exists. It is complete when the user can move through the product with less friction because that page exists. Interestingly, technical writing is never truly finished. Product updates and iterations mean documentat...
