Structural Correction

Chapter 15: Pull, Not Push

Central functions that mandate adoption produce compliance without substance. The board’s role is to verify annually that central capabilities are genuinely good, affordable, and funded through unit demand rather than top-down allocation.

Thomas's first quarterly review after the transitional fund renewal included the CISO's report on security posture across the four operational units: 94% compliance with the mandated container scanning policy.

Thomas asked a question the metric could not answer: “What does 94% compliance mean for our actual security risk?” The CISO explained that the scanning tool was integrated into every unit's deployment pipeline and that the remaining 6% was a configuration issue being resolved. Thomas asked a different question: “Are the units using the tool because they need it, or because we told them to?”

The answer took two weeks. Two of the four units had configured the tool to auto-approve all findings below critical severity, because the default thresholds generated hundreds of false positives and the units had no mechanism to work with the security team on tuning them. The dashboard showed adoption while the security risk was unchanged. “We are measuring whether the units consume what we push,” Thomas observed, “not whether they are managing the risk they own.”

The central security team had two responses available. One was to retool: work with each unit to tune the thresholds to its context, and offer the tool as a service the units would choose to consume. The other was to reframe: present the 94% as evidence of successful adoption, add a remediation plan for the 6%, and keep pushing the unchanged tool. The CISO chose the second. Six months later the dashboard showed 100%. Thomas asked whether the false-positive rate had changed; the CISO could not say, because the dashboard measured adoption, not substance. The units had learned to comply without consuming. Overt opposition is one reversal mechanism; the more common one is quieter. Central functions push capabilities rather than responding to demand, and governance obligations accumulate one reasonable request at a time, until the charter's authority has been hollowed without anyone deciding to hollow it.

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 it, and mandates its adoption. Security tools are mandated, compliance frameworks imposed, observability standards prescribed. Push appears responsible, because it produces the universal coverage metrics a board can review, and it produces compliance without substance: pushed observability produces dashboards nobody uses for operational decisions, pushed compliance produces checkbox adherence, pushed standards produce superficial conformity. The units adopt on paper, second-line oversight verifies compliance rather than substance, and risk ownership exists in the dashboard without operating in practice.

The autonomous unit model changes the incentive. Each unit owns its process and the risk attached to it, is monitored against its contracts and published SLOs, and is audited against those commitments. That accountability creates genuine demand for capabilities the unit cannot efficiently build itself: a unit that owns its process risk needs security capabilities it cannot build in-house; a unit that publishes SLOs needs observability that serves its own operations. The unit pulls for these because its accountability requires them, and the adoption is genuine because it is solving a problem the unit owns. The demand pattern itself becomes board-level evidence: each unit's quarterly report shows which central capabilities it consumed and why, and if three of four units consume the central security tool and one built its own, the question why is diagnostic, either the tool's quality is insufficient or the unit's governance has drifted.

...

See also: Full contents · Preview chapters · Illusions of Work