You can’t deliver quality at speed when your automation is duct-taped together. If your pipelines are stitched across multiple systems, your deployments depend on human rituals, and your tests run in the shadows, you don’t have a delivery system, you have a liability.
If your automation strategy looks something like this:
- Manual SQL deployments from someone’s laptop
- Azure Pipelines building unversioned assemblies
- Manual deployment to dev and test environments
- TeamCity rebuilding new unversioned assemblies
- Octopus Deploy is deploying from Team City to staging and production
- Selenium tests running on a black-box scripted node that only one person monitors
You’re not building a product. You’re building chaos. You’re not scaling a team. You’re scaling dysfunction.
Fragmentation Is Not an Engineering Strategy
When every team uses a different deployment tool, stores secrets in a personal vault, and runs tests on unmonitored boxes, you’ve created a system that no one understands and no one can change safely.
This isn’t flexibility. It’s fragility.
Fragmentation leads to duplication of effort, inconsistent results, increased cognitive load, and slower delivery. You waste time debugging pipeline differences instead of building product value. And every deviation from a shared system adds risk to quality, security, and compliance.
Engineering excellence comes from enabling consistency where it matters, creating common foundations that support autonomy without sacrificing reliability. It comes from designing systems that are observable, changeable, and resilient, systems that empower teams through clarity, not confusion.
This kind of fragmentation also violates the core ethos of DevOps: continuous delivery of value through the union of people, processes, and products. If your toolchain is stitched together by tribal knowledge and Slack messages, you’re not enabling flow. You’re creating friction.
DevOps Is Not Tooling. It’s Feedback, Flow, and Learning
DevOps isn’t a toolkit war. It’s the discipline of enabling feedback, flow, and continuous learning across the entire product lifecycle.
- It’s about amplifying feedback loops, build, test, and release systems that surface issues early and often.
- It’s about enabling flow, removing friction between commit and customer, reducing handoffs and rework.
- It’s about fostering learning, capturing telemetry, responding to incidents, and improving from every iteration.
DevOps without visibility is cargo cult. DevOps across disconnected systems is just automation theatre. And DevOps without learning is just technical debt in fast-forward.
Building One Engineering System (1ES) through Platform Engineering
If DevOps is the ethos, then Platform Engineering is the strategy, and One Engineering System (1ES) is the execution model.
Platform Engineering is not just infrastructure automation. It’s a practice grounded in DevOps principles that aims to improve every development team’s time-to-value, compliance, cost control, and security through improved developer experiences and governed self-service. It’s both a mindset shift and a system of reusable tools and services.
Platform Engineering teams build and evolve Internal Developer Platforms (IDPs), paved paths that reduce cognitive load, eliminate manual gates, and guide teams safely toward production.
These platforms:
- Help developers be self-sufficient (e.g. starter kits, templates, IDE integrations)
- Encapsulate patterns into reusable services
- Automate security and compliance checks
- Streamline operations and infrastructure management
1ES, pioneered at Microsoft, embodies this by unifying:
- Azure Pipelines for end-to-end CI/CD
- Azure Repos, Boards, and Artifacts as a single source of truth
- Infrastructure as Code, Policy as Code, and integrated telemetry
The result: a secure, observable, scalable system where guardrails are built in and teams can move fast without creating risk.
No handoffs. No tool silos. No black-box deploys. One path from idea to production that every team and every skillset contributes to.
You may be thinking that “this breaks self-management” and the agency of the teams. But self-management in Agile doesn’t mean chaos. Scrum Teams don’t self-manage in a vacuum, they operate within the boundaries defined by the organisation. Self-management means giving teams the autonomy to solve problems within a clearly defined system of constraints. That system of constraints, your engineering boundaries, your compliance requirements, your platform capabilities, is your Platform Engineering strategy, and your 1ES is your implementation of that strategy. It defines what good looks like. Those boundaries must be engineered and not left to tribal knowledge. If you want consistent results, define the edges and let the teams operate freely within them.
Consolidate. Standardise. Enable.
If you want scale, you must design for it. That means:
- One build system.
- One deployment path.
- One way of managing secrets, tests, telemetry, and deployments.
Azure Pipelines is capable of it all. With templates, approvals, gates, agents, deployment groups, and environment strategies, everything you need to build a 1ES-style delivery platform is already there. Yes, there are other tools, but if you are already rooted in the Microsoft stack, then these purpose-built tools fit like a glove.
Stop spreading your delivery process across half a dozen tools with no visibility. Pick a platform. Make it great. And let your teams focus on product, not plumbing.
Engineering excellence isn’t about choosing the coolest tools.
It’s about building a system of work that enables every team to deliver safely, sustainably, and continuously.
Stop optimising for familiarity. Start optimising for flow.