The Fix

Chapter 18: Pull, Not Push

Central functions that mandate adoption produce compliance without substance. When autonomous units own their process risk, they pull for capabilities they genuinely need rather than performing compliance with tools they did not choose.

The CISO of a European retail bank had rolled out a container scanning tool across all development teams eighteen months earlier. It was mandated by security policy, integrated into every CI pipeline, and reported weekly compliance metrics to the executive team. Compliance stood at 94%.

An audit of the payments team, six months into operating as an autonomous unit, revealed what the dashboard could not: the team had integrated the scanner but configured it to auto-approve all findings below critical severity, because the default thresholds produced four hundred false positives a week and the team had no relationship with the security function through which to resolve them. The scanner ran and the pipeline stayed green, while the security posture stayed exactly where it had been.

The motor insurance unit, autonomous for nine months, had a different relationship with the same capability. It owned its process risk, was audited against its policy commitments, and had identified that its payment card handling required controls it lacked the expertise to build. The unit lead contacted the security team, negotiated a service agreement, and integrated the tool with thresholds tuned to the unit's actual risk profile. The same tool, consumed through demand rather than mandate, produced genuine security improvement rather than dashboard compliance.

The CISO's problem was not the tool but the direction of authority: the mandated rollout produced compliance metrics; the demand-driven adoption produced security. Once authority moves to the units, three capabilities stay central: platform infrastructure, regulatory coordination, and M&A integration. How those capabilities relate to the units they serve is where the central function most often recaptures governance authority under a different name, and the mechanism that prevents it is the direction in which capability flows.

The default relationship between a central function and the rest of the organisation is push: the function defines what is needed, procures it, and mandates its adoption. Push was a consequence of absent ownership: when no one owned the process, no one owned its risk, so the central function had to push capabilities because no one would pull for them. The unit then complies because compliance is required, not because it has identified a risk the tool helps manage, which is why pushed observability produces dashboards nobody reads and pushed compliance produces checkbox adherence.

The autonomous unit model inverts the direction. The unit owns its process risk, is audited against its published commitments, and needs security capabilities it cannot efficiently build and observability that serves its operations rather than a central team's reporting. It pulls for these because its accountability requires them, and the adoption is genuine because it is solving a problem it owns rather than satisfying a mandate it was handed.

Accountability alone does not produce the pull. Three conditions must hold, and if any fails the units will either build locally, producing fragmentation, or not comply, producing risk the organisation cannot see.

The capabilities must be good. A unit that pulls for security help and receives a tool producing four hundred false positives a week has a legitimate grievance; one that receives a dashboard built for executive reporting rather than operational diagnosis will build its own. The central function must understand what units need rather than defining what they should have.

...

See also: Full contents · Preview chapters · Illusions in the Boardroom