The person missing from the diagram
The diagram shows a handoff. Someone still has to chase it, check it and make it happen. How to design for the human work your system depends on.
A handover can be marked complete while the receiving team is still missing the information it needs. The diagram shows an arrow. Someone still has to make a call, explain the case and check that the right person has picked it up.
That work is easy to leave out of a system model. So are the extra checks, remembered promises and small corrections that stop a routine case becoming a problem.
I recognise the person who stays with the case until it makes sense. When I draw the system, I want to show what that person contributes and what would happen without them.
The applications and data are only part of the story. The handoff also depends on attention, context and someone with time to act.
What a clean arrow hides
A diagram has to simplify. The question is whether it leaves out details the reader can safely ignore or work the outcome depends on.
“Review sends the case to operations” may require several steps: clarify the decision, check the evidence, find the owner, reconcile two case numbers and confirm receipt. If these regularly need human effort, the model should make that effort visible.
Susan Leigh Star and Anselm Strauss argued that work is not simply visible or invisible by nature. Visibility depends on what a setting knows how to represent, what its measures can detect and whose account is allowed to describe the work. This makes invisibility a systems question, not only a question of personal appreciation.
A handoff is not a line. It is work.
The arrow records the intended transition. The middle reveals the coordination required to make that transition true.
The work of making work work
This connective activity has a name. Sociologist Anselm Strauss called it articulation work: the work required to align, sequence, negotiate and reconnect all the other work when interdependent activities do not join themselves together. Later research in computer-supported cooperative work asked what it would mean for software to support this activity rather than treating it as noise around the “real” process.
Calling this “helping” can make it sound optional. When a case cannot move without it, it is part of the workflow and needs support.
Five actions help me look for it:
- Notice: detect that the formal state and the surrounding reality do not agree.
- Translate: carry meaning across teams, terminology and systems without flattening it.
- Remember: preserve history, promises and exceptions that have no dependable home.
- Repair: restore a broken handoff before it becomes a visible failure.
- Absorb: hold the uncertainty and emotional weight while everyone else sees a normal result.
The work of coordinating work belongs in the architecture
Plans do not perform the work
Lucy Suchman's work on situated action helped me understand why the process and the performance of the process can never be identical. A plan can orient action. It cannot determine every action in advance, because people encounter particular materials, histories and social circumstances while doing the work.
A process can guide the work while leaving room for the situation in front of someone. A missing document or an earlier promise may change what the next sensible step is.
If the same detour keeps happening, investigate it. It may show that the process is missing a routine case.
The same intended outcome, two different accounts of the journey
Knowing before the knowledge becomes a rule
Sometimes I question a number before I can explain exactly why. That feeling should not be treated as proof; experience can be wrong. But it should not be dismissed simply because it has not yet become a validation rule.
Michael Polanyi's account of tacit knowledge describes a familiar feature of skilled practice: we can know more than we can immediately state. Donald Schön later wrote about reflection-in-action, the thinking a practitioner does while an uncertain situation is unfolding and “talking back.” Both ideas give language to the space between a documented rule and an unsupported guess.
Ask the experienced person to work through examples. Which detail made them pause? What did they compare it with? Which cases would change their decision? Capture what can be shared and keep a review route for the judgement that remains.
From explicit rule to acknowledged uncertainty
Why quiet competence disappears
Preventative work can be difficult to see because the problem never becomes an incident. Someone corrects the number or catches the missing approval before it reaches the customer.
Stephen Graham and Nigel Thrift place repair and maintenance at the centre of how infrastructure continues to function, even though accounts of technology often give their attention to invention and breakdown. Invisible repair has a similar problem inside an organisation: the better it works, the easier it is to believe it was never needed.
Successful repair can hide the fragility it prevented
“She always sorts it out” can hide a dependency. If one person holds the history and knows every workaround, the team needs a way to share that knowledge and reduce the repeated repairs.
Otherwise, colleagues cannot learn from decisions they never see. The workload stays hidden, and an absence can expose a gap nobody has planned for.
Attention is part of architecture
Iris Murdoch was not writing about software architecture, but her philosophy of attention offers a useful challenge. She treated attention as a disciplined effort to see particular reality rather than forcing it into the picture we find convenient.
When I review a model, I look for the work that does not fit its categories. What is someone checking or remembering outside the system? Why does the case need that extra attention?
That does not mean treating a person's attention as an unlimited operational resource. Joan Tronto's work on care asks us to notice how necessary caring activity is distributed and valued. In a system, somebody's memory, vigilance and willingness to intervene cannot remain the free capacity that makes an incomplete design affordable.
I want that question to become part of every important handoff I model. Who notices that the transition has not really happened? Who has enough context to question it? Who has authority to act? Where does the reason for an intervention live? What happens when that person is unavailable?
Share the work and support the judgement
Making this work visible should help the people doing it. Record recurring repairs, improve the handoff and spread critical knowledge. Avoid turning the exercise into monitoring every small action.
The practical changes include:
- showing exception and recovery paths alongside the happy path;
- expanding consequential arrows into the coordination they require;
- marking judgment points instead of disguising them as automatic decisions;
- recording recurring repairs as evidence for design improvement;
- naming who has the information, authority and time to intervene;
- pairing or rotating critical knowledge so it does not remain private;
- preserving human overrides where context carries real weight; and
- asking the people doing the work whether the diagram describes actual work or only prescribed work.
This is a socio-technical design problem. Gordon Baxter and Ian Sommerville argue that organisational change and technical development cannot be treated as separate systems-engineering concerns. The software, the work, the authority and the learning mechanism have to be designed together.
Resilience means sharing what the system depends on
Try it: review a handoff before automating it
Use a handoff review to find the responsibility hidden inside an arrow. The useful result is an agreement about the work, including what happens when the usual person is away.
How to try it. Use this as an interview worksheet or paste it into a chat to analyse the fictional notes. Validate the result with the people who own the real process before applying it.
Handoff review worksheet
Included file: handoff-review.txt
Full prompt
CASE NOTES — FICTIONAL
[H1] Client services sends a request marked “ready” to Operations.
[H2] A coordinator checks that all six files are present and belong to the right client.
[H3] If a file is unreadable, the coordinator calls the client, explains the problem
and agrees when a replacement will arrive. The application records only “pending”.
[H4] The operations lead can accept a documented exception; the coordinator cannot.
[H5] When the coordinator is away, colleagues use a shared inbox. No backup is named.
REVIEW
For each step, record: trigger, evidence needed, responsible role, permitted
decision, output, recipient, deadline or escalation trigger, and backup role.
Cite H1–H5 for facts. Mark missing agreements as unresolved.
DELIVER
A handoff contract defining what “ready” promises; a list of decisions requiring
human authority; and three interview questions that would change the design.
Separate a proposed backup arrangement from one already agreed.
Do not assess individual employee performance or silently assign new authority.What your result should show
- “Ready” has an explicit evidence condition; a pending label alone does not preserve the client’s replacement commitment.
- The coordinator can request clarification, the lead decides exceptions, and backup ownership remains unresolved until agreed.
Change one condition
The replacement arrives after the coordinator’s shift ends. Trace how the next person learns what was promised, what changed and what they are authorised to decide.
Drawing the system again
When I redraw the system, I want the human work to be specific enough to support: who checks, what they need, what they can decide and who takes over when they are away.
The diagram can stay simple. Add the judgement points and recovery routes that matter, and link to examples where more context is needed.
Then walk through it with the people doing the work. Ask whether a case can really move as drawn, including when something goes wrong.
Who is still doing essential work that the diagram does not show?
Takeaways
- Ask who makes each important handoff happen and what they need to do it.
- Record the recurring checks, decisions and recovery routes the system leaves out.
- Share critical knowledge and plan who takes over when the usual person is away.
REFERENCES AND FURTHER READING 10 sources
- Layers of Silence, Arenas of Voice: The Ecology of Visible and Invisible Work Susan Leigh Star and Anselm Strauss, Computer Supported Cooperative Work 8, 1999, pp. 9–30 Shows that work is not inherently visible or invisible; visibility depends on how an organisation represents, measures and values it.
- The Articulation of Project Work: An Organizational Process Anselm Strauss, The Sociological Quarterly 29(2), 1988, pp. 163–178 Names the coordination, alignment and recovery work required to keep interdependent activities moving.
- Taking CSCW Seriously: Supporting Articulation Work Kjeld Schmidt and Liam Bannon, Computer Supported Cooperative Work 1, 1992, pp. 7–40 Connects articulation work directly to the design of systems that support cooperative work.
- Human–Machine Reconfigurations: Plans and Situated Actions Lucy Suchman, 2nd edition, Cambridge University Press, 2007 Explains why plans orient action without determining everything people must do in a real situation.
- The Tacit Dimension Michael Polanyi, University of Chicago Press, 1966; reissued 2009 A philosophical account of skilled knowledge that exceeds what a person can immediately state as a formal rule.
- The Reflective Practitioner: How Professionals Think in Action Donald A. Schön, Basic Books, 1983 Describes how practitioners think within uncertain situations and respond when the situation answers back.
- Out of Order: Understanding Repair and Maintenance Stephen Graham and Nigel Thrift, Theory, Culture & Society 24(3), 2007, pp. 1–25 Places maintenance and repair at the centre of how infrastructure continues to function.
- The Sovereignty of Good Iris Murdoch, Routledge Classics, 1970 Provides the philosophical lens of attention as the disciplined effort to see particular reality more truthfully.
- Moral Boundaries: A Political Argument for an Ethic of Care Joan C. Tronto, Routledge, 1993 Examines how necessary care is recognised, valued and distributed rather than treating it as an unlimited private resource.
- Socio-technical Systems: From Design Methods to Systems Engineering Gordon Baxter and Ian Sommerville, Interacting with Computers 23(1), 2011, pp. 4–17 Connects organisational change and technical development as one systems-design problem.