Someone asks in the team channel: Why does the retry job skip weekends? There is silence for forty minutes. Eventually, a senior engineer replies with a short answer, three people give a thumbs up, and the conversation disappears.
The same question came up back in March. It was a different person, but it still took forty minutes to get an answer.
No one did anything wrong. The answer existed, someone knew it, but the team still lost an hour finding it. That gap between knowing something and being able to access it is where a lot of engineering speed quietly disappears.
Hiring is supposed to fix this. You add three engineers and expect to ship more. But every new person has their own questions, and the only way to get answers is to ask someone who is already busy. Growth means more people and more questions, but the number of answers stays about the same.
The knowledge doesn’t disappear - it stops being reachable
No one is hiding this information. If you ask an engineer why the deploy has a strange manual step, they will happily explain. The real problem is where that explanation ends up - maybe in a DM from eight months ago, a comment on a closed pull request, or just in the memory of the person who fixed it at 2 am while everyone else was asleep.
Then that person moves to another team or leaves. Their laptop gets wiped, and a decade of context disappears. It’s not because they were careless, but because at the time, nobody wrote it down. Everyone in the room already knew.
When the team was just four people, everyone knew the background. With twelve, half the team missed the original conversation. With forty, most people were not even hired yet.
The tax that never shows up on the roadmap
Look for the signs. They’re everywhere. A service gets rebuilt because no one knew the old one already did that. The same bug gets fixed twice, in two places, by two people who never talked. Someone spends a whole day on a problem that was solved last quarter by a teammate sitting just a few feet away.
Decisions get debated again as well. Why are we using this queue instead of that one? Nobody remembers, so the discussion starts over, and this time it ends differently. It is not because there is new information, but because a different group of people happened to be in the meeting.
None of this gets tracked as a ticket. It just appears in retrospectives as a vague sense that everything takes longer than it used to.
What actually helps
Keep decisions close to the work. A short note in the repo, right next to the code it explains, is better than a polished wiki page in a tool nobody checks. Record what you chose, what you tried first, and what failed. It does not have to be perfect. The goal is for it to be easy to find, not ready to publish.
Use code review as a way to teach, not just to gatekeep. Saying, “This works, but here’s the thing that’ll bite you in six months” is more valuable than just giving an approval stamp, and it applies to a real change instead of a hypothetical one.
Pair up on the tough tasks like migrations, tricky legacy modules, or incidents that nobody understands yet. Knowledge spreads best through hands-on work, and two people who solve the same problem both end up knowing where to find the solutions next time.
Hold short demos. In fifteen minutes, someone can walk through what they built and explain their decisions. Half the value comes from the questions that follow.
Make your search better. This step often gets skipped, but it can undo all your other efforts. If your wiki has four different pages about the same service and none are dated, it is basically the same as having no wiki at all. Knowledge that cannot be found is knowledge nobody has.
You can’t mandate this into existence
A common mistake is launching a Big Documentation Initiative. Leadership announces it, everyone writes pages for two weeks, the pages become outdated, nobody reads them, and eight months later someone suggests doing it all over again.
What actually works is smaller and sometimes a bit annoying. Senior people ask their questions in the public channel instead of in DMs, so the answer is visible for the next person who needs it. Someone says, “good question, let me write that down,” and then actually does it. Newcomers are told that a confused question is a gift, because confusion is the cheapest bug report you will ever get about your own onboarding.
Then there is the incentive problem, which is where most of these efforts quietly stop. If the engineer who documents the deploy process gets little recognition, while the one who ships the flashy feature gets promoted, everyone quickly learns what really matters. No announcement at an all-hands meeting can change that.
Where AI actually fits
There is a lot of hype right now. People talk about building an MVP in 48 hours or shipping in days instead of months. Some of this is true. The tools really do speed up typing, and things like scaffolding, first drafts, boilerplate tests, and quick prototypes are faster than before.
But notice what actually changes. Writing code becomes easier, but understanding it does not. You might build a working product over a weekend, but now you have a codebase that nobody on the team has read closely. It is built on decisions nobody remembers, because they were not made by someone who can explain them later. The bottleneck just moves further along.
Testers have been asking the same question: is this tool coming for my job? The honest answer is that it is a multiplier, not a replacement. A tool can handle boring, repetitive tasks much faster than a person. But deciding what is worth testing, figuring out if a flaky failure is the test or the system, or noticing when a passing suite is misleading you, that is judgment. Judgment is what the machine needs from you, not what it provides.
This brings us back to the same point. A team that understands its own system truly benefits from these tools. A team that does not just ends up creating confusion more quickly.
The short version
Speed is not mostly about tools, process, or team size. It really comes down to how long it takes for a question to get answered. Teams where anyone can find out why something was built a certain way stay fast even with forty people. Teams where that knowledge is only in a few people’s heads seem quick until one of them leaves.
So when you see a question in the channel, answer it. Then take two extra minutes to put the answer somewhere the next person can find it, because there will always be someone else who needs it.
