Work management was built around human latency

I have been in software long enough to remember when enterprise products shipped on CDs. Actual plastic discs reviewed by enterprise IT committees. PMs maintained 200-page specifications, engineers worked from Microsoft Project files and updates circulated as email attachments. If the plan changed, the PM opened the file, saved a new version and emailed it around again. A few days later, half the team would be working from the latest plan while the other half was still operating from an outdated version. That sounds absurd now, but at the time it matched the operating tempo of software development. Why Waterfall worked The original project-management models for software came from industries that built large, complex systems long before software existed, particularly manufacturing and construction. Six-month specifications, multi-year builds, gated phases and tightly controlled handoffs made sense in a world where software shipped slowly, and markets moved in quarters rather than days. The giant specification document served a real purpose. It compressed everything the organization had learned into a single artifact, handed it to the builders and effectively said: go build this, and we’ll regroup in a year. Then the web changed the clock. Feedback loops collapsed from quarters to weeks, and eventually to days. Teams could ship on Tuesday and observe user behavior on Wednesday. In that environment, the 200-page specification stopped looking like disciplined planning and started looking like operational drag. The pace of work changed which meant the tooling and coordination model had to change with it. Why Agile took over Jira, Asana, Notion, Linear and Slack became foundational because they matched the tempo of modern work over the last two decades. They were designed for a world where execution still took humans days or weeks, where work moved across queues owned by different people, and where plans required constant revision because reality kept shifting underneath them. A ticket tracks a commitment made at a specific point in time because somebody else is waiting on that work. Sprint boards help teams coordinate around the reality that humans cannot execute instantly and cannot keep every dependency loaded into memory simultaneously. Standups exist because information spreads slowly. Backlog grooming exists because demand arrives faster than available execution capacity. The process ceremony has a real function. It compensates for latency. Often smart latency compensation. Often necessary latency compensation. But latency compensation, nonetheless. Waterfall was correct for the pace of 1995. Agile was correct for the pace of the last twenty-five years. Different operating speeds produce different management systems. Execution speed changes the system Now compare that model with what happens when I ask an agent to do something instead of asking a human colleague. In the old workflow, the colleague already had their own priorities and queue of work. They could not immediately stop everything for my request. Maybe they got to it later that afternoon. Maybe the next day. Maybe it entered sprint planning and returned one to three weeks later. By the time the work came back, I had already context-switched into something else. That waiting creates more than delay. It creates in-flight work, and in-flight work creates management overhead. Teams start tracking, grooming, triaging, reminding, reconciling and coordinating because the work itself is sitting in queues. Once execution speeds up dramatically, much of that overhead starts looking different. With an agent, I ask for something, it runs and it comes back ten minutes later while I am still operating inside the same mental context. I review the output, redirect it, ask again and iterate immediately. Five iterations can happen in half an hour, producing work that previously might have taken weeks to move through a marketing queue, an ops process or an engineering sprint. That workflow does not fit naturally onto a sprint board anymore. If I encounter an issue at 10:00 a.m., an agent drafts a fix by 10:20 and I review it by 10:35, the ticket increasingly becomes a historical artifact recording a bottleneck that no longer meaningfully exists. Backlogs exist to manage latency David Allen’s GTD methodology includes the two-minute rule: if something takes less than two minutes, do not queue it. Just do it. The cost of tracking the task can exceed the cost of completing it. Writing the task down, tagging it, categorizing it, finding it again later and deciding when to handle it may require more energy than simply finishing the work immediately. Agents introduce an organizational version of the same principle. If an agent can complete something quickly, it often becomes easier to launch the agent than to delegate the work to another person and manage the surrounding coordination. Mechanically, that is what tickets and backlogs do. They create ledger entries indicating that somebody committed to work and the organization is now waiting for it. Those ledgers matter because human execution is slow and shared organizational memory is fragile. As those constraints weaken, the ledger has less to track. The work runs, returns and waits primarily for review. The scarce resource increasingly becomes judgment rather than execution itself. Sprint ceremonies, standups, backlog grooming, triage meetings and workflow management largely exist to compensate for execution bottlenecks that are beginning to shrink across large portions of knowledge work. Not every category of work changes this way. Deep architectural decisions, strategic judgment, creative direction and interpersonal negotiation still operate on human time. But the enormous, long tail of “someone should probably get to this” work changes meaningfully when that someone can be an agent that starts immediately. What agentic workflows look like Imagine a customer posts a small product complaint into a shared Slack channel: “This dropdown closes when I try to scroll inside it. Driving me crazy.” Under the old model, QA reproduces the issue and files a ticket. A PM triages it, groups it into other frontend work and schedules it into a sprint. A developer eventually picks it up, fixes it, opens a PR, waits for review, merges the change and ships it in the next release cycle. Two to four weeks pass. Multiple people touch the issue. The organization produces tickets, PRs, release notes and Slack threads because context decays over time and teams need durable coordination artifacts. Under the new model, an agent reads the message, reproduces the issue in a sandbox, drafts a fix, runs tests and security scans, attaches a short video showing the corrected behavior and notifies a human reviewer. The human watches the video, reviews the diff and decides whether the change should ship. The elapsed time drops below an hour, while human attention concentrates almost entirely on judgment rather than coordination. Versions of this workflow already exist inside highly agentic teams. The next layer of tooling Most technology shifts follow a similar pattern. First, information moves faster. Then work itself moves faster. After that, entirely new management and coordination systems emerge around the new operating speed. That is the phase we are entering now. AI accelerates execution itself, and early adopters are already stitching together workflows that look very different from the work-management stack most companies still use today. The next generation of organizational tooling probably will not resemble software built for the pre-AI era because those systems assumed the slowest part of the organization was human execution. That assumption is beginning to break. This article is published as part of the Foundry Expert Contributor Network. Want to join?