Hostility, resistance, complexity, anxiety: these are the four forces that obstruct anyone innovating inside a complex organization, and that I group in the book under the acronym O.R.C.A. Here I focus on the third one.
First distinction, and a fundamental one: complex and complicated are not synonyms. A complicated problem is hard, but it can be solved by following precise rules and procedures — you need skill, you need time, but the road exists. A complex system is made of dynamic interactions among many elements, which make the consequences of any intervention unpredictable. Public administration belongs to the second category, and in a rather extreme form.
Take INPS's digital services. Every service is born from a law, which must be translated into a procedure, which must be turned into a digital product. The work happens in silos: each area develops its own services with its own suppliers, each of whom brings frameworks, technologies and practices rarely coordinated with anyone else's. Then everything must flow into the same infrastructure and reach the same touchpoints — portal and app — giving citizens a coherent experience. In such an entangled ecosystem, even a small intervention propagates effects far beyond the perimeter where it was born. And the risk, it must be said, is rarely that of breaking invisible connections: far more often it is that of failing to connect at all — the technically successful project that lives in an operational bubble, correct within its own perimeter and without any impact on the system.
The watch metaphor
A complex system like the public administration resembles a mechanical watch: interdependent gears, where every movement influences all the others. When you introduce a new gear — an innovation — it isn't enough for it to work well on its own: it has to work together with the rest. The typical mistakes are two.
The wrong gear. An apparently effective intervention that alters the balance of the mechanism: at first everything seems to move, then the force disperses, the wheels jam, the watch loses precision.
The isolated gear. Perfect in its construction, but connected to nothing: it spins on itself without transmitting any movement. The most frequent case in the public sector.
Either way, the outcome is the same: time stops. Innovating in a complex system doesn't mean adding parts, it means tuning them to one another.
The three balancing acts
Moving inside such a system means keeping opposing forces in balance. Three balancing acts, in particular, have accompanied me in every project:
Change and conservation. Changing only what is necessary is much harder than tearing down and rebuilding from scratch — an option that, in organizations, is almost never on the table anyway. And there is an emotional component to handle with care: insisting on redoing everything sends the message that other people's work was inadequate, and breeds resentment. When we simplified the Institute's administrative forms, each form was the operational translation of laws to be respected to the letter: we kept the mandatory elements and worked on language, structure and practical examples. Preserve the regulatory value, change the experience.
Recklessness and awareness. Anyone facing a tangle of laws, procedures, obsolete technologies and isolated departments risks paralysis by complexity: if you looked at everything at once, nothing would ever get started. At the beginning of the INPS design system, creating a uniform solution for such a fragmented organization seemed unthinkable: a certain dose of recklessness was essential — temporarily ignoring the vastness of the problem and focusing on a first core of rules and components. Only after the first results did the necessary awareness kick in, to extend the system and integrate it with the rest of the organization.
Speed and gradualness. Innovations introduced all at once, in a complex context, have little chance of surviving. The new INPS brand arrived over many months, channel by channel: no operational discontinuity, time to get familiar, and constant communication of the results as they matured. Gradualness surfaces the interconnections one at a time, so the problems get solved one at a time.
Risk #1: the stone skipping on water
The first way to fail: the innovation that never penetrates the system and stays on the surface. You solve a local problem while ignoring the context — a project confined to one department, a tool developed without integration, a quick win that neglects the long term. If your project "skips" instead of sinking in, there are only two possible outcomes: doing damage or, if you're lucky, being irrelevant.
The case I know best: the early attempts to unify the look and behaviour of INPS's digital services, before Sirio was born. The need was real, and it spawned multiple well-intentioned initiatives — but fragmented ones, parallel to each other instead of integrated into a common effort. Adopting the guidelines wasn't mandatory, the necessary organizational areas weren't all involved, and each team carried on with its own tools and rules. Without central governance and an evolutionary vision, those initiatives worked well within individual projects and expired with them. Well-thrown stones, grazing the surface of the system without ever penetrating it.
Risk #2: the paper bridge
The second way to fail: the innovation that is ambitious and sound on paper, and collapses under the first real load because it ignores the technological complexity it should rest on. Underestimated legacy systems, neglected integrations, infrastructure costs that explode halfway through. The root cause is rarely technological ignorance in itself — normal for anyone who isn't an expert — but rather the lack of humility to acknowledge it and to lean on people who can assess real feasibility and costs.
The perfect example is the idea, ambitious and only apparently simple, of making all of INPS's digital services — roughly five hundred — available in a single native app, in one go. The goal is intuitive and legitimate: a single, coherent entry point for citizens. But:
The native app, like the web portal, is not the service: it is a container.
Inside that container live hundreds of applications built by different teams, with suppliers, languages and frameworks that don't always get along. Only a fraction of the services have mobile-optimized interfaces; integrating all of them would require the near-total redesign of many pre-existing systems — one service at a time, making sure each new gear fits without breaking the mechanism. The design system helps with visual coherence, but the underlying technological challenge remains. The outcome of the "one go" approach wouldn't be a spectacular failure, but something subtler: an incomplete innovation, one that promises unity and delivers fragmentation and disillusion.
Risk #3: the maze with no exit
The third way to fail: the innovation that, instead of simplifying the system, complicates it further. It happens when cross-cutting coordination, prioritization and integration are missing: every area works autonomously, introduces tools and rules that don't talk to the rest, and every new piece adds layers to an already unmanageable puzzle.
Real case: measuring citizens' satisfaction with digital services. Several organizational areas, each with its own supplier, independently developed their own instant-feedback tools. The result: dozens of mutually incompatible metrics, from the "like" to the Likert scale, by way of little hearts and little stars. Data that couldn't be compared, different formats, non-interoperable tools: instead of a clear picture of the citizens' experience, more complexity — resources spent without generating value for anyone. No governance had answered the two fundamental questions: which metrics matter? and in service of what?
There is a lesson inside this risk that alone is worth the price of admission: simplicity as a survival strategy. If the innovation is not the most direct, essential and proportionate way to reach the goal, it is adding complexity to a system that already has far too much. Every superfluous feature opens decision forks, interdependencies and integration points with unpredictable chain effects. Every design choice should pass a single question: is this really needed?
In short
Understanding complexity is what makes change deliberate: anticipating and managing the system's reactions, on top of solving the specific problem. The stone, the paper bridge and the maze are three different ways of ignoring the same truth: in a mechanical watch, no gear lives alone. One letter of the model remains, the most personal one: anxiety. I write about it in the piece that closes the series.