Brilliant post. Forensic analysis of the edges to much work where entropy is born and multiplies rapidly. Combined with this I would add the tendency of functions to specialise as organisations grow, increasing fragmentation and potential handoffs because each unit is more narrowly specialised. As organisations grow, either naturally or through M&A, the fabric of these interconnections are more and more vulnerable. Few leaders actively focus on what it takes to build something that lasts rather than delivers in the short term
One element I think needs more attention on the boundaries is human aspect. Things like trust, “us against them” mentality, politics. All these can sabotage the best process design interventions.
Really enjoyed this — especially the “integration paradox” framing and the concrete failure modes (semantic mismatches, responsibility gaps, queues, signal loss).
One nuance I’d separate a bit more: boundary as interface vs boundary as system-definition. Interfaces/handoffs are where risk concentrates — but “system boundaries” are also the lines we draw around what counts as the system (and therefore what becomes invisible, unowned, and unmeasured). When those two meanings blur, it can sound like the risk is in the connections by default, while in practice the risk is often produced by the way accountability and visibility are bounded.
A helpful add-on lens here is “boundary objects” — shared artifacts (forms, schemas, checklists, handoff templates) that different communities interpret differently, yet rely on to coordinate. Designing the boundary often means designing/maintaining those objects, not just monitoring queues.
Also: I like the point about informal workarounds — I’d treat them not only as risk accumulators, but as diagnostic signals of a mismatch between “work-as-imagined” and “work-as-done”. Making workarounds observable can be a fast way to locate the real boundary that the org is actually operating on.
If you ever turn this into a checklist, I’d love to see a two-layer map: (1) operational handoffs/interfaces, and (2) modeling/accountability boundaries (who/what is out of scope) — because the nastiest failures often happen when those two don’t align.
I like the idea of work around as diagnostic signals. Great idea thanks for sharing!
Brilliant post. Forensic analysis of the edges to much work where entropy is born and multiplies rapidly. Combined with this I would add the tendency of functions to specialise as organisations grow, increasing fragmentation and potential handoffs because each unit is more narrowly specialised. As organisations grow, either naturally or through M&A, the fabric of these interconnections are more and more vulnerable. Few leaders actively focus on what it takes to build something that lasts rather than delivers in the short term
One element I think needs more attention on the boundaries is human aspect. Things like trust, “us against them” mentality, politics. All these can sabotage the best process design interventions.
Yes totally agree
Really enjoyed this — especially the “integration paradox” framing and the concrete failure modes (semantic mismatches, responsibility gaps, queues, signal loss).
One nuance I’d separate a bit more: boundary as interface vs boundary as system-definition. Interfaces/handoffs are where risk concentrates — but “system boundaries” are also the lines we draw around what counts as the system (and therefore what becomes invisible, unowned, and unmeasured). When those two meanings blur, it can sound like the risk is in the connections by default, while in practice the risk is often produced by the way accountability and visibility are bounded.
A helpful add-on lens here is “boundary objects” — shared artifacts (forms, schemas, checklists, handoff templates) that different communities interpret differently, yet rely on to coordinate. Designing the boundary often means designing/maintaining those objects, not just monitoring queues.
Also: I like the point about informal workarounds — I’d treat them not only as risk accumulators, but as diagnostic signals of a mismatch between “work-as-imagined” and “work-as-done”. Making workarounds observable can be a fast way to locate the real boundary that the org is actually operating on.
If you ever turn this into a checklist, I’d love to see a two-layer map: (1) operational handoffs/interfaces, and (2) modeling/accountability boundaries (who/what is out of scope) — because the nastiest failures often happen when those two don’t align.
Much obliged.