There is a particular kind of meeting that most engineering leaders have sat through at some point.
The product isn't growing fast enough. Or a competitor has shipped something. Or a board member asked a difficult question. The energy in the room is high — charged with urgency, pressure, the feeling that something must be done, and done quickly.
Decisions get made in that energy. Features get reprioritised. Deadlines get moved. Engineers get pulled off ongoing work to address the crisis. The team goes into what gets called "wartime mode."
A few weeks later, the crisis has passed. But the damage remains — half-finished work abandoned, technical debt accelerated, engineers tired in a way that doesn't recover in a weekend, trust in the planning process quietly eroded.
This is what panic looks like in a product organisation. And it is extraordinarily common.
The Seductive Logic of Urgency
Urgency feels productive. When you're moving fast, responding to every signal, staying in constant motion, it feels like you're doing something. The alternative — pausing, thinking, resisting the pull to react — feels passive, even irresponsible.
But there is a difference between urgency and clarity. Urgency is a feeling. Clarity is a condition. And decisions made in urgency without clarity tend to be expensive.
The engineering team that abandons a half-built feature to respond to a competitor's announcement hasn't gained an advantage. It has acquired two pieces of unfinished work, a confused backlog, and a team that has learned that the plan can change at any moment based on external signals. That last cost is the most expensive, and the hardest to measure.
What Panic Actually Costs
When an organisation operates in chronic urgency, several things happen simultaneously and none of them are good.
Planning stops being credible. If the team has watched three "top priority" projects get deprioritised mid-execution to make room for the next urgent thing, they stop investing in planning. Why think carefully about scope and approach if it's all going to change anyway? Execution becomes reactive, which produces exactly the kind of messy, hard-to-maintain code that makes the next crisis harder to respond to.
Technical debt accelerates invisibly. Panic mode produces code that works right now. The shortcuts taken under pressure accumulate in the codebase quietly, and their cost is paid later — often when the organisation is already under pressure again, which is when the accumulated debt becomes most painful.
People protect themselves. In an environment of chronic urgency, engineers learn to keep their heads down, avoid visibility, and not raise the concerns they're observing. The psychological cost of being the person who slows down the urgent thing is too high. So problems that could have been caught early stay invisible until they can't.
The wrong things get built. Speed in the wrong direction is not progress. A team that ships quickly based on panic signals rather than clear thinking about user problems and product direction is expending real energy on work that may not matter.
The Alternative Is Not Slow
"Don't panic" is not an argument for going slow. It is an argument for going in the right direction with sustained intent rather than in whatever direction feels most urgent today.
The organisations that move fastest over time are not the ones that respond to every signal. They are the ones that have enough clarity about what they're building and why that they can resist the signals that don't serve that direction — and accelerate hard on the ones that do.
This requires two things that feel luxurious in an urgent environment but are actually prerequisites for sustained performance.
A North Star that's actually shared. Not a mission statement on the wall but a genuine shared understanding of what success looks like — specific enough to be useful when making tradeoffs. "Grow revenue" is not a North Star. "Make it so simple to send a client proposal that a designer does it from their phone before the meeting is over" is closer.
A planning process that holds. Not a rigid waterfall that can never accommodate new information, but a rhythm that creates enough stability for the team to do deep work while giving leadership a real mechanism to update direction when it genuinely needs to change. The key word is mechanism — not "whenever something feels urgent."
Prepare What Can Be Planned
There is a phrase I come back to often: prepare what can be planned, so you can handle what can't be planned.
Every engineering organisation will face genuine crises. Systems will go down. Competitors will ship. Markets will shift. Customers will complain. These are not avoidable.
What is avoidable is being in a state of permanent crisis in response to ordinary business pressure. The organisation that has done the structural work — clear ownership, documented decisions, an on-call process, a backlog that reflects real priorities rather than accumulated urgency — can absorb a genuine crisis without shattering. The organisation that has skipped that work in the name of moving fast has no shock absorbers. Every crisis is felt at full force.
Panic is not a strategy. It is the absence of one.
The engineering teams I've seen move fastest over time are the ones where "don't panic" is not a slogan but an operational principle — a shared understanding that urgency is a feeling, clarity is a choice, and sustainable pace is not a compromise but a competitive advantage.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.