This article draws on guidance originally published at ciol.com (2017) and expands on the core principles for a DevOps engineering audience.
DevOps Has Been Around Long Enough to Know What Works
DevOps as a movement traces its roots to roughly 2008, when practitioners began formalizing the collaboration between development and operations teams. Nearly two decades later, the approach has moved well beyond early adopters in web-scale companies and is making significant inroads in industries with complex, legacy-heavy environments — including telecommunications and communications service providers.
The promise is real: faster time-to-market, higher release quality, and tighter feedback loops between engineering and the business. But in environments that span hundreds of systems, multiple vendors, and tightly coupled legacy technologies, that promise can be harder to deliver than it looks on a conference slide. The good news is that the path is well understood — if you follow it deliberately.
DevOps Do’s and Don’ts for Complex Environments
DO: Plan the Journey Before You Start
DevOps is not a product you install or a certification you earn — it is an ongoing transformation. Like any significant journey, it requires you to know two things before you take the first step: where you are starting from and where you intend to go. Map your current state (tooling, team structure, deployment frequency, incident metrics) and define concrete, measurable goals for where you want to be. Without this baseline, you cannot demonstrate progress or course-correct when you drift.
DON’T: Mistake Your Inspiration for Your Competition
Netflix and Amazon are frequently cited as DevOps exemplars, deploying thousands of changes per day. They are excellent sources of patterns and inspiration. They are not, however, your direct competition if you are a telecommunications provider or an enterprise software shop. Benchmarking yourself against them can create unrealistic expectations and demoralise teams. Instead, study how they operate — their culture of ownership, automated testing pipelines, observability practices — and apply those lessons to close the gap on your actual competitors.
DO: Find an Experienced Guide
DevOps transformations in regulated or legacy-heavy industries surface problems that generic DevOps literature rarely addresses: vendor lock-in at the infrastructure layer, compliance gates that block continuous deployment, and organisational structures designed around waterfall release cycles. A partner or internal champion with direct, relevant experience in your industry can help you navigate these pitfalls rather than discover them the hard way. Look for demonstrated experience with organisations at a similar stage of maturity, not just published case studies from greenfield startups.
DON’T: Expect Immediate Transformation
The metrics that matter most in a DevOps transformation — deployment frequency, lead time for changes, mean time to recovery, change failure rate — take months to move meaningfully in a complex environment. Expecting a quarter-over-quarter turnaround sets up both the engineering team and the business for disappointment. Set intermediate milestones: improved unit test coverage, a reduction in manual handoffs, the ability to demo a new feature in a controlled environment on demand. These leading indicators keep stakeholders aligned while the lagging indicators catch up.
DO: Choose an Easy Starting Point
Resist the temptation to boil the ocean. Identify a project or system that is:
- Relatively isolated — minimal dependencies on other teams or vendor systems
- Single-vendor or single-team owned — so you can make decisions without weeks of coordination overhead
- Part of a dynamic business area — where faster delivery would have a visible commercial impact
Use this first project as a controlled experiment. Document what you learn — what worked, what didn’t, what you would change — and carry those lessons into the next area of the organisation.
Keep the Big Picture in Mind
DON’T: Assume Every Team Needs to Transform at the Same Pace
Not every part of your organisation delivers value at the same cadence. A billing engine that changes twice a year and a mobile feature team shipping weekly updates have fundamentally different needs. Forcing a full DevOps transformation on a slow-moving, stable system introduces overhead without proportional benefit. Focus your investment on the areas experiencing rapid, dynamic change — where the feedback loop between development and operations has the highest return. Let stable, low-velocity systems continue operating under their current model until there is a clear case for change.
When Is It OK to Fail?
The short answer: almost always — as long as you learn from it.
One of the most important cultural shifts in DevOps is moving from a blame-oriented, failure-avoidance posture to a learning-oriented one. Failures in a well-instrumented DevOps pipeline surface information: a flawed assumption in a deployment script, a gap in test coverage, a misconfigured feature flag. That information has value. The failure itself is only a problem if it repeats.
This is why practices like blameless post-mortems, chaos engineering, and progressive delivery (canary releases, feature flags) exist — they create safe-to-fail conditions where the blast radius of any individual failure is limited and the learnings are captured systematically. A team that ships, fails fast, learns, and iterates will outperform a team that ships rarely in order to avoid failure.
The principle to hold onto: failure is acceptable; repeated failure from the same unaddressed cause is not.
Summary: Key Principles for a Sustainable DevOps Journey
- Treat DevOps as a continuous journey with defined starting metrics and measurable goals.
- Draw inspiration from web-scale companies, but compete against your actual industry peers.
- Engage partners or internal champions with domain-specific experience.
- Set intermediate milestones; don’t wait for end-state results to validate progress.
- Start with an isolated, high-value project and expand outward with documented learnings.
- Apply full DevOps investment selectively — focus on high-velocity, high-value areas.
- Build a culture where failure generates learning, not blame — and where the same mistake is never made twice.