Building in the Dark: How Tech Teams Keep Reinventing Wheels Nobody Knew Already Existed

Somewhere right now, two engineers at the same company are solving the exact same problem. They're using different libraries, writing different tests, and drawing on different assumptions. Neither of them knows the other exists. And when both solutions eventually surface — one in a code review, one in a Slack message six months later — nobody will laugh. Everyone in the room will recognize the feeling immediately.

This is the knowledge silo problem, and it's one of the most expensive invisible costs in modern tech.

The Gap Nobody Talks About in Standups

It's tempting to frame this as a communication failure, something fixable with better meetings or a more active Slack workspace. But the engineers and team leads who've wrestled with this issue for years will tell you it runs deeper than that. The real culprit isn't a lack of talking — it's a lack of structured, findable, persistent knowledge.

"We had two teams building authentication middleware at the same time," says one engineering director at a mid-sized SaaS company who asked not to be named. "Both teams were talented. Both solutions were solid. But we'd already paid for the same problem twice, and the real cost was when we had to merge those systems later. That was brutal."

In open source communities, the problem takes a slightly different shape. Projects grow organically, contributors come and go, and institutional memory evaporates with every maintainer who quietly stops submitting PRs. A feature that was deliberately not built three years ago — because someone discovered it created a security edge case — gets proposed again by a well-meaning new contributor who has no way of knowing that history exists.

What Silos Actually Cost

Duplicate work is the obvious headline, but it's not the most dangerous consequence. The subtler damage shows up in system architecture. When teams don't know what each other is building, they make integration assumptions that don't hold. APIs get designed without knowing what will eventually need to consume them. Data models get locked in before anyone realizes another team needed a slightly different shape.

The result is technical debt that's structurally baked in from day one — not the kind that comes from cutting corners, but the kind that comes from building in the dark.

There's also a security dimension that rarely gets enough attention. Vulnerabilities often emerge precisely at the seams between systems that different teams own. When nobody has a clear picture of how those systems connect, nobody owns the gaps either. And in open source projects with distributed maintainership, those gaps can sit exposed for years.

Why Documentation Alone Won't Save You

The usual prescription is documentation. Write more of it. Keep it updated. Make it searchable. This advice isn't wrong, but it's incomplete in a way that leads a lot of teams to invest heavily in wikis and internal portals that nobody reads.

The problem is that documentation is typically written after the fact, by the person who built the thing, optimized for what they think someone else needs to know. It rarely captures the reasoning behind decisions — why this approach and not that one, what alternatives were considered, what the known limitations are.

"The docs told you what the system did," explains one open source maintainer who contributes to several widely-used infrastructure projects. "They didn't tell you why it worked that way, or what we tried first that didn't work. New contributors would show up and propose the exact thing we'd already ruled out, and we'd have to explain it from scratch every time."

What actually works, according to teams that have made real progress here, is treating knowledge transfer as a first-class engineering practice — not a nice-to-have that happens after the real work is done.

Practices That Actually Move the Needle

Several engineering organizations have started experimenting with what some call "architecture decision records" or ADRs — short documents that capture not just what was built, but the context, constraints, and tradeoffs that shaped the decision. The format is lightweight enough that engineers will actually write them, and specific enough that they remain useful years later.

Other teams have had success with internal "show and tell" sessions — not project status updates, but genuine technical deep-dives where engineers share what they built and why, including the parts that didn't work. The cultural shift here is significant: it requires psychological safety around discussing failure and uncertainty, which isn't a given in competitive engineering environments.

In open source contexts, some projects have started maintaining explicit "decision logs" in their repositories alongside the code itself. When a contributor opens a PR that revisits a previously rejected approach, maintainers can point to a document rather than reconstructing the argument from memory — or worse, accepting the change because nobody remembers why it was declined.

Cross-team pairing has also shown real results, particularly for reducing the kind of silent divergence where two teams gradually develop incompatible mental models of shared systems. Even a few hours of pairing per sprint across team boundaries can surface misalignments before they become architectural problems.

The Open Source Angle

For open source communities specifically, the knowledge silo problem has a unique dimension: contributors aren't employees. You can't mandate documentation practices or require attendance at knowledge-sharing sessions. Everything has to be designed around the reality that people are volunteering their time and attention.

This is where tooling and defaults matter enormously. Projects that make it easy to capture context — through PR templates that prompt for rationale, issue trackers that link related decisions, changelogs that explain the why alongside the what — tend to accumulate institutional knowledge more naturally than projects that rely on individual discipline.

The NetBux community has seen this play out repeatedly: projects with strong knowledge infrastructure attract more confident contributors, because newcomers can actually understand the codebase's history and reasoning. Projects where knowledge lives only in the heads of a few long-term maintainers create a bottleneck that eventually becomes a single point of failure.

Transparency as Infrastructure

Maybe the most useful reframe is this: knowledge sharing isn't a soft skill or a cultural initiative. It's infrastructure. The same way you invest in monitoring so you can see what your systems are doing, you need to invest in knowledge infrastructure so your team can see what each other is building.

That investment looks different at different scales. For a small open source project, it might mean a well-maintained CONTRIBUTING.md and a habit of leaving detailed PR comments. For a larger engineering organization, it might mean dedicated tooling, regular cross-team reviews, and explicit time budgeted for documentation.

But the underlying logic is the same: you can't collaborate effectively on things you can't see. And right now, in tech organizations and open source communities across the country, a staggering amount of valuable knowledge is invisible — locked in individual heads, buried in old Slack threads, or simply never written down at all.

The good news is that this is a solvable problem. It just requires treating the solution with the same seriousness you'd bring to any other piece of critical infrastructure.