The disruption caused by the Covid-19 pandemic accelerated this shift, forcing companies to lean on cloud platforms to enable remote work at scale. What had been a gradual trend became an immediate operational necessity. That urgency has made the development of in-house cloud skills not just desirable, but essential.

The Problem With IT Outsourcing as a Cloud Strategy

Many organizations have historically responded to digital transformation pressures by outsourcing their IT departments, assuming that this makes them effectively “digital.” Fred Flack, Head of Talent Academy at CloudStratex, argues this is a fundamental mistake.

“Digital knowledge is leased,” Flack explains, “and any advantage they enjoy from it will disappear when they can no longer afford to pay, putting them right back at square one.”

True digital capability requires ownership. Organizations moving toward cloud-only operations have, in Flack’s view, a duty of responsibility to their employees — to keep them upskilled, or reskilled where necessary, rather than paying lip service to digital training programs.

Practically, this means two things: making targeted digital hires despite the competitive talent market, and engaging specialist IT training organizations that can qualify existing staff and help build an internal digital knowledge hub with a culture of continuous improvement.

Cloud Roles Are Becoming Software Development Roles

One of the clearest signals that cloud talent development needs to evolve is the changing nature of cloud engineering itself. As cloud environments grow more complex, the skill profile of a cloud practitioner increasingly overlaps with that of a software developer.

There is still a meaningful crossover with traditional IT: cloud engineers need to understand hardware, infrastructure, and troubleshooting. But the weight has shifted. Organizations recruiting for cloud roles are now, in many cases, looking for developer competencies.

Simon Utting, COO at Amito, puts it plainly: “With the cloud environment becoming increasingly complex feature-wise, staying ahead of competitors, maintaining platforms and scaling requires consistent automation. This brings us back to coding. Make sure your team is on a pathway of continually developing these skills.”

Utting also identifies Linux expertise as a specific gap, noting that the majority of his company’s client base runs on Linux and that qualified Linux talent is currently difficult to find. Security is another emerging priority: “Tying security into your cloud talent development is going to be huge in the next couple of years as cyber security becomes more sophisticated — your team needs to know how to respond to it effectively.”

Culture and Continuous Learning Matter More Than Certifications

Certifications have their place — they provide a common benchmark and a basis for conversations in interviews — but they are not the end goal. The organizations building the strongest cloud teams are those investing in learning culture, not just training programs.

Utting describes what he looks for when hiring: “Personally, I’m far more interested in curiosity, a desire to solve a problem, being self-starters — this talent goes much further as you develop it.”

Sean Farrington, SVP EMEA at Pluralsight, echoes this view, highlighting the operational challenge of maintaining cloud skills once people are in post. “Businesses need the ability to accurately map skill levels and proficiencies within teams and put in place tailored learning pathways to address knowledge gaps,” he says.

This requires rethinking how learning is delivered. Pluralsight’s own research found that 40% of IT professionals prefer learning online — through self-paced or instructor-led courses — over classroom-based formats. Farrington draws the practical conclusion: “The ability to upskill on demand and in bite-sized chunks is likely to keep cloud computing talent motivated, current and project-ready.”

Simon Ratcliffe, Principal Consultant at hybrid IT services provider Ensono, agrees. He argues that the organizational culture must catch up with the technology itself: “It is no longer enough to produce a list of technical requirements and pattern match applicants to skills. We must adopt a far more people-centric approach to recruitment and development right across the organisation. The speed, agility and freedom to fail provided by the cloud are worthless without an underlying culture that accepts this.”

Making the Cloud Career Path Visible and Appealing

There is an often-overlooked dimension to the cloud talent shortage: perception. Cloud engineering competes for attention against roles in artificial intelligence, machine learning, and cyber security — areas that currently attract significant media coverage and are seen as more prestigious by many early-career technologists.

Farrington identifies this directly: “Half the battle with developing cloud computing talent is showing bright employees that there is a long, enriching career in the cloud. As technology leaders, we must show them that the cloud is the engine room for tomorrow’s innovation; helping build our smart cities by underpinning big data, AI, IoT or 5G applications.”

