I am Lino
June 8, 2026

The cult of urgency: when everything was needed yesterday and tomorrow will be worse

Posted on June 8, 2026  •  16 minutes  • 3227 words
Table of contents

At a software company I won’t name (but which absolutely exists), a developer received the same message three Fridays in a row at 5:45 pm: “It’s critical, I need this today.” On the third Friday, he finished the fix, deployed it, and nobody opened it until the following Tuesday. The developer is still in therapy. The manager has had the same unread email sitting in his backlog for two months.

There is a religion in tech companies that has no temples, no candles, no scripture — but it has millions of devoted followers who wake up every morning ready to worship its one commandment: today is more urgent than yesterday, and tomorrow will be even more so.

It’s called the cult of urgency.

Nobody knows exactly when it was founded, but it spread with particular ferocity the moment Slack made it possible to interrupt someone every four minutes with the same casual ease with which you’d previously have tossed a crumpled piece of paper at their head.

The technology that was supposed to set us free turned out to be the most effective corporate panic-distribution system ever invented. We use artificial intelligence to predict customer churn but can’t figure out that calling a meeting on a Thursday at 6 pm means people will be mentally checked out before it even starts.

The commandment is simple and admits no nuance: everything that happens in this company is a maximum-priority emergency. Everything. Always. No exceptions. Including the “team culture alignment meeting” that’s been postponed three weeks running because, honestly, nobody has managed to explain what exactly is going to be aligned.

The holy grail of “needed it yesterday”

There’s a precise moment when you know you’ve joined an organization infected by this cult.

It doesn’t show up in the job description, obviously. They don’t mention it in interviews either, where everyone talks about “healthy work culture” and “team autonomy” with the conviction of someone who’s been rehearsing the speech since Sunday night. You find out on your own, firsthand, the day you innocently ask what the sprint priorities are and someone — with the face of someone who just smelled smoke in the building — tells you, without flinching: “Everything is a priority.”

This statement is technically equivalent to saying that nothing is. The difference is that “nothing is a priority” would make you push back immediately, while “everything is a priority” gets delivered with such gravity that it implies you’re the one with a reading comprehension problem if you don’t get it . Sometimes it comes with a hand gesture suggesting the matter is too complex to explain in one sentence and that you should probably just absorb it over time.

The funny thing is that real urgency exists, and nobody denies it. There are situations that genuinely require immediate action: a production system down, a security breach with customer data exposed, that specific moment when the database goes rogue at 3 pm on a Friday. All of that deserves the red alert, the crisis channel, and every available pair of hands.

The problem is when urgency stops being an exception and becomes the organization’s default state. When panic mode isn’t a response to an incident but simply the normal way of operating. When the permanent fire isn’t an accident but the office décor and nobody remembers what the place looked like before it was burning. At that point, urgency is no longer a signal that something’s wrong — it’s just the background noise of work, as unavoidable as elevator music but considerably more expensive in terms of mental health and considerably less pleasant in every other sense.

Anatomy of the urgency-dealer manager

The cult needs its true believers, and it has plenty of them.

You can spot them from a distance with a bit of practice. They’re the managers who arrive at every meeting already running, even if they just came from the bathroom twelve feet away; who open Slack messages with the same energy you’d open a certified letter from a lawyer; and who have the supernatural ability to turn anything, absolutely anything, into a top-tier corporate emergency.

A database migration that’s been planned for three months: urgent. An SSL certificate renewal expiring next week: urgent. Choosing the color palette for the quarterly executive presentation: urgent and, on top of that, “strategic.” If you ask them when something isn’t urgent, the question genuinely throws them, like you’d asked what language fish think in or whether a company should have a written onboarding process.

What they typically don’t say out loud — and here’s the part that stings — is that, according to Harvard Business Review research on fake urgency in the workplace , the phenomenon “doesn’t arise from business reality, but from poor planning, unclear priorities, or anxiety at the management level.”

No euphemisms: the fire is very often set by the same person who shows up with the extinguisher and a hero face.

They’re not necessarily bad professionals. Many are smart people with years of experience and genuinely good intentions. But somewhere in their career they learned that urgency is an effective shortcut to get things moving without having to convince anyone, without having to prioritize explicitly, and above all without having to accept that prioritizing means — by definition — giving things up. Saying “this is urgent” avoids the uncomfortable conversation of “so what do we stop doing.”

And since nobody has ever told them no, they keep using urgency as if it were the only mode of communication available in the building.

