Six Myths About Transformation Pace That Stall DevOps Change

Every consultant who has spent a few years inside enterprise IT has a version of the same story. A company announces a bold DevOps transformation with a kickoff event, new tooling and a slide deck full of arrows. For three months, energy is everywhere. By month eight, the war room is empty, the pipeline project has stalled and people speak about the initiative in the past tense. What failed was rarely the technology. It was the pace. The transformation pace a company chooses, sprint-and-collapse or slow and regular, shapes the outcome more than any tool decision. Below are six myths about pace that we hear repeatedly, and what tends to happen in practice. The managers quoted along the way are composite characters, stitched together from situations that recur across many organisations rather than drawn from any single client.

Myth 1: A big launch creates momentum that carries itself

Meera, an engineering manager at a mid-sized insurer, remembers the launch week well. Leadership flew in, teams were reorganised over a weekend, and a new deployment toolchain was announced with real excitement. “We thought the buzz would carry us,” she told us. “It carried us about six weeks.”

Momentum from an event decays quickly because nothing in the week-to-week routine has changed. Engineers still face the same release approvals and the same manual handoffs. What sustains change is a recurring rhythm that people can feel: a fixed fortnightly slot where one bottleneck is removed, a standing review of what shipped, a predictable moment when progress is shown. Energy follows routine far more reliably than routine follows energy.

Myth 2: You need to transform everything at once or it will not stick

This myth sounds bold and strategic. In reality, attempting to change every team, every pipeline and every approval process at once creates so much simultaneous disruption that nobody can tell which change helped and which hurt. When results are mixed, as they always are at first, the whole effort gets blamed.

A steadier approach changes a few things at a time on a regular schedule. One team adopts trunk-based development this month; another automates its test environment next month. Each change has room to settle, problems are traced quickly, and successes become examples for the next group. Our guide to building continuous improvement into consulting engagements describes how to sequence these modest steps so they reinforce each other.

Myth 3: Slow and steady means slow

Rakesh led platform work at a logistics firm that took the opposite path to Meera’s insurer. There was no launch event. Instead, every second Thursday, his team shipped one small improvement to the shared delivery platform and walked other teams through it in a half-hour session. “It felt almost too modest,” he said. “Then at the one-year mark we listed what had changed, and it was more than the previous three years combined.”

Steady cadence compounds. Twenty-six small, completed improvements in a year outrun a single ambitious programme that stalls at sixty percent. Deployment frequency usually rises along the way too, almost as a side effect, because teams get used to smaller, more frequent changes. The perception of slowness comes from comparing a regular rhythm against the promises of a launch deck rather than against what launch-driven programmes actually deliver.

Myth 4: Consultants should arrive, transform and leave

The fly-in, fly-out model of consulting fits the burst pattern perfectly: an intense engagement, a handover document, and then silence. Organisations often find that practices introduced during the engagement fade within months because no one is maintaining the rhythm once the external team departs.

Engagements that last tend to be structured differently. They establish a recurring internal cadence early, with clear owners inside the client, and gradually shift the work of running it from consultants to staff. By the end, the consultants are attending the rhythm rather than driving it. A realistic plan, such as the phased approach in our enterprise modernisation roadmap, includes this handover of the cadence itself, not just of documents.

Myth 5: Communication can wait until there are results

Many teams stay quiet until they have something impressive to announce. The trouble is that silence gets interpreted. Other departments assume nothing is happening, sceptics fill the gap with their own story, and when the big announcement finally arrives, it lands on an audience that has stopped paying attention.

Regular, unglamorous updates work better. A short note every two weeks covering what changed, what was learned and what comes next keeps people connected to the effort even when progress is incremental. Some organisations extend this outward, sharing lessons through engineering blogs or guest articles on industry sites. Those who write externally often draft several pieces when they have time and release them on a timetable; a guest-post platform like GuestPostAI, which combines templates, an editing step and scheduled publishing, is one way to keep that outward voice regular rather than sporadic.

Myth 6: If the cadence slips once, the effort has failed

Rhythms break. A production incident consumes a fortnight, a release freeze arrives at year end, a key person resigns. Teams with a burst mindset treat any interruption as proof that the change has failed, and quietly abandon it.

Teams with a cadence mindset simply resume at the next scheduled slot. The point of a rhythm is not perfection; it is that there is always a known next step. Meera’s insurer eventually recovered its stalled programme this way. “We stopped trying to restart the whole transformation,” she said. “We just picked one Tuesday a fortnight and started removing one blocker each time. Nobody announced anything. It worked.”

There is a practical lesson in that recovery. When a cadence lapses, the instinct is to compensate with a catch-up push: a double session, an extra workshop, a weekend of clean-up. That push usually exhausts the people involved and sets up the next lapse. It is better to accept the missed slot, keep the next one exactly as planned and, if needed, trim its scope so it can be finished on time. Protecting the rhythm matters more than recovering the lost ground in one go.

What these stories say about transformation pace

Across industries, the transformations that endure share a few traits:

• A fixed, recurring slot for change that survives busy periods.
• Small scope per cycle, so each step is finished before the next begins.
• Visible, regular communication, even when progress is modest.
• Ownership of the rhythm inside the organisation, not only with outside advisers.
• A habit of resuming quietly after interruptions rather than relaunching loudly.

None of these require a special budget or a new tool. They require patience and a calendar. The organisations that change most over five years are rarely the ones that moved fastest in their first quarter. They are the ones that kept showing up, every week or fortnight, long after the launch slides were forgotten.

Kabir Malhotra