How I Turned Slack Messages Into Documentation

The unsexy process behind gathering information as a solo technical writer

At startups, knowledge doesn't live in neatly organized wikis or comprehensive handoff documents. It lives in Slack threads, Notion pages with outdated information, and most critically — in engineers' heads.

As the only technical writer at an AI startup, my job isn't just writing documentation. It's excavating knowledge before it disappears.

Here's the actual process I use to turn scattered internal conversations into documentation that developers can actually use.

The Reality of Information Gathering

When I joined my company, I inherited documentation that was outdated and AI-generated. The product had evolved significantly, but the docs hadn't kept pace. The knowledge existed — it was just trapped in places I couldn't access.

I quickly learned that the best explanations weren't in formal documents. They were in Slack messages where an engineer answered a customer question at 11 PM. In casual conversations during standups. In the comments of pull requests.

My job became part technical writer, part archaeologist.

Step 1: Build Relationships Before You Need Them

This is the step most technical writers skip, and it's the most important one.

Engineers are busy. They're shipping features, fixing bugs, and attending meetings. Documentation is rarely their priority. If you only show up when you need something, you'll always be at the bottom of their to-do list.

What I do instead:

I show up in engineering channels even when I don't need anything. I react to their wins. I ask genuine questions about what they're building. When I see an interesting technical discussion, I engage with curiosity, not just for documentation purposes.

When I finally do need their help documenting a feature, I'm not a stranger asking for a favor. I'm a colleague they've interacted with.

This sounds soft, but it's the difference between getting a response in two hours versus two weeks.

Step 2: Ask Specific Questions, Not Open-Ended Ones

Early on, I made the mistake of asking engineers: "Can you explain how this feature works?"

The responses were either overwhelming (a 30-minute monologue covering edge cases I didn't need) or unhelpfully brief ("It does what the PR says").

What actually works:

Instead of "How does this work?", I ask:

• "What happens when a user sends an invalid API key?"
• "What's the most common mistake customers make with this endpoint?"
• "If this fails, what error message do they see?"

Specific questions get specific answers. Specific answers become useful documentation.

The best question I've learned to ask: "What do you wish customers understood before they start using this?" Engineers love answering this one because it lets them vent about the support tickets they're tired of seeing.

Step 3: Capture Conversations in Real-Time

The gold is in the Slack threads. Here's my actual process:

When I see an engineer explain something well in Slack:

1. I screenshot or copy the message immediately
2. I DM them: "That explanation was really clear. Mind if I turn this into docs?"
3. Most say yes. Many are flattered.

When a customer asks a question in a support channel:

1. I note the question (this tells me what's unclear in current docs)
2. I watch how the engineer responds
3. I add this to my documentation backlog

When I'm in meetings:

I keep a running note of anything that makes me think "wait, is that documented?" It usually isn't.

The key is capturing knowledge when it's fresh. Engineers explain things clearly in the moment, but ask them to re-explain two weeks later and the clarity is gone.

Step 4: Make Reviews Stupidly Easy

Getting engineers to review documentation is like pulling teeth — unless you make it effortless.

What doesn't work:

"Hey, can you review the docs I wrote?"

This gets ignored because it feels like an undefined time commitment.

What works:

"Hey, can you check if the code example in section 3 actually runs? Should take 5 minutes."

I break reviews into tiny, specific asks:

• "Is this parameter description accurate?"
• "Did I get the error codes right?"
• "Any gotchas I should add?"

I also learned to set deadlines with consequences:

"I'm publishing this Thursday at 2 PM. If I don't hear back, I'm assuming it's accurate."

This sounds aggressive, but it works. Engineers don't want wrong documentation published under their name. They'll make time to respond when there's a deadline.

Step 5: Build a System, Not Just Documents

Individual documents are nice. A system is sustainable.

My simple system:

I keep a "docs debt" list — a running note of everything I've noticed needs documentation but haven't had time to write. Every Friday, I spend two hours chipping away at it.

I also maintain templates for common documentation types:

• API endpoint documentation
• Tutorial structure
• Troubleshooting guides
• Release notes

Templates mean I spend my mental energy on content, not structure. They also create consistency across documents.

The Slack channel hack:

I created a #docs-updates channel where I post whenever I publish new documentation. Two benefits:

1. Engineers see their work being documented (makes them more likely to help in the future)
2. People can flag issues immediately ("Actually, we changed that endpoint last week")

What I've Learned

After months of doing this, a few things have become clear:

Documentation is 20% writing, 80% gathering. The actual writing is the easy part. Getting accurate information from busy people is the real skill.

Timing matters more than asking nicely. Catch engineers right after they ship a feature — they're still excited and remember the details. Wait two weeks and you'll get "I don't remember, check the PR."

Perfect is the enemy of published. I used to wait until documentation was comprehensive before publishing. Now I ship "good enough" and iterate. Something helpful today beats something perfect next month.

Your documentation is only as good as your relationships. I know which engineers explain things clearly, which ones need more specific questions, and which ones prefer async communication. This knowledge is as valuable as any writing skill.

The Unsexy Truth

There's no magic tool that extracts knowledge from your organization. Mintlify makes the publishing beautiful. GitHub makes version control seamless. But the actual information gathering?

That's Slack messages at 9 PM. That's coffee chats that turn into impromptu explanations. That's asking "dumb questions" in engineering channels and not caring if you look uninformed.

It's not glamorous. But it's how documentation actually gets made at startups.

What's your biggest challenge in gathering information for documentation? I'd love to hear what works (and what doesn't) for others.