<div id="readability-page-1" class="page"><div>*This is the English version of <a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/technical-writing-1">a previously published article</a>.Hi, I’m Juyeon Han, Technical Writing Chapter Lead at Toss. In this series, I’ll share how Technical Writers (TWs) at Toss have expanded our role from simply writing documentation to designing the systems that manage knowledge across the organization.<hr>“Why is this built this way?”It’s the kind of question you hear, and ask, all the time at work. Maybe you track down the person who wrote the code and try to piece together what they remember. Maybe you dig through a year-old thread for context. And sometimes, there’s simply no one left to ask.As we rely more on AI, this problem becomes even harder to ignore. AI may know a lot about the world, but it doesn’t know the context and history unique to your organization. So every time you ask it to do something, you have to fill in the gaps.People often say that code is the Single Source of Truth (SSoT). But code only preserves the outcome. It can tell you what something does, but not necessarily why it was built that way or what decisions led to it. Most of us have probably stared at uncommented code at some point, trying to figure out how we got there.That’s why I believe documentation matters as much as ever. A true SSoT is only complete when you have both the code and the context surrounding it.Ultimately, we’re the ones who have to explain why the code is the way it is. If we want AI to work with what we know, we first have to capture that knowledge somewhere. And that’s the gap the Technical Writing Chapter has been working to fill.But our job isn’t simply to write documents that fill in the missing context. Looking at what TWs do today, the role has changed significantly since I first joined Toss five years ago.<figure id="3d4a360d-33e3-802f-bbd5-cc753f5faa47"><img src="https://static.toss.im/ipd-tcs/toss_core/live/98adff3e-bbbb-4fe1-bd41-ccb59601b295/image.png" alt=""></figure>Our goals have changed, too. This year, we’re working toward a system where knowledge builds up on its own. And the ultimate goal of the Technical Writing Chapter is to make ourselves unnecessary.When I first thought about how AI might change our work, I assumed Technical Writers would be among the first to be replaced. But I couldn’t have been more wrong. If anything, our work has expanded. So how did we get from writing technical docs to designing knowledge systems, with the ultimate goal of making ourselves unnecessary?<h2 id="3d4a360d-33e3-8062-98fc-f81ec048f295">From Writing Documents to Bringing Knowledge to People</h2>When I first started working on internal documentation at Toss, one of my first projects was creating onboarding documents for our Frontend Chapter. But as I worked on internal docs, something kept bothering me. To me, the goal of Technical Writing isn’t to produce great writing. It’s to help readers solve problems and accomplish what they need to do. And no matter how good a document is, people rarely read it from beginning to end. They look for the one thing they need. I do the same. So I started thinking: instead of writing a document and sending people a link, how could we make sure the knowledge inside it actually gets used?That question led to <a target="_blank" rel="noreferrer noopener" href="https://toss.tech/article/toss-frontend-ai-docs">Mr. Park (박씨)</a>, a chatbot we built. (*Refer to <a target="_blank" rel="noreferrer noopener" href="https://www.youtube.com/watch?v=zlXsomDPQ_U">TMC25</a>) It lets people ask questions conversationally from the messaging tools and IDEs they already use, then answers based on our existing documentation, with sources included.Instead of asking people to go find the documentation, we brought the documentation to them.<figure id="3d4a360d-33e3-80c1-a42a-d9e75236d619"><img src="https://static.toss.im/ipd-tcs/toss_core/live/9a776a33-f3eb-46b4-8b32-ba5fb55f2e5f/dark2_usefunnel_en.png" alt=""></figure>What happened next was interesting.People who had never been particularly interested in writing (or reading) documentation started coming to us.“We want something like this for our chapter.” “Could we build this for our organization too?”As Toss grew, people were getting tired of getting the same questions over and over. They wanted a way to retrieve institutional and tacit knowledge from a system.At the same time, rapid advances in AI were making documentation more important than ever. If we wanted AI to understand our work and actually be useful, we first had to give it the knowledge and context to work with.Documentation had long been treated as a chore. Suddenly, everyone wanted it.It was fascinating to watch. And amid that shift, I started building a knowledge system that everyone at Toss could use. I’ll cover that product in more detail in the next article.<figure id="3d4a360d-33e3-80f9-845a-ee37f8989781"><img src="https://static.toss.im/ipd-tcs/toss_core/live/be009018-121e-45d4-ab5d-0c4ef8d27b73/image.png" alt=""></figure><h2 id="3d4a360d-33e3-8037-8684-d37c2ff81fb2">From Documentation to Knowledge Systems</h2>That was when we began to push beyond the traditional boundaries of Technical Writing. We realized our role could no longer stop at documentation. We needed to become people who design knowledge systems tailored to the needs of different organizations. And as AI takes on more and more work, capturing the knowledge and tacit context scattered across the organization has become more important than ever.A well-designed knowledge system makes the entire organization more productive while helping every team member get up to speed quickly. As organizations grow, questions multiply and communication becomes increasingly costly. A strong knowledge system is critical for maintaining both the speed and quality of how we work.Today, the work of the Technical Writing Chapter at Toss falls into four main areas.First, we build products. We lead the team that builds and operates todoc, our internal knowledge management platform.Second, we embed ourselves in different organizations and lead their documentation efforts. We bring together scattered knowledge in ways tailored to each organization and make that knowledge as useful as possible. There’s no one-size-fits-all knowledge system, so we adapt our approach to each organization.Third, we eliminate the manual Technical Writing work. Through AI workflows and automation, we’re building ways for anyone to create and review documentation at a consistently high level.<figure id="3d4a360d-33e3-803e-a6ec-fa6c491dea87"><video muted="" loop="" autoplay="" playsinline=""><source src="https://static.toss.im/ipd-tcs/toss_core/live/510d08e2-56f1-4e35-8a19-1a7aa1243564/%E1%84%92%E1%85%AA%E1%84%86%E1%85%A7%E1%86%AB_%E1%84%80%E1%85%B5%E1%84%85%E1%85%A9%E1%86%A8_2026-02-04_%E1%84%8B%E1%85%A9%E1%84%8C%E1%85%A5%E1%86%AB_11.36.39_(1)_(1).mp4"></video></figure><figure id="3d4a360d-33e3-807a-ae7e-fcb6644c3d90"><img src="https://static.toss.im/ipd-tcs/toss_core/live/d26b7311-8ee8-439e-8114-1460e44418c9/image.png" alt=""></figure>Finally, we build a culture of documentation across Toss. We run community-wide sessions on topics such as how to write documentation that AI can understand effectively. We also run documentation guilds and knowledge committees within individual organizations, changing how knowledge is captured and managed throughout Toss.What We’ll Cover in This SeriesHere’s what we’ll explore in the rest of the series:Our job title is still “Technical Writer.” But the work we actually do today is much closer to designing an organization’s knowledge infrastructure. We didn’t set out to redefine the role. We simply followed the problems that needed solving, and ended up redrawing the boundaries of the job along the way. Before we knew it, we had created a role that didn’t quite exist anywhere else in the industry.And this shift isn’t unique to Technical Writing. AI is redefining the work of every profession. In such an environment, anyone can expand the boundaries of their role. Our chapter started with one person. Now there are three of us, and we’re looking for more people to join us. Over the course of this series, we’ll share how we got here, one story at a time.</div></div>

