Boundary Spanning Role Identification¶

Why It Matters¶

Organizations are divided into functional silos, product teams, geographic regions, or business units. Most people interact primarily within their group. But some individuals—through their role, personality, or network—bridge boundaries: they translate between technical and business teams, connect headquarters with field offices, or link customer-facing and internal functions. These boundary spanners are disproportionately valuable: they transfer knowledge across silos, spot opportunities that require cross-group collaboration, and prevent coordination failures. But they're often invisible in formal structures because their value isn't captured in individual output metrics. When boundary spanners leave or are removed in reorganizations, coordination silently degrades.

The Key Move¶

Map organizational structure, then identify: Who do people in Group A go to when they need something from Group B? Who knows what's happening in multiple domains? Whose calendar is filled with meetings across organizational boundaries? Who gets pulled into cross-functional initiatives? These are your boundary spanners. Assess: If this person left, what connections would break? What knowledge transfers would stop? Then protect these roles: compensate them for boundary spanning work, don't overload them, and explicitly recognize their coordination value rather than penalizing them for appearing less productive in within-group metrics.

Classic Application¶

Tushman and Scanlan's research on R&D innovation. They found that high-performing R&D organizations had "gatekeepers"—individuals who read extensively outside the organization, attended conferences, and maintained external networks, then brought external knowledge into internal teams. These boundary spanners between external knowledge and internal practice were critical for innovation. Organizations that measured only internal productivity metrics (patents, publications, internal projects) didn't value gatekeepers and often lost them. Innovation subsequently declined not because internal talent left, but because the translators bringing external knowledge in had been de-prioritized.

Surprising Application¶

DevOps transformation. Traditional organizations have separate Development (build features) and Operations (run systems) teams with conflicting incentives and minimal communication. DevOps attempts to align them. The boundary spanners who make this work aren't necessarily DevOps evangelists or tool experts—they're people who understand both developer workflows and operational constraints, can translate between the groups' different languages and priorities, and have credibility in both camps. Organizations that identify these boundary spanners and empower them as bridges see successful DevOps adoption. Organizations that don't—relying on mandates or tools alone—experience persistent Dev/Ops conflict because no one is effectively spanning the boundary.

Failure Modes¶

Assuming boundary spanning is always beneficial—sometimes silos serve legitimate purposes and spanning them creates harmful backdoor coordination. Overloading boundary spanners—they become bottlenecks if too much crosses boundaries through too few people. Ignoring that boundary spanning can be political manipulation—some "coordination" is empire-building or information hoarding. Assuming you can just hire boundary spanners—they often become effective through accumulated context and relationships over time. Creating formal boundary spanning roles without actual boundary spanning work—the value comes from informal networks, not job titles.

Go Deeper¶

Tushman & Scanlan, "Boundary Spanning Individuals: Their Role in Information Transfer and Their Antecedents," Academy of Management Journal 24(2), 1981; Cross & Parker, The Hidden Power of Social Networks (2004).