Despite being deemed as a typical tech buzzword, “DevOps” – the process of combining software development and information technology operations to shorten development lifecycle – brings clear benefits. Faster lead times from commitment to deployment, greater customer responsiveness and the ability to scale and respond to market changes are just a few advantages businesses can expect by embracing DevOps transformation.

However, whether an organisation is contemplating a minor improvement on its current software delivery pipeline or a major transformation, the process of DevOps is often overlooked. So, why isn’t every business using DevOps practices? Gordon Cullum, chief technology officer of digital services firm Mastek, reflects on the matter below.

In reality, it is rare, these days, for an organisation not to have adopted any of the technologies and practices that have become part of DevOps. But often a company can be unsure of where to start, how to continue, and equally afraid of failure at any point along the journey. This article summarises the typical stages that, in my experience, most organisations pass through as they adopt DevOps strategies in the attempt to improve their technology and processes. Every business will have unique needs and challenges, but there are recognisable stages common to most.

Fail to prepare – prepare to fail
Before setting out on a DevOps transformation an organisation needs to be prepared. One of the most important elements of this stage is ensuring that the goals of the transformation have been communicated across the organisation, that there is buy-in, that management will support staff in the challenges ahead and that this is transparent to staff.

Scaling up effectively by embracing DevOps transformation

A successful DevOps transformation relies on a business’s most valuable resource: its workforce. Organisational and technical change will often put significant demands on them and so having their confidence that the transformation will succeed and their willingness to change old processes and attitudes, is vital.

Before setting out on a transformation path, it is therefore essential that a business clearly communicates the goals of the process with its staff. Essentially, the primary DevOps goal is to optimise the flow of value from idea to end user, and with this, comes a cultural change that must take place for a company to be successful. Whilst culture is a big focus, the DevOps goal is to make the delivery of value more efficient and effective whether that’s reliability, predictability or maximising skill re-use. Getting expert support, to not only answer concerns but also run workshops to increase understanding of DevOps practice can also be pivotal to success.

Visibility will be key
Before a business can start the process of change, it is essential to have a clear and comprehensive picture of existing technologies and an assessment of their complexity. This list can then be used to identify ways to remove unnecessary complication, for example by eliminating duplication where different tools or processes do the same thing, getting rid of in-house products that are no longer fit for purpose and moving to standard technologies, tool sets and configuration methods across the organisation.

It’s important to help create clear schedules for the review and consolidation of technologies and let teams take the initiative in choosing which technologies to keep and how to manage the migration with agreed priorities and realistic deadlines.

At this part of the process it’s also essential to turn migration goals into milestones and celebrate their success. Early wins can deliver measurable cost and time savings to reassure senior stakeholders and also provide a less-pressured stage to build collaborative and constructive processes. Use this as opportunity to boost team morale and secure longer term buy-in before the more ambitious transformation begins.

Streamlining DevOps processes
The success of the consolidation and standardisation process can typically cause a range of problems that are often a surprise to the organisation. For instance, increased efficiency can place unprecedented strain on parts of the business, its processes, the application architecture and the infrastructure. Meanwhile, removing known bottlenecks can reveal previously unknown inefficiencies, while if improvement is uneven (as is likely), morale and collaboration between teams may fluctuate as the finger of blame is pointed.

These issues can be addressed through the improvement of DevOps processes and culture. Many staff, at this stage, are likely to see technical remedies as far more important than culture improvements, but it is vital to show them that cultural change enables technical improvement. The business must therefore reduce bureaucracy, give teams autonomy to decide on solutions and encourage a blame-free culture. Ultimately, cultural change has to happen from the top down.

“Managing a DevOps culture is not the same as creating one; processes must be put in place that boost new attitudes and behaviours.”
– Gordon Cullum, CTO of Mastek

Automating infrastructure
As efficiency and productivity continue to increase, there will be increasing strain on the infrastructure. This is not least due to fact that the application of development good practice to infrastructure code is a relatively young and immature discipline. It is also usually the trickiest to address and the hardest to make scalable. Even moving to the cloud does little to help if infrastructure provisioning is not sufficiently automated.

A high level of automation must be developed and applied to infrastructure configuration and provisioning. The infrastructure also needs pervasive monitoring and logging, with automated responses to alerts about significant state changes and good data analysis to reveal trends. Without this, substantial time and money can be lost through inefficiency and inappropriate scaling.

