TL;DR
We can all see that AI can reduce the time needed for an individual task. And that saving becomes useful capacity when the surrounding workflow can put it to use. As managers we should follow the work through review, correction and handoff, and then decide what the released time is for. Maybe a better customer conversation or a more manageable workload may be worth more than another batch of drafts. Measure the result the team can use, alongside the effort and attention still required.
Why do I follow the work beyond the first draft?
I think we need to follow AI’s time savings further than the task that produced them. A faster draft is useful but the more consequential question is whether the people who depend on that draft can now do better work or act sooner than before.
I was reading a recent discussion in the project management community on Reddit that brought the problem into focus. A learning and development project manager was struggling to reconcile claims that AI could run the working day with the effort still needed to prepare follow-up emails, handle spreadsheet exceptions and keep overlapping deliverables moving. It is one person’s account, not evidence of how every team works. But it describes a practical difficulty: the work still has to pass between people and systems, however quickly one part of it gets done.
Source Project management discussion on Reddit
That distinction shapes how I read claims about AI productivity. Producing a document faster, delivering more work with the same team and finishing the day with fewer unresolved demands are different outcomes. Each matters. But evidence that we have achieved one does not establish the others.
What does the evidence say about AI time savings?
A randomized field experiment involving 7,137 workers at 66 firms examined Microsoft 365 Copilot over six months. In the May 2025 version of the paper, workers offered access spent about 1.3 fewer hours a week on email than the control group. The researchers also found suggestive evidence of faster document work, without a corresponding change in time spent in meetings.
I take that as a useful gain, with a clear boundary around what it tells us. The study observed work patterns; it did not establish that projects finished sooner or decisions improved. Three of the four authors worked for Microsoft at the time. That relationship deserves disclosure, while the randomized design gives us a stronger basis for assessing the time saving than a collection of enthusiastic user stories.
Source Shifting Work Patterns with Generative AI
My starting point would be to ask what the team could do with that capacity? Did the time spent reconstructing a status report could go into resolving the issue it describes. A quicker proposal draft could leave room to understand a customer’s requirements more carefully. Neither benefit appears simply because the drafting tool gets faster. Someone has to change how the work is actually done.
So where does the saved time go?
Consider a hypothetical delivery team preparing client proposals. AI reduces the effort needed for the first version. The team could now respond to the customers sooner, investigate uncertain requirements, or produce more proposals. Each choice places a different demand on the people reviewing scope, price and delivery commitments.
If more proposals reach the same reviewers, a faster first draft may simply create a longer queue. If the team uses the time to clarify a difficult requirement, it may produce the same number of documents and make fewer promises it later has to revisit. A simple count of drafts would favour the first outcome. What I would want to know is which choice helps the team deliver what the customer actually needs.
This is where the argument about AI becomes a management question. Improving one activity changes the demands on the work around it. But we need to understand where the constraint moves and whether the next person has what they need to proceed. Otherwise, the local improvement can be genuine while the overall result barely shifts.
The attention still required after delegation also deserves a place in that assessment. A study published in Frontiers in Psychology on 24 September 2026 followed 642 hybrid and remote knowledge workers across two survey waves. Greater dependence on AI delegation was associated with more vigilance about the work, more rumination and poorer recovery. The study used self-reported data and a newly developed measure. It does not establish that AI caused those effects or that they apply to every team.
Source When AI works employees worry
For me, the practical question is whether a task has stopped consuming someone’s attention. A manager may spend less time writing and still keep checking whether an agent has misunderstood the assignment. That is a different experience from having time available for another piece of work, even if the drafting timer shows a saving.
I would not combine these studies into proof of a universal productivity paradox. They examine different people, tools and outcomes. They do, however, give us a reason to look at the review and attention that remain after the faster task is complete.
How should managers turn time saved into useful capacity?
I would start with one recurring workflow and follow it through to a result someone can use. For a customer proposal, that means measuring the time from a qualified request to a reviewed response the delivery team can honour. Stopping the measurement when the first draft appears leaves out much of the work that determines whether the proposal is any good.
The measure needs to include the review and corrections that follow. It should also tell us whether the recipient could act on the result or had to reconstruct the missing context. I am not suggesting that we monitor every keystroke. A small amount of consistent evidence about the complete workflow would tell us more than an impressive total of hours saved on isolated tasks.
Then we need to decide what the released capacity is for. A startup may need more customer conversations. An established team may have important work it keeps postponing. There is also a legitimate case for making an excessive workload more manageable. The choice depends on the business and its constraint. Leaving it unanswered means the next incoming request will make the choice for us.
That decision needs an owner beyond the rollout. In his September Substack essay, project practitioner Dieter Zibert distinguishes introducing AI into a defined workflow from taking continuing responsibility for the capability once it is in use. This is a practitioner’s argument rather than experimental evidence. I think the distinction is useful because the workflow will keep changing after the implementation team has moved on.
Source Dieter Zibert on AI rollout and ownership
Review should change as we learn. I would expect a change to a customer commitment to receive close attention. Whereas repeatedly checking a reliable formatting step may add little value. The useful discipline is to examine where review catches consequential errors, where it merely adds delay and when changed circumstances mean we need to look again.
What would I ask next?
The opportunity I see is to make room for the work that loses out to the next report or update. A project manager could resolve an ambiguity before it holds up delivery. A founder could spend more time testing an assumption with customers. Those are plausible uses of saved capacity, and they need to be judged by what actually improves.
Faster production can also raise output expectations and leave everyone with more material to review. We should be able to recognise that result rather than calling it a productivity gain because the first step became easier.
The question I would bring to the next team discussion is straightforward: which part of the work became easier, and what did we do with the capacity it released?
If the answer ends at the first draft, I would follow the work a little further. The next useful improvement may be in the decision, handoff or review that comes after it.
I explore the related question of keeping AI-assisted work aligned with its intended outcome in one of my earlier article.
Every AI Agent Needs a Baseline
What we want to avoid is people feeling busy because they feel like things are getting done with agents and AI, but ifthe deliverables themselves are not changing, it just makes us feel like we did a hard days work.
Frequently asked questions
Does time saved with AI prove a team is more productive?
No. A faster task is evidence of a local improvement. To judge the team’s productivity, I would also look at the review, rework and handoffs needed to produce an accepted result. More drafts can coexist with a longer queue or a workload that is harder to manage.
How should managers measure the value of AI time savings?
Measure one recurring workflow from the request to a result the recipient can use. Compare the time and effort required before and after introducing AI, including review and corrections. Check that quality holds up. For a proposal, the useful endpoint is a reviewed response the delivery team can honour.
What should teams do with the capacity AI creates?
Choose a use that addresses the team’s actual constraint. I would consider whether better customer understanding or resolving delayed work would help more than increasing output. A more manageable workload is also a valid aim. Make the choice explicit, then check whether the intended benefit appears.
Can AI delegation leave people with more supervision?
Supervision can remain after a task is delegated. Checking and corrections therefore belong in the assessment. The study discussed here found associations between AI delegation, vigilance and recovery, but did not establish causation. It is a reason to examine the attention still required, rather than assume delegation removes it.
Who should own an AI assisted workflow after rollout?
I would assign continuing responsibility to a named business owner who understands the workflow and its intended result. That person should review the evidence and decide when the process or level of supervision needs to change. Installing the capability does not settle how it will be operated over time.
Sources
