{"id":4763,"date":"2026-10-18T05:15:00","date_gmt":"2026-10-18T05:15:00","guid":{"rendered":"https:\/\/www.devopsfreelancer.com\/blog\/devops-tools-vs-habits-freelance\/"},"modified":"2026-10-18T05:15:00","modified_gmt":"2026-10-18T05:15:00","slug":"devops-tools-vs-habits-freelance","status":"publish","type":"post","link":"https:\/\/www.devopsfreelancer.com\/blog\/devops-tools-vs-habits-freelance\/","title":{"rendered":"Two Clients, Two DevOps Playbooks: A Comparison"},"content":{"rendered":"

In March, two clients hired me in the same fortnight. Both ran small software teams, both lost sleep over release day, and both had read the same articles about DevOps. Eighteen months later, one was shipping most days and sleeping through the night. The other had bought a lot of dashboards and stood exactly where it was. The difference was not budget, talent, or luck. It was the playbook each chose in the first week \u2014 and the comparison is worth walking through slowly, because one of these paths is far more common than it should be.<\/p>\n

Two Kickoffs, Two DevOps Beliefs<\/h2>\n

Ferryman runs a logistics tracking product with fourteen engineers. Its leadership opened with a purchase order: a pipeline platform, a monitoring suite, a security scanner, all from the same vendor family. “DevOps,” the CTO told me, “is what we just bought.” Brindle, a booking platform for holiday cottages with six engineers, asked a different opening question: “What would we have to believe for small releases to be safe every single day?” Same word, two religions. Everything that followed flowed from those first sentences.<\/p>\n

The First Playbook: Buy the Toolbox<\/h2>\n

Ferryman migrated everything onto the new stack in a quarter, and to be fair, the pipelines ran beautifully. Green ticks everywhere. But releases stayed quarterly in practice, because branches lived for weeks and nobody trusted the test suite enough to merge on a Tuesday. The platform team became a ticket queue for the rest of engineering. Dashboards filled with numbers nobody acted on, and two metrics were quietly repurposed as personal scoreboards, which is how measurements turn into theatre.<\/p>\n

The cost of that stall was calculable. One pricing feature, worth roughly 12 units of value per week across 5,000 users, slipped three weeks past its promised date \u2014 about 180,000 units of value unearned in that quarter alone. Then came the dip. Automation work raised the testing bar, throughput dropped, and because nobody had agreed in advance how long the dip could last, the programme very nearly got cancelled in month five. When a payment incident finally hit, recovery took hours, because \u2014 despite all the tooling \u2014 nobody had ever rehearsed a rollback. The tools had changed. The habits had not moved an inch.<\/p>\n

The Second Playbook: Change What Gets Rewarded<\/h2>\n

Brindle spent its first month drawing. A value stream mapping session on one booking flow showed that changes spent most of their life waiting \u2014 for review, for a release window, for an environment. So the window died for that service, branches were cut to days, and each build was produced exactly once and promoted as-is. The feedback target was simple: any commit should get a test verdict inside ten minutes. Rehearsal came next; the team drilled rollback on a payments sandbox until it was dull, which is the point. When the first real incident arrived, restoration took 25 minutes, and the review happened in a calm room within five working days, with no names attached.<\/p>\n

Notice what Brindle did not do. It did not create a DevOps team, did not run a big-bang programme, and did not add approval gates after the incident \u2014 the evidence linking heavyweight change boards to worse delivery is hard to argue with. It watched five numbers \u2014 lead time, release frequency, restoration time, failed-change share, and rework rate, the one DORA added in 2024 to catch work that comes back after being called done. Recovery had been redefined in 2023 to count only failures a change itself caused, which kept the number honest. The metrics lived on a wall, reviewed monthly, never ranked.<\/p>\n

What the DevOps Comparison Shows<\/h2>\n

Neither client’s outcome was mysterious. Adoption research has marked the coached-pilot route \u2014 one value stream, expert guidance beside it \u2014 at 4.25 of a possible 5; a toolchain rolled out from the centre took 2.40, and an organisation-wide edict 2.50 \u2014 Ferryman ran the second experiment, Brindle the first. The J-curve behaved as the literature says it does for both teams: quick wins, then a dip as automation raised the bar, then a climb. Only Brindle had agreed upfront how long its dip could run, which is why only Brindle crossed it. If you want the frameworks behind these numbers, xOps School keeps a thorough DevOps reference<\/a> that covers CALMS, the Three Ways and the maturity ladder that climbs from siloed teams to learning systems.<\/p>\n

The Quarter Ferryman Turned<\/h2>\n

Credit where due: Ferryman did eventually move, and the pivot was not technical. Their auditor arrived, asked for evidence of who changed what and when, and the vendor stack produced a beautiful report nobody could explain. Meanwhile Brindle \u2014 six engineers, no platform purchase \u2014 walked the same audit with a quarterly sample of roughly ten changes pulled at random, least-privilege access on every service, and short-lived credentials issued through OpenID Connect so that no long-lived key existed to leak. The auditor preferred Brindle’s evidence. So did Ferryman’s CTO, and that comparison landed harder than any benchmark I could have quoted.<\/p>\n

The following quarter, Ferryman shrank its change process instead of growing it. Migrations were rewritten to expand and then contract, so a rollback never had to reverse an irreversible step. The pipeline platform stayed \u2014 bought and paid for \u2014 but it started serving habits rather than replacing them: builds produced exactly once, promoted unchanged, verdicts back inside ten minutes. Six months on, they ship most Tuesdays. Not every day, and not heroically, but without the 11 p.m. war room. In my experience that is the realistic ceiling for a team that started with the toolbox: a season behind, yet salvageable, provided an audit or the market eventually forces the conversation the kickoff should have had.<\/p>\n

Choosing a Playbook for Your Own Team<\/h2>\n