Are We Undervaluing Automation? The Hidden Cost of “It’ll Only Take Two Minutes”

“Can you just add a couple of queues? It should only take two minutes.”

If you work in technology, you’ve heard or said some version of this phrase countless times. It’s usually asked with good intent. The task sounds simple. The request feels reasonable. And in isolation, it probably is straightforward.

But that casual estimate, “two minutes“, is one of the most common ways organizations quietly undervalue automation.

Earlier this month, I asked a team member to create two Azure Service Bus queues and configure Event Grid to route events to them, a simple enough request. The team member knew exactly what to do. Their response:

That sounds good, but only if you measure the task from the moment hands touch the keyboard to the moment the configuration is saved.

What it doesn’t include is everything that surrounds those two minutes:

• Context switching from their current task
• Reloading mental models of the environment
• Navigating subscriptions, resource groups, and naming standards
• Verifying configuration and permissions
• Making sure nothing breaks downstream

None of this is unusual. In fact, it’s entirely normal. Yet when I’ve been involved in automation business cases, that “two minutes” often becomes the full cost of the work.

A practitioner’s perspective on the value of automation

My frame of reference on this comes from being responsible for a Red Hat Ansible Automation Platform at scale. One of the hardest parts of this role isn’t building or running automation, it’s explaining its value.

The platform can tell us exactly how many jobs ran, how long they took, and how consistently they executed. What it can’t easily show is the true human cost of the work it replaced. When that baseline is built on informal estimates like “it only takes a couple of minutes,” automation almost always appears undervalued on paper—even when its operational impact is undeniable.

The question that changes the conversation

Whenever I hear the phrase “it’ll take two minutes,” I now ask a different question: If it really takes two minutes, could you do 30 of these in the next hour?

Could you create 30 queues, configure Event Grid, test them, and still handle meetings, messages, and other work in the same hour?

Adding more scale further highlights the issue:

• Could you do 240 in a day?
• 1,200 in a working week?

The two-minute estimate feels much less plausible now.

This isn’t about catching anyone out, and it’s certainly not a question of competence. It’s about recognizing that, in practice, human effort doesn’t scale linearly—especially in environments full of interruptions, competing priorities, and cognitive load. Automation, by contrast, is not limited.

The hidden cost of context switching

For technologists, this will feel familiar, but for many business leaders, it’s often invisible.

Every “quick task” has a hidden productivity tax:

• Dropping out of focused work
• Rebuilding context afterward
• Losing momentum on higher-value activities
• Increasing the chance of small but costly mistakes

That tax doesn’t show up in time-tracking tools. It doesn’t appear on sprint boards. But it’s paid every day.

When someone pauses feature development, incident analysis, or architectural thinking to create “just a couple of queues,” the cost isn’t just the execution time, it’s the disruption. Multiply that across teams, weeks, and environments, and you begin to see why productivity feels lower than the numbers suggest.

That’s the part automation protects. And the part it almost never gets credit for.

Research from the University of California, Irvine, found that after an interruption, it takes an average of more than 20 minutes to fully regain focus. Cognitive studies show that what we call “multitasking” is actually “rapid task switching”. Each switch increases mental load, slows performance, and raises the risk of error. In other words, the cost of a “two-minute task” is rarely two minutes—it’s the disruption that follows.

Why automation ROI so often looks underwhelming

When organizations build automation business cases, they usually start with a simple question: “How long does this task take a person to do?”

The answer, often delivered casually, becomes a hard number in an ROI model. Two minutes multiplied by frequency produces a saving that looks… modest.

What’s missing?

• The frequency of interruptions
• The variability of the task
• The cost of switching attention
• The fact that humans slow down as volume increases

As a result, automation often gets framed as a minor efficiency gain, even though it frees up capacity in a way manual work never can.

In the Azure example, automating queue creation and Event Grid configuration isn’t about saving a couple of minutes. It’s about:

• Enabling consistent, repeatable provisioning
• Removing interruptions from skilled engineers
• Supporting growth without proportional headcount increases
• Reducing risk as volume and complexity rise

But if the business case is built on “two minutes,” none of that shows up.

Reframing how we talk about automation value

To show the true value of automation, we need to flip the script. “How long does this take?” becomes:

• “How often does this happen?”
• “What gets interrupted when it does?”
• “What happens when the volume doubles?”
• “Who shouldn’t be doing this manually?”

For technologists, this means challenging assumptions. Not defensively, but constructively. Scaling questions are powerful because they’re neutral. They turn a gut feel into a shared thought experiment.

For business leaders, it’s about seeing how automation protects focus, reliability, and growth—beyond a per-task saving.

Automation isn’t just faster, it’s more honest

The irony is that automation doesn’t exaggerate its benefits. Humans unintentionally minimize the value of their own work.

When we say, “it’ll only take two minutes,” we’re not being dishonest. We’re just measuring the wrong thing. And when those measurements drive investment decisions, automation inevitably looks less valuable than it truly is.

The next time someone makes a casual estimate, pause and ask the scaling question. Not to challenge the person, but to challenge the assumption.

In a world of growing complexity and constant interruption, automation isn’t just about speed. It’s about making the real cost of work visible, something we’ve been underestimating for a long time.

Further Reading

For readers interested in the research behind context switching and productivity, the following studies and articles provide useful perspective:

• University of California, Irvine – Gloria Mark et al. Research shows that after an interruption, it takes an average of more than 20 minutes to fully regain focus, highlighting the hidden cost of “quick” tasks.
• American Psychological Association – Multitasking and Task Switching cognitive studies demonstrate that task switching increases completion time and error rates, as the brain must repeatedly reconfigure context rather than truly multitask.
• Forbes Coaches Council – Context Switching and Multitasking analysis indicates that over 97% of people lose productivity when switching tasks, even when they believe they are managing interruptions effectively.
• Rubinstein, Meyer & Evans – Journal of Experimental Psychology found that task switching can reduce productivity by up to 40%, reinforcing why human effort does not scale linearly with task volume.

Taken together, they all point to the same thing: the real cost of work isn’t just time spent—it’s attention lost.