FITS Framework, Part 4 of 4: How to protect ownership when deadlines slip, incidents escalate and the stakes are genuinely high.
The real test of ownership is not what happens during a normal week.
It is what happens when a release is at risk, a major customer escalates, production goes down, an executive asks for an immediate answer, or two teams reach an impasse with no time left to negotiate.
Until that moment, it can look as if the dependency has disappeared. Your Team Leads run their areas, decisions move without you and people bring recommendations instead of open problems. You have more time for strategy, organisational design and the work that actually requires your level of authority.
Then the pressure rises.
Suddenly, you are copied into every message. A Team Lead who was deciding independently asks what you want them to do. You answer one question, then another, and join the next call to help. Within hours, the team is executing again, but you are making the decisions, coordinating the dependencies and reporting the status.
The loop is back.
Not because the previous work failed. Not necessarily because the team was never ready. It is back because pressure exposes the part of the ownership system that was never made explicit: what happens when the normal operating conditions no longer apply?
This is the final part of FITS.
First, you Find the Dependency. Then you Interrupt the Pattern that keeps recreating it. Next, you Transfer Ownership with clear outcomes, decision rights, boundaries and accountability. Finally, you learn how to Stay Out of the Loop when every instinct tells you to step back in.
That does not mean remaining passive while the business is at risk. It means intervening at the right level without automatically taking the work, decisions and accountability back.
High stakes do not erase ownership
When the situation becomes serious, many leaders collapse several different risks into one conclusion:
This is too important. I need to take over.
Sometimes that conclusion is correct. A severe security incident, a legal or regulatory exposure, an irreversible architectural decision, or a trade-off that affects several organisations may genuinely require your authority.
But many situations that feel high stakes do not require a transfer of ownership back to you. They require faster visibility, tighter feedback loops, clearer constraints or a decision that only you can make. Those are not the same thing.
A slipping deadline does not automatically mean that you should rebuild the plan. An executive asking questions does not make you the project spokesperson. A production incident does not require you to direct every engineer. A cross-team conflict does not make you the permanent bridge between the teams.
Your role under pressure is to make the system safer and clearer. It is not to make yourself the system.
Taking over often works in the short term. Decisions become faster and the team feels protected because the most senior person is carrying the uncertainty. But the organisation learns that ownership is conditional. The team owns the work while things are going well. When it becomes visible, risky or politically uncomfortable, the leader owns it again.
That lesson is stronger than anything you said while delegating.
The difference between intervening and taking over
Staying out of the loop does not mean using the same level of involvement in every situation. It means choosing your involvement deliberately.
There are four useful levels.
1. Observe
The owner handles the situation and keeps you informed at an agreed cadence. You remain available if an escalation trigger is reached. This is appropriate when the impact is contained, the decision is reversible and the existing guardrails still apply.
2. Coach
You enter briefly to challenge the thinking or surface missing risks. The owner still recommends, decides and communicates. Useful questions include:
What changed since the original plan?
What is the actual risk if we do nothing for the next two hours?
Which part of this decision is reversible?
What options did you reject, and why?
Who needs to be involved because they hold relevant authority or information?
What decision do you believe we should make?
If you ask and then provide the answer anyway, you have only delayed the takeover by ten minutes.
3. Constrain
You set or tighten the boundaries within which the owner can act. You might define the maximum acceptable customer impact, protect a non-negotiable standard, approve resources or make an organisation-level trade-off. The team still owns the response.
For example:
We cannot move the regulatory deadline, and we will not reduce the validation scope. You own the recovery plan. You can pause the lower-priority initiative and pull in one engineer from the platform team. Bring me a recommendation by 2 p.m., then update me every four hours.
That changes constraints and provides leverage without turning you into the project manager.
4. Take command temporarily
Sometimes you do need to step in. The decision may exceed the owner’s authority, the consequences may be severe and irreversible, or the situation may require judgement the team has not yet developed.
The important word is temporarily.
A legitimate step-in has three explicit parts:
The reason: Why does this situation require your authority now?
The scope: What exactly are you taking over, and what does the existing owner still own?
The exit condition: When and how will ownership return?
You can say:
I am going to make the customer commitment because it affects three organisations and exceeds the authority we agreed. You still own the recovery plan, technical decisions and team coordination. Once the commitment is made, communication returns to you. Tomorrow we will review whether our original escalation boundary was clear enough.
Without those elements, a temporary intervention quietly becomes the new operating model.
Pressure is not an escalation criterion
One of the most useful distinctions I make with leaders is the difference between risk and discomfort. Risk belongs to the situation. Discomfort belongs to the leader.
An executive asking for an update can create discomfort without changing delivery risk. A Team Lead choosing a different approach can feel uncomfortable even when the decision is sound and reversible. Not knowing every detail can feel dangerous when you have historically known everything.
If discomfort is allowed to masquerade as risk, almost anything can justify re-entering the loop.
Before you intervene, ask:
Has the potential impact materially changed?
Is the next decision irreversible or difficult to reverse?
Does it cross a legal, security, financial or reputational boundary?
Does the current owner lack the authority, information or capability required?
Is there truly no time to coach or constrain before acting?
“This is visible to senior management” is not, by itself, an escalation criterion. Neither is “I could solve this faster.”
Build the pressure protocol before you need it
You cannot design good decision boundaries in the middle of an incident. By then, everyone is optimising for speed, and the most familiar pattern wins. This is why the ownership transfer from Part 3 needs a pressure protocol.
For every meaningful area of ownership, agree on five things in advance:
The escalation trigger: Use observable conditions such as customer impact, security exposure, delay beyond an agreed threshold, a decision affecting another organisation or spend beyond the owner’s authority.
The continuing owner: Escalation should change access to support and authority, not automatically change ownership. A Team Lead can remain the delivery owner while you remove an organisational blocker or negotiate with another director.
The decisions that move upward: Identify the specific decisions requiring a different authority level. Leave the rest where they were.
The temporary visibility cadence: A weekly update might become daily or an asynchronous summary might become a short check-in. That is increased visibility, not reclaimed ownership.
The exit condition: Define when the temporary structure ends. Otherwise, crisis rituals survive the crisis and decisions that were independent keep returning for approval.
The five-step Stay Out protocol
When pressure rises, use this sequence.
Step 1: Name the risk
State what has actually changed. “The release might slip” is vague. “The integration will miss the testing window unless we remove one dependency by Thursday” gives the team something to manage.
Step 2: Reconfirm the owner
Ask, “Who owns the next move?” Resolve ambiguity before discussing solutions. A room full of helpers with no owner produces activity, not accountability.
Step 3: Choose the lowest sufficient level of intervention
Observe, coach, constrain or temporarily take command. Do not default to the highest level because it creates the fastest feeling of control.
Step 4: Time-box your involvement
Be explicit about why you are entering and when you will leave. Join one decision meeting, review one recommendation, open one cross-organisational door or lead the first thirty minutes of an incident.
Step 5: Hand back visibly
Do not assume that ownership will return naturally. State it.
The escalation condition has cleared. Sara owns the next phase and will provide the Friday update. I am stepping out of the working channel and returning to the original check-in cadence.
Everyone watching needs to see that escalation did not permanently move authority upward.
What this looks like in common senior leadership situations
A critical deadline is slipping
Instead of rebuilding the scope, assigning work and reporting upward, ask the owner for their assessment and recommendation. Decide only the trade-offs requiring your authority, agree on the update cadence and let the owner run the recovery.
A production incident becomes highly visible
Preserve the incident roles, ensure the technical lead has decision authority, remove organisational blockers and manage the stakeholders at your level. If you assume command, define the scope and return it when your authority is no longer required.
Two teams are blocked by a dependency
Resolve the priority or resource conflict that the teams cannot resolve themselves, require named owners on both sides and make their interface explicit. You own the organisational boundary. You do not become the permanent bridge across it.
An executive challenges the team’s decision
Let the owner explain the reasoning, support the decision boundary you gave them and step in only where the conversation reaches a trade-off belonging to your role. Team Leads cannot develop executive presence if the senior leader takes the microphone whenever the room becomes uncomfortable.
After the pressure: run an ownership review
A normal post-incident review asks what happened and how to prevent the technical or delivery failure from recurring.
An ownership review asks a different set of questions:
At what moment did ownership become unclear?
Which escalation trigger worked, and which one was missing?
Did the right decisions move upward, or did all decisions move upward?
Where did I add necessary authority?
Where did I act mainly to reduce my own discomfort?
Did I bypass the owner in communication or decision-making?
What temporary meetings, approvals or reporting lines must now be removed?
What judgement does the owner need to build before the next situation?
The purpose is not to criticise the leader for stepping in. It is to prevent an emergency response from becoming a permanent dependency.
Sometimes the conclusion will be that you should have intervened earlier. Staying out is not a virtue when the agreed risk boundary has clearly been crossed. The goal is not minimum involvement. It is the correct involvement.
The hardest part is tolerating a different answer
Even after the structure is clear, there is a deeper leadership challenge.
If ownership is real, people will sometimes make decisions differently from you. They will run meetings differently. They will communicate with less polish. They may take a route you would not have chosen. Occasionally, they will make a mistake you could have prevented.
This is where many transfers quietly fail. The leader says the team owns the outcome, but continues to use personal preference as an invisible standard. Under pressure, that preference suddenly becomes a reason to intervene.
Staying out requires separating three things:
A decision that is different from yours
A decision that is weaker but still inside the agreed boundary
A decision that creates unacceptable risk
Only the third one automatically requires escalation.
The team does not become more capable because you wait for them to think exactly like you. They become more capable because they learn to make sound decisions, see consequences and adjust their judgement while the boundaries are still safe.
The real leverage appears when they start producing answers you would not have produced yourself, including some that are better.
What we work on in coaching
In coaching, we do not discuss pressure as an abstract leadership principle. We take a real incident, deadline or escalation and reconstruct the exact moment ownership moved back to the leader.
We look at what the leader knew, what they feared, what authority was actually required and what they did next. Then we redesign the escalation triggers, decision boundaries, communication path and handback. When another high-pressure situation appears, we use the live situation to practise choosing the lowest sufficient level of intervention.
This is usually where the whole FITS system becomes real. It is relatively easy to delegate when the work is predictable. It is much harder to remain a leader of the system when your credibility, customer or deadline feels exposed.
A practical exercise for this week
Choose one important area that someone else now owns. Do not choose the easiest one. Choose an area where you know you would be tempted to step in if something went wrong.
Write down:
The observable conditions that require escalation
The decisions that still belong to the owner after escalation
The decisions that require your authority
The temporary visibility cadence under pressure
The condition that ends your involvement
Share it with the owner and ask where they see ambiguity.
Then ask each other one final question:
If the pressure doubled tomorrow, what would pull ownership back to me?
Whatever answer you get is the next dependency to design out of the system.
How you know you are out of the loop
You are not out of the loop because your calendar is empty or because nobody asks you for help.
You are out when the organisation can face serious pressure without making you the automatic owner of every important decision.
You still have visibility. You still protect standards. You still make the decisions that genuinely belong to your level. You still step in when the risk crosses an agreed boundary.
But the team continues to think, decide, coordinate and communicate. Your involvement increases the system’s capacity instead of replacing it.
That is the difference between a team that can operate without you during a quiet week and an organisation that can lead without depending on you when it matters most.
The complete FITS framework
The four parts work as one system:
Find the Dependency: Make visible where decisions, meetings, coordination and escalations still depend on you.
Interrupt the Pattern: Stop the automatic responses and routines that keep pulling ownership back.
Transfer Ownership: Move outcomes, decision rights, judgement, accountability and feedback loops to the right level.
Stay Out of the Loop: Protect that ownership when the stakes rise, intervening without becoming the permanent centre again.
Reading the framework is the easy part. Applying it to your own role is harder because the dependency often hides inside behaviour that looks responsible, helpful and necessary.
One Senior Mobile Engineering Manager I worked with removed three recurring meetings, reclaimed more than six hours a week and created more space for roadmap and modernisation work. The time was not recovered through better calendar management. It was recovered by changing where ownership lived.
If you are a tech founder or senior engineering leader and your team is capable but too much still depends on you, this is the work I do in Get Out of the Loop, my 1:1 coaching program.
We use your real meetings, decisions and escalations to work through FITS, so that you can regain time without lowering standards or abandoning the team.
Book a Fit Call, or send me “LOOP” if you want to explore where the dependency is currently sitting in your organisation.