Shirked, Narrow, Shared: Where Your Culture Puts the Risk

Published October 7, 2026

Part 3 of The Generative Culture Series

A team's project depends on a firewall change owned by one group, a ServiceNow page that a second group has to create, hardware that a third has to cable and power up, and permissions held by a fourth. The team cannot finish until all four deliver.

If any one of them slips, who is exposed? The team waiting for the firewall change still has a delivery commitment. The group that controls the change has made no commitment to the date the team is working toward. The dependency ties the two groups' work together, but the consequences of a slip land on only one of them.

Ron Westrum, whose research on safety ran through aviation and health care, sorted organizational cultures into three types: pathological (power-oriented), bureaucratic (rule-oriented), and generative (performance-oriented). His table describes how each handles responsibility: “Responsibilities shirked,” “Narrow responsibilities,” and, in a generative culture, “Risks are shared.” (Ron Westrum, “A typology of organisational cultures,” Quality and Safety in Health Care 13, Suppl. II, 2004.) I read that last phrase this way: every group owns its piece as part of the whole, and answers for what its piece does to the whole.

Shirked

In a pathological culture, you need someone to take responsibility for a piece of work, and every attempt to put a name on it meets resistance. The request gets routed, deferred, or returned with a condition that puts the next move back on you. The work still has to be done, and nobody will own the outcome.

Westrum puts it this way: “Pathological environments will discourage taking responsibility, and can be expected to conceal their problems.” Accepting responsibility puts your name in the one place everyone else is working to keep theirs off, so people spend more effort avoiding that position than doing the work.

Concealment follows from the same logic. In a culture organized around personal power, a problem with your name on it is a liability, and the safest response to an early sign of trouble is to make sure nobody hears of it. Westrum notes that suppression appears to be a defining trait of pathological environments. Apply that to the firewall change. If it slips, the owner's safest course is silence, and the waiting team learns of the delay when the date passes.

Narrow

In a narrow culture, the group that owns the dependency gives a more orderly answer. Submit a ticket, and we'll get to it when we can. Or the work goes to next quarter, once somebody funds it. Each answer comes with a process, and each leaves the waiting team to explain the delay against its own commitment. So the waiting team follows the process and plans around the date it expects the work. When the date arrives, the answer is a shrug: resubmit the request, or keep waiting. The date carried little weight with the owning group, and the waiting team replans around a priority call it had no part in making. I have been on the waiting side of that shrug more than once: a date my team was counting on, a dependency my team could not touch.

The specialists on the owning side are usually competent and busy with necessary work. Everyone is focused on their own area, with little view of how their choices land on other teams. The firewall change is one item in one queue. The ServiceNow page is an item in another. The cabling belongs to a third. The waiting team experiences the three as one risk; the organization handles them as three unrelated tasks.

In bureaucratic organizations, Westrum observed, thinking “may stop at the department's boundary because what is beyond it is 'not my concern', even though it may be of great concern to the mission.” A team can take its assigned responsibilities seriously and stop caring at exactly that line. Everything beyond the line becomes the waiting team's problem.

Experts often help across the boundary and still leave the risk where it was. They answer questions and explain what has to happen with their own part. Under the courtesy, the message is: we'll help, but it's your problem. The waiting team comes away better informed and no less exposed.

Each owner can explain the status of one part. The waiting team has to answer for all of them together: its obligation runs across every part, and its authority stops at the edge of its own.

The groups then meet to settle whose problem the delay is. Each documents the limit of what it agreed to do. The waiting team needs the work finished and spends the meeting arguing that anyone else should share the risk. Even a successful negotiation leaves the next dependency open to the same dispute.

Shared

A specialist team in a shared-risk culture still owns its specialist work. It also knows what other groups are counting on and what its timing makes possible for them. When a dependency is in trouble, the owning group has a problem to solve alongside the waiting team, because its responsibility does not end where its own part does.

Under shared risk, the owning group's offer of help comes with names. It tells the waiting team who is available from its side and commits to doing what it can to unblock the work. The names show that the owner has taken a share of the date. The two groups can then hold a working session where a narrow culture would hold a negotiation: the owning group brings what it knows about its part and its limits, the waiting team brings what the delay will cost, and because both are exposed to the result, the conversation can move beyond defending the original request.

A dependency that slips is then a miss for both groups. The miss is scored jointly; each group still does its own job. Shared ownership also differs from hero culture, in which one person repeatedly rescues a commitment everyone else has disclaimed. When the goal is common, each team has a reason to support the people whose work it depends on, and each person can count on colleagues to help carry a problem that outgrows their contribution. Across the projects I have been on, that is the version of shared risk that held: experts in one area helping the experts in another and owning the risk together.

Belonging does part of this work. “A sense of ownership,” Westrum wrote, “is a natural consequence of identification with the leaders and the team.” DORA, the research program that adopted Westrum's typology for software delivery, applies the idea in its “Share risks” practice: quality, availability, reliability, and security are everyone's job, including developers' responsibility for how their code behaves once customers are using it. (DORA, “Generative organizational culture”.)

The slogan gap

