Social Network Analysis

Purpose

Every company has two architectures: the boxes on the CTO's PowerPoint and the real web of people trying to get work done every day. Social Network Analysis measures the second one. It is graph theory applied to human interaction. SNA exposes the real bottlenecks, hidden influencers, workforce single points of failure, and teams that are starving in isolation.

Context of Use

Use SNA before any major agile reorganization, such as adopting a Spotify-like model, or before a central architecture board pushes developer tribes into new domain silos. If the system architecture is split into microservices but the teams still need to stay socially welded together, SNA will show that the plan is heading for bloody failure within weeks.

Step by Step

1.Scan the network: Gather data from surveys, Slack metadata, or Git collaboration. Ask, "Who do you go to when your team lacks the expertise to solve a technical issue?"

2.Draw the graph: Every employee or team becomes a node. Every interaction becomes an edge.

3.Measure centrality: Find the nodes with the most incoming and outgoing connections.

4.Identify brokers: Find the people who act as the only bridge between otherwise isolated departments.

5.Check the periphery: Who is hanging at the edge of the graph with almost no connections?

Example

An architect draws an SNA graph for a one-hundred-person backend department. The official model shows ten autonomous squads of ten people. The SNA graph looks like a giant chaotic ball of yarn. Nearly every arrow for database-migration questions points to one developer: Sarah. Sarah is the true broker and knowledge bottleneck of the company, even though on paper she is just another developer in Squad 3. The diagnosis is brutal: if Sarah goes on vacation, department-wide delivery velocity drops by fifty percent. The architecture response is not to hire more people blindly but to build the database knowledge around Sarah into the system.

Diagram

How Diagnosis Turns into Action

Software engineers often ignore sociology. SNA forces them to understand that code is written by networks. If the network is broken, the code will be broken too. Networks often contain structural holes, places where two teams ought to communicate because their services are tightly coupled, but no connection exists in the social graph. If you diagnose that hole early, you can predict that the API contract will fail under deployment stress.

When This Method Fits Best

Dependency Mapping measures hard technical coupling such as "my API call depends on yours." SNA measures the softer layer of human collaboration: who gives advice, who blocks ideas politically, and where hidden coordination burden lives.

How to Use the Diagnosis in Everyday Work

In architecture meetings, destroy the illusion that "the Ops team" talks to "the Dev team." Teams do not talk. People do. Run regular pulse checks in informal settings and ask: "If your service catches fire tonight, who is the person you message privately on Slack even though they are not on call?" That is where your hidden load structure lives.

First Analysis Steps

Do not mistake centrality for productivity. A developer who sits at the center of the SNA graph is often not a hero but a symptom of a dysfunctional architecture that needs constant manual coordination instead of clean self-service interfaces. The best architectures produce open, loosely coupled social graphs, not dense balls of yarn.

How You Recognize a Useful Diagnosis

When defining Domain-Driven Design bounded contexts, did you check whether the proposed team boundaries actually align with the real communication boundaries visible in your social network?

Sources

Rob Cross & Andrew Parker — The Hidden Power of Social Networks (Harvard Business Press, 2004)

Valdis Krebs — Social Network Analysis (OrgNet)

Wikipedia: Social Network Analysis