Ask anyone in an organisation how they first used AI and you will hear the same answer. They used it to get rid of something they hated doing. The report nobody wanted to write. The email that required five drafts. The meeting notes that took longer to type up than the meeting itself. This is a reasonable start. It is not where the value lives.
The Task You Hate Is Not the Prize
The instinct to offload unwanted work is rational. Nobody likes writing status updates or summarising documents they barely read. AI handles both without complaint. But this use of AI is substitution. It replaces a known quantity with a faster version of the same thing. The output is the same. The process is slightly quicker. The value captured is small.
There is a second category of AI use. It is less discussed, more powerful, and it changes what individuals inside organisations are structurally capable of. Call it role-adjacent work: tasks that sit just outside your core responsibility, tasks you would normally have to hand to someone else, tasks blocked by a queue, a specialist, or a process.
This is where the transformation is actually happening. Not in the automation of known tasks. In the expansion of what each person can reach.
AI does not just make you faster at your job. It makes you capable at jobs that were never yours to do.
What Role-Adjacent Actually Looks Like
The developer who writes tests reluctantly, or not at all, is a well-known problem. Testing is important. It is also not what most developers find interesting about their work. With AI, a developer writes the code and then prompts their way to a full test suite they did not have to dread writing. That is substitution, still in their lane. But the same developer can now go further: they can build a polished front-end interface, something that would once have required a designer and a round of feedback. They remain a developer. But their output now includes work that previously needed another role.
That is the pattern. Here it is across the organisation.
The Marketer Who Became Their Own Analyst
Marketing teams wait weeks for data pulls. The analyst queue is always full. With AI, the marketer writes plain-English instructions and gets working SQL back. They pull their own campaign data, build their own pivot tables, and stop waiting. The analyst has not been replaced. The dependency has been dissolved.
The Product Manager Who Shipped a Prototype
A product manager who can sketch a wireframe has always been useful. One who can build a working HTML prototype and share a live link is something else. They arrive at the design review having already answered half the questions. The designer's time is now spent on decisions, not on translating vague briefs.
The Lawyer Who Stopped Waiting for IT
A contracts team needed a tool to flag non-standard clauses across a folder of documents. Normally, this is a six-month IT project. A senior associate built it in an afternoon, in plain language, with AI turning the requirement into working code. The tool exists. The project was never raised.
The HR Manager Who Ran Their Own Analysis
Engagement surveys produce spreadsheets. Spreadsheets require someone who understands statistics to interpret them. The HR manager who previously handed the file to the data team now runs sentiment analysis and clusters responses themselves. The insight arrives before the quarterly review, not after it.
The Designer Who Tested the API
A product designer wanted to see how their interface would behave with live data before the sprint review. They wrote the API call themselves, with AI handling the syntax. The demo used real data. The feedback was specific. The gap between design and engineering closed by one working day.
The Finance Director Who Modelled It Live
Scenario modelling used to mean sending a brief to the data team and waiting. In the meeting, the FD now builds the model while the room watches. Assumptions change in real time. Decisions that once required a follow-up call get made in the room. The conversation and the analysis are no longer separate events.
The Sales Lead Who Wrote Their Own CRM Report
Pipeline reporting took a day of manual wrangling every Friday. The sales lead described what they needed in plain language. AI turned it into a formula set and then, when that was not enough, a lightweight script. Friday morning is now spent selling, not counting.
It Was Never the Work. It Was the Handoff.
What these examples share is not that the people involved learned a new skill. They did not train as developers, analysts, or statisticians. They used AI to bridge the gap between what they needed and the specialist who would normally provide it. The skill they brought was the ability to describe the problem clearly, which is a skill most knowledge workers already have.
Organisations are built on handoffs. You need a thing, you ask a person, you join a queue, you wait, you receive, you review, you ask again. The handoff is the fundamental unit of organisational friction. It is where time goes. It is where intent gets lost. It is where context gets dropped.
AI does not eliminate specialists. It removes the mandatory handoff for a large category of requests that were never complex enough to require one in the first place. The analyst still exists. They now work on problems that actually need an analyst, not on pulling standard reports for people who could have pulled them if pulling had been simpler.
This is a structural change. It is not about individual productivity in the narrow sense. It is about where work actually stops inside an organisation, and whether that stop is still necessary.
Temporal Compression
The Evolving Software framework identifies Temporal Compression as Layer VI of its emergence architecture. The principle is precise: the same process, under a faster clock rate, produces structurally different outcomes. Not incrementally better outcomes. Different ones. A feedback loop that closes in minutes does not merely accelerate the same result. It changes what is possible within a given decision window. Role-adjacent AI use is Temporal Compression applied to organisational structure. The handoff that once took three days now takes three minutes. That is not a faster process. It is a different process, with different consequences for what can be known, decided, and shipped inside a single working day.
The Policy Is Pointed at the Wrong Target
Most organisations that take AI adoption seriously focus on training people to use AI within their existing role. How do we help marketers write better copy? How do we help developers code faster? These are reasonable questions. They are also the smaller questions.
The more important question is: which handoffs in this organisation are unnecessary? Not which tasks can be automated within a role, but which dependencies between roles have only ever existed because the alternative was too slow or too technical.
That requires a different kind of thinking. It requires organisations to look at their workflows not as sequences of tasks assigned to fixed roles, but as systems with friction points. The friction points are where AI creates the most value. Not because AI is doing the specialist's job, but because it is doing the coordination work that got the specialist involved in the first place.
Organisations that understand this will not just train people to use AI tools. They will actively encourage people to cross their brief, to reach into adjacent territory, to use AI to do things they were never hired to do. Not because role definitions no longer matter, but because a great many small tasks are currently allocated to specialists who would rather be doing something harder.
The question is not which tasks can be automated within a role. It is which dependencies between roles were never necessary in the first place.
What Changes When the Brief Expands
Individuals who work this way report something specific: they stop feeling blocked. The experience of being blocked, of needing something from someone who is busy with something else, is one of the most corrosive features of organisational life. It kills momentum. It separates intention from output. It turns a capable person into a person who is waiting.
Role-adjacent AI use removes a category of blockage. The person who can pull their own data, build their own rough prototype, draft their own script, or run their own analysis is no longer hostage to another team's backlog. They keep moving. Their thinking stays connected to their action.
This does not make organisations flat or specialists redundant. It makes the specialist's time worth more, because the work arriving on their desk is harder and more genuinely requires what they know. The analyst who used to spend Tuesday pulling reports now spends Tuesday interpreting them. That is a better use of the analyst. It is also, usually, a better experience for the analyst.
The brief expands. The specialist deepens. The organisation moves faster because fewer people are waiting and fewer experts are doing work that did not need them.
Start With the Tasks You Cannot Do. Not the Ones You Hate.
Using AI to escape your least favourite tasks is fine. It is a reasonable place to begin. But the people who are extracting the most from these tools are not using them to do their job faster. They are using them to do adjacent work they never had access to before.
The developer building a front end. The marketer writing a query. The lawyer building a tool. The finance director who does not need to send a brief before the meeting starts.
These are not curiosities. They are the shape of what AI actually changes inside a working organisation. Not speed. Reach.
If you want to find where AI will matter most in your organisation, look for the handoffs. Find the queues. Ask which requests never needed a specialist but got one anyway because there was no other way to get it done.
Then ask who could do it themselves, if doing it were simpler.
It is simpler now.
This essay was written for EvolvingSoftware.com. The Temporal Compression layer referenced above is documented in full at evolvingsoftware.com/layers/acceleration.html. Further essays on the structure of AI adoption and organisational intelligence are available in the Articles archive.