Discouraged, Tolerated, Encouraged: How Your Culture Handles Bridging
In brief
Every organization handles cross-team help somewhere between discouraged, tolerated, and encouraged. How to tell which one you run, and how to make the favor economy visible without punishing the people who keep it working.
People use two routes to get cross-team work done. On the formal route, they submit a ticket, find funding, secure approval, and wait for a specialist. Meanwhile, someone uses a personal connection to get the work moving. They call a director, or find the person who can spare two hours a day. The specialist helps. The team makes progress.
People build a shadow system out of those relationships: a path for real work that rarely shows up in the formal process. It runs on horse trading and personal connections, and people with the right names in their networks move sooner than people with the right tickets. It can also produce something really beneficial to everybody. Any honest look at bridging has to keep that usefulness in view.
Bridging is one row in Ron Westrum's typology of how information moves through an organization, and the row has three settings: discouraged, tolerated, encouraged. I have worked in all three. (Ron Westrum, “A typology of organisational cultures,” Quality and Safety in Health Care 13, Suppl. II, 2004.) He built it from case material. Systematic tests since have gone both ways, and he said so himself.
Discouraged
A team needs help from a specialist group, so someone submits a ticket. The two teams may never talk directly; the requester takes whoever gets assigned, for whatever time the process allows. Work moves through a queue, not between people.
Contacting a specialist directly is a risk. A reach-out can turn into an escalation almost immediately. Before helping, the specialist may need a billing code or a manager's permission — and anyone who crosses the boundary anyway can get their “hand slapped” for working outside their job description, especially when nobody approved the time.
Managers protect what they own. Someone who helps across one of those boundaries looks like a rule-breaker, even when the crossing was exactly what the work needed.
Westrum connects good information flow with “problem solving, innovation, and inter-departmental bridging.” Discouraged bridging blocks more than a favor between colleagues. Sometimes the boundary is standing between urgent information, or specialized help, and the people who need it.
The polite version of discouragement is “Let me see what I can do,” followed by nothing. The procedural version is a ticket that produces an available specialist six months later, for a project that shipped without them.
Tolerated
A tolerated culture runs two systems at once. The official path: submit a request, wait, accept whoever gets assigned. A bounded exchange, on an approved route, with a stated limit.
The other path gets the work done. You know a friendly director. The director agrees to lend someone unofficially and tells the specialist to give the other team two hours a day. Nothing is written down. Both teams understand the arrangement sits outside the process. The help is real, and people benefit from it.
That path runs on relationships and standing. The right director in your network moves you sooner; the loudest requester gets served first. Horse trading beats the queue, and the quieter demand stays in it. A leader can read every approved request and still miss most of what actually moves through favors.
The backchannel gives the requester a named person, and the lending manager sets a narrow allowance. Nobody answers the capacity question: what comes off the specialist's plate?
Usually, nothing does. Nobody rebalances the specialist's work: they keep the whole original job and absorb the loan on top of it. An hour or two a day can also be too thin for someone to understand the other team's context and contribute meaningfully in the time available.
Rob Cross, Reb Rebele, and Adam Grant found the same concentration in organizational-network data. Across more than 300 organizations, 3% to 5% of employees accounted for 20% to 35% of value-added collaboration. Helpful people absorb a disproportionate share of the demand. That concentration is a reason to measure how much of a team's capacity cross-team demand consumes — the counting question this essay returns to below. (Rob Cross, Reb Rebele, and Adam Grant, “Collaborative Overload,” Harvard Business Review, January–February 2016.)
A blocked project starts moving, so the borrowing looks efficient. The lending team pays the unrecorded cost: planned work continues while interruptions arrive through private relationships. The borrowed specialist now carries both commitments. The original workload never shrank.
The stakes are usually a late project. Sometimes they are larger. Westrum observed that standard channels and procedures “are often insufficient in a crisis,” and his two contrasting cases show why. The fumbling that led to the loss of the shuttle Columbia “shows bureaucracy at its worst”: what the moment required could not move fast enough through the channels it was required to use. The Apollo 13 rescue is his “excellent example of a generative response”: people crossed departmental lines and used backchannels, and the information got where it needed to go.
Encouraged
Encouraged bridging feels different from the first ask. You reach out to another team: is anyone available? Teams mob on the same problem, or work in cross-functional groups, or keep connectors who maintain relationships between groups. The coolest places I have worked could shift people around or lend them out without a fight over budget or ownership first. It felt like one team solving one problem, and no part of it felt like a competition.
That takes real capacity. Some teams protect slack so they can respond. Some leaders cross-skill people, or automate enough recurring work to create room.
Leaders still need limits. I think people carry more cognitive load when everyone communicates with everyone all the time. A person with the right specialist in their network can keep skipping the line. Private fixes, applied repeatedly, let a team avoid ever addressing the recurring demand. Too much bridging covers up a deeper problem, one repaired symptom at a time.
Matthew Skelton and Manuel Pais make a narrower argument in Team Topologies. Drawing on cognitive-load theory, they focus on the amount a team owns and ask leaders to design team boundaries a team can carry. They put a time boundary around high-bandwidth collaboration, reserve clear service boundaries for ongoing work, and offer a separate facilitating mode for temporary help. A leader can use the framework to design team-to-team interaction without turning unlimited communication into the goal. (Matthew Skelton and Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow, IT Revolution Press, 2019; Skelton and Pais, “Key Concepts”.)
Helpful people can also stretch themselves too thin. A specialist welcomed onto three teams still has one person's capacity. A leader who lends someone needs to adjust that person's other commitments enough for the help to matter.
Different industries, domains, cultures, and histories produce different right answers here. There is no one right answer. Some leaders designate connectors. Some add cross-functional capacity, or put firmer routing around a specialist group. The judgment has to come from the demand and conditions in front of you.
The diagnosis
Permission status and raw volume tell a leader very little. The useful question: can the team see the work, and connect separate requests into a common demand?
The immediate help is real. A bridge can solve the problem in front of the team and hide a larger one at the same time.
Consider a team of ten. Each person has a different set of relationships across the organization. People from other teams contact all ten of them separately for help, and each person handles the request through a private connection. If nobody surfaces those requests to the other nine, the repeated need never reaches the backlog.
Because each instance gets fixed on the fly, the underlying demand never appears as work that deserves priority. Leaders decide with partial information because “not all of the work is actually visible.” Recurring work gets classified as one-off trouble; capacity gets committed without anyone seeing all the commitments. Ten people solved ten requests. The team saw ten unrelated favors.
When off-book help stays private, the backlog records only a portion of the team's work. A leader may believe the team has room because the cross-team assists are absent from the record. None of this requires carelessness. It does require a leader who never asks what the record is missing, and that part is a choice.
Susan Leigh Star and Anselm Strauss argued that work is never inherently visible or invisible; people see it through selected indicators that shift with context and negotiation. Their subject was not software delivery — the software reading is mine. Even when everyone updates the work they were asked to record, a backlog can omit coordination. A leader who chooses what to count and whose activity to expose is distributing exposure as well as information. (Susan Leigh Star and Anselm Strauss, “Layers of Silence, Arenas of Voice: The Ecology of Visible and Invisible Work,” Computer Supported Cooperative Work 8, 1999.)
Make the work visible
Let the bridging continue while the team begins observing it. You do not need to stop anything yet. You need to start getting data. On the board, put interruptions and off-board help beside planned work. Give each item a work type. For every item, record the team or source creating the demand and its volume, then capture enough of the capacity cost to understand its effect.
One sequencing caveat before any of this. In a culture where people already get their hand slapped for helping, measurement is not the first move — asking people to log the favors they are quietly doing, before it is safe to admit doing them, produces a clean and useless dataset. Safety comes first, then counting. A leader who cannot yet name which culture they run should assume they are earlier in that sequence than they think.
Count the work, not the people.
Eventually the count points at a person anyway: the data shows someone carrying far more cross-team demand than anyone realized. Make that a support conversation. What is on your plate? What can the team absorb? Should we cap how much of this comes to you? The aim is managing workload and lowering the odds that this person burns out — raw counts are a signal to investigate, never a scorecard, because too many factors sit behind them to rank people by. In a culture where crossing a boundary already earns a hand slap, a record of who helped whom becomes an enforcement list, and the first person named will be the last person to volunteer. Log demand, category, volume, and cost. Aggregate before anyone attributes. When the pattern finally does need a name, the name should hear an offer of help.
Record the work a board currently omits, too. A specialist who joins another team for part of the day, or handles an interruption, has taken on work. Once it gets recorded, teammates have a chance to notice that several people are responding to the same kind of request.
Dominica DeGrandis names unknown dependencies as one of five “thieves” of time that stay hidden until the work goes on a board. (Dominica DeGrandis, Making Work Visible: Exposing Time Theft to Optimize Work & Flow, IT Revolution Press, 2017.) The sequencing around it — safety before counting, aggregate before attribution — is my own, and she should not be blamed for it.
Once the work is visible, the team can ask where it comes from, what it implies, why it keeps happening, and what it costs. The response might change staffing, routing, automation, cross-skilling, or the official request path. The response might also be that the current bridging arrangement fits this context and stays. During the first pass, the team records the work without changing the arrangement.
Audit your own backchannels
Leaders participate in the same shadow system. Look without judgment at your backchannel work and the agreements you make off-process, then ask: “Are you using relationships to get stuff done? And if so, why do you need to do that? What's causing it?”
Treat your backchannel use as evidence about the conditions around you. When the official route moves too slowly, you reach for a relationship. When a team lacks a capability, it borrows one repeatedly. Your standing may give you access other people cannot use. Start the audit with your own behavior, because you can see the reasons behind your own choices.
Combine that self-examination with the team's record of cross-team work, and use the evidence to propose changes. People should be able to bridge while the activity and its impact stay trackable. Shape the proposal for this organization and this moment. Keep the useful crossings, and give the people making capacity decisions a way to see them.