Upskilling the workforce
A business should put its regular automation and monitoring to the test by providing teams with self-service capabilities when it feels its challenges have been solved. Team productivity will increase with self-service infrastructure automation and in time free up operations staff, so that they can focus more time on developing automation solutions. Businesses need to bear in mind though that to achieve this level of automation, staff will need to be upskilled or people with relevant skills recruited. However, it’s important to note that the upskilling of staff isn’t just the upskilling of technologies (AWS, Azure), it’s also about security, financial accountability and technological and architectural adherence.

If at this stage the disciplines of immutable infrastructure haven’t been adopted, now is the time to do so. Re-evaluate infrastructure automation and configuration patterns, looking for things that are no longer appropriate or necessary on immutable infrastructure, and enforce a discipline of no manual intervention for maintenance of servers/virtual machines/network infrastructure. Automated testing and monitoring should also be reviewed to ensure complete confidence in both.

The next step for DevOps transformation…
When embracing DevOps transformation, as with any technological advancement, new challenges and opportunities will be presented. Market growth and innovation will eventually generate more technical change, but the cultural changes should be long lasting and a permanent gain, however, this can only be accomplished if they are preserved. Managing a DevOps culture is not the same as creating one; processes must be put in place that boost new attitudes and behaviours.

A business will continue to reap the rewards of DevOps transformation by demonstrating to staff that the sustained duration of change will result in more space to think and use their initiative. With people being at the heart of any successful business, having employees onboard will be vital when scaling up effectively.

Why DevOps Transformation Still Fails to Scale

The combination of software development and IT operations—DevOps—has been part of the industry conversation for well over a decade. Despite well-documented benefits including faster lead times, improved customer responsiveness, and greater resilience, many organisations still struggle to move beyond isolated pockets of adoption. Fear of failure, unclear starting points, and cultural inertia continue to block progress.

Whether your organisation is contemplating a major DevOps transformation or a modest improvement to an existing software delivery pipeline, the same foundational question applies: where are you now, and what does the path forward actually look like?

While every business has unique constraints and goals, most organisations move through five recognisable stages when adopting DevOps at scale. Understanding these stages helps teams set realistic expectations, secure stakeholder buy-in, and avoid the most common pitfalls.

Step 1: Preparation — Align People Before You Touch the Pipeline

No toolchain change succeeds without organisational alignment. Before writing a single pipeline definition or restructuring a team, an organisation needs to establish shared clarity around the goals of the transformation.

Preparation means more than creating a project charter. It includes:

• Communicating goals organisation-wide: Staff at every level should understand why the transformation is happening, what success looks like, and how their role will evolve.
• Securing management commitment: Leadership must visibly support the effort—not just endorse it in writing—by allocating time, budget, and tolerance for early-stage disruption.
• Building psychological safety: Teams asked to change established processes need confidence that experimentation and failure will be treated as learning opportunities, not performance failures.
• Getting expert support where needed: Workshops, coaching, and external facilitation can accelerate understanding and address concerns before they become blockers.

The primary DevOps goal is to optimise the flow of value from idea to end user. This involves improving time-to-market, reliability, predictability, and skill reuse—but those outcomes require cultural change first. Skipping preparation is the single most reliable way to ensure a transformation stalls after the first sprint.

Step 2: Inventory Visibility — Know What You Have Before You Change It

Before standardising or automating anything, teams need a clear, comprehensive picture of the existing technology landscape. This means cataloguing tools, platforms, services, deployment processes, and configuration methods across the organisation—including shadow IT and legacy tooling that may not appear in official documentation.

A thorough inventory enables teams to:

• Identify duplication—different tools or processes doing the same job.
• Flag in-house products that are no longer fit for purpose and are candidates for retirement or replacement.
• Define a target state with agreed standard toolsets, configuration methods, and technology choices.
• Create realistic migration schedules with clear milestones and ownership.

One often-overlooked principle at this stage: let teams participate in choosing which technologies to retain and how migrations should be sequenced. Autonomy at this level increases ownership and reduces resistance later.

Early consolidation wins—retiring a redundant tool, standardising a build process across two teams—deliver measurable cost and time savings. Celebrate these milestones. They build stakeholder confidence and team morale ahead of the more demanding phases to come.

Step 3: Managing Cultural Change — The Hardest Step Is Also the Most Important

Paradoxically, the success of standardisation and consolidation often surfaces new problems. As known bottlenecks are removed, previously hidden inefficiencies emerge. Increased throughput in one part of the system creates strain in another. If improvement is uneven—as it almost always is—inter-team friction increases and blame becomes a default response.

