I have worked with smart people, in organizations with good intentions and modern practices. And yet I kept seeing the same things go wrong. In the same places. That made me think.
Developers found security restrictive. Security teams found developers reckless. Operations wanted stability while management wanted speed and innovation.
The usual diagnosis is: a communication problem. Teams need to collaborate more. Meet more often. Have more understanding for each other. And so: more meetings, more alignment sessions, more joint retrospectives.
I have heard that advice given many times. And I have seen how little it structurally solved. Because a year later, the same organization had the same tension — just now with a fuller calendar.
More consultation solves nothing when people operate from fundamentally different logics. They are not talking past each other because they don’t know each other — but because they understand each other quite well and still disagree about what matters.
I probably look at this differently due to my background. Alongside my work in IT, I studied public administration. During those studies I read Jane Jacobs and her book Systems of Survival. Jacobs describes how societies function from two fundamentally different moral systems. Some systems are oriented toward protection, stability, and control. Others toward trade, innovation, and movement. Both are necessary, but they look fundamentally differently at risk, responsibility, and change.
Years later I began to see the same patterns — first in IT organizations, then also in industrial environments.
Cybersecurity, operations, and IT management largely function from a protective logic. Safeguarding continuity. Accountable for disruptions, incidents, and availability. From that perspective, caution is rational. Control is rational. Standardization is rational.
Development teams and innovation departments often function from the opposite logic. Enabling change. Rewarded for speed, new functionality, and growth. From that perspective, governance feels like delay. Extra controls feel like friction.
And suddenly a lot of behavior started making sense to me.
The developer who gets frustrated by change procedures is not necessarily immature. The security engineer who demands additional controls is also not automatically bureaucratic. These teams clash not because people are difficult, but because they serve different moral logics.
In industrial environments that tension becomes even sharper
An IT developer who wants to deploy something can, at worst, roll it back. A process operator on a production floor works with physical installations, safety systems, and processes that cannot simply be restarted. A firmware update on a PLC is not a sprint task — it is a change with potentially physical consequences, where the people near the installation have a stake in you being careful.
I have worked in those kinds of environments. And what always struck me: the tension rarely sat in the technology itself. The technology was solvable. The tension sat in the seams — the interfaces between systems, between teams, between responsibilities.
But I saw that same dynamic outside technical environments too. When I was involved in a large-scale educational reform — new pedagogical models, programmatic assessment, different organization — I recognized exactly the same pattern. Teachers safeguarding the quality and continuity of education. Innovators wanting speed because the world is changing and education must keep up. Two groups with good intentions, but with fundamentally different definitions of success. And the tension there was also not in the people, but in the seams — the places where schedules, assessment systems, and working methods didn’t connect because they had been designed from different logics.
That was the moment I realized this pattern is not sector-specific. It exists in every organization that must simultaneously protect something and change something.
That insight also changed my view on architecture.
Many organizations still see architecture as a technical discipline: designing systems, establishing standards, modeling infrastructure. But the hardest questions are rarely purely technical.
How do you give development sufficient speed without fully relinquishing control? How do you prevent security from becoming a brake on innovation? How do you protect stability without making every experiment impossible?
These are ultimately not purely technical questions. They are governance questions. And it is precisely that combination — technical and governance — that I find most valuable in my work.
Perhaps that is also why many DevOps and DevSecOps transformations prove more difficult than expected. Organizations try to bring two different logics closer together, but treat the tension as if it is fully resolvable. I think that is a misconception.
A healthy organization actually needs both systems. Without protective logic, chaos and fragility emerge. Without innovative logic, stagnation and loss of adaptability emerge.
But then what?
If more consultation is not the solution, and the tension is inherent to how organizations work — what do you do with it?
My answer is: treat it as an architecture question, not a process question.
Most organizations try to manage the tension with better governance. Clearer procedures, faster change boards, more disciplines at the table. That helps marginally. The fundamental problem remains: control sits as a gate after the development process, so it structurally feels like a brake.
What does help are three principles I keep seeing work in practice.
Design the boundary, not the behavior. Stop trying to control what happens within a team or system. Instead, control the interfaces — the places where systems and teams touch each other. Within that boundary: freedom. Across that boundary: governance. In industrial environments this has been practice for years — zones and conduits, ISA-95, the Purdue model. The IT world can learn more from that than it often realizes.
Make the safe path also the fast path. If the safe option costs more effort than the unsafe one, people will structurally choose the unsafe one. Not out of unwillingness, but out of time pressure. The solution is not stricter enforcement — it is lowering the threshold for the right choice. Pre-approved infrastructure, automated checks, standard solutions that developers can simply pick up. The freedom remains, but the friction sits on the right side.
Differentiate on risk. Not every change is equal. A UI adjustment is fundamentally different from a change in authentication logic or an update on a PLC that controls a physical process. Organizations that have one change process for everything create the frustration themselves. Those who take risk seriously make distinctions — and give low-risk changes the space to move quickly.
The overarching principle behind all of this: you don’t resolve the tension between protection and innovation by bringing people closer together. You resolve it by designing the architecture so that speed and safety are no longer each other’s opposites.
That is ultimately what an architect does. Not choosing between the two logics — but building the environment in which both can exist.