The tyranny of deadlines, and a growing trail of sub-par outputs.
Inside the Rickety Machine
I once found myself, as a client, advising a consulting team to push back on deadlines I was demanding. It wasnât out of some newfound benevolence, but to mitigate dysfunction.
In a new role, I inherited a project that an external consulting partner had committed to deliver by the end of May. On paper, the remit and the timeline didnât reconcile. I assumed I was missing some context â I wasnât.
The project finally landed in August â after four âfinalâ reviews, each a slightly different variant of incomplete and sub-par output.
The journey was marked by unpleasant executive reviews and considerable heartburn on both sides: client and consultants alike.
At the center of the fiasco was a partner whose reflexive answer was âyes sirâ to every new ask and instance of scope creep. His teams suffered in the wake of those acquiescent commitments â burning midnight oil, still coming up short, and getting chastised.
Had the deadline been reasonably negotiated and aligned upfront, the delivery quality, experience, and perception would have been diametrically opposite. Same timeline. Calm execution. Constructive communication.
The pattern was hardly an exception.
On another front in the same organization, rapid internal movements meant HR and business teams would scramble before every executive review to reconcile headcount numbers that differed across systems.
This circus repeated every two months.
Each time, everyone acknowledged it was inefficient, and no one created a system that would eliminate the problem with a small, dedicated investment.
Urgency crowded out design.
The Accruing Debt
In the world of technology, this pattern has a name.
Teams dedicate sprints to ârefactoringâ â deliberately paying down technology debt created when quick fixes are chosen over robust design in order to meet deadlines.
Good technology teams leave a clear trail of what theyâve patched, what theyâve deferred, and what will need fixing for the system to scale safely.
Short-term patchwork creates the same kind of debt in organizations.
The difference is that while technology teams acknowledge and service their debt, most organizations pretend theirs doesnât exist.
Organizational debt is stickier. Humans exhibit inertia, and cannot be refactored like code in a sprint. Habits harden and structures tend to calcify.
As with all debt, it only gets more expensive to service with time â eventually courting implosion.
What Technology Management Teaches Us
Getting everything right the first time is a luxury that real-world deadlines rarely permit. But neither is it sustainable for leadership to become a perpetual whack-a-mole â endlessly reacting to issues that surface because the underlying system was never properly designed.
We could pick more than a few leaves from modern technology management.
- Version releases are planned
- Comprehensive testing before going live
- Audit trails of what was deferred and hustled
- Budgeting time for refactoring
The owner of the deliverable must make the trade-offs visible â and advocate for a timeline that reflects reality.
May be the question is not:
Can we do this by Friday?
but rather:
What are we deferring, and risking, by choosing Friday?
Array
(
[0] => WP_Term Object
(
[term_id] => 26
[name] => POV
[slug] => pov
[term_group] => 0
[term_taxonomy_id] => 26
[taxonomy] => post_tag
[description] =>
[parent] => 0
[count] => 4
[filter] => raw
)
)
A WordPress Commenter
February 7, 2026Hi, this is a comment.
To get started with moderating, editing, and deleting comments, please visit the Comments screen in the dashboard.
Commenter avatars come from Gravatar.