Escalating Requests to Sponsors
Pushback from IT, security, and data teams can be incorrect, and the errors tend to follow predictable patterns.
A Project That Stalls for Reasonable-Sounding Reasons
Consider a high-priority project that needs a new dataset within two weeks. The request goes to the data team, which replies that the access request is in a queue with many others and will be handled later. Somewhere else, the IT team has declined a request because the form did not match the format they usually process. The security team has added a restriction designed for a completely different kind of risk. Each team sounds reasonable on its own terms. Yet the project stalls.
This article is about learning to tell when a team's objection is mistaken, and what the FDE does about it. The main idea is simple to state: a team applies its normal reasoning to a request that does not match the situation that reasoning was built for. Once you can see that pattern, the right next step becomes clearer.
Following the Stalled Project Step by Step
Before naming any principle, trace what happens to the project over time. Each objection arrives at a different team, and each team responds from its own point of view. The diagram below lays out the sequence in the order the events occur.
Read the diagram as a state of the request rather than a list of complaints. At the start, the request is simply a need with a deadline. After the data team's reply, it is a queued item. After the IT team's refusal, it has a formatting problem. After the security team's restriction, it carries a control that was never meant for it. By the end, the original need has been replaced by a set of local objections, and nobody is looking at the need itself.
Pushback That Is Mistaken
Pushback from IT, security, and data teams can be incorrect, and the errors tend to follow predictable patterns. A mistaken objection is one where the team's reasoning is sound in general but does not fit the situation of this particular request.
The source emphasizes that the error is not usually carelessness. Each team is doing its normal job. The problem is that its normal job assumes a typical request, and this request is atypical. The test is therefore not whether the team's reasoning is good in principle, but whether it applies to the request at hand.
A team's objection is mistaken when its reasoning is correct for the situation it was designed for but the current request does not belong to that situation.
Three Predictable Habits
The source names three teams and a specific habit for each. It helps to see the three habits side by side, because they are examples of one underlying phenomenon rather than three unrelated problems.
| Team | Typical mistaken habit | Why the objection is mistaken | What it is really about |
|---|---|---|---|
| IT | Refuses a request because its shape does not fit the standard format | The request may be sound; only its form differs from the usual one | Form, not need |
| Security | Applies a control suited to a different threat model | The control addresses a risk that this request does not carry | Wrong threat model |
| Data | Deprioritizes an access request that only resembles routine work | The request is treated as routine when it is urgent or different | Resemblance, not substance |
The three predictable incorrect patterns named in the source
Notice the shared structure. In each row, the team's objection depends on a surface feature of the request, such as its format, its apparent risk category, or its apparent similarity to routine work. In each case, the objection would be correct if the surface feature really reflected the request's substance. The mistake is treating the surface as the substance.
Checking One Objection Against the Request
Deciding whether an IT refusal is mistaken
An IT team declines a request because the form does not match the format it usually processes. The requester believes the need is genuine and urgent. Is the objection mistaken?
- 1Identify the reason given
The stated reason is that the form's shape does not fit the standard format. This is a reason about form.
- 2Ask whether the reason concerns need
The source describes IT refusals of this kind as a question of form rather than need. So the next question is whether the need itself is in doubt.
- 3Check whether the need is real
If the request genuinely serves the project and the only problem is that it does not look like a standard submission, the objection concerns form and not the substance of the request.
- 4Make the classification
The objection is mistaken for this request, because the team's reasoning about format does not address whether the request should be fulfilled.
The IT objection is mistaken. The FDE should not accept it as a valid reason to stop, and should move to escalation.
The FDE's Move: Escalating to the Sponsor
Once the FDE can see that a team's pushback is mistaken, the FDE's job is to escalate the request to the sponsor. The source is specific about what this does and does not mean. The FDE does not simply accept the objection, and does not simply override the team.
Escalation moves the decision to the person who has authority over the project. The mismatch is made visible in the process: the sponsor sees that the objection rests on form, or on the wrong threat model, or on resemblance to routine work, rather than on the substance of the need. The diagram below shows the order of events.
Mistakes When Escalating Pushback
Common mistake Treating every objection as a valid judgment
What it looks likeThe data team says the request is queued, so the FDE waits without checking whether the queue applies to an urgent request.
Why it failsEach team's objection should be checked against the request. Accepting it without that check lets a surface feature decide the outcome.
Do this insteadAsk whether the team's reasoning fits this request before accepting it.
Common mistake Overriding the team directly
Why it failsThe source states that the FDE does not simply override the team. Overriding bypasses the person with authority over the project.
Do this insteadEscalate to the sponsor so the decision moves to the person who has authority.
Common mistake Escalating without naming the mismatch
Why it failsThe escalation is meant to make the mismatch visible. A vague escalation gives the sponsor nothing to evaluate.
Do this insteadState whether the objection rests on form, on the wrong threat model, or on resemblance to routine work.
Common mistake Assuming the three teams make the same kind of error
Common mistake Reading each objection as a fresh, unrelated judgment
Why it failsThe three habits share one underlying phenomenon: normal reasoning applied to a request it was not built for.
Do this insteadLook for the shared pattern before deciding how to respond.
Classifying Objections in Practice
A security team objects to a request because it applies a restriction meant for a different kind of risk. Before reading the hints, decide whether this objection is mistaken, and state which of the three habits it resembles.
Hints
- Ask what threat model the restriction was designed for.
- Ask whether this request carries that risk at all.
- The predictable habit for security teams is applying a control suited to a different threat model.
Key Takeaways
- A team's pushback can be mistaken even when its reasoning is sound in general, because the reasoning was built for a different kind of request.
- IT, security, and data teams tend to err in predictable ways: refusing on form, applying the wrong threat model, and deprioritizing requests that only resemble routine work.
- When the FDE judges pushback to be mistaken, the FDE escalates the request to the sponsor, with the mismatch made visible.
- The FDE neither simply accepts the objection nor simply overrides the team; escalation moves the decision to the person with authority over the project.