토스테크

*This is the English version of a previously published article.
Hi, I’m Juyeon Han, Technical Writing Chapter Lead at Toss. In this series, I’ll share how Technical Writers (TWs) at Toss have expanded our role from simply writing documentation to designing the systems that manage knowledge across the organization.
“Why is this built this way?”
It’s the kind of question you hear, and ask, all the time at work. Maybe you track down the person who wrote the code and try to piece together what they remember. Maybe you dig through a year-old thread for context. And sometimes, there’s simply no one left to ask.
As we rely more on AI, this problem becomes even harder to ignore. AI may know a lot about the world, but it doesn’t know the context and history unique to your organization. So every time you ask it to do something, you have to fill in the gaps.
People often say that code is the Single Source of Truth (SSoT). But code only preserves the outcome. It can tell you what something does, but not necessarily why it was built that way or what decisions led to it. Most of us have probably stared at uncommented code at some point, trying to figure out how we got there.
That’s why I believe documentation matters as much as ever. A true SSoT is only complete when you have both the code and the context surrounding it.
Ultimately, we’re the ones who have to explain why the code is the way it is. If we want AI to work with what we know, we first have to capture that knowledge somewhere. And that’s the gap the Technical Writing Chapter has been working to fill.
But our job isn’t simply to write documents that fill in the missing context. Looking at what TWs do today, the role has changed significantly since I first joined Toss five years ago.
Our goals have changed, too. This year, we’re working toward a system where knowledge builds up on its own. And the ultimate goal of the Technical Writing Chapter is to make ourselves unnecessary.
When I first thought about how AI might change our work, I assumed Technical Writers would be among the first to be replaced. But I couldn’t have been more wrong. If anything, our work has expanded. So how did we get from writing technical docs to designing knowledge systems, with the ultimate goal of making ourselves unnecessary?
From Writing Documents to Bringing Knowledge to People
When I first started working on internal documentation at Toss, one of my first projects was creating onboarding documents for our Frontend Chapter. But as I worked on internal docs, something kept bothering me. To me, the goal of Technical Writing isn’t to produce great writing. It’s to help readers solve problems and accomplish what they need to do. And no matter how good a document is, people rarely read it from beginning to end. They look for the one thing they need. I do the same. So I started thinking: instead of writing a document and sending people a link, how could we make sure the knowledge inside it actually gets used?
That question led to Mr. Park (박씨), a chatbot we built. (*Refer to TMC25) It lets people ask questions conversationally from the messaging tools and IDEs they already use, then answers based on our existing documentation, with sources included.
Instead of asking people to go find the documentation, we brought the documentation to them.
What happened next was interesting.
People who had never been particularly interested in writing (or reading) documentation started coming to us.
“We want something like this for our chapter.” “Could we build this for our organization too?”
As Toss grew, people were getting tired of getting the same questions over and over. They wanted a way to retrieve institutional and tacit knowledge from a system.
At the same time, rapid advances in AI were making documentation more important than ever. If we wanted AI to understand our work and actually be useful, we first had to give it the knowledge and context to work with.
Documentation had long been treated as a chore. Suddenly, everyone wanted it.
It was fascinating to watch. And amid that shift, I started building a knowledge system that everyone at Toss could use. I’ll cover that product in more detail in the next article.
From Documentation to Knowledge Systems
That was when we began to push beyond the traditional boundaries of Technical Writing. We realized our role could no longer stop at documentation. We needed to become people who design knowledge systems tailored to the needs of different organizations. And as AI takes on more and more work, capturing the knowledge and tacit context scattered across the organization has become more important than ever.
A well-designed knowledge system makes the entire organization more productive while helping every team member get up to speed quickly. As organizations grow, questions multiply and communication becomes increasingly costly. A strong knowledge system is critical for maintaining both the speed and quality of how we work.
Knowledge is verified information that helps an individual or organization understand a problem or situation, make better decisions, and take action. Information only becomes knowledge when it has been validated within that context.
A knowledge system is the structure that brings that knowledge together and delivers it to the people, and AI, that need it, when they need it. Knowledge scattered across code, conversations, deployments, and other sources is brought together into a Single Source of Truth. It’s then structured so that it can be understood not only by people but also by AI, and immediately put to use through questions, workflows, and automation.
Today, the work of the Technical Writing Chapter at Toss falls into four main areas.
First, we build products. We lead the team that builds and operates todoc, our internal knowledge management platform.
Second, we embed ourselves in different organizations and lead their documentation efforts. We bring together scattered knowledge in ways tailored to each organization and make that knowledge as useful as possible. There’s no one-size-fits-all knowledge system, so we adapt our approach to each organization.
Third, we eliminate the manual Technical Writing work. Through AI workflows and automation, we’re building ways for anyone to create and review documentation at a consistently high level.
Finally, we build a culture of documentation across Toss. We run community-wide sessions on topics such as how to write documentation that AI can understand effectively. We also run documentation guilds and knowledge committees within individual organizations, changing how knowledge is captured and managed throughout Toss.
What We’ll Cover in This Series
Here’s what we’ll explore in the rest of the series:
Beyond Our Expertise: How our expertise in Technical Writing found its way into todoc, the knowledge product we built.
Why Documentation Never Seems to Stick / Same Problem, Different Solutions (Korean version only): In two interviews, we’ll share how we approached a problem nearly every company faces: knowledge that never seems to accumulate, and what we learned along the way.
Technical Writers, Planning Our Own Disappearance (Korean version only): Can Technical Writing be automated? We’ll share what we’ve built so far.
Becoming Knowledge Experts (Korean version only): Explore our ultimate goal of enabling organizations to create and manage knowledge on their own, without Technical Writers.
Our job title is still “Technical Writer.” But the work we actually do today is much closer to designing an organization’s knowledge infrastructure. We didn’t set out to redefine the role. We simply followed the problems that needed solving, and ended up redrawing the boundaries of the job along the way. Before we knew it, we had created a role that didn’t quite exist anywhere else in the industry.
And this shift isn’t unique to Technical Writing. AI is redefining the work of every profession. In such an environment, anyone can expand the boundaries of their role. Our chapter started with one person. Now there are three of us, and we’re looking for more people to join us. Over the course of this series, we’ll share how we got here, one story at a time.

1. Creating a Role That Didn’t Exist Before

댓글