# Culture doesn’t eat strategy. Incentives do.
I managed the legacy pipeline. For about a year and a half I ran DevOps, the central CI/CD pipeline we had spent a couple of years galvanising the engineering community to adopt across every hub. It became the foundation Cloud First ran on. From there I moved into Cloud Enablement, and later into Information Cybersecurity, where I took on the security last mile team.
By then engineering leadership had decided the legacy pipeline could not scale. A new one was afoot. The performance narrative was clean. The truth was messier: it wasn’t the pipeline that could not scale, it was the habits underneath it, and the successor was going to expose them.
The last mile team owns the security controls the build must pass before anything reaches production. Application level controls, vulnerability scans, SAST, secrets, IaC, SCA, DAST, API, container. From that seat I watched the new pipeline land: faster, better engineered, friction dutifully removed from the developer value stream. And I watched the debt underneath grow. The risk acceptance queue never emptied. Escalations did not stop. Higher performance had not produced better hygiene. It had produced larger, uglier repositories, faster. The friction removal work had solved everything except the actual problem.
That is when it landed. **Culture doesn’t eat strategy. Incentives do.** In most large enterprises, we have engineered the incentives to produce exactly the developer behaviour we then complain about.
## The wrong diagnosis
The argument for the new pipeline was familiar: the legacy platform could not scale. That is a story large enterprises tell themselves regularly. Sometimes it is a real capacity constraint. Other times it is a proxy for something else: a leadership transition, a vendor decision, a desire for a clean slate.
In our case the diagnostic was incomplete on its face. The legacy pipeline had scaling paths that had not been exhausted, including horizontal scale, commercial variants, and targeted architectural work. None of them had been costed against the migration. The successor was cloud hosted, and cloud pipelines do not serve every jurisdiction cleanly. Countries with data residency constraints ended up on locally hosted runners that partly recreated the deployment pattern the migration was meant to leave behind. The consumption pricing model looked leaner in the pitch and heavier in operation. And there were tech stacks in the estate the new platform did not natively support.
None of this was hidden. It surfaced in reviews. It was noted, and it was proceeded past, which is not a failure of intelligence but a familiar pattern in transformation work, where a decision’s momentum tends to outrun its evidence. The interesting question is not why the migration proceeded. It is what the migration was really being asked to solve, and whether it could have solved that thing even if every technical criterion had been met.
The answer, as it turned out, was no. Because the constraint was not the pipeline. It never had been.
## It was never the pipeline
If the pipeline was not the constraint, what was?
The reflex answer is “culture.” Developer culture. Engineering culture. The old cliché, dusted off and applied. It is the wrong answer, and it has been wrong for a long time. When we say culture, what we usually mean is behaviour we do not like. When we say developer culture, we mean behaviour we do not like from developers. Naming it does not explain it. And blaming it does not change it.
The behaviour has a cause, and the cause is upstream of the developers by a considerable distance.
Large enterprises run on an annual funding cycle. Projects are approved and staffed at the start of the year. Teams stand up. Backlogs are populated. And two performance moments are already visible on the calendar: the midyear review, and the year end review. Compensation, promotion, and continued funding all move through those two doors.
Now ask what a rational team, staffed against that cycle, will optimise for.
They will optimise for visible delivery at the review moments. That produces a hockey stick shape in every measurable output: a slow ramp, a midyear surge, a year end sprint. Anyone who has worked in a large firm has seen the chart. It is not a cultural artefact. It is the deterministic output of how funding, staffing, and performance are timed against each other.
Hockey stick delivery is incompatible with continuous integration by construction. Continuous means every day. Hockey stick means every six months. You cannot run both.
If the review calendar rewards the sprint, the sprint wins. CI/CD becomes theatre in the last month before the demo. Branching hygiene erodes because velocity to demo trumps repo cleanliness. Pull requests get rubber stamped because the alternative is missing the window. And technical and security debt, the things whose remediation is invisible to a midyear review, gets *risk accepted and deferred*. That phrase, in a corporate register, is what “we will not fix this” looks like when the person saying it is measured on delivery, not on debt.
None of this is a failure of the developer. It is a rational response to the incentives the developer is measured against.
This is why tooling first transformations stall. You can make the pipeline faster. You can add every conceivable security scan. You can remove friction from the value stream and celebrate the throughput. And the underlying behaviour will not move, because the behaviour was never a function of the tooling. Pouring engineering effort into pipeline performance while leaving the operating model untouched is putting lipstick on a pig.
Two reframes fall out of this, and the rest of the essay follows from them.
First, it is not culture. It is operating model. If you want to change the behaviour, the intervention has to live at the layer that produced the behaviour: funding cycles, review timing, team persistence, ownership boundaries. That is a very different conversation from “developers need to care more about quality.”
Second, it is not developer failure. It is incentive design. When intelligent, well trained people consistently do the wrong thing, look at what they are being rewarded for. The developer is doing exactly what the system asked for.
## The Friction / Consequence Model
You cannot lecture people out of a rational response. Culture change memos, mandatory training, “quality is everyone’s job” posters: noise applied to a system whose signal is coming from elsewhere. If the incentive structure produces the behaviour, the intervention has to live at the incentive layer.
There are two levers a delivery organisation actually controls at that layer. Reduce the friction of the desired behaviour. Raise the cost of the undesired one. Neither works alone. Call it the Friction / Consequence Model, carrot and stick, but engineered.
Start with the carrot, because that is where most transformation programmes stop.
In cybersecurity we rebuilt the security last mile. Historically it had lived in an operations ticket system, off to one side of the developer pipeline, a queue of remediations opened after the fact, worked by different people, on a different tool, on a different clock. We moved it into the pipeline as a first class stage. Then we introduced a concept called *security noncompliance*: a signal delivered to the developer in the pipeline, in real time, warning them of any finding that would otherwise end up on the CISO’s risk acceptance queue. On that queue, critical and high findings do not get signed off, because CISOs hold domain risk targets, and they cannot spend risk they do not have. Fixing early, in other words, was the only path that did not end in escalation.
Around that we built the rest of the carrot stack. A real time application security posture graph showing which teams were fixing bugs and which were sitting on them. Targeted learning routed to the developers carrying the highest severity findings on the top CVE list. AI assisted fixes to lower the effort of remediation until the friction argument disappeared. Peer visibility, because engineers are more responsive to what other engineers are doing than to any policy document.
We had bent over backwards to make the right thing the easy thing.
It did not fully work. Visibility exposed the scale of the debt. Escalations dropped where they should have. But underneath, the rhythm did not change. The reviews still ran on the same calendar. The funding still ran on the same cycle. And a rational actor optimising for delivery at the review moment will still push debt into the next window, even when a beautifully designed carrot is asking them not to.
That is the empirical case for the second lever.
The consequence has to be immovable. Not aspirational. Not policy. Not an escalation path that becomes an approval workflow that becomes a rubber stamp. In practice: a deterministic risk score, calculated in the pipeline, that breaks the build above a threshold. No override. No standing exception queue, because a standing exception queue is a compliance mechanism that has already lost. And the organisational level consequence, the CISO’s risk appetite ceiling, held firmly enough that critical and high do not slip through under time pressure.
Carrot and stick, in the same pipeline. The carrot removes every honest excuse. The stick makes the dishonest ones unaffordable.
You still have not changed the operating model, but you have made the pipeline behave as if the operating model had changed. That is often the best a practitioner working two layers below the funding cycle can do. And on the strength of the case above, it is enough to start moving the debt in the right direction.
## The same pattern, everywhere
This is not a story about DevSecOps. Or not only.
Every transformation programme I have worked on has met the same wall. DevOps, cloud, cybersecurity, and the many transformation labels in between. Tooling is upgraded. Metrics improve. Dashboards go green. And underneath, the operating model that produced the original behaviour keeps producing it, because the operating model was never on the transformation roadmap. The pattern is universal; the specifics rotate.
What has changed, recently, is the cost of the pattern going unaddressed.
Frontier AI has compressed the attacker’s cycle. Vulnerabilities that once had weeks of exploit window now have hours. Bad actors have the same models defenders do, and they are using them to shorten every step of the kill chain. The operating model debt, the thing that used to be tolerable because remediation windows were forgiving, is no longer tolerable. Deferring a critical no longer means deferring it into an acceptable risk band. It means shipping an exploitable path into production before the review cycle it was going to be fixed in has even begun.
This is why CISOs cannot spend risk they do not have.
The Friction / Consequence Model is not a silver bullet. It is a way to engineer around an operating model you cannot reach, in an environment where the time to reach it has just run out. The real work sits above the pay grade of the practitioner: funding cycles, review timing, team persistence, ownership. The pipeline sits below it. Meet in the middle. Carrot and stick, in the same build. And if you are the executive committee, notice which way the causal arrow points.
Culture doesn’t eat strategy. Incentives do. In the current threat environment, the bill is due sooner than you think.