Stop Documenting the Wrong Things

We’ve all seen it: internal wikis full of step-by-step tutorials on how to click a button in Slack, upload a file to Dropbox, or set a reminder in Asana. Pages and pages of redundant how-to guides for tools that already have their own support centers.

I get where it comes from—someone thinks our setup is unique. Or worse, they think “owning” the documentation means they’re helping. But what it actually creates is unnecessary technical debt. Because here’s the reality:

• Software changes.
• The vendor updates their documentation.
• Your internal docs don’t.
• Now your team is referencing screenshots from three versions ago.

Even if someone owns the doc, it’s still work to maintain. What if no one needed to own it? What if the answer didn’t live in a dusty wiki, but right where it belongs—in the vendor’s support center?

When You Don’t Need a How-To Guide

Not everything needs to be documented internally. In fact, documenting the wrong things just adds noise. Here are examples where it’s better to link out than write your own:

1. The vendor has a great support center

• Slack: Want to create a channel? Mute notifications? It’s all covered.
• Google Workspace: Gmail, Drive, Calendar—fully documented and always up to date.
• Asana: Their task creation guide includes steps, images, and video. Better than anything you’d build in Confluence.

2. The process isn’t unique to your team
If every user, in every company, would do it the same way—don’t write it up.

• Uploading a file to Dropbox? Skip it.
• Creating a Zoom meeting? Let Zoom explain it.

What is worth writing: when and why your team uses these tools, or what’s expected internally.

Example: “All recorded client calls should be uploaded to the ‘Client Recordings’ folder within 24 hours.”

3. The tool handles its own education

• Notion, Airtable, and Loom are great at pushing updates and tips directly in the product.
  Let your team learn where they’re working—no extra doc required.

4. You can just link to it
Instead of recreating every detail, say:

“We manage all internal tasks in Asana. Here’s how to create and assign tasks.”

That’s it. Done.

Where Your Docs Should Focus

Internal documentation should answer:

• What are we doing with this tool?
• What’s the workflow or standard we’ve adopted?
• Who owns what and when?

That’s the kind of clarity that actually helps teams work better. (This is a great place to link to your own “Internal Tooling Guidelines” or “How We Use Asana” if you build one.)

Takeaway

Don’t waste time documenting what doesn’t need to be documented. Let the software vendors do their job—so you can focus on yours.

Build a system of references, not replicas. Save your internal documentation for the things that are truly yours: process, structure, and expectations.

‍