Ninety-five percent of executives report that roles and team structures are changing because of AI. Most internal software was built around the previous shape, and software encodes assumptions about who does what far more rigidly than an org chart does.
The result is quiet and expensive. The tool assumes a handoff between two roles that have merged. It requires an approval from a position nobody holds. It presents a queue organised around a division of labour that stopped existing last year. People work around it, and the workaround becomes the real process while the system records a fiction.
Software encodes an organisation more firmly than policy does
A policy document describing who approves what can be updated in an afternoon. A system enforcing it through permissions, states and required fields cannot.
That rigidity is usually deliberate and useful. It is what stops people skipping steps. It also means every organisational assumption baked in at build time keeps being enforced long after the organisation stopped agreeing with it.
Three specific places this shows up. Permissions modelled on job titles rather than on what someone needs to do. Workflow states matching a handoff sequence between teams. Required fields that made sense when a specialist filled them in and now block a generalist who does not have the information.
Each was correct when written. None updates itself.
The workaround is the symptom worth reading
When a tool no longer fits, people do not usually complain. They adapt, and the adaptations are informative.
A shared login because the permission model has no category for what someone now does. A spreadsheet running alongside the system because the system cannot represent the current process. Records created with placeholder values to get past a required field. Work tracked in a chat channel and entered into the system afterwards, in bulk, inaccurately.
These get treated as discipline problems and they are design feedback. Nobody maintains a parallel spreadsheet for enjoyment. They do it because the sanctioned path stopped working and nobody asked them.
The data consequence follows. Once the real work happens elsewhere, the system holds a summary reconstructed after the fact, and every report drawn from it is wrong in ways that are impossible to detect from inside the report. We described the same mechanism in a sales context in why CRM adoption fails.
The spreadsheet beside the system is the artefact we look for first. It never comes up in a requirements conversation and it describes the actual process more accurately than any documentation does.
Read More - Your SaaS Pricing Model Is Breaking. Both Ends of It.
Design around the work, not the job title
The durable fix is to model what happens rather than who does it.
A permission system built around actions survives reorganisation. Someone who can approve expenses up to a limit is a capability that can be granted to whoever holds it this year. A permission system built around a title needs rewriting every time the titles change, and titles now change often.
Workflow states should describe the state of the work rather than whose desk it is on. "Awaiting technical review" is durable. "With the platform team" is a fact about last year's structure that becomes misleading the moment the team is renamed or merged.
Required fields deserve periodic scrutiny for the same reason. Each one was added because somebody needed it, and some of those people left, and their reports stopped being produced years ago. The field remains, and people put anything in it to continue.
What changes when agents are among the users
There is a newer version of this problem that most internal tools have not encountered yet.
If an agent is going to perform part of a workflow, it needs the same things a person needs: a way to authenticate, a scope of permitted actions, and a record of what it did. Most internal systems have no concept of a non human actor, so the agent runs as somebody's account, and the audit trail says a person did something they have never heard of.
That is fixable and much easier to design in than to retrofit. Give agents their own identities, scope them to actions rather than roles, and make the audit trail distinguish them. It costs little at build time and is genuinely difficult once a system has been running for three years on the assumption that every actor is a person.
A review worth doing annually
Take your most used internal tool and answer three questions with the people who use it daily rather than with the team that owns it.
Which steps do you skip or work around, and what do you do instead. Which fields do you fill in with something meaningless to proceed. What do you keep outside this system, and why.
The answers map exactly onto where the software has drifted from the organisation. Most of it is fixable cheaply once seen, and almost none of it reaches the owning team through normal channels, because working around a tool does not feel like something worth raising.
The same shift shows up in delivery, where the bottleneck has moved rather than disappeared, covered in which phase now takes longest.
If your internal systems were built around a structure that has since changed, our enterprise tools work usually starts here rather than with a rebuild, because most of these are configuration and modelling problems rather than replacement projects.
We find the gap between the role a system assumes and the role somebody performs widens quietly, a little each year, until a new starter cannot be trained on it. Nobody notices because everyone present adapted gradually.
Frequently Asked Questions
How do we know our tools have drifted?
Look for parallel spreadsheets, shared logins, and fields containing obvious placeholder values. Each is someone solving a problem the software created. They are reliable indicators and they never arrive as formal feedback, so you have to go and look.
Is it cheaper to reconfigure or rebuild?
Reconfigure, in the large majority of cases. Most drift is in permissions, workflow states and required fields, all of which are usually configurable. Rebuilds get chosen because the frustration is high, and they frequently reproduce the same rigidity around the current structure, which will also change.
Should permissions be based on roles at all?
Roles are a convenient way to group capabilities, so long as the underlying model is capabilities. The failure is when the role is the permission, with no way to grant one part of it. Model what someone may do, then bundle those into roles for convenience.
How often should we review internal tools?
Annually as a baseline, and after any reorganisation. A structural change is exactly the moment tools stop fitting, and it is also when nobody has time to look, which is why the mismatch persists for years.
Our users say the tool is fine. Should we believe them?
Ask what they do rather than what they think. People adapt and stop noticing, and a workaround performed daily for a year becomes invisible to the person doing it. Watching someone complete a task reveals more than any survey.
How do we handle agents in a system that assumes humans?
Give them distinct identities rather than borrowing a person's account, scope them to specific actions, and make the audit trail record which actor did what. Retrofitting this is unpleasant, so it is worth doing at the first agent rather than the fifth.
What if the process itself is unclear?
Then that is the finding, and it is a good one. Software cannot resolve a process nobody agrees on; it will simply encode whichever version the loudest person described. Establish the process first, on paper, with the people who perform it.
Talk to our team if your internal tools were designed around a structure your organisation no longer has.