Before we started Asterminds, I spent several years at a large systems integrator in Tokyo. One of the things that stuck with me was a discovery we made while auditing the internal tooling for one of the manufacturing business units: three separate engineering teams, each in a different division, had independently built a data normalization utility for handling inconsistently formatted input data from legacy systems. Not similar utilities. Almost identical ones, solving the same core problem with the same basic approach, built over overlapping time periods without any of the three teams knowing the others were working on it.
When we asked how this happened, the answers were consistent across all three teams. Each had a project that needed the utility. Each had searched internally for existing tools and found nothing. Each had concluded that building from scratch was the only option. The searching was real and it was thorough, within the limits of what each team could reach. The problem was not that they did not look. The problem was that the organization had no infrastructure to make internal work discoverable across divisional boundaries.
This pattern, three teams independently solving the same problem, is one of the clearest markers of a knowledge visibility failure. It is common. Most large organizations, on honest reflection, can identify their own version of this story. And the root cause is almost always the same: not a lack of willingness to share or a culture of hoarding, but a genuine absence of the infrastructure needed to connect people across the invisible walls of organizational structure.
Why duplication is the default
When an engineer or analyst faces a technical problem, the rational first step is to search for existing solutions. In most large organizations, that search is bounded by what is findable through official channels: the internal wiki, the shared drive, the project management tool. These channels have a characteristic coverage gap: they capture what people explicitly chose to document and make findable, which is a small fraction of what has actually been built and learned. The process artifacts, the intermediate decisions, the utility code that works but was never written up, the analysis that was done and used but never formally published: none of this is typically findable through official channels.
What is findable through informal channels, through personal networks and direct outreach, depends on the team's network reach. An engineer at a Tokyo-based manufacturing division who does not have relationships with engineers in the Nagoya and Osaka divisions has no practical way to know that those teams have solved the same problem. The informal network that might carry the knowledge does not cross the divisional boundary.
Faced with a failed search and a project deadline, the rational response is to build from scratch. The engineer is not making a mistake. They are responding rationally to the information available to them. The mistake is at the organizational level: the failure to build infrastructure that makes what the organization knows accessible across the boundaries where it is needed.
The cost that looks like normal overhead
Duplicated engineering effort has an obvious direct cost: the person-hours spent building something that already exists. For the data normalization utility example, each of the three teams spent several weeks on initial development, plus ongoing maintenance. The combined cost over two years was significant. None of it appeared anywhere as waste, because it was categorized as normal project overhead. Each project manager saw the development hours as a cost of their project. No one was tracking the aggregate.
The less obvious cost is what happens after the duplication is discovered. Three separately developed utilities now exist in the organization's technical infrastructure. They produce similar but not identical outputs in edge cases. Teams that use different utilities for the same input data get different results. Debugging why those results differ requires someone to understand all three implementations. When a change in the upstream data format requires updating the utility, three maintenance efforts are needed instead of one. The organizational complexity cost of the duplication compounds over time.
And then there is the learning cost. The three teams arrived at similar solutions through separate problem-solving cycles. If they had been able to see each other's work, the best elements of each approach could have been combined into a single stronger solution. One of the three implementations had an edge-case handling approach that was genuinely better than the others. The other two teams never knew about it. The organization effectively paid three times for one solution and got three different versions of suboptimal, instead of one best version.
Structural duplication versus communication failure
It is worth distinguishing between two explanations that both appear frequently when this pattern is diagnosed in organizational post-mortems. The first explanation is culture or communication: the teams did not share because the culture does not encourage sharing, or because the communication channels did not work well, or because people were territorial about their work. The second explanation is visibility infrastructure: the teams could not share what they did not know others needed, and could not find what they did not know others had built.
Both explanations are sometimes correct. Culture and communication do shape knowledge sharing behavior. But the infrastructure explanation is more frequently the primary cause, and it has a different implication for what to fix. Communication culture interventions, all-hands meetings, cross-team knowledge-sharing sessions, internal tech talks, require sustained behavior change and are difficult to scale across a large organization's day-to-day work. Visibility infrastructure changes, building systems that make what the organization has built and learned discoverable, are a different kind of investment with different leverage.
The three-team duplication at my former employer happened in an organization with good cross-team communication norms. The teams were not territorial. The culture valued sharing. The problem was that no one knew who was working on what, so the communication about it never happened. Better culture would not have prevented the duplication. A knowledge graph that connected project work to expertise domains and made it visible across divisions would have.
What changes with better visibility
When an organization has an infrastructure layer that makes work visible across divisional boundaries, the early stages of problem-solving change. A team beginning to scope a technical or operational problem can ask not just "has this been formally documented somewhere" but "who in the organization has worked on something like this." The answer, when it is available, changes the trajectory of the project. Instead of building from scratch, the team can reach out to the people who have relevant experience, understand what they tried, what worked, and what did not, and build from that foundation rather than from nothing.
This is not a hypothetical benefit. In the early-access pilot work we have done with enterprise teams, the most consistent positive response from the engineers and analysts using the tool is that it surfaces people they did not know to look for. The discovery is not always a perfect match. But the partial match, the person who did something adjacent two years ago and has relevant context, is often enough to save days of duplicated exploration.
The organizational cost of duplication is a visibility cost, not a motivation cost. Most people would rather build on what their colleagues have already done than build from scratch. They just need to be able to find it.
Starting with the right question
Organizations looking to reduce duplicated effort often reach for solutions aimed at behavior: mandating that teams document their work, requiring knowledge-sharing sessions, building out wiki infrastructure. Some of these help at the margins. None of them directly addresses the core visibility problem.
The more productive starting question is not "how do we get teams to share more" but "how do we make what teams have already done findable." The knowledge mostly exists. The problem is that it is not organized in a way that connects to the questions other people have. Building that connection is the infrastructure work that prevents the next three-team duplication from happening.
