← Back to list

How to Stop Re-Explaining Everything

You’ve explained this before. Multiple times. To different people. And you’ll explain it again next week.

Petra Ivanigova in The Startup · 2024-11-14 22:39 · 0 claps · 3.1 min read
#team-wiki #knowledge-management #digital-library #information-flows #team-culture
Open on Medium ↗
Wiki topics: BIZ · Business Strategy CUL · Culture & Media 📚 · Books & Reading

How to Stop Re-Explaining Everything

You’ve explained this before. Multiple times. To different people. And you’ll explain it again next week.

This is a waste of your time.

The pattern

Someone asks how to do something. You explain it. They do it. Two weeks later, someone else asks the same question. You explain it again.

Or the same person asks again because they forgot. Or they almost remember but need clarification. Or they remember wrong and break something.

Every explanation takes ten minutes. You’ve done it twenty times. That’s over three hours spent repeating yourself.

And it’s not just you. Everyone on your team is re-explaining things. Onboarding takes forever because nothing is written down. Decisions get revisited because nobody remembers why you made them.

Why this happens

Writing things down feels slower than just answering the question.

Someone asks in Slack. You could type a full explanation and save it somewhere. Or you could just answer quickly and get back to work.

You choose quick. Everyone chooses quick.

The problem is that quick now means slow later. You save five minutes today. You lose an hour next month answering the same question six more times.

Write it once

When someone asks a question you’ve answered before, that’s your signal.

Stop. Write down the full answer. Put it somewhere people can find it. Send them the link.

Yes, this takes longer than just answering. But you’ll never answer that question again.

Next time someone asks, you send the link. Takes ten seconds instead of ten minutes.

Where to put it

Pick one place for documentation. Not five different tools. Not scattered across Slack, Google Docs, Notion, and someone’s personal notes.

One wiki. One source of truth.

Every explanation goes there. Every process. Every decision that people need to reference later.

If you can’t remember where something is documented, it’s not documented. It’s lost.

Make it findable

Writing things down doesn’t help if nobody can find them.

Use clear titles. “How to deploy to production” not “Deployment notes.”

Organize by topic, not by when you wrote it. Group related things together.

Add a search function. Let people find answers without asking you.

When to write

You don’t need to document everything immediately. You need to document things when they prove they matter.

The second time you explain something, write it down. The first time might be unique. The second time is a pattern.

When you make a decision that affects how people work, write it down. When you solve a tricky problem, write down how you solved it. When someone asks “why did we do it this way?” write down the answer.

Keep it simple

Don’t make documentation complicated. You’re not writing a manual. You’re answering questions.

Write like you talk. Short sentences. Clear steps. No jargon unless it’s necessary.

If the explanation is three paragraphs, that’s fine. If it’s three sentences, that’s also fine. Just make it complete enough that people don’t need to ask follow-up questions.

Make it a habit

The hardest part is starting. You’re used to just answering questions. Now you need to answer and document.

For the first month, it feels like extra work. Because it is.

But after a month, you start seeing the payoff. Questions you used to answer daily stop coming. New people onboard faster. You have more time for actual work.

After three months, the documentation answers more questions than you do.

Update it

Things change. Your documentation needs to change too.

When a process changes, update the doc. When someone points out that instructions are wrong, fix them immediately.

Outdated documentation is worse than no documentation. It wastes people’s time and breaks their trust.

Add a date to each page. When you reference a doc that’s over a year old, check if it’s still accurate.

The test

Here’s how you know it’s working.

Count how many times people ask you the same question this month. Next month, that number should be lower.

Count how long onboarding takes. In three months, it should be faster.

Count how much time you spend explaining things. Every month, you should have more time for other work.

If those numbers aren’t improving, your documentation isn’t good enough yet.

Stop explaining, start writing

Next time someone asks you a question you’ve answered before, don’t just answer it.

Write it down. Put it in the wiki. Send them the link.

It takes five extra minutes now. It saves hours later.

That’s the entire strategy. There’s nothing complicated about it.

Stop re-explaining everything. Write it once. Reference it forever.


메타데이터
post_id
5d2c69413f53
slug
building-our-team-wiki-growing-a-shared-knowledge-base-5d2c69413f53
url
https://medium.com/@petraivanigova/building-our-team-wiki-growing-a-shared-knowledge-base-5d2c69413f53
canonical_url
https://medium.com/@petraivanigova/building-our-team-wiki-growing-a-shared-knowledge-base-5d2c69413f53
author_url
https://medium.com/@petraivanigova
status
ok
fetched_at
2026-07-17 19:04:00