techlist.io
KREN

knowledge-management

6 posts

toss

6. Beyond Tools: Standards and Responsibility (opens in new tab)

Toss’s commerce domain found that reliable organizational knowledge cannot be created by writing more documents or adding automation alone. Sustainable knowledge management requires clear standards for what should be documented, who owns it, how it is maintained, and which sources can be trusted. The proposed solution combines AI-assisted documentation with domain-level responsibility and company-wide governance. ## The Limits of Writing Alone - A commerce wiki consolidated terminology, onboarding material, code references, and policy documents. - This reduced confusion over terms such as “seller” and “store” and gave teams a shared starting point. - However, product and policy changes happened faster than one Technical Writer could document them. - Important knowledge also appeared in policy changes, temporary experiments, and chat discussions that were difficult to track manually. ## Why Culture and Participation Were Not Enough - The team promoted documentation through: - A weekly “Commerce Wiki News” newsletter - A policy-question channel and bot - AI documentation workshops - A documentation guild - These efforts increased requests, wiki usage, and adoption of official terminology. - Participation rarely continued beyond an individual’s first document because documentation was not part of normal work priorities. - Writers lacked guidance on: - What information to preserve - How much detail to include - Which audience to target - How to verify whether a document was correct - Documentation became sustainable only when it was treated as a team responsibility embedded in existing workflows. ## AI Automation Reveals the Governance Problem - AI now creates draft documents nightly from two signals: - Product deployment and policy-change announcements - Questions that the commerce Q&A bot cannot answer - AI gathers supporting context and produces drafts, while humans verify the evidence and approve them. - This removes the burden of starting documents from a blank page. - Automation also exposed new problems: - Duplicate or overlapping documents - Unclear authoritative sources - Outdated policies being used in bot answers - Difficulty distinguishing current policies from completed experiments - Automation can collect and draft information, but it cannot decide who owns a policy or whether a document should still be trusted. ## Knowledge Standards and Governance - The focus shifted from “How do we create more documents?” to “How do we create knowledge people can trust?” - Toss’s knowledge-management standards state that teams should: - Preserve recurring questions, important decisions, and information needed by newcomers. - Organize knowledge so both people and AI can find it. - Connect documents to work tools such as Q&A bots and GitHub. - Assign owners and review cycles to keep information accurate and current. - Possible classification systems include: - **Technical layers** for teams with clear data or system flows - **Service domains** for teams responsible for multiple service areas - **Functional units** for systems with distinct feature boundaries - Information becomes organizational knowledge only when it helps people understand situations and make better decisions, with sufficient context and verification. ## The Role of the Knowledge Committee - The Knowledge Committee defines and maintains company-wide documentation standards and resolves conflicts between organizational rules. - Unlike a voluntary guild, it has designated members with decision-making authority. - Governance operates at two levels: - The Technical Writing Chapter manages shared standards for sources, ownership, document status, and lifecycle. - Individual domains decide how those standards apply locally, including ownership, update schedules, and retirement rules. - This balance prevents both inconsistent practices across teams and overly centralized rules that ignore local realities. - For example, commerce teams may need separate handling for permanent deployments and temporary experiments so expired policies do not remain authoritative. The practical recommendation is to treat knowledge management as an operating system for the organization, not a documentation project. AI can reduce the effort of capturing knowledge, but clear ownership, review processes, lifecycle rules, and governance are necessary to keep that knowledge reliable and useful.

knowledge-managementaiautomationtechnical-writing+3
toss

Why Does Our Team’s Documentation Fail? (2) (opens in new tab)

