Part 1 of 2: When “Efficiency” isn’t Efficient
There is an epidemic. I think we can all feel it. AI is accelerating the pressure to prove efficiency, and for some orgs, that pressure is getting close to a breaking point. AI use in personal and professional lives is increasing. Many organizations have invested in apps and programs that claim to improve productivity, efficiency, and quality, and now they need to have something to show for it.
Quality gains are uneven—and without oversight, quality can drop fast. We see the receipts everywhere with what a large portion of the population not-so-lovingly call “slop”. This is usually when they offload far too much to the AI program and don’t retain enough human oversight.
Productivity with AI is often treated simply as “more tasks completed”. And while this can be more productive in output-driven work, in modern commercial teams and knowledge work, this usually means that you’ve simply created more noise to filter through in order to generate outcomes.
For the purposes of this post, I want to talk about “efficiency”.
The goal for as long as any of us can remember has been to become more efficient. And yes, there are obvious benefits to efficiency gains that we have achieved to this point, and that we will achieve in the future.
But a big problem we have is the definition of efficiency.
Essentially, if our output stays flat but our input increases, we lose efficiency. Ideally, we should be able to increase output with the same or less input or sustain output with less input. This is the cleanest definition I’ve found.
Unfortunately, that definition doesn’t always translate to the corporate world. I’ve seen it countless times in my over 20 years of work: leadership push for efficiency, like they push for productivity, but what they’re really pushing is utilization and proof-of-work—and that ends up as unsustainable overwork.
To put it plainly, What efficiency can legitimately mean:
Lower cost per unit (same outcome)
Faster end-to-end cycle time (same quality)
Less rework / fewer defects
What gets dangerously mislabeled as corporate efficiency:
Higher utilization where everyone “booked solid”
Fewer people on a team through capacity reduction
Fewer meetings (the ones where you’re removing alignment)
There is a point where perceived efficiency gains become detrimental to the overall outcome. Most of the damage in the “danger zone” isn’t about efficiency, it’s more about mistaking utilization and austerity for efficiency.
This happens because we are making efficiency the goal. And as I’ve talked about before (previous blogs/posts and in Chapter 7 of my book From Busy to Better), corporate will too often optimize for the goal, and not the outcome. If you optimize for busy by setting the goal as more tasks, fewer wasted minutes, or more reports, then you get busy. The key is to optimize for outcomes by optimizing for things like flow, quality, resilience, learning, and processes.
This is the most common way that efficiency becomes harmful. When you’ve spent so much time and energy optimizing one part of the system so much, that it causes stress on the rest of the system.
There are many ways that misapplied efficiency creates problems, we’ll cover three of them here.
1. When utilization gets too high, your waiting time increases…a lot
Let’s assume the system you are building or running has variability. Don’t want to assume that? Too bad, because every human system will have variability. In commercial teams, variability is demand spikes, escalations, approvals, and context switching.
In this system, queues of some kind will inevitably form, and as utilization increases, delays can spike quickly. You might look efficient and even productive on paper because everyone is busy, but customers and employees feel the opposite because everything starts to take longer.
If you are aiming for “maximum efficiency” by keeping everyone at 95% capacity, end up building a queue. Even in a non-software engineering system, this will happen. Response times will get worse, cycle times will stretch, handoffs get delayed, and then small spikes turn into major disruptions because the system has become brittle.
Let’s think of an always-on enablement desk as an example.
Your team supports the sales org with content tweaks, deck reviews, onboarding asks, and certification reviews. Leadership wants faster turnaround, all-hands-on-deck, and utilization, so every enablement partner is booked with team calls, updates, housekeeping, program building and maintenance, and other tasks. It all looks very efficient on paper.
However, in real life, sellers are waiting longer for responses, managers are waiting longer for coaching input and data, “quick questions” are now escalations, and deadlines remain fixed so they end up with rushed work. This increases rework, which increases load, which slows down response…
You see the problem?
The paper efficiency of the team created a self-reinforcing feedback loop down the line. And most of the time you don’t know you have an issue until it is suddenly a massive issue.
2. When you remove slack, you remove resilience
A lot of leaders think that removing slack will remove waste. They argue that the only reason there is slack is because of waste, inefficient time and work. “In order to be optimized, you need to be near capacity”, is the cry heard from every productivity guru trying to sell you a fantasy.
Sure, there can be unused time that is wasted, but they fail to realize that there is a necessary amount of slack in order to have a buffer that absorbs reality.
However, modern research on organizational resilience frames slack resources as a contributor to resilience and as important in absorbing shocks and adapting to them (1).
Another study in International Journal of Production Economics describes how “unabsorbed slack” can be mobilized into redundancies that cushion operations against disruptions (2). Of course, this depends a lot on how well the organization pays attention to what’s going on, and how it chooses to react.
Slack, or “unused time” isn’t automatically wasted or inefficient, it’s often what is keeping you from breaking when things go sideways.
This efficiency trap is very visible in healthcare because the costs are immediate. A 2025 editorial from JAMA Network Open cites projections that national hospital occupancy could exceed 85% and calls it a critical threshold where basic hospital operations can become “dysfunctional and even unsafe” (3).
But why would 85% occupancy lead to dysfunction?
At high capacity, the system has no buffer, so even “normal variability” can tip into a crisis quickly. In the hospital, people queue in the ER because there are no beds in the hospital.
We can translate the “hospital beds” into a host of commercial systems:
· support tickets
· legal review
· onboarding ramp and bandwidth
· enablement requests
· deal desk approvals
· customer escalation
The problem isn’t system specific. Any time you optimize away a buffer, you create fragility.
3. When “efficiency” drives quality down through measurement, documentation, and defensive work
This is the one that most knowledge teams don’t see coming until it is already happening. In most customer-facing and commercial roles, this “efficiency” gets operationalized as something to the effect of “every minute is documented and accounted for”. Time tracking, activity logging, internal updates, and status checks all to prove what you did, show utilization, and justify your schedule. This is also a common trap in productivity, but we will focus this section on how it is weaponized in the name of efficiency.
These are often looking at tasks completed but fail to consider overall task quality until it’s dropped below healthy thresholds.
But, this type of work is not just “did you complete the task. It’s:
· did you make the right judgment call
· did you catch nuance
· did you prevent rework
· did you align stakeholders
· did you communicate clearly enough that the downstream teams don’t mis-execute
· did you protect the customer experience while moving fast
All of these require thinking time, synthesis time, and coordination time.
But the more you push “efficiency” (and activity as productivity), the more you create a predictable, ugly shift:
· People start optimizing for what’s measurable, not what’s valuable
· People do defensive work (documenting, explaining, pre-justifying)
· Work gets broken into smaller fragments to be “trackable”.
· Context switching increases
· And quality suffers—leading to rework, escalations, and more documentation
Trying to squeeze productivity and efficiency by forcing constant proof-of-work increases overhead, decreases quality, and creates rework issues down the line.
A lot of your teams feel this deeply and innately in their bones, and this is one reason that they push back. But this is also backed up by research on electronic monitoring and performance monitoring, as it shows consistent downsides. Meta-analytic evidence finds electronic monitoring is associated with higher stress and lower job satisfaction and doesn’t reliably improve performance, especially when paired with targets and feedback pressure (4).
And if you want to talk about what’s happening in modern knowledge work before we even add the “document every minute” layer, Microsoft’s analysis of digital work patterns describes employees being interrupted frequently during core hours by meetings, email, and chat. All of these interruptions come together to make deep work and quality thinking harder to sustain (5).
We are literally keeping our teams from being able to produce the outcomes we are requiring, by requiring them to become over-efficient and over-productive. Of course, they aren’t either of those because the mechanisms are completely wrong when leadership implements and looks for performative solutions instead of real results. The already fragmented day is nearly shot.
The Takeaway
This isn’t a post on how efficiency is bad. Efficiency is very good.
But there is a line where organizations stop pursuing true efficiency (less waste, less rework, faster flow), and are instead pursuing efficiency proxies like utilization, elimination of slack, and proof-of-work…which hurt outcomes.
In Part 2, I’ll tie this directly to the productivity lens I use in From Busy to Better: why “more output” is not the same as “better outcomes,” how AI makes that distinction unavoidable, and how commercial teams can build a system that’s actually sustainable.
Resources:
