Culture doesn't eat strategy. Incentives do.
Reuben Athaide
SubscribeSign in
Culture doesn't eat strategy. Incentives do.
Reuben Athaide<br>Jul 12, 2026
Share
# Culture doesn’t eat strategy. Incentives do.<br>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.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.
Subscribe
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.<br>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.<br>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.<br>## The wrong diagnosis<br>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.<br>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.<br>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.<br>The answer, as it turned out, was no. Because the constraint was not the pipeline. It never had been.<br>## It was never the pipeline<br>If the pipeline was not the constraint, what was?<br>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.<br>The behaviour has a cause, and the cause is upstream of the developers by a considerable distance.<br>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.<br>Now ask what a rational team, staffed against that cycle, will optimise for.<br>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.<br>Hockey stick delivery is incompatible with continuous integration by construction. Continuous means every day. Hockey stick means every six months. You cannot run both.<br>If the review calendar rewards the sprint, the sprint wins. CI/CD becomes theatre in the last month before the demo. Branching hygiene...