Documentation succeeds not through individual resolve, but through centralized knowledge, clear purpose, and systems that reduce the fear of being wrong. Interviews across a commerce domain and a server-development chapter show that documentation strategies must match an organization’s existing maturity, audience, and work patterns. AI lowers the cost of writing and sharing knowledge, while also requiring more deliberate document organization. ## Lessons from Early Attempts - The commerce wiki was initially designed as a self-service platform supported by workshops and guilds. - Workshops could encourage a first contribution, but sustaining second, third, and later contributions was difficult. - In the Ads domain, documentation was already strong, so the better approach was to respect existing conventions and help people locate knowledge rather than create another system. - Organizations with little documentation need to build foundational knowledge; organizations with mature documentation need better discovery and maintenance. ## Reducing the Fear of Asking and Writing - Developers often avoid asking questions because doing so publicly reveals what they do not know. - They may also hesitate to publish documentation because they fear their knowledge could be inaccurate. - The team addresses this through: - **“Lee’s Development Consultation Week,”** which normalizes questions and encourages teammates to answer questions Lee cannot address. - **A daily knowledge bot, “Ha,”** which shares short server-development tips automatically. - Correcting or adding to an existing shared post feels easier than writing a complete document from scratch. ## How AI Has Changed Documentation - AI makes it faster to create initial drafts and distribute knowledge through chatbots. - It also enables measurement of knowledge flow, including: - The number of questions asked. - Whether teammates provide answers. - The quality and content of those answers. - The number of new documents and week-over-week growth. - These metrics reveal knowledge gaps and recurring questions without manually reviewing every channel. - AI also creates a need for more detailed internal context than human readers typically require. - Commerce therefore separates: - Central, human-friendly documentation managed by technical writers. - Team-repository documentation containing detailed, team-specific context useful to AI but unnecessary for everyone else. ## Shared Principles and Organizational Differences - Both domains and chapters should centralize knowledge and avoid spreading it across too many channels. - Domains typically: - Connect documentation to products and code. - Change rapidly. - Serve a broad and varied audience. - Chapters typically: - Document conventions, working methods, and professional knowledge. - Change more slowly. - Focus on productivity and capability development. - Have a clearer audience, such as a specific role or discipline. - Domain documentation should be understandable even to non-developers, since developers may also lack context outside their specialties. - Separating guides, capability-based policies, glossaries, and metrics helps different readers find documents suited to their needs. ## Where to Begin - First diagnose the organization’s current documentation maturity by asking what people do when they get stuck: - **Ask coworkers or search chat:** foundational documentation is largely missing. - **Search documents:** assess whether information is easy to find; fill gaps if searches fail. - **Ask an AI or bot:** evaluate whether answers are accurate and whether the underlying documents are complete, current, centralized, and sufficiently contextualized. - Define the specific problem driving documentation, rather than starting with a vague goal. - Begin with a focused need, such as creating a glossary for inconsistent terminology or building references for sharing knowledge with other teams. The practical recommendation is to centralize knowledge, identify the organization’s biggest documentation gap, and build a low-friction system where people can contribute, correct, and consume information without relying solely on personal effort.

knowledge-managementaichatbottechnical-writing+3
toss

Why Does Our Team’s Documentation Fail? (1) (opens in new tab)

Documentation often fails not because people lack motivation, but because it depends on individual initiative and lacks clear standards. Interviews with a commerce domain and a server chapter showed that teams struggle to know what to document, how much detail to include, and whether their knowledge is accurate. Both organizations found that consolidating scattered knowledge into a shared system is the essential first step. ## Documentation in Domains and Chapters - **Domains** bring together developers, product owners, and designers around a business area such as commerce or advertising. - Their documentation focuses on product-related knowledge, including policies, terminology, and specifications. - **Chapters** group people with the same profession, such as server or frontend engineers. - Their documentation focuses on shared technical knowledge, conventions, and tools. - Dongjin works on consolidating internal knowledge across commerce and advertising domains, while Hyebin develops the company-wide documentation system “Todoc” and runs a documentation guild in the server chapter. ## Different Starting Points - The commerce domain already had strong awareness of documentation needs. - Members specifically requested terminology guides, policy documentation, experiment records, and API references. - Although writing standards were not clearly defined, people understood which documents would help their daily work. - The server chapter was initially more hesitant. - Members had worked without documentation and had not experienced its benefits directly. - An AI chatbot gave poor answers because its source documents were incomplete or disorganized. - Improving the underlying documents gradually made the chatbot more useful, helping members recognize the value of shared knowledge. ## Interviews Revealed the Real Obstacles - Dongjin interviewed developers to identify knowledge gaps and determine what information should be recorded. - The interviews clarified the organization’s needs, even though solving those needs required additional work. - Hyebin initially reviewed onboarding documents very thoroughly and repeatedly reminded people to complete them. - Interviews showed that contributors generally appreciated external review because it improved document quality. - The main problem was not a lack of motivation, but uncertainty: - What knowledge should be included? - How much detail is appropriate? - Is the information accurate enough to share? - These findings shifted the focus from persuading people to write toward making documentation easier and safer to produce. ## Problems Caused by Missing Documentation - In a domain, scattered policies create collaboration bottlenecks. - A team modifying a feature may first have to search for the policy owned by another team. - Newcomers struggle to understand what they do not know, creating prolonged “unknown unknowns.” - In a technical chapter, engineers often need to reconstruct the history behind unusual code. - They search old chat threads, try multiple keywords, or contact the original author. - More time may be spent assessing context and risk than implementing the change itself. - Useful knowledge often remains private. - Engineers may assume everyone already knows it or worry that it is too trivial to share. - As a result, people repeatedly solve the same problems independently, reducing overall productivity. ## Why Documentation Does Not Continue - Documentation benefits the future, while current work usually feels more urgent. - It is often treated as secondary work that requires a deliberate decision to begin. - Authors may also feel responsible for maintaining documents indefinitely. - Without documentation embedded in normal workflows, every update depends on personal willpower. - AI tools can reduce the effort of drafting and maintaining documents, but unclear standards and fear of being wrong remain significant barriers. Both organizations reached the same starting point: gather scattered knowledge in one accessible place, then integrate writing, review, and updates into everyday work rather than relying on individual motivation.