Why your brain refuses to cooperate

There’s a very clear physiological reason why living in permanent urgency mode is a terrible idea, and it’s not “burnout” as a vague concept from an HR wellness deck with photos of people meditating on beaches.

It’s messier than that.

When your brain perceives an urgent threat, it activates exactly the same system it would activate if a prehistoric predator were chasing you through the woods: cortisol, adrenaline, all attention focused on immediate survival.

The system is an evolutionary masterpiece and works beautifully for escaping the bear. It is, however, terrible for designing a microservices architecture, reviewing a pull request with a clear head, or making any technical decision with consequences beyond the next forty-eight hours.

The bear doesn’t understand distributed systems. Neither does cortisol.

The result is predictable and has been documented so thoroughly that citing it is almost boring at this point: permanently accelerated teams that make less and less actual progress. That do an enormous number of things and finish very few. That ship fast, with enough patches baked in that the next sprint starts with three inherited fires already burning — which become the next urgencies, which require the next interruptions, which prevent the work that would have stopped the next fires.

The loop is so perfectly sealed it deserves its own flowchart, with red arrows and a fire emoji on every node , framed next to the Eisenhower matrix on the meeting room wall.

The data isn’t ambiguous. 42% of tech professionals are at high risk of burnout , and among the consistently cited causes you won’t find “the work is technically too hard” or “the problems are too complex.”

What you do find, over and over, is constant pressure with no distinction between what actually matters and what simply has a made-up deadline on a PowerPoint slide . That’s not a statistical coincidence. It’s the exact, measurable, documented cost of slapping “critical” on everything that has a deadline, real or fabricated.

The Eisenhower matrix: that poster nobody looks at

Dwight D. Eisenhower coordinated the Normandy landing, planned the end of World War II, and then governed the most powerful country in the world for eight years, simultaneously managing the Cold War, the space race, and the early years of color television. Somewhere in all of that, he found time to formulate the principle that now bears his name: the urgent is rarely the important, and the important is rarely urgent .

A man who had to decide whether to launch a hundred-thousand-person amphibious invasion in adverse weather with decades of geopolitical consequences still found enough conceptual clarity to keep those two things separate. This should give us some useful perspective on whether the rollout of a new search filter feature really warrants P0 incident treatment.

Decades later, someone turned that principle into a 2x2 matrix that is, at this point, probably the most-printed productivity poster in the history of open-plan offices. It’s been published in thousands of articles, laminated, hung next to motivational quotes about the power of teamwork, and completely ignored in every single organization where the manager walks through the door looking like the world is ending every forty-five minutes.

It’s not a tools problem. Nobody in the history of teamwork has ever solved a cultural problem with a poster.

Culture is set by whoever has the power to decide what’s urgent and what isn’t, and if that person has a concept of urgency calibrated with the precision of a car alarm in an underground parking garage — going off constantly without anyone understanding why or caring much anymore — no 2x2 matrix, however polished the typography, is going to change anything at all.

The developer as permanent firefighter

In teams that have spent enough time under the regime of chronic urgency, one recognizable profile emerges almost inevitably: the incident superhero.

That developer who’s always available at any hour, who fixes whatever needs fixing without asking too many questions, who never says “that’s out of scope for this sprint” because in this context sprints are more of a mood than a plan, and who shows up every time things break as if they had an internal alarm synchronized directly with the production logs.

In many companies this profile is celebrated in a way that, when you stop and think about it coldly, is fairly disturbing (or pathetic, depending on the day).

They’re the one who “really shows up,” “steps up when things get hard,” “who we absolutely have to keep because we don’t know what we’d do without them.” And all of that might be completely sincere.

The problem is what nobody mentions in the performance review or the thank-you email from leadership: that developer is plugging, literally with their own body, the holes in a planning process that has been systematically and deliberately catastrophic.

The fires they put out with such commendable effort didn’t emerge from nowhere or bad luck.

They were generated by a process where someone decided that an architecture multiple engineers had flagged as problematic “had to work” because the timeline had already been committed to the client and reopening that conversation was awkward.

And that developer — who statistically has been sleeping badly for months, has their LinkedIn profile updated and set to visible for recruiters even if they won’t admit it in the dailies, and is thinking about leaving more often than they’d ever acknowledge in a one-on-one with their manager — is providing an enormous service to the organization while the organization interprets this, with serene indifference, as a sign that the system is working fine.

