Every organisation has rules nobody can source.
“It must be Windows.” “The creative team only work on Macs.” “We don’t use open source.” Stated with the authority of policy, enforced with the consistency of law, and — when you ask where they came from — traceable to nothing more than habit, a long-departed IT manager’s preference, or a vendor requirement from a decade ago that no longer applies.
These are not constraints. They are inherited assumptions wearing the clothes of constraints.
The difference matters enormously. A real constraint shapes the solution. An inherited assumption blocks it for no return.
How to tell them apart
A genuine constraint is stable. It exists because of a dependency that is real and current — a regulatory requirement, a vendor agreement, an integration that cannot be abstracted away. Push on it and it stays exactly where it is, because it is grounded in something that does not move.
An inherited assumption behaves differently. Push on it and it shifts.
“It must be Windows.”
Propose a solution that works on Windows.
“We don’t support PHP.”
That is the diagnostic. The objection moved. Which means the first objection was not the real one, and the second may not be either. You are no longer dealing with a technical requirement. You are dealing with something else.
IT as a law unto itself
The hardest version of this pattern lives inside IT departments.
IT accumulates authority gradually and without always accumulating equivalent accountability. The constraints it enforces are rarely written down as formal policy. They are simply how things are done — and because IT controls infrastructure, procurement sign-off, and access, challenging those constraints feels like a political act rather than a technical question.
It is not malicious. It is territorial. The department has built a stable environment around a set of known tools and known behaviours. Anything outside that set creates work, risk, and the possibility of being blamed for something going wrong with something unfamiliar.
The instinct is to protect the perimeter. The shifting objection is the mechanism.
What agnostic actually means
A CTO brought in from outside has no allegiance to the ingrained pattern. That is not incidental to the engagement — it is the point of it.
Agnostic does not mean uninformed. It means the evaluation starts from the requirement, not the preference. What does this system need to do? What environment does it need to run in? What constraints are real? The answer to those questions determines the solution. The answer is not determined first and the questions arranged around it.
This is a different process from the one most organisations run internally, where the answer is known before the question is asked.
Pragmatic is not a compromise
The solution that emerges from a genuinely agnostic evaluation is sometimes unexpected.
WordPress runs on Linux. That is the standard deployment, the documented path, the configuration most developers know. It is also not the only valid configuration.
If an organisation runs a Windows environment — Windows hosting, Windows-trained infrastructure team, Windows tooling throughout — then deploying WordPress on Windows IIS is the right answer. Not a workaround. Not a compromise. The right answer, given the actual constraints of the actual environment.
Pragmatic and correct are not opposites. The best solution is the one that works reliably in the environment that exists, maintained by the people who are actually there.
What it is not is the textbook answer applied without reading the room.
A few rules
Ask where the constraint came from. Not confrontationally — as a genuine question. If nobody can answer it, it is not a constraint. It is folklore.
A constraint that moves when you apply a solution is a preference, not a requirement. Note the movement. It is more informative than the original objection.
The shifting objection is the real diagnostic. When the blocker migrates from “we need Windows” to “we don’t support PHP,” the conversation has changed subject. The question is now about territory, not technology.
Pragmatic is a method, not a concession. The best answer works in the real environment, with the real team, within the real constraints — not the ideal ones.
Distinguish between what the system needs and what IT prefers. Both are legitimate inputs. Only one is a constraint.
Richard King is CTO at Sixteen Pillars — technical leadership, architecture, and governance for organisations that need it without the overhead of a full-time hire.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.