knowledge-managementtechnical-writingdocumentationapi-documentation+2
toss

Creating a Role That Never Existed in the World (opens in new tab)

Technical Writing at Toss has evolved from producing documents to designing organizational knowledge systems. The core argument is that code captures outcomes but not the context, decisions, and history behind them—information that both employees and AI need. Toss’s Technical Writing Chapter therefore aims to make knowledge discoverable, structured, and increasingly self-sustaining, with the long-term goal of making the chapter unnecessary. ### Why Code Alone Is Not a Sufficient Source of Truth - Code records what a system does, but rarely explains: - Why it was designed that way - Which alternatives were considered - What organizational history shaped the decision - Employees often reconstruct context from colleagues’ memories or years-old messenger threads. - AI faces the same problem: it understands general knowledge but lacks an organization’s internal context. - A true Single Source of Truth requires both the code and the surrounding knowledge that explains it. ### From Writing Documents to Bringing Knowledge to People - Early work focused on creating onboarding documentation for the frontend chapter. - The team recognized that well-written documents are ineffective if people do not actively read or find them. - Toss created “Parkssi,” a chatbot integrated into messaging tools and IDEs: - Users ask questions conversationally. - Answers are based on existing documents. - Sources are provided for verification. - Instead of requiring employees to search for documents, the knowledge reaches them where they work. - Teams that previously ignored documentation began requesting similar systems to reduce repetitive questions and capture implicit knowledge. ### From Documents to Knowledge Systems - A knowledge system collects scattered information from code, conversations, deployments, and other sources. - It structures that information so both humans and AI can understand and use it through questions and automation. - Properly designed systems: - Increase productivity across the organization - Reduce communication costs as the company grows - Help employees adapt quickly and consistently - Toss defines knowledge as verified information that helps people understand situations, make better decisions, and act within a specific context. ### The Four Responsibilities of Toss’s Technical Writing Chapter - **Build products:** The chapter develops and operates “Todok,” an internal knowledge-management platform. - **Lead organizational documentation:** TWs work directly with teams to collect and organize knowledge according to each group’s needs. - **Automate Technical Writing:** AI workflows and automation help employees create and review documentation with consistent quality. - **Shape documentation culture:** The chapter runs company-wide sessions, documentation guilds, and knowledge committees focused on making knowledge easier for AI and people to use. ### A Broader Definition of the Technical Writer - Although the job title remains “Technical Writer,” the role now resembles a knowledge-infrastructure designer. - The role expanded by following organizational problems rather than staying within a fixed professional boundary. - The chapter’s ultimate goal is for teams to create and manage knowledge independently, eliminating the need for a dedicated TW chapter. - The series will explore Toss’s knowledge product, failed documentation approaches, automation of TW work, and the path toward self-sufficient organizations. Technical writers can create greater value by designing systems that make knowledge continuously available—not merely by writing more documents. As AI reshapes every profession, expanding a role around the problems it must solve is presented as an opportunity for any discipline.

