The Network You Have Is Part of the System

Two hospitals deployed the same knowledge management system in the same year. Same vendor, same configuration, same training program. Eighteen months later, one had an active community contributing case notes, sharing protocols, updating best practices continuously. The other had a system full of outdated documents that nobody touched. The IS evaluator blamed poor training at the second site. The more precise explanation is that the two hospitals had different social capital, and the system depended on social capital to work.

The concept comes from sociology, but its IS applications are significant. My recollection is that Nahapiet and Ghoshal (1998) provided the most widely cited treatment of social capital in the organizational theory literature. They argued that social capital has three dimensions that together explain why some networks generate value and others do not. The structural dimension is about who is connected to whom: network configuration, presence or absence of ties between people, density and reach. The relational dimension is about the quality of those connections: trust, norms of reciprocity, obligations, and shared histories. The cognitive dimension is about shared understanding: a common language, shared schemas, and mental models that allow people to communicate complex knowledge without constant translation. My recollection is that they framed these three as jointly necessary: structural ties give you access, relational capital gives you the willingness to use that access, and cognitive capital gives you the ability to actually exchange meaningful content through those ties.

Coleman (1988) had developed the foundational argument earlier, that social capital is a resource embedded in social relations, not in individuals. It is not something you possess personally. It exists in the structure of the relationships around you. A person with identical skills and knowledge has more or less access to resources depending on the network they are embedded in. This is a very different claim than saying networks are nice to have. It says the network is a constitutive part of how value flows.

Wasko and Faraj (2005) connected this to IS directly, looking at knowledge contribution in electronic networks of practice. Their paper is in the local study library. They found that individuals who contribute knowledge in online communities are not primarily motivated by personal gain. They are responding to structural and relational capital: they contribute because of their position in the network (structural dimension) and because of their sense of obligation and commitment to the community (relational dimension). The cognitive dimension showed up in the finding that individuals with reputation in the community, those who were known and whose knowledge was trusted, contributed more and more useful content. The network was not separate from the knowledge-sharing system. The network was what determined whether the system produced value at all.

This challenges a basic design assumption that I think most IS projects carry without examining it. The assumption is that the information system provides the coordination mechanism. Build the platform, deploy the tool, connect the users, and the coordination follows. Social capital theory says that coordination through a system requires prior social infrastructure: you need structural connections between people, relational trust that makes people willing to share, and cognitive alignment that makes shared content meaningful. When that infrastructure is absent, people can log into the same platform and generate nothing useful.

The knowledge management system story at the top of this post is not a training problem. If the second hospital had weak relational capital between its clinical departments, trust between teams was low and people did not see each other as legitimate knowledge sources, then no amount of training changes whether clinicians contribute to a shared system. If the cognitive capital was low, if different departments spoke different clinical dialects, used different frameworks for understanding the same problems, then contributions from one group were not easily readable by another. The system could not fix those gaps. It could only surface them.

I keep thinking about this when I read analysis of why Slack changes communication in some teams and creates noise in others. Slack is a coordination tool. It provides structural connections: everyone is in the same channels. It reduces the friction of message passing. But it cannot manufacture relational capital. A team with high trust, shared norms, and a history of collaborative work will use Slack to do more of what they were already doing, just faster and more visibly. A team with low trust, unclear norms, and weak relationships will use Slack to generate more noise. The notifications multiply. The communication volume goes up. The quality of coordination stays low or gets worse because the signal-to-noise ratio drops. The structural affordance of the platform is the same in both cases. The relational and cognitive capital underneath are not.

Remote work created a version of this problem at scale. Distributed work destroyed weak ties, the low-intensity connections with acquaintances and professional contacts that generate most novel information and cross-team insight, while generally preserving strong ties with close colleagues. My read of the organizational research on this (and I need to verify the specific studies more carefully before citing them precisely) is that the loss of weak ties in distributed work is not primarily a communication problem. It is a social capital problem. Weak ties are where cognitive capital across groups gets built: you learn how other teams think, what terms they use, what problems they are working on. When those ties disappear, the cognitive dimension of social capital degrades. People in the same organization start operating with increasingly incompatible mental models of what the organization is doing.

This connects directly to what I wrote about absorptive capacity and why tools alone fail. Cohen and Levinthal (1990) argued that absorptive capacity, the ability to recognize, assimilate, and apply external knowledge, is path-dependent and cumulative. Prior related knowledge enables absorption. Social capital is one of the mechanisms through which that prior related knowledge becomes accessible. You can only absorb what flows through your network. If the structural dimension of your social capital keeps you away from certain knowledge sources, you cannot build the absorptive capacity to use what those sources produce, even if you acquire the tools that are supposed to carry that knowledge to you. The tool moves data across the system. Social capital determines whether that data becomes useful knowledge.

There is also a link to effective use and what faithful system engagement actually requires. Burton-Jones and Grange (2013) argued that effective use means engaging the deep structure of a system faithfully. That requires not just technical knowledge of the system but access to colleagues who share their practices, feedback on whether your use is producing the right outputs, and the trust to admit when your engagement with the system is not producing good results. All of these are relational capital. Effective use is not purely an individual cognitive achievement. It is embedded in the social structure around the user.

I think the IS field has treated the social structure around its systems as a background condition, something to be managed in the change management workstream, not something that fundamentally determines whether the system works. Social capital theory says it is the most important variable. The platform is a multiplier on existing social capital. If the capital is there, the platform amplifies it. If the capital is absent, the platform has nothing to amplify. That is why the same system, deployed in the same way, produces such different results in organizations with different histories, cultures, and relationship structures.

The IS evaluator who blamed training got the diagnosis wrong. The question was never whether people knew how to use the system. The question was whether the network around the system had enough trust, connection, and shared understanding for the system to do what it was designed for.