Last week’s article examined what happens when a workflow changes. This week, we’re asking a different question: what happens when the workflow was never really ours in the first place? In many organizations, software isn’t supporting work; it’s actually defining it. The tool arrives with its own fields, states, steps, and approval logic, and users must adapt themselves to that structure. Much of what we’re calling workflow disruption starts there.
Vendors ship a model of work and present it as efficient and proven. Companies buy it only to discover that the “best practice” embedded in the software is more of a suggestion. It fits some cases, misses others, while struggling with local variation. When that happens, the tool usually stays put and the users do the adapting.
We can see the effects in the way that people change their behavior. They adjust when they ask for approval, how they enter information, how they document exceptions, even how they define the task. A manager who once handled exceptions in a conversation now has to figure out how to squeeze them into predefined dropdowns. An HR team delays action because the sequence that makes sense to the system clashes with payroll timing. The software doesn’t need to be broken for this to happen; it just has to be intransigent.
Research on workflow interruptions makes the cost easier to recognize. In multidisciplinary team settings, interruptions have been shown to change communication patterns for several minutes, increasing repetition and negative statements as people re-establish shared context.¹ A rigid tool can create a similar kind of interruption. It interrupts the natural flow by forcing users to stop, translate their intent into terms the system recognizes, and then check the next step. Those small breaks add up to friction that becomes part of the workflow.
Workarounds are the predictable response. When a system and a workflow don’t fit, people build structures around the system to make it usable: side spreadsheets, parallel notes, extra emails, clarifying chat messages, delayed data entry. Organizations sometimes read this as resistance but really, it’s simply an effort to repair the broken workflow. The workaround is how users keep things moving when the official tool is at odds with the needs of the users.
Adoption research helps explain what follows. A large meta-analysis of digital transformation efforts found that usefulness, ease of use, satisfaction, habit, and intention are among the strongest predictors of sustained use.² If a system makes work harder at the point of use, if its logic is opaque, or if it forces unnecessary steps, the organization should expect shallow adoption and heavy workaround behavior. Training may improve familiarity, but it won’t erase a poor fit.
This suggests that low adoption is often misdiagnosed. The default explanation is that users cling to old habits or lack information. While habit does matter, habits usually reflect the path that best fit the work once upon a time. People return to old methods because those methods still feel smoother in practice. A process can look efficient in a demonstration and still be awkward in context.
And this brings us to an interesting question: should software give users multiple ways to accomplish the same task? The research that looks at this tends to focus on workflow flexibility rather than interface variety. One useful distinction is between flexibility by selection and flexibility by adaptation. Flexibility by selection means the system offers different predefined paths for different situations. Flexibility by adaptation means the process model itself can be adjusted when reality does not match the original.³ A single, rigid path is rarely a good fit for knowledge work or exception-heavy domains.
But not all flexibility is equal. Giving users several identical buttons that do the same thing just adds noise. What helps is having distinct paths for distinct situations: a standard route, an exception route, a fast-track route. All serve the same business goal but reflect differences in timing, risk, or context. Studies of workflow flexibility support this kind of variation in domains where work can’t be fully systematized in advance.³ What they caution against is trying to encode every possible twist in advance or introducing complexity with no clear purpose.
The practical middle ground is to be deliberate about what must be rigid and what can be flexible. Most organizations can safely standardize a small core: key data, approvals with legal or financial weight, safety and compliance steps. Around that core, they can allow some flexibility. That might mean multiple predefined paths for different case types, the ability to adjust step sequences, or a lightweight way for teams to propose small workflow changes without rebuilding the system.
It looks like software development is moving in this direction. More platforms are designed to be configurable at the edge and easier to adjust without a full replacement. The goal isn’t to let every user rewrite the rules but to let the system share the effort of adaptation. When users are always the ones bending, the organization may get consistency in theory but, as noted above, a large amount of uncounted work in practice.
From that perspective, workflow disruption can be read differently. It’s often a signal that the software’s model of work and the real work have drifted apart. The follow-up question, then, is not just how to get users to adopt. It is whether the tool, in its current form, deserves adoption. When tools set the rules too rigidly, people adapt in the margins, through side channels and multiple little fixes. A more realistic stance would treat that adaptation as information and use it to bring the tool closer to the work it’s meant to support.¹ ² ³
Citations
- Janssens & Brüggen – Workflow interruptions and team communication
“The impact of workflow interruptions on multidisciplinary team communication in hybrid healthcare settings.” Group & Organization Management, 2024.
https://research.tilburguniversity.edu/en/publications/the-impact-of-workflow-interruptions-on-multidisciplinary-team-co - Cavalcanti, Oliveira & Santini – Drivers of digital transformation adoption
“Drivers of digital transformation adoption: A weight and meta-analysis.” Heliyon, 2022.
(PubMed entry) https://pubmed.ncbi.nlm.nih.gov/35198776/
(Publisher / full text) https://www.sciencedirect.com/science/article/pii/S2405844022001992 - Georgakopoulos, Hornick & Sheth – Workflow flexibility
“An overview of workflow management: From process modeling to workflow automation infrastructure.” Distributed and Parallel Databases, 1995.
https://api.semanticscholar.org/CorpusID:446699