I have seen organizations describe themselves as blameless and collaborative while every silo kept its own reporting line and its own incentives. When a dependency slipped, the conversation still ended in fault-finding. People could endorse shared responsibility sincerely and still be managed in ways that kept the risk on the waiting team.

DORA's culture survey carries the statement “On my team, responsibilities are shared.” (DORA, “Generative organizational culture”.) The statement stops at the team's edge. A team can agree with it honestly, sharing responsibility generously among its own members, while the risk from work outside the team arrives at its door.

Edgar Schein observed that in U.S. organizations “it is common to espouse teamwork while actually rewarding individual competitiveness.” (Edgar H. Schein with Peter A. Schein, Organizational Culture and Leadership, 5th ed., Wiley, 2017, ch. 2, “The Structure of Culture.”) Steven Kerr made the companion point in the title of his 1975 paper, “On the Folly of Rewarding A, While Hoping for B”: organizations hope for one behavior and reward another, and the reward tends to win. (Steven Kerr, “On the Folly of Rewarding A, While Hoping for B,” Academy of Management Journal 18, no. 4, 1975, 769–783.)

Managers hold the slogan gap open every time they accept “our part is done” as a complete answer while the work that depends on it is still stuck. A team's commitment reaches exactly as far as its reporting line. Shared risk means the owning group's result includes what its work does to the team waiting on it, even when counting that is inconvenient. The next time a dependency slips, notice whose date moves.

Shared measurement

A group can meet every measure attached to its own work while the team depending on it fails. In my experience that is the usual reason risk stays unshared: each group has its own numbers and its own definition of done. Under a shared measure, the failure belongs to both.

DORA's research on software delivery metrics makes the same point. Reporting them across the teams that build, run, and release software fosters collaboration and shared ownership; giving each team its own metrics can lead to friction and finger-pointing. (DORA, “DORA's software delivery performance metrics”.) “We'll help, but it's your problem” is what that measurement produces. A team can sincerely want to help and still be judged in a way that leaves the other team's failure as someone else's problem.

Google's site reliability engineers built a shared measure of this kind and published it. Product developers are judged on how fast they ship. Reliability engineers are judged on whether the service stays up, and they carry the pager, the duty to respond at any hour, when it goes down. The error budget gives both groups one number: how much failure the service may have in a quarter and still meet its availability target, which Google calls its service-level objective. While the budget lasts, developers can take risks. As it runs down, they slow releases and add testing themselves, because an empty budget would stall their own launches. Google's Site Reliability Engineering says the budget “removes the politics from negotiations” over how much risk to allow. (Google, Site Reliability Engineering, ch. 3, “Embracing Risk,” O'Reilly, 2016.)

In a dependency the party whose decisions create the risk should carry a share of the consequence, the way the developer whose launch can set off the pager does at Google; here that party is the owner whose slip lands on the waiting team. The book names the condition, too. The mechanism works because the reliability team has the authority to stop launches when the target is missed, and a shared number without that authority is one more report about the risk. Teams with different work need different instruments. A group waiting for cabling needs something simpler: the people responsible for the cabling carrying a share of the date.

What to do

Start with where the risk currently sits. In a culture where putting your name on a date is dangerous, none of what follows comes first; safety does. Everywhere else, put the dependency's date on the owning group's plan as well as the waiting team's, so a slip shows up as the owner's miss too. I have seen that done a few ways, and not often. Target dates carried on both teams' plans, which sometimes works. A shared objective both teams are judged on, in an organization that had not yet learned to run objectives well. Program-level measures of what was committed and delivered, and how old the waiting work had grown, inside a quarterly planning cycle that put the dependent teams in one room. Any of these works if the owner's number moves when the waiting team's date does.

Make each group's commitments explicit to the groups that depend on them, and the stakes of a slip explicit to the group that might cause one. Keep the dependencies visible, so the owner sees a date at risk before the waiting team has to explain a miss. Where a team has the knowledge and the authority to decide, remove the sign-off gates that stop it acting on an outcome it owns; where a control cannot be waived, say so early and plan around it.

When the owner's queue and the waiting team's date collide, somebody has to decide. In most places I have watched, the decision goes to whatever has the biggest impact, or to the highest-paid opinion in the room, or to a vice president's number. That is not always the best call. Where it worked, the owning group understood its own queue and knew its partner teams well enough to see when something was needed and what a miss would cost. It would deprioritize its own work to meet a hard date: a regulatory requirement, an audit deadline, a consequence with money attached. The other half was the waiting team understanding its own work well enough to say plainly what it needed and why, advocating for itself, and still giving ground in places. Both halves are one habit, each side treating the other's deadline as partly its own.

A late ask gets a question before it gets a verdict. Thank the person who raised it, then ask why it came so late. Sometimes it was late for everyone. Sometimes the system let it happen, which is a question for the people who own the system. Sometimes a person made a mistake, and the owning group has to decide how it handles that moment too.

An ordinary day

On an ordinary day under shared risk, the owner of the firewall change calls the waiting team while there is still time to work on the date. The call comes with help attached: who on the owner's side can work the problem, and when. The waiting team still has a hard conversation ahead, but it arrives with a plan, and nobody spends that conversation establishing whose problem the delay is.

Back to Field Notes