knowledge-managementtechnical-writingchatbotdocumentation+3
toss

Going Beyond Expertise (opens in new tab)

Technical Writers (TWs) can contribute far beyond writing documentation: they can lead product teams and build systems that turn knowledge into an organizational asset. Toss’s Knowledge System Team created “todoc,” an internal platform that makes documentation easier to write, centralizes scattered knowledge, and enables AI access. Its broader goal is to make documentation emerge naturally from daily work and remain accurate without constant manual maintenance. ## TWs as Product Owners and Makers - The author leads a product team of developers, designers, and TWs. - Their responsibilities include: - Setting product direction, roadmap, and priorities - Interviewing users and bringing insights to the team - Planning features - Building features directly with AI tools - TW expertise is especially valuable because TWs have deeply considered: - Why documents are difficult to read - What makes documentation effective - How information should be structured for AI consumption ## Why Toss Built Todoc Todoc was launched to address weaknesses in Toss’s existing documentation environment. - Static-site-generated documentation required users to: - Clone a repository - Write Markdown - Submit pull requests - Wait for review - This workflow was familiar to developers but created major barriers for designers, PMs, and other non-developers. - Existing documentation tools accumulated outdated policies, unfinished notes, and unexplained content, creating “documentation debt.” - Knowledge was fragmented across: - Static sites - Documentation tools - Code - Collaboration messengers - Individual employees’ knowledge After its beta launch, Todoc grew to more than 500 documents and 40,000 valid pages, with over 1,000 monthly users. ## Todoc’s Four Core Values ### Easy Documentation for Everyone - Anyone can create or edit documents immediately. - Content can be connected from GitHub, documentation tools, internal messengers, and other sources. - The platform removes the technical and procedural barriers to documentation. ### AI-Ready Knowledge - Well-organized documentation can be used by team bots and other AI tools. - Todoc supports API, CLI, and MCP access. - Teams use it for request bots, product specifications, and other workflows. ### A Single Source of Truth - Todoc consolidates scattered sources into complete, centralized documents. - Users can determine which information is current without searching across multiple systems. - The platform serves as the organization’s SSoT (Single Source of Truth). ### Scalable Infrastructure - Teams no longer need to select, build, or maintain their own documentation infrastructure. - Each team can have its own space on a shared platform. - The model is being expanded to Toss affiliates. ## Automating Documentation Quality and Maintenance Lowering the barrier to writing creates a new challenge: maintaining quality. - TW judgment is being converted into: - AI proofreading - Automated document reviews - Bots that generate initial drafts - Todoc is also designed to create documentation automatically from: - Decisions and discussions in internal messengers - Code changes - Ongoing project conversations - The system aims to update documents without relying on someone remembering to maintain them. - It evaluates whether knowledge is still valid by checking: - Whether policies match implemented code - Whether information is actively used - How recently it was updated ## The Evolution of TW Expertise The role is shifting from writing excellent documents manually to designing systems that consistently produce and maintain excellent documentation. - Experience understanding why documents are hard to read becomes standards for human- and AI-readable content. - Judgments about what makes a good document become criteria for AI review and automated editing. - Expertise in identifying outdated information becomes a system for validating knowledge. - TWs increasingly focus on: - Creating places where knowledge can gather - Defining quality standards - Encoding human judgment into systems - Generating documentation through normal work - Keeping knowledge continuously updated The practical vision is an organization where outdated documents trigger their own notifications, project work leaves behind organized records, and recurring explanations are preserved for future employees. Toss’s Technical Writing Chapter is therefore working to systematize TW expertise and establish documentation governance so teams can document effectively without constant manual intervention.

knowledge-managementaigithubmcp+4
line

ODW #8: A Hands-On Internal Workshop on Accelerating Incident Response and FAQ Generation with Slack MCP (opens in new tab)