This is a legitimate leadership challenge. If cloud is positioned internally as infrastructure plumbing rather than as a foundation for innovation, it will continue to struggle to attract the best candidates.

Building a Talent Pool Designed for Constant Change

Because cloud technology evolves so rapidly, Ratcliffe argues that chasing specific technical skills is a losing strategy. The skills that are in demand today may be commoditized or obsolete within a few years.

Instead, he advocates for building a talent pool around diverse thinking and a genuine passion for continuous learning: “The days of a couple of technical courses a year for staff are long gone. Learning is constant, consistent, on the job and flexibility needs to be built into the culture to allow for this.”

The practical implication is that organizations need to stop treating cloud talent development as a periodic HR exercise and start treating it as an ongoing operational discipline — one that is embedded in how teams are structured, how work is done, and how success is measured.

Key Takeaways for Engineering and DevOps Leaders

• Don’t mistake outsourcing for digital capability. Leased digital knowledge creates dependency, not competitive advantage.
• Hire and develop for developer competencies. Automation, coding, and Linux skills are increasingly central to cloud roles.
• Embed security in cloud talent development from the outset, not as an afterthought.
• Build learning pathways that match how engineers actually learn — online, self-paced, and in manageable increments.
• Prioritize curiosity and learning agility over certification checklists when assessing candidates.
• Communicate the career opportunity in cloud clearly. Position it as foundational to AI, IoT, and smart infrastructure — not just as back-end infrastructure work.
• Make learning continuous and culturally normal, not an annual compliance activity.

Original reporting by Information Age. Quotes attributed to Simon Ratcliffe (Ensono), Fred Flack (CloudStratex), Simon Utting (Amito), and Sean Farrington (Pluralsight).

Overview

AppDynamics published findings in May 2020 revealing a significant spike in demand from IT professionals for Application Performance Management (APM), cloud monitoring, and microservices support during the early months of the COVID-19 pandemic. The company analyzed organic web traffic to its own site, trending search terms, training course enrollment, and frequently asked customer questions across a defined window — March 1 to April 4, 2020 — to identify where practitioners were seeking help most urgently.

The findings were not independent market research but an analysis of AppDynamics’ own platform data and website behavior, so they reflect the needs of its existing audience and prospects rather than the broader industry as a whole. With that context in mind, the trends they identified are consistent with the pressures IT organizations faced as remote work, online commerce, and telehealth scaled almost overnight.

The Context: Digital Services Under Unprecedented Load

The shift to remote work, e-commerce, online education, and telehealth during 2020 placed extraordinary demand on enterprise IT infrastructure. Applications that had previously handled moderate or predictable traffic suddenly became the sole channel through which organizations delivered value to both employees and customers.

AppDynamics cited its own pre-pandemic research finding that 71 percent of consumers said digital services were so embedded in daily life that they rarely paused to consider how much they depended on them. When physical channels closed, that latent dependency became explicit — and the quality of digital experiences became a direct business differentiator.

“Applications have quickly become the gateway to the critical digital services we now rely on to function day to day, both for personal and professional needs. This means application owners are getting hit with record usage, while under intense pressure to get products, services and information to their customers quickly — all while maintaining a great digital experience.”

— Angie Mistretta, Chief Marketing Officer, AppDynamics

Trend 1: Rising Demand for Application Performance Management

As application traffic surged and user expectations rose, IT teams increasingly searched for guidance on monitoring and managing application performance. AppDynamics reported the following signals from its data:

• Search terms including “APM”, “Application Performance Monitoring”, and “Digital Experience Monitoring” ranked in the top five most frequently searched terms globally among visitors to the AppDynamics site.
• Pages covering end-to-end APM strategy saw a 35% increase in web traffic during the March 1–April 4 window.
• Resources focused on application performance testing saw a 24% traffic increase over the same period.
• Enrollment in AppDynamics’ Core APM class through its Premium University program increased by 233%.

The steep jump in training enrollment is particularly notable. Practitioners were not just reading about APM concepts — they were committing time to structured learning, indicating a recognition that existing monitoring practices were insufficient for the scale and criticality of applications under pandemic conditions.

