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. The tool was mandated by information security policy, integrated into every CI pipeline, and reported weekly compliance metrics to the executive team. Compliance stood at 94%.

An internal audit of the payments team, which was six months into operating as an autonomous unit, revealed something the compliance dashboard could not show: 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 per week and the team had no relationship with the security function through which to resolve them. The scanner ran, the pipeline was green, and the security posture was unchanged.

The motor insurance unit, which had been autonomous for nine months, had a different relationship with the same capability. The unit owned its process risk, was audited against its policy commitments, and had identified that its payment card handling required specific security controls the unit lacked the expertise to build. The unit lead had contacted the security team, negotiated a service agreement, and integrated the scanning tool with custom thresholds tuned to the unit's actual risk profile. The same tool, consumed through demand rather than mandate, was producing 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, while the demand-driven adoption produced security. The previous chapter described what remains central after the transition: platform infrastructure, regulatory coordination, and M&A integration. This chapter describes how those central capabilities relate to the autonomous units they serve, because getting this relationship wrong is the most common mechanism through which the central function recaptures governance authority under a different name.

The default relationship between a central function and the rest of the organisation is push: the central function defines what is needed, builds or procures the capability, and mandates its adoption. Security tools are pushed into every pipeline, observability standards into every service, and compliance frameworks into every process. The push model appears responsible, because the central function can point to universal coverage and the executive team can report that the capability exists across the organisation.

The push model fails in the autonomous unit context for a specific reason: it treats the units as consumers of mandates rather than owners of their processes. When a security tool is pushed into a unit's pipeline, the unit has no ownership of the security problem the tool addresses. It complies because compliance is required, not because it has identified a risk within its process that the tool helps manage. The difference is visible in the opening vignette: one unit produces a green dashboard, the other produces genuine security improvement, and the only variable is whether the unit consumed the capability because it needed it or because it was told to.

The failure is not limited to security. Every central capability that is pushed rather than pulled exhibits the same pattern. Pushed observability produces dashboards that nobody reads, because the dashboards were designed by the central team for the central team's reporting needs rather than for the unit's operational needs. Pushed compliance frameworks produce checkbox adherence, because the framework was designed for a generic process rather than for the unit's specific process and its specific risks. Pushed architectural standards produce superficial conformity, because the standards were written for a system map that does not match the unit's actual service topology. The pattern is consistent across domains: pushed capabilities produce reporting compliance without operational improvement, because the unit has no ownership of the problem the capability is meant to solve and therefore no incentive to make the capability genuinely effective.

The autonomous unit model changes the incentive structure that makes the push model the default. In the previous structure, no one owned the process, which meant no one owned the process risk, which meant the central function had to push capabilities because no one would pull for them. The central function pushed security tools because no team was accountable for the security of its process. It pushed compliance frameworks because no team owned the compliance obligations associated with its process. The push model was a consequence of absent ownership, and it was the rational response to the structure that produced it.

...

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