LY Corporation’s Orchestration Development Workshop demonstrated how Slack MCP can turn scattered Slack conversations into structured operational knowledge. Using AI, employees can summarize incidents, generate reports, create FAQs, and publish results to Confluence with minimal setup. The workshop’s central conclusion was that hands-on practice, reusable skills, and human review are essential for turning new AI capabilities into practical workplace tools. ## The Information and Adoption Challenge - Slack contains valuable real-time information from incident response, customer inquiries, and project discussions. - Much of this information remains unstructured because employees lack time to document it. - Documentation quality varies by author, causing useful knowledge to become difficult to find. - Although Slack MCP became available internally in March 2026, adoption barriers remained: - Limited time to explore new tools - Concerns about complex configuration - Slow internal distribution of technical knowledge ## Introducing Slack MCP Through Hands-On Practice - Slack MCP is an internally developed MCP server connected to company authentication. - Employees can access internal Slack data without issuing personal tokens or configuring OAuth. - The workshop began with a simple exercise: - Launch a coding tool such as Claude Code - Ask the AI to post “Hello” in a designated Slack channel - Confirm that the message was actually posted - This immediate success helped participants understand MCP’s practical capabilities. ## Combining Slack MCP with Other MCP Servers Slack MCP supports several core operations: - Reading messages and threads - Posting messages and performing actions - Looking up channels and members - Searching Slack content Combined with other MCP servers, it can support broader workflows: - Slack plus Confluence MCP: Generate and publish project reports or FAQs - Slack plus Jira MCP: Create work tickets from discussions - Slack conversations can be transformed into structured documents rather than remaining isolated in chat history. ## Automatically Creating FAQs from Slack Inquiries The first major exercise converted repeated support discussions into reusable knowledge. - Slack inquiry threads were collected and converted into FAQ-formatted Markdown. - Existing Confluence content was checked to identify duplicates. - New FAQs were published as child pages under an existing Confluence knowledge base. - The output was formatted as a table containing: - Symptoms - Causes - Solutions The workflow was packaged into reusable skills such as: - `slack-to-faq`: Searches recent inquiry threads and generates new FAQ files - `faq-to-confluence`: Converts and publishes the FAQs to Confluence This demonstrated how MCP can automate the entire path from conversation search to knowledge-base publication. ## Supporting Incident Response The second exercise focused on reducing the time needed to understand and document incidents. ### Rapid Situation Summaries Participants could ask the AI to summarize an outage in natural language. MCP searched relevant Slack threads and organized the information into: - Current resolution status - Customer impact - Actions being taken by team members - A chronological timeline This helps managers or newly joining responders understand the situation quickly without reading every thread. ### Automated Incident Reports After resolution, the AI generated reports in a specified format, including: - Incident and detection times - Duration - Root cause - Affected users and features - Whether data was lost - Remediation steps The `slack-incident-status` and `slack-incident-report` skills separated real-time status checking from post-incident documentation. ## Practical Guidelines and Safeguards - Clean and constrain source data before processing it: - Compare results with existing Confluence FAQs - Filter messages using reactions or other markers - Limit searches to relevant channels and threads - Do not publish AI-generated documents without review. - Check for personal information and confirm that the output accurately reflects the source conversations. - Include links or references to the original Slack threads. - Specify the desired output structure, such as a three-column table for symptoms, causes, and solutions. - Convert successful prompts into reusable skills so teams can avoid rewriting complex instructions and maintain consistent output quality. ## Lessons from the Workshop - **Timing matters:** Holding the workshop soon after Slack MCP became available captured user interest and accelerated experimentation. - **Practice is more effective than explanation:** Starting with a simple Slack post and progressing to FAQs and incident reports made the benefits immediately tangible. - **Real work makes training relevant:** Inquiry handling and incident response were chosen because they are common, time-consuming tasks. - **Reusable skills improve adoption:** Prompt patterns were tested manually, refined, saved as skills, and shared with participants for continued workplace use. The recommended approach is to introduce new AI tools through timely, task-focused workshops, then refine successful workflows into shared skills. MCP can greatly reduce the effort of operational documentation, but human validation remains necessary before generated knowledge is published.

knowledge-managementgen-aimodel-context-protocolslack+4