When organizations struggle with cross-department collaboration, the standard diagnosis points to structural problems: silos reinforced by reporting lines, incentive systems that reward local optimization, meeting cultures that keep information inside teams. These are real problems. But there is a simpler, more fundamental barrier that gets less attention because it feels less tractable: people often do not know who in the organization to contact in the first place.
This is not about unwillingness to collaborate. In most large organizations, people are generally willing to help colleagues from other departments when asked. The barrier is discovery. Before you can have a collaboration, you have to find the right person. In a 3,000-person organization, that search is non-trivial. In a 15,000-person organization, it is a genuine operational problem that consumes meaningful time on every cross-functional initiative.
The invisible cost of the search
When a project lead needs expertise from outside their department, the typical search sequence looks something like this. They ask their manager if anyone comes to mind. They send a message to someone they know in the target department asking for a referral. They may post to an internal communication channel. They attend a meeting and mention what they are looking for. Somewhere in this process, a name surfaces, and they follow up. Or they move forward without finding the right person and accept the gap.
The cost of this process is invisible because it is distributed across many people's time and because no one is tracking it. A project lead spending four or five days on this search at the start of every major initiative does not file an expense report for those four or five days. The time is simply absorbed into how projects start. When we ask project leads in large organizations how long it takes to assemble the right people for a new initiative, the answers cluster around two weeks for routine cross-functional work and longer for anything that requires specialized knowledge the project lead's network does not readily cover.
The more important cost is the quality degradation that happens when the search fails partially. The project lead finds someone available in the target department, but not the person best suited to the task. Collaboration happens, but it is less effective than it would have been with better-matched expertise. That quality gap is even less visible than the time cost, and it compounds across all the decisions the collaboration informs.
Why org charts do not solve this
Organizations generally have employee directories and org charts, and these do help with some kinds of cross-department routing. If you need to find the head of a particular function, the org chart gets you there. But cross-department collaboration rarely needs the department head. It needs the specific person three or four levels down who has actual hands-on experience with the process, system, or domain that is relevant to the project.
Org charts do not encode expertise. They encode authority relationships and administrative groupings. A person who spent two years building compliance process documentation before moving into a different role still carries that knowledge. The org chart shows their current role. The directory shows their name and contact information. Neither tells you that this person is one of the few people in the organization who understands the edge cases in a compliance process that your project is about to run into.
This is a structural gap in how organizations represent themselves to their own members. The formal information architecture is designed for management purposes, not for expertise routing. Cross-department collaboration requires expertise routing, and most organizations do not have an infrastructure for it.
The role of social network topology
In practice, expertise routing in large organizations runs almost entirely on informal networks. People find the right collaborators by knowing people who know people, by accumulated reputation, and by the informal directories that experienced employees carry in their heads. This works reasonably well for common collaboration patterns and for expertise that is widely distributed.
It breaks down in three specific situations. First, when the needed expertise is unusual or cross-functional in a way that does not match the established informal network topology. Second, when the people who hold the expertise are not well-connected into the social networks that route collaboration requests. Individual contributors who do deep technical work and have long tenure are often among the most valuable expertise holders in an organization and among the least visible through informal network routing. Third, when the project needs expertise that existed in the organization but changed location through transfers or organizational restructuring, and the informal network maps have not caught up.
All three of these situations are more common than organizations typically acknowledge. The informal network is a real and valuable structure, but its reliability is uneven in ways that are difficult to see from the outside.
What better discovery looks like
The alternative to informal network routing is not a top-down managed directory of expertise, which historically fails because it is expensive to maintain, falls out of date quickly, and does not capture the nuance of what people actually know versus what their job titles suggest. The alternative is a system that infers expertise from the work people have done, not from the titles they hold or the self-assessments they filed during the last HR cycle.
Project history, collaboration patterns, document authorship, knowledge base contributions, and problem-solving traces all carry signals about what a person actually knows. When these signals are aggregated across a large organization and connected through a knowledge graph, the resulting picture of expertise distribution is substantially richer than what any org chart or directory provides. And crucially, it reflects the current state of who knows what, not the state that was documented when someone joined the organization or last updated their profile.
We are not suggesting that a knowledge graph eliminates the need for human judgment in how collaborations are assembled. The graph surfaces candidates. A project lead still makes the call about who to engage and how. What changes is the starting point for that decision. Instead of a search that begins with an informal network query and may take days, the search begins with a structured picture of who in the organization has relevant expertise and what their connection path to the project looks like.
Designing for the moment of need
One finding from our early-access work is that the timing and interface of expert-finding matters as much as the quality of the underlying data. Project leads do not typically think to consult an expertise database when they are planning a project. They think about it when they hit a specific question they cannot answer, or when they realize they need someone from a specific domain they do not have a relationship with. The tool has to meet them at that moment.
This has implications for how knowledge analytics tools should be integrated into enterprise workflows. A standalone system that requires a separate login and a separate search habit is a high-friction tool that will be underused. Integration with the tools project leads already use for planning and coordination is much more likely to change behavior, because it reduces the cost of the search at the exact moment when the search cost matters.
The underlying thesis is simple: better cross-department collaboration does not require better intentions. Most organizations already have the intentions. It requires better discovery infrastructure, and better discovery infrastructure requires treating expertise as a first-class organizational data asset rather than an attribute that gets documented once and forgotten in a profile field.