A company that permanently needs heroes doesn’t have an engineering team. It has a life-support system that runs exclusively because there are people who haven’t yet figured out they should be charging twice as much or walking out the door. Probably both.

The life of an urgency: from Wednesday afternoon to Monday morning

To understand how urgency gets manufactured from scratch, you don’t need to invent a hypothetical. You just have to describe what happens, in nearly identical versions, in hundreds of companies every Thursday at the same time.

It starts like this: someone in leadership has an idea.

The origin is irrelevant. It might be a meeting with an important client, an article read on LinkedIn at 11 pm, or a casual conversation at an industry event where someone mentioned the competition was doing something similar.

What matters is that this idea, at the exact moment it crosses the mental threshold of the person with decision-making power, undergoes an instantaneous metamorphosis: it stops being an idea and becomes a “top strategic priority initiative”. This elevation process takes approximately sixteen hours and requires zero external validation.

Friday, there’s a meeting. Called with a few hours’ notice because, obviously, it’s urgent. The initiative is presented with genuine enthusiasm and a timeline that, upon closer inspection, was already yesterday when it was conceived.

The engineering team listens with the expression of people who recognize the pattern but haven’t fully given up on humanity, and calmly points out that this requires analysis, design, implementation, and at least one decent round of testing, that two weeks would be a tight but workable timeline, and that starting without that runway will mean technical debt and problems down the road.

This information is received with the same face you’d make if someone told you water is wet. The final decision — reached with agility, to be fair — is that the team will “figure it out” and that “we need to be more agile.”

Being agile, in this specific context, means doing in two days what needs two weeks, generating all the technical debt that implies, none of the documentation that would make it maintainable, and the three bugs that will surface the following Wednesday and will be, without any surprise, the next round of Thursday urgencies .

The cycle repeats with admirable efficiency until the team quits, the product collapses under the accumulated weight of its own patches, or both simultaneously — which is the statistically most common outcome and the one that surprises leadership the most.

The antidote: extraordinarily boring

The solution to all of this isn’t photogenic, and that’s probably why nobody adopts it with much enthusiasm. There’s no new framework. No methodology with an English name, a memorable acronym, and a minimalist three-color logo that’ll fix everything with a two-day workshop and a certification. No app.

What works, in the teams where it works, is uncomfortably simple: someone with real authority learns to say “this can wait” and says it out loud, with a specific name and a specific deadline, without their voice wavering and without the compulsive need to add “but we value it deeply and we’ll definitely get to it as soon as we have bandwidth.”

In production, this problem has been solved for decades through SLOs: explicit criteria defining what level of system degradation constitutes a real incident — the kind that justifies waking someone up at 3 am — and what level is a problem that goes in the backlog and gets resolved in a reasonable window next week.

Most companies have SLOs for their technical systems. Almost none have the equivalent for their decision-making and prioritization process, which is exactly where false urgency lives, thrives, and reproduces without restraint.

Protecting background work is the other piece that’s always missing.

Technical debt, architecture improvements, documentation, tests: none of it ever has the urgency of a Friday demo or the emotional weight of a client waiting. But it’s exactly what determines whether next year there are ten weekly urgencies or two .

Teams that invest time systematically in that invisible work aren’t faster because they’re smarter or because they work longer hours. They’re faster because they have the context, focus, and architecture that lets them move without having to reset their mental state every half hour because of a Slack message marked critical about something that’s been unresolved for weeks because nobody wanted to have the uncomfortable conversation of assigning it a real deadline.

And the most important thing — which is also the hardest to accept for anyone who’s been inside this system for years: if a manager discovers they can solve their planning problems by declaring everything urgent, and nobody tells them no, they will keep doing it indefinitely. Not because they’re a terrible person. Because it works. There’s always someone willing to scramble. And as long as there’s someone willing to scramble, there’s no incentive to learn how to pace themselves.

Next time someone tells you they need something “yesterday,” respond calmly: “Yesterday is already gone. Tell me what you’re going to stop doing so I can do this first.”

The look on their face will tell you everything you need to know about whether the urgency was real or whether someone simply forgot to plan ahead and now needs their management failure to become your calendar problem.

Which, in many companies, is also urgent to fix. Paradoxically.

Quick glossary

A few terms from this article that deserve two lines of context, because using them correctly in a meeting is, at minimum, a start.

Sources and references

Not everything can be urgent — you can process these at normal cortisol levels.

Follow me

I write and share opinions about technology, software development and whatever crosses my mind.