Responding, fast and slow
Why giving yourself time to respond may be better than rapid reaction.
Don’t react, respond
After writing about how some organisations are reactive by design, a reader challenged me on whether I was forgiving dysfunction.
I won’t lie. I flinched a little. I wondered if I’d missed the point I was trying to make, that intentional reactivity is not a bad thing. A reactive organisation that adopts a flexible planning model can create a dynamic environment where teams can not only pivot and respond to change, they can actively welcome it.
However, when an organisation pours large amounts of energy and efforts into planning, then disrupts it without pause as soon as an urgent request comes in, its reactivity is a blind spot.
Imagine that you work in an organisation like this. You’ve just tied the bow on your latest quarterly planning. You’ve got epics written, sized and sequenced. Day one of the quarter comes and, while you’re still tidying up a few hangovers from the previous quarter, you’re confident that you’ll get to your plan and make good progress against it.
On Day 3, an urgent customer request gets relayed through from a senior leader. The dev team scramble to react. Your beautiful plan is in tatters. This is the fifth quarter in a row this has happened. Everyone on the team is as frustrated as you are.
The good news? This organisational blind spot presents an opportunity.
If an organisation refuses to accept that it is reactive, then it is saying that it values its plan. If teams are constantly dealing with interruptions, then it doesn’t have the processes in place to protect this plan. It doesn’t understand how to respond, so any new request goes straight to the product team, with little, if any, intervention.
This hits the product team like an asteroid. Once the request breaches the organisation’s atmosphere, it’s going to slam into an unsuspecting team. The result is chaos, with plans interrupted as people react to this latest demand, assuming that it is now the most important thing in the world.
You need a heat shield.
The issue isn’t that the organisation doesn’t value its plan. It’s that it doesn’t have the wherewithal to prevent interruptions making their way to the team. For Engineering Managers and others caught in the middle of this, it can feel impossible to make progress. They have a new urgent priority to deal with, their stakeholders are still expecting delivery on their plan, and they have no idea what the scope of the new request is. Everyone is reacting, Nobody is responding.
Responding, fast and slow
In Thinking, Fast and Slow, Daniel Kahneman describes how we all have two ways of dealing with changes to our environment.
System 1 is our automatic response to things that happen around us. It’s intuitive, emotional, and relies on shortcuts and associations built from experience. This system handles everyday tasks like reading facial expressions, driving on an empty road, or detecting hostility in a voice. It’s efficient but prone to biases and errors because it jumps to conclusions based on limited information.
System 2 kicks in when we intentionally allocate attention to a topic. It is invoked when we are faced with tasks that require difficult calculations, careful analysis, and deliberate choices. This system is slower, more logical, and capable of following rules and making comparisons. You use System 2 when solving a difficult maths problem, parking in a tight space, or checking the validity of a complex argument.
Our brains try to deal with changes using System 1 as much as possible. When System 1 encounters difficulty, it calls on System 2 for more detailed processing. However, System 2 is lazy, and we often accept System 1’s suggestions without sufficient scrutiny, leading to predictable errors in judgement.
This happens in the organisation when new urgent requests arrive. Change request = instant interruption is System 1 thinking. Everybody defaults to a panicked reaction, running around trying to make everything work. Nobody stops to think ‘what should we do here?' There’s an instant assumption the plan will be interrupted, but, often, this assumption isn’t tested.
Calling the organisation’s System 2
Instead of presuming that the customer or leader’s demand is an immovable interruption, any request that will derail a plan should be brought into a review process. This forces the organisation to make a conscious decision about it. This review involves Engineering Managers and Product Managers, and takes place before any engineers are interrupted.
This review will cover:
what is the request?
how much of an interruption is it?
what are the trade offs?
how does the request fit with the longer-term product roadmap?
This will lead to a recommendation or decision as to whether to accept or reject the interruption. The product team will only be disturbed from their work if the interruption is accepted, thus protecting them from unnecessary distraction.
How does this review work?
The requestor should write down as much as they know about the request, and then a meeting is held with the Engineering Manager and Product Manager to review it. The resulting review and recommendation is recorded in writing.
Creating this written record is essential. Documenting the number and source of potential interruptions may lead to decisions from the organisation about dealing with them before they come to the product team. It also ensures that there’s a record of requests from customers that the team has chosen to push out. These requests may inform the upcoming product roadmap.
Let’s break down the key parts that the review must cover.
1. The request
Calling the organisation’s System 2 requires a proper consideration of the request. Instead of just reacting and asking the team to jump all over a vague request, the person representing the request has to definitively say what the ask is. This requires proper consideration of the scope of the request, its urgency, and the customer requesting it. This should be written down in as much detail as possible.
2. The impact
The request should be sufficiently well-defined that the size of the ask is obvious. Does this require a couple of engineers for a couple of weeks? A full development team for three sprints? Is it effectively a roadmap pivot? Understanding the impact will give the decision-makers context on how much of an interruption they will be imposing on the team.
3. The trade-offs
It’s critical that the request comes with a statement of the benefits of doing it. Does it represent a killer commercial opportunity? Is your biggest customer going to go to a competitor if you can’t achieve feature parity? Given your understanding of the impact, what are the costs this will impose? What isn’t going to get done if this interruption is accepted?
4. The fit
It’s possible that the request, while it’s not currently prioritised, is aligned with the overall product roadmap. This makes it easier to accommodate than a full pivot to new, as-yet unconsidered, functionality. It may also lead to telling the customer that while the request won’t be accommodated now, it is on the roadmap, and similar functionality that will allow the customer to achieve their goals will be available in a few months’ time.
5. The recommendation
Once all of the above information is considered, the reviewers make a recommendation. This can be to reject the interruption, in which case the team will not be interrupted.
For example, a Sales Director returns from negotiations with a prospect that would be a great addition to the client portfolio. They’re not necessarily going to be a massive client, but it is a marquee name. The Sales Director issues a demand for a new product capability, claiming that if it isn’t built immediately, then the client won’t sign. Reviewing the request reveals that it would be a three-month pivot for a prospect that hadn’t signed. The team would have to abandon work that’s committed for some of the organisation’s highest-value clients in the coming quarter. The prospect’s ask is turned into a planned piece of work for the upcoming quarter instead, and communicated as such to the prospect.
If the interruption is accepted, then the work is brought to the team with the supporting context, so that they completely understand what is driving this decision, and the benefits of changing tack.
For example, an Account Manager flags that they need SSO integration for a $400k contract renewal in six weeks. The request is documented by the Account Manager in partnership with the Product Manager. The review reveals it to be approximately three weeks’ work that would put a planned performance optimisation at risk. With the commercial risk clear and the trade-off understood, the interruption is accepted. When it comes to the team, it comes with full context about the customer, the revenue at stake, and what is being deprioritised. No panic, just a calm pivot. The performance work can be planned for the next quarter, not lost in the chaos.
Why does this work?
The immediate benefit is obvious: your team isn’t interrupted until there’s a conscious decision that the work is necessary. But the compound effects run deeper.
First, you’re breaking the reaction cycle. When every ‘urgent’ request triggers immediate action, teams start to believe that planning is theatre. They stop investing mentally in the roadmap because experience has taught them it’s fiction. The review process signals that plans have value worth protecting, which also makes teams more willing to pivot when it’s genuinely needed.
By creating space for System 2 thinking, any request that comes to the team arrives with full context and explicit trade-offs. Teams can absorb the change calmly rather than reactively. There’s no need for an emotional reaction. The process builds trust, which aggregates over time.
Second, you are building a written record of requests, both accepted and rejected, that becomes valuable data for addressing how the organisational system works. How many interruption requests happen per month? Where do they originate? How often are they accepted? Six months in, you might discover that a high number of ‘urgent’ requests come from one account management team that aren’t triaging customer requests appropriately. You can then work with that team to understand how to deal with these requests rather than pass them on to the team.
The heat shield doesn’t just protect against individual asteroids. It’s an effective planetary defence mechanism.
What happens if everyone keeps reacting?
It’s going to take a while for the wider organisation to appreciate what you’re doing. If you can get an executive sponsor for the new process, it will help to get other parts of the organisation aligned.
Some rejections will result in escalations to senior leadership, and the record of the review will help ensure shared understanding of the decision. It may get reversed, but at least the logic will be clear.
The very act of slowing down, and playing back the request and its trade-offs will force people to slow down and really consider the value of the request. You’ll be surprised how often simply articulating the trade-offs transforms ‘must-have immediately’ into ‘let’s schedule this properly.’
Start responding
If you work in the kind of environment where plans get raised, and then get razed, introduce this process. You won’t immediately stop the interruption requests. They’re the organisation’s default System 1 reaction.
But you can protect your team by invoking a System 2 response. The asteroids will keep coming. Be the heat shield.