> ## Content Index > Fetch the complete content index at: https://mikegarcia.io/llms.txt > Use this file to discover other available public pages before exploring further. # Cultural transformation has an error budget - URL: https://mikegarcia.io/cultural-transformation-has-an-error-budget/ - Published: 2026-04-04T19:00:16.000Z - Updated: 2026-07-31T23:28:57.000Z - Description: Each practice is a component cutover. The team's own metrics are the SLIs. Regressions consume error budget. Culture shifts as a downstream consequence. - Author: Miguel Garcia - Tags: Team Transformation, Engineering Culture, SRE, Automation Operations teams already have the discipline—the mechanics of migrating a system move that discipline into code. Operations teams troubleshoot infrastructure methodically and write up findings, then build procedures so the same failure doesn't repeat. That rigor rarely reaches their own scripts and configurations. Production changes happen through direct server edits because the path works and nobody framed coding practices as the same systematic work. Each practice introduced is a component cutover. The team's operational metrics are the SLIs, and the SLO is the acceptable range for each one. Each regression consumes error budget. When the budget is spent, the practice gets pulled back and adjusted, then reintroduced. The cultural shift follows from applying existing discipline through better tooling. ## Call it what they already do A component swap hides behind a stable interface. Consumers keep calling it while the implementation changes underneath, and nothing on their side notices the swap. For a practice, the vocabulary is that interface. Framing new practices as training implies the team has been doing something wrong. Professionals who keep critical systems running often resist that framing, even when they'd accept the practice itself. The same practices land as extensions of existing discipline. Version control is change tracking for code. Code review catches problems before deployment, using the diagnostic instincts the team already applies to infrastructure. Testing extends upstream: find the defect before it ships, with skills the team already has. ## Metrics control the pace A system migration that burns through its error budget triggers a rollback. Cultural transformation needs the same mechanism. The SLIs come from metrics the team already owns and can explain: change frequency (deployment frequency once a pipeline exists), incident resolution time, manual effort per change. The SLO for each marks the line it has to stay on the good side of: a floor for deployment frequency, a ceiling for resolution time, and a ceiling for manual effort. A regression in any of them spends error budget, and the practice gets pulled back when the budget is exhausted, not the first time a metric dips. A practice that doubles manual effort and keeps it there has burned its budget. One that slows deployments by 10% for two weeks is spending the budget on adjustments, recoverable if the signal bounces back. The signals move on their own. The interpretation requires judgment. A metric dips in week two. Is the practice failing, or is the team still building the habit? Rejection looks like a dip that correlates with a specific practice, shows up across the team, and draws complaints about the practice itself. Adjustment is different: the dip coincides with an unrelated incident, affects only the people still building the new habit, or fades within a sprint. Check-ins make that distinction. Without them, every regression looks the same. ## The big-bang cutover fails for culture too Introduce version control, code reviews, testing, and CI/CD in the same sprint. The team hears one message: everything you've been doing is wrong. Frustration comes from two directions. One is visible: "That's developer stuff." The objection targets what the practice represents, not what it does. The other is invisible. Under production pressure, hands go to the manual fix. The old response fires before the new one has been practiced enough to compete. Simultaneous introduction compounds both. Each practice gets a fraction of the repetition it needs. Every subsequent attempt carries the friction of the last one. ## Practices stick when the cost arrives after the payoff Vocabulary reduces friction at introduction. What makes a practice persist is whether the person gets something concrete before the overhead becomes visible. Some practices pay fast. Code review catches a production-bound defect in the first week, and the person who found it defends the process. Version control's payoff is slower. The daily cost (branching, writing commit messages) arrives immediately. The return (reverting a bad change, tracing when something broke) may not land for weeks. Front-load the practices whose payoff is fastest. That's the migration's cutover order: the components that validate fastest ship first. The slower ones arrive with credibility borrowed from the earlier ones. Version control is the exception: as the foundation the rest need, it earns its place by making the repo-to-running path visible early. Resistance to the next practice shrinks when the last one already paid off. ## Each practice creates the demand for the next Version control is the foundation. Deployment pipelines and automated test gating need code in a repository. Code review and local testing get sharper once it's there, but they don't require it. Version control lands fastest when the team can see a path from the repo to the running system, even a manual one. Without that path, version control adds a step without replacing one. Even with the path in place, the old step closes only when the team stops editing servers directly. Automated test gating needs a point in the automated flow to attach to: a commit, a push, or the moment a merge lands. The motivation for testing often arrives before the gate does. A defect slips through review into production, and the team feels the cost. By that point, testing feels overdue. The demand emerged from the workflow. The vocabulary framing still helps it land as operational discipline. Automation formalizes whatever workflow exists. If the workflow is incomplete, the pipeline automates confusion. Different baselines produce different sequences, but the principle holds: each practice creates the conditions for the next one. ## The migration succeeds when nobody calls it one A production incident or a routine deployment. The team responds through version-controlled changes and tested fixes, deployed automatically. The old path doesn't occur to anyone. It stopped being the default somewhere between the second and third practice, and nobody marked the date. The transformation is complete when the manual edit would feel unnatural.