Many engineers at this stage push for more tooling, more automation, or more architectural change. These are legitimate needs, but without addressing the cultural layer, technical solutions tend to create new forms of the same problems.

Cultural change at this stage means:

• Reducing bureaucracy: Approval chains, change advisory boards, and heavyweight process gates are often the real constraint. Identify and streamline them.
• Giving teams genuine autonomy: Teams that can decide how to solve problems—not just execute on decisions made elsewhere—move faster and take more ownership.
• Enforcing a blameless culture: Post-mortems should focus on system improvement, not individual fault. This requires explicit policy and visible leadership behaviour.
• Driving change from the top: Cultural shifts must be modelled by leadership. If executives or senior managers don’t visibly operate according to the new norms, teams won’t either.

Cultural change is not a soft add-on to DevOps—it is the mechanism through which technical improvement becomes sustainable.

Step 4: Automation — Reduce Manual Toil at the Infrastructure Layer

As development velocity increases, infrastructure becomes the next constraint. Manually provisioned or configured infrastructure doesn’t scale with the pace that DevOps practices demand. Even migrating to a public cloud provider doesn’t solve this if provisioning workflows remain largely manual.

At this stage, the focus shifts to infrastructure automation in earnest:

• Infrastructure as Code (IaC): All infrastructure configuration should be expressed as version-controlled code using tools such as Terraform, Pulumi, or cloud-native equivalents. This enables reproducibility, auditability, and automated provisioning.
• Pervasive monitoring and logging: Every environment should emit structured logs and metrics. Automated alerting should trigger on significant state changes, with runbooks or automated remediation where possible.
• Data-driven scaling: Capacity decisions should be informed by trend analysis from monitoring data, not reactive firefighting.

Applying software engineering discipline—code review, testing, version control—to infrastructure code is a relatively recent practice and one that many organisations still underinvest in. Without robust infrastructure automation, scaling the delivery pipeline will be perpetually constrained by operational overhead.

Step 5: Self-Service — Empower Teams, Free Up Operations

The final stage of a maturing DevOps transformation is giving development teams self-service access to the infrastructure and tooling they need, without requiring operations team intervention for routine requests. This is the practical endpoint of the automation work completed in Step 4—validated and stress-tested by real usage patterns.

Self-service capabilities typically include:

• On-demand environment provisioning and teardown.
• Automated deployment pipelines that teams can trigger and monitor without ops involvement.
• Developer portals or internal platforms that abstract infrastructure complexity while maintaining governance guardrails.

Reaching this level requires upskilling—and that upskilling goes beyond learning AWS or Azure APIs. Teams also need to develop competence in financial accountability (understanding cloud spend), architectural governance, and security practices. These are shared responsibilities in a mature DevOps organisation, not the exclusive domain of specialist teams.

If immutable infrastructure practices have not yet been adopted, this is the right moment to introduce them. Immutable infrastructure—where servers and compute resources are replaced rather than patched in place—eliminates configuration drift and makes automated testing and deployment dramatically more reliable. Enforce a discipline of no manual intervention for maintenance of servers, virtual machines, or network infrastructure. Automated tests and monitoring should be comprehensive enough that the team has full confidence in the pipeline without manual verification steps.

What Comes After the Five Steps?

Completing these five stages doesn’t mean the transformation is finished—it means the organisation has established a foundation capable of continuous improvement. Technical capabilities will continue to evolve as the market and the platform landscape change. Cultural gains, however, are the more durable output: blameless post-mortems, collaborative cross-functional teams, and a shared commitment to reducing toil and improving flow don’t become obsolete when the next generation of tooling arrives.

Preserving those cultural gains requires deliberate effort. Organisations must reinforce new norms through hiring decisions, performance frameworks, and leadership behaviour. They should reward work that removes technical debt as visibly as work that ships new features. And they should continue to create space for teams to think, experiment, and improve—not just deliver.

DevOps transformation is not a project with a completion date. It is a sustained operating discipline. The five steps described here provide a practical sequence for organisations that need to move from hesitation to execution—and from execution to scale.

What Electric Cloud Released

Electric Cloud announced the Winter 2019 edition of its ElectricFlow platform in February 2019, targeting a long-standing problem in enterprise DevOps adoption: the tools are powerful, but they are often too complex for anyone outside a core engineering team to use effectively. The update focused on usability improvements that lower the barrier to entry without reducing the platform’s underlying capability.

