Dependency Review Workshop¶

Ritual — instantiates Dependency Exposure

Puts maintainers, users, and domain experts in one room to surface the dependencies that live only in people's heads — the tacit handoffs and workarounds no document records — and to claim owners for them on the spot.

Some dependencies are written down; the dangerous ones usually aren't. The Dependency Review Workshop exists to reach the reliance that no diagram, registry, or contract can hold because it lives in people's habits: the informal handoff between two teams, the manual workaround someone runs every morning, the "just ask Priya" knowledge that keeps a process alive. Its distinguishing move is social elicitation — it treats the group's collective, tacit operational memory as the evidence source, and it converts what surfaces into two durable things before the room breaks up: recorded depends-on relations, and named owners who claimed them out loud. It is the mechanism for the dependencies that only a conversation can find.

Example¶

Before a national tour, a production company runs a Dependency Review Workshop: stage manager, head rigger, lighting and audio leads, the tour-bus coordinator, and a local-promoter liaison, all in one room walking a typical show day. Documents show a tidy schedule. The conversation shows what the schedule rests on: the load-in timing secretly depends on the head rigger's memory of which venues have low grid clearances; the pyrotechnics depend on a permit that one coordinator has always quietly filed the week before; and catering for the crew depends on an informal deal the tour manager renews by phone.

None of these appears in any plan, and each is a single-person dependency that would strand the show if that person were out. The workshop's value is that all three surface and leave the room owned: the clearance knowledge gets written into the venue pack, the permit process gets a documented backup filer, and the catering deal gets a second contact. What was tacit and fragile is now recorded and shared.

How it works¶

The workshop's distinctive contribution is reaching evidence no artifact contains, and it does so by structure, not luck: it deliberately assembles different vantage points — the people who build, run, use, and depend on the system — because each sees dependencies the others are blind to, and a reliance invisible from every seat but one only appears when that seat is in the room. The output is disciplined: each surfaced reliance is written down as a relation with a plain note on how it's known (who reported it, how sure they are), and — the step that makes the ritual stick — an owner is named while the person is present to accept it, rather than assigned later to someone who never agreed.

Tuning parameters¶

Room composition — who is invited. The workshop only surfaces dependencies someone in the room can see; omit the night-shift operator or the downstream team and their dependencies stay hidden.
Prompt structure — free discussion versus a guided walk through a normal (or worst) day. Structure surfaces the routine tacit handoffs that open brainstorming skips.
Psychological safety — how safe it is to admit "this only works because I do X manually." Low safety hides exactly the fragile personal dependencies the workshop exists to find.
Capture discipline — whether surfaced items leave the room as owned, recorded entries or as flip-chart notes that evaporate. This is the difference between a workshop and a vibe.

When it helps, and when it misleads¶

Its strength is unique reach: it is the only mechanism here that finds dependencies existing solely as tacit knowledge and informal practice — precisely the ones that documents, graphs, and SBOMs are structurally blind to. Naming owners live also makes the accountability far stickier than assignment in absentia.

Its weaknesses are those of any group ritual. It surfaces only what the assembled people know and are willing to say, so an absent viewpoint or a defensive culture leaves whole dependencies undiscovered, and confident consensus can manufacture false certainty about a reliance no one actually verified. It is also expensive and easily degenerates into an unfocused meeting whose findings evaporate without capture. The discipline is to compose the room for coverage, tag each finding with its evidence and confidence rather than treating group agreement as proof, and refuse to end until items are recorded and owned. It is especially the antidote to the bus factor problem — the reliance on one irreplaceable person^[1] — which no automated inventory will ever flag.

How it implements the components¶

dependency_map — it produces depends-on relations that no document held, drawn straight from the group's operational memory.
evidence_and_confidence_basis — it establishes the human-reported evidence class: each surfaced dependency is tagged with who knows it and how sure they are, the only basis available for tacit reliance.
owner_assignment — owners are claimed face-to-face while the person is present to accept accountability, which makes the assignment far stickier than a name added later.

It does not maintain the durable record those owners live in (Dependency Registry), rank the surfaced items by criticality (FMEA Dependency Table), or watch them over time (Critical Dependency Dashboard).

Instantiates: Dependency Exposure — the workshop is the archetype's human-discovery mechanism, reaching dependencies documents cannot.
Sibling mechanisms: Dependency Registry · Assumption Log · Architecture Dependency Review · Contract and SLA Review · Critical Dependency Dashboard · Dependency Graph · FMEA Dependency Table · Impact Analysis · Software Bill of Materials · Supply Chain Mapping · Vendor Risk Map

Notes¶

A workshop's findings are perishable: the tacit dependencies it surfaces must be written into a Dependency Registry the same day, or the ritual becomes a pleasant conversation that changed nothing. The workshop discovers; the registry preserves.

References¶

[1] The bus factor is the number of people who would have to be lost before a task or system stalls for lack of the knowledge only they hold. A bus factor of one is a pure tacit-knowledge dependency — invisible to every automated inventory and findable mainly by asking the people involved. ↩