Gautier warns on knowledge silos
- Developer Gautier posted a real example where a six‑person team moved slower than a solo developer because documentation and shared conventions were missing. - He emphasised concrete fixes: consistent writing conventions, documented technical decisions, and shared knowledge to avoid single points of failure. - The social thread frames documentation and short decision records as practical levers to speed teams and make handoffs less risky. (x.com)
Software teams love to talk about velocity, but Gautier’s point is simpler than that: a team can have more people and still move slower. Not because the developers are worse. Because the work only exists inside a few heads. Once that happens, every task turns into interruption, translation, and waiting. That’s the thing his thread was really warning about. Not “documentation is nice.” More like — undocumented knowledge is a tax, and teams pay it every day in tiny delays until the whole system feels heavy. In his example, a six-person team underperformed a solo developer because shared conventions, written decisions, and basic handoff material were missing. The team had more hands, but no shared map. ### Why would six people be slower than one? Because adding people only helps when they can work independently. If every change depends on asking the same person how things work, where files live, why a pattern exists, or what not to touch, the team is not parallelized. It is serialized through whoever remembers the most. That is the hidden bottleneck Gautier was pointing at. ### What kind of knowledge goes missing? Usually not the big obvious stuff. The repo exists. The code compiles. There may even be a README. The missing layer is the practical layer — naming conventions, expected architecture, why one approach was chosen over another, what tradeoff the team already debated, and which parts are fragile. That’s the knowledge people keep in Slack threads, meetings, and memory. Then someone leaves, gets sick, or just goes offline, and the team discovers that “working software” was actually being held together by oral tradition. ### Why does that slow teams down so much? Because uncertainty compounds. A developer who lacks context does not just lose ten minutes. They hesitate, ask for review earlier, avoid touching risky areas, duplicate old discussions, or make a change that later has to be unwound. One undocumented decision creates rework. Ten undocumented decisions create a culture of caution. That is how a bigger team starts feeling weirdly fragile. ### So what was Gautier actually pushing teams to do? The fixes were pretty unglamorous — and that is why they matter. Write down conventions. Record technical decisions in short form. Make sure more than one person can explain how a core system works. Basically, create enough shared memory that a developer can move without asking for permission from the team historian. Gautier framed short decision records and explicit writing conventions as speed tools, not bureaucracy. ### Why are short decision records such a big deal? Because they preserve the “why,” not just the “what.” Code shows the final state. It usually does not show the rejected alternatives, the constraints, or the reason something slightly awkward was still the best call. A short note can do that in a few lines. That means the next person does not have to reverse-engineer intent from commits and guesswork. ### Is this really about documentation? Partly, but the deeper issue is single points of failure. When one person becomes the only route to understanding, the team becomes operationally brittle. Security and operations people use that phrase for infrastructure, but it fits teams too — one weak link, one unavailable person, one undocumented subsystem, and normal work stalls. Gautier’s warning lands because this kind of fragility often forms quietly inside otherwise competent teams. ### Why does this matter right now? Because more teams are distributed, lean, and expected to ship faster with fewer people. In that setup, knowledge transfer is not a side chore. It is part of the product system. The teams that look fast from the outside are often the ones that made context cheap to access. Everyone else is burning time rediscovering decisions they already made. The bottom line is blunt: headcount does not create leverage by itself. Shared understanding does. Gautier’s thread resonated because it named a common failure mode teams still pretend is normal — and offered a boring, practical fix that actually scales.