Key Features in the Winter 2019 Release

Role-Based Personas and Tailored UIs

The most notable change in this release was the introduction of role-based personas. Rather than presenting every user with the same dense, feature-rich interface, ElectricFlow now allows users to select a persona that matches their organizational role. Each persona surfaces only the information and controls most relevant to that role, reducing cognitive overload for non-specialist users.

According to Sam Fell, Vice President of Marketing at Electric Cloud, the intent is to make the platform usable by a wider population—not just senior engineers who already understand the underlying DevOps concepts, but also project managers, QA leads, and release coordinators who need visibility without needing to master the full toolset.

Task-Oriented Login Experience and Bookmarks

The Winter 2019 release also introduced a customizable login experience oriented around frequent tasks rather than a generic dashboard. Users can now save bookmarks or favorites to jump directly to the pages and pipelines they access most often, reducing the number of clicks required to reach common workflows.

This kind of quality-of-life improvement is often underestimated in enterprise tooling, but the friction caused by slow navigation compounds quickly across large teams working under delivery pressure.

Release and Pipeline Templates with Git Triggers

Electric Cloud also added release and pipeline templates designed to accelerate onboarding. Templates can be configured to respond to user-defined events and triggers—including code check-ins to a Git repository—so teams can get pipelines running quickly without building everything from scratch.

For organizations trying to standardize DevOps practices across multiple teams, reusable templates represent a practical forcing function: they encode institutional best practices and reduce the variability that comes when each team designs its own pipeline from the ground up.

The Broader Problem: DevOps Adoption Is Still Uneven

Electric Cloud’s usability push addresses a genuine and widely recognized challenge: most organizations have not achieved organization-wide DevOps adoption. What typically exists instead is a pattern of pockets of DevOps—small, highly motivated cross-functional teams continuously delivering a specific set of applications, while the rest of the organization continues to rely on older, more familiar tools and processes.

This is not simply a cultural problem, though culture is often blamed. A significant contributing factor is the skill gap: the engineers who pioneered DevOps within an organization typically have a higher baseline of automation and infrastructure knowledge than the broader IT population. When organizations try to scale DevOps beyond the initial team, the tooling that worked for experts can intimidate or block less specialized colleagues.

What looks like organizational resistance or cultural inertia is often something more concrete: an IT professional who is already proficient with an older tool will frequently reach for that tool rather than invest time in mastering a more capable but less familiar platform—especially when delivery deadlines are pressing.

Automation and Human Oversight: A Deliberate Balance

Fell noted that while modern DevOps platforms—including ElectricFlow—increasingly incorporate machine learning and automation to reduce manual toil, this creates its own accessibility problem. Highly automated systems can become black boxes: they produce results that users cannot easily interpret, troubleshoot, or override.

Electric Cloud’s stated strategy is to layer automation on top of a transparent, human-readable interface rather than replacing human judgment with opaque automation. The persona-based UI is part of this approach: it gives each user a clear view of what is happening at a level of abstraction appropriate to their role, without drowning them in raw pipeline data.

What This Means for DevOps Teams in Practice

The features in ElectricFlow’s Winter 2019 release reflect a broader design philosophy that is worth taking seriously regardless of which platform your organization uses:

• Role-appropriate interfaces reduce errors. When users see only the controls relevant to their role, they are less likely to make changes outside their area of responsibility or to be overwhelmed by irrelevant information.
• Templates accelerate standardization. Providing pre-built, Git-integrated pipeline templates lowers the effort required to onboard new teams and reduces pipeline-to-pipeline variation.
• Navigation friction is a real cost. Bookmarks and task-oriented dashboards are small improvements with a measurable impact on daily workflow efficiency across large teams.
• Accessibility is a prerequisite for scale. No DevOps platform delivers organizational value if only a subset of the team can use it confidently. Tooling that meets users where they are—rather than requiring everyone to level up to the tool—scales more reliably.

Conclusion

Electric Cloud’s Winter 2019 ElectricFlow release is a practical example of a DevOps vendor acknowledging that feature richness and usability are not the same thing. By investing in persona-based interfaces, streamlined navigation, and opinionated pipeline templates, the company signaled a shift toward meeting enterprise teams at their actual skill level rather than their aspirational one.

More accessible tooling alone will not complete a DevOps transformation—process changes, organizational buy-in, and skill development are all required. But reducing the interface friction that slows adoption is a necessary step, and it is one that every DevOps platform vendor should be actively investing in.