This insight comes from practitioners working inside government and large enterprises. One such practitioner, Lidgey (as reported by DevOps Online / devopsonline.co.uk), has worked across organisations including Monitise, IBM, and Companies House — the UK government’s executive agency and trading fund responsible for the register of companies in England and Wales. His experience offers a grounded view of how DevOps principles can take root even when the terminology doesn’t.

Culture First, Tools Second

The word that consistently surfaces in DevOps discussions is culture. As Lidgey put it directly: “DevOps is all about culture. Get the culture right, the people right, and the rest will follow.”

This isn’t a platitude. It reflects the practical reality that automation pipelines, continuous delivery workflows, and cross-functional teams all fail without the psychological safety and collaborative norms that allow people to experiment, fail fast, and learn openly. Digital transformation strategies that skip the cultural groundwork tend to end up with CI/CD tooling bolted onto dysfunctional team structures.

Making Cultural Change Concrete: The DESC Framework

Abstract calls for cultural change rarely land. Lidgey advocates for small, demonstrable steps — and recommends a structured communication approach called DESC to help teams navigate difficult conversations with stakeholders, colleagues, and leadership:

• D — Describe what happened, factually and without blame.
• E — Explain how the situation affected you or the team.
• S — Share what outcome you would like to see instead.
• C — Compromise by stating what concrete action you will take.

DESC is borrowed from assertiveness and conflict-resolution training, and it maps well onto the kinds of friction that DevOps transformations generate — missed deadlines, unclear ownership, and pressure to deliver without adequate runway. Using a structured framework removes some of the emotional charge from these conversations and keeps teams focused on outcomes rather than personalities.

How Companies House Applied This in Practice

At Companies House, the primary lever for cultural change was test automation. The organisation had historically relied on large manual testing teams, which created significant risk against delivery deadlines. As soon as one project wrapped, teams were immediately pulled onto the next — with little time for reflection or process improvement. DESC helped surface and address the longer feedback loops this created.

By investing in automated testing as the default approach — covering training for test teams, stakeholders, and business analysts — Companies House reduced its testing cycle dramatically. According to Lidgey: “We now only test for a day, instead of weeks.”

This is the kind of concrete, measurable outcome that resonates with stakeholders who remain skeptical about DevOps as a concept. You don’t need to call it DevOps. You call it “we ship faster with fewer defects.”

Talking to Stakeholders About Time and Money

Like most organisations undergoing transformation, Companies House faced the classic triad of constraints: finance, time, and team capacity. Lidgey was candid about the challenge: “The issue we face is telling stakeholders we need time and money to support our innovative platforms.”

His recommended approach for navigating this:

1. Identify the specific problem you are trying to solve — avoid vague transformation language.
2. Work on it in a focused, time-boxed way — demonstrable progress matters more than grand plans.
3. Demonstrate results — show stakeholders working software, reduced cycle times, or measurable quality improvements.
4. Solicit critical feedback — good or bad. Feedback loops are the engine of continuous improvement.

This iterative, evidence-based approach mirrors the core DevOps feedback loop. It also builds the internal credibility needed to secure ongoing investment in automation, tooling, and training.

The Technical Stack Still Matters

Focusing on culture and communication doesn’t mean deprioritising the technical work. Lidgey acknowledged there is significant technical lift involved: “There is a lot of technical stuff we need to do — automation, Jenkins, cloud, infrastructure and code.”

The learning curve — particularly for teams moving toward infrastructure-as-code and modern CI/CD pipelines — is steep. But Lidgey’s experience at Companies House suggests that investing in training and financial support for that technical upskilling pays meaningful dividends over the long term. Teams that can write and maintain automated tests, manage cloud infrastructure, and contribute to shared codebases become fundamentally more capable and autonomous.

Key Takeaways for DevOps Practitioners

• Lead with outcomes, not terminology. If “DevOps” triggers resistance in your organisation, frame the work as continuous improvement, faster delivery, or reduced defect rates.
• Use structured communication tools like DESC to manage the interpersonal friction that transformation inevitably creates.
• Start with automation where you feel the most pain — for many organisations, that’s testing. A single day of testing versus several weeks is a compelling story for any stakeholder.
• Make progress visible. Small demonstrations of working, improved systems build trust faster than slide decks about transformation strategy.
• Invest in people alongside tools. Training teams to own and extend automation is the difference between a one-time efficiency gain and a lasting capability.

Original source: DevOps Online (devopsonline.co.uk). Attribution to practitioner Lidgey, speaking about his work at Companies House.