For DevOps teams, APM in this context means full-stack visibility: tracing transactions from the end-user browser or mobile device through APIs, microservices, databases, and network infrastructure. Without that visibility, diagnosing the root cause of degraded user experience at scale becomes guesswork.

Trend 2: Cloud Monitoring Becomes Critical Infrastructure

The pandemic invalidated capacity planning models built around historical patterns. Demand curves that had taken months or years to develop shifted in days, and organizations needed the ability to scale compute resources rapidly — something on-premises infrastructure cannot easily accommodate.

AppDynamics reported a more than 40% increase in traffic to cloud monitoring pages on its website. Search terms trending among its audience included “cloud operations”, “Azure”, and “AWS monitoring”.

For organizations still running primarily on-premises workloads, the immediate challenge was enabling a remote workforce to securely access business-critical systems in real time. Cloud infrastructure — whether through migration or hybrid deployment — offered the elasticity those organizations needed. Monitoring that cloud infrastructure then became an immediate operational priority rather than a future-state roadmap item.

Key cloud monitoring concerns in this environment typically include:

• Auto-scaling behavior and cost visibility across cloud providers
• Latency and availability of cloud-hosted APIs and services
• Correlating cloud infrastructure metrics with application performance data
• Multi-cloud and hybrid environments where workloads span both on-premises and cloud resources

Trend 3: Microservices and Kubernetes Adoption Accelerates

Speed of delivery became a survival requirement for many businesses in early 2020. Developers needed to ship new features, fix critical bugs, and scale services faster than traditional monolithic application architectures permit. Microservices — decomposing applications into small, independently deployable services — offer the development velocity and horizontal scalability that teams needed.

AppDynamics observed a 21% increase in traffic to pages covering microservices adoption challenges and implementation guidance. Related trends included:

• Traffic to Kubernetes monitoring resources increased by 20%.
• Resources on best practices for instrumenting containers saw a 33% traffic increase.

These numbers reflect a well-known operational challenge: microservices architectures significantly increase observability complexity. Where a monolith might generate a single log stream and a handful of metrics, a microservices deployment running dozens or hundreds of services generates distributed traces, per-service metrics, and inter-service dependencies that require purpose-built tooling to understand.

Kubernetes adds another layer: container scheduling, resource allocation, pod health, and node-level metrics all require monitoring in addition to the application-layer instrumentation teams would apply in any architecture. The interest in instrumentation best practices suggests teams were not just deploying containers but actively working to make those deployments observable in production.

What This Means for DevOps Teams

The three trends AppDynamics identified — APM adoption, cloud monitoring, and microservices observability — are closely interrelated. Organizations accelerating cloud migration to enable remote work often simultaneously adopt containerized, microservices-based architectures to gain deployment agility. Both shifts increase monitoring complexity, which drives demand for APM tooling capable of providing unified, correlated visibility across distributed systems.

Practically speaking, the implications for DevOps teams include:

• Instrument early: Adding APM agents or OpenTelemetry instrumentation at deployment time is significantly less disruptive than retrofitting a production system under load.
• Define SLOs before incidents happen: Service Level Objectives give teams a clear threshold for acceptable performance and a shared definition of what “degraded” means before users start complaining.
• Correlate infrastructure and application metrics: Cloud resource saturation (CPU, memory, network) and application-layer latency need to be visible in the same context to diagnose root causes quickly.
• Invest in distributed tracing: In microservices environments, request traces that span multiple services are often the only way to identify exactly where in a call chain latency or errors are introduced.
• Treat monitoring as a team skill: The 233% jump in APM training enrollment suggests organizations recognized that tooling alone is insufficient — practitioners need to understand how to use it effectively.

“IT professionals need additional support and tools in order to combat these new challenges, because they know the quality of the digital experiences they deliver today will impact their success both now, and after the pandemic subsides.”

— Angie Mistretta, AppDynamics CMO

Summary

AppDynamics’ self-reported data from March–April 2020 documented a measurable surge in practitioner interest across APM, cloud monitoring, and microservices observability. While the data reflects AppDynamics’ own audience and should not be extrapolated as industry-wide benchmarks, the underlying pressures it describes — rapidly scaling digital traffic, accelerated cloud adoption, and the observability challenges of distributed architectures — are well-documented phenomena that continued well beyond the initial pandemic period. Teams that invested in monitoring infrastructure during this period were better positioned to maintain service reliability as digital-first operating models became permanent.

ServiceNow: Quiet Infrastructure, Outsized Business Impact

Enterprise IT service management is rarely glamorous. Ticketing systems, helpdesk portals, and asset tracking tools do not generate headlines the way consumer apps do. Yet ServiceNow (NYSE: NOW), founded in 2004, turned this unglamorous corner of enterprise software into one of the most successful SaaS businesses of the last decade. Understanding why requires a close look at what the company actually does and why enterprises find it so hard to replace.

What ServiceNow Does: IT Workflow Automation at Scale

ServiceNow’s core product is a SaaS platform that centralises IT service delivery within large organisations. Instead of IT departments juggling email chains, spreadsheets, and phone calls to manage internal requests, ServiceNow provides a single interface for:

• IT asset management — tracking hardware and software across the organisation
• Trouble ticket management — logging, routing, escalating, and resolving IT incidents
• Device provisioning and ordering — automating new-hire and replacement workflows
• Employee onboarding — coordinating IT-side tasks when staff join or leave
• Service-level agreement (SLA) tracking — ensuring IT teams meet response and resolution commitments to internal business units

The platform replaces fragmented, manual processes with a structured workflow engine. IT staff get a clear view of request status; end users get a self-service portal instead of a phone queue. The result is measurable productivity improvement inside IT departments and a better experience for the internal customers they serve.

Why Enterprises Find It Difficult to Leave

ServiceNow benefits from strong switching costs — a structural characteristic that is central to understanding its business model. Once an IT department has configured ServiceNow, trained staff on its workflows, integrated it with adjacent systems, and built institutional muscle memory around it, replacing it becomes a significant undertaking.

Switching to a competing platform involves:

• Re-training all IT staff on a new interface and new workflow logic
• Migrating historical ticket and asset data
• Re-integrating with monitoring tools, identity management systems, and business applications
• Accepting a productivity gap during the transition period
• Risking SLA breaches while teams ramp up on the new system

Competitors including IBM, HP (Hewlett Packard Enterprise), and BMC have historically entered this market through acquisitions, which often results in complex, patchwork integrations. ServiceNow’s organic platform approach — building a coherent, unified data model from the ground up — gave it an architectural advantage that acquisition-led competitors have struggled to replicate.

These dynamics show up in ServiceNow’s retention metrics. As of the time of original publication (early 2020), the company reported customer retention rates approaching 99%, a figure that had been steadily improving over several years.

The Expansion Playbook: From IT to the Wider Enterprise

ServiceNow’s growth strategy relies on a well-documented land-and-expand approach. The company wins an initial deployment in the IT department, demonstrates clear productivity gains, and then uses IT’s internal credibility and relationships to expand into adjacent business functions.

This works because workflow management problems in other departments structurally resemble those in IT. Customer service teams manage queues of cases. HR teams manage onboarding checklists and recruitment pipelines. Facilities teams manage maintenance requests. ServiceNow extended its platform to address all of these:

• Customer Service Management (CSM) — tools for managing customer-facing case queues and resolution workflows
• Human Resources Service Delivery (HRSD) — employee onboarding, offboarding, and HR request management
• Field Service Management (FSM) — dispatch and task management for field technicians
• Facilities Service Management — maintenance request handling and facility operations

According to the original analysis, these non-IT modules accounted for approximately 40% of new contract value at the time and were growing rapidly. More than 75% of ServiceNow customers were reported to be running multiple modules simultaneously — a clear indicator that the expansion strategy was working in practice.

Each additional module deepens the switching cost further. An organisation running ServiceNow across IT, HR, and customer service has an enormous migration problem if it ever wants to leave — a dynamic that reinforces both retention and the company’s pricing power.

Market Opportunity and Financial Context (as of Early 2020)

The original analysis cited a core IT service management market of approximately $20 billion, growing at around 10% annually, and an expanded total addressable market reaching an estimated $165 billion by 2023 when non-IT workflow modules are included. These figures were attributed to ServiceNow’s own investor presentations and should be treated as company estimates rather than independent research.

Financial highlights cited in the original January 2020 analysis:

• Revenue growing at approximately 33% year-over-year in the most recently reported results at the time
• Five-year annualised revenue growth of approximately 43%
• Gross margins improving from approximately 67% in 2016 to approximately 77% at the time of writing
• Free cash flow conversion of approximately 20% of revenue
• Nearly 900 Fortune 2000 customers
• Market capitalisation of approximately $60 billion
• Share price of approximately $312 at time of publication, trading at roughly 19x forward sales

These figures are historical snapshots. ServiceNow’s financials, valuation, and market position have changed materially since January 2020. Do not use these numbers for current investment decisions.

Leadership Transition: Bill McDermott Takes the Helm

The original analysis noted a CEO transition that had unsettled investors in late 2019. John Donahoe departed to become CEO of Nike, and Bill McDermott — formerly CEO of SAP — was appointed to lead ServiceNow. The analysis viewed this positively, citing McDermott’s deep enterprise software experience and his track record at one of the world’s largest business software companies as qualifications well-suited to ServiceNow’s trajectory.

Key Takeaways for DevOps and IT Leaders

From a practitioner’s perspective, ServiceNow’s success offers a useful case study in platform strategy within enterprise IT:

• Unified workflow platforms beat point solutions over time. Fragmented tooling creates integration overhead. A coherent platform with a shared data model compounds its value as more teams adopt it.
• Switching costs are a legitimate competitive moat. Deep process integration, staff training investment, and historical data gravity are real barriers — not just theoretical ones.
• IT departments are strategic beachheads. Winning the trust of an IT organisation gives a vendor visibility and advocacy into every other department that IT serves.
• Workflow automation generalises across functions. The underlying problem — routing, prioritising, tracking, and resolving work items against SLAs — is structurally similar in IT, HR, customer service, and facilities. A strong workflow engine can address all of them.

ServiceNow’s trajectory illustrates how disciplined focus on a specific, high-friction operational problem — enterprise IT service delivery — can serve as the foundation for a much broader platform business. The unglamorous work of keeping IT departments organised turned out to be a highly durable and scalable opportunity.

Original analysis sourced from SeekingAlpha, published January 2020. Financial data and market figures reflect conditions at the time of the original publication.

Traditionally, software development was depicted as a linear, assembly-line process. DevOps reframes it as a continuous loop: each stage of the development lifecycle — planning, development, testing, deployment, and operations — depends on the stages before it and feeds into those that follow. Crucially, information about adoption and product effectiveness flows back from users to planners, closing the loop and enabling ongoing improvement.

Below are five of the most persistent DevOps myths, each one examined and debunked.

Myth 1: DevOps Is Purely a Horizontal, IT-Centric Initiative

Debunked. The name “DevOps” points to the union of development and operations, which can make it sound like a purely internal IT concern. In reality, breaking down the silo between dev and ops is only part of the story. Effective DevOps also requires dismantling barriers between IT and the business, and between the business and its customers.

Consider what happens when a dev team optimises purely for deployment speed without regard for operational stability: quality problems land on the operations team, and ultimately on users. Equally, building features quickly means little if adoption data is never fed back to planners. The feedback loop — where each stage of development is informed by every other stage — is precisely why effective software delivery cannot be treated as a straight line from requirements to release.

DevOps is rooted in IT, but its scope extends to business outcomes and customer experience. Teams that treat it as a narrow, horizontal IT reorganisation miss the broader value it can deliver.

Myth 2: You Must Achieve CI/CD Immediately

Debunked. Continuous integration and continuous delivery (CI/CD) represent a high level of DevOps maturity, not a starting point. Organisations arrive at CI/CD through a series of incremental improvements, and no two organisations start from the same position.

A more realistic progression looks something like this:

1. Establish version control as the single source of truth for all code and configuration.
2. Define a repeatable release pipeline so that builds and deployments follow a consistent, documented process.
3. Automate testing and verification to give teams fast, reliable feedback on new code.
4. Extend automation progressively toward continuous delivery and, where appropriate, continuous deployment.

A critical caution here: DevOps is not simply a collection of tools. Automating a broken process does not fix the process — it only makes the failures happen faster. Define and improve your processes first; then apply tooling to those improved processes.

Myth 3: DevOps Is a Technology

Debunked. Technology is one component of DevOps, not its definition. DevOps practitioner Jez Humble has described DevOps as “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” That definition encompasses culture, team structure, working practices, and technology together.

The right balance of priorities also varies significantly by industry. Heavily regulated sectors — banking, insurance, healthcare, and the public sector — place a premium on trust, compliance, and stability. Consumer technology companies may weight speed and experimentation more heavily. Neither approach is universally correct. Every organisation needs to map its own balance of innovation velocity against stability requirements, then design its DevOps journey accordingly.

Selecting a tool and calling it “DevOps” misses the cultural and organisational change that makes the tooling valuable in the first place.

Myth 4: Development Teams Should Build Their Own DevOps Tools

Debunked. The earliest DevOps automation was built from homegrown scripts, and there remains a legitimate place for teams to automate genuinely unique aspects of their workflow. But the development lifecycle as a whole is now well understood, and mature tooling exists to support virtually every stage of it.

The pattern of custom tooling eventually giving way to established commercial or open-source solutions has repeated itself across every business function that has been automated over the past two decades. Custom tooling carries hidden costs:

• Developers must maintain deep platform expertise and track API changes across every integrated system.
• Engineering time spent maintaining internal tools is time not spent building product features.
• Homegrown solutions rarely keep pace with the innovation rate of dedicated tooling vendors or active open-source communities.
• Long-term total cost of ownership is typically higher than that of pre-built, well-supported alternatives.

The 2019 State of DevOps Report noted that the strongest concentration of fully proprietary, internally built tooling was found among low-performing teams, while high and elite performers had largely moved away from that model. Building everything in-house is rarely a competitive advantage; shipping better products faster is.

Myth 5: DevOps Relies Primarily on Open-Source Tools

Debunked. According to the 2019 State of DevOps Report, only around 22% of DevOps teams rely primarily on open-source tooling, while approximately 70% use commercial tools for at least some parts of their pipeline. Open-source tools are more common among individual developers or small teams building their own processes — partly because they require no budget approval — but that pattern does not reflect how mature DevOps organisations operate.

The right tooling decision depends heavily on context:

• Platform fit: A DevOps pipeline for mobile application development looks substantially different from one targeting an infrastructure-as-a-service (IaaS) environment or a software-as-a-service (SaaS) platform.
• Integration depth: Generic tools often require extensive scripting and customisation to integrate with specific platforms, increasing maintenance burden and reducing reliability.
• Team autonomy: The 2017 State of DevOps Report found that teams with the autonomy to select the tools best suited to their platform outperformed teams required to use centrally mandated tooling.

Neither open-source nor commercial is universally superior. The right question is which tool — regardless of licensing model — is best suited to the specific platform, team, and workflow at hand.

A Practical Framework for Thinking About DevOps

DevOps practitioner Jonathan Smart has summarised the goal of DevOps as: better value, sooner, safer, happier. Breaking that down:

• Better — continuously improving the quality of both the work and the process that produces it.
• Value — using agile development and design thinking to understand and address the real needs of end users.
• Sooner — applying continuous delivery techniques to release working software more frequently.
• Safer — integrating automated quality checks and security scanning into the development workflow rather than bolting them on at the end.
• Happier — improving the day-to-day experience of both the engineering team and the customers they serve.

Clearing away the myths above is a prerequisite for building toward that goal. DevOps is not a tool to purchase, a team to hire, or a certification to earn. It is a sustained, organisation-wide effort to deliver better software more reliably — and to keep getting better at doing so.

Original source: techbeacon.com

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.