This article is based on analysis originally published on diginomica.com, drawing on findings from the Google Cloud State of DevOps report and a MongoDB study on security in DevOps teams.
What Makes a DevOps Team Truly Elite?
Every engineering team wants to ship excellent software quickly, maintain reliability, and help the business hit its goals. But wanting those outcomes and consistently achieving them are two different things. Research from Google Cloud and MongoDB sheds light on the concrete, measurable factors that separate elite DevOps teams from the rest — and the gap is larger than most leaders expect.
Here are four evidence-based principles that define high-performing DevOps teams, distilled from those two research sources.
1. Understand What an Elite Team Actually Looks Like
It is tempting to assume your team is already performing at a high level. But without a clear definition of “elite,” that assumption is unfalsifiable. The Google Cloud State of DevOps report defines performance using five concrete Software Delivery and Operational (SDO) metrics:
- Deployment frequency — how often code is shipped to production
- Lead time for changes — time from code commit to running in production
- Time to restore service — how quickly incidents are resolved
- Change failure rate — the percentage of deployments that cause production failures
- Availability — the reliability of systems as experienced by users
A common misconception is that speed and stability are a trade-off: deploy faster and you will break things more. The State of DevOps report found the opposite. For six consecutive years, the research showed that high-throughput teams also achieved higher stability. Speed and reliability reinforce each other when the underlying practices are sound.
The performance gap between elite and low-performing teams in the report is striking. Elite teams had lead times that were 106 times faster and deployed 208 times more frequently than low performers. The mechanism behind this is straightforward: when deployments are routine, teams build the muscle memory and tooling to do them well. Infrequent, high-risk releases compound risk; frequent, small releases reduce it.
Critically, elite SDO performance was not just an engineering achievement — elite performers were approximately twice as likely to meet or exceed their broader organisational performance goals, including customer acquisition, profitability, customer satisfaction, and operating efficiency. This is the business case for investing in DevOps excellence.
2. Prioritise Developer Experience as a First-Class Concern
Developer experience (DX) is notoriously difficult to quantify, but the research reinforces its importance. Giving developers the right tools, appropriate automation, and a low-friction workflow is a prerequisite for elite performance, not a nice-to-have.
The State of DevOps report highlights several technical dimensions of DX that correlated with high performance:
- Cloud adoption — fully cloud-native teams showed a stronger correlation with DevOps success than those using cloud in a limited capacity.
- As-a-service platforms — offloading undifferentiated infrastructure work (databases, messaging, monitoring) reduces cognitive overhead for development teams.
- Managing technical debt — teams that proactively addressed technical debt reported better velocity and lower friction.
However, the research makes clear that technology choices are only one dimension of developer experience. The so-called “10x engineer” — the individual genius who operates at superhuman speed — is largely a distraction. Elite teams are elite because every member has the opportunity to do their best work, not because one person carries the rest. Building that environment requires investment in culture and process, not just tooling.
3. Build a Culture of Psychological Safety
Of all the findings in the State of DevOps report, psychological safety may be the most underappreciated in engineering organisations. The report found that a culture of psychological safety — where team members feel safe to take risks, ask questions, and raise concerns without fear of punishment or embarrassment — was predictive of software delivery performance, organisational performance, and overall productivity.
This aligns with Google’s earlier internal research (Project Aristotle), which identified psychological safety as the single most important factor in team effectiveness. The State of DevOps report built on this by showing that good technical practices and improved processes together can reduce employee burnout — a concrete, measurable outcome.
The mechanism creates a virtuous cycle: when developers operate in a psychologically safe environment, they collaborate more openly, share problems earlier, and iterate faster. This reduces the pressure to work unsustainable hours. Lower burnout sustains productivity over time rather than exhausting it in short bursts. Combining sound technical practices with this kind of culture is where elite performance becomes self-reinforcing.
For engineering leaders, the practical implication is clear: blameless post-mortems, open retrospectives, and explicit norms around failure and experimentation are not soft-skills exercises — they are performance investments.
4. Clarify Security Ownership — Shift Toward DevSecOps
The MongoDB research on security in DevOps organisations surfaced a fundamental tension: when responsibility is everyone’s in theory, it often ends up being no one’s in practice.
When developers in the MongoDB study were asked who bears the most responsibility for securing an application, only 29% cited themselves. The remainder distributed responsibility across security specialists (22%), business stakeholders (18%), the operations team (16%), and unnamed security personnel (14%).
This fragmentation is not necessarily a failure — specialisation is valuable. Security teams bring depth that individual developers should not be expected to replicate. The problem arises when fragmented ownership means security is treated as a handoff that happens at the end of a development cycle rather than a shared, continuous practice. When security is an afterthought, vulnerabilities are cheaper to ship and expensive to fix.
The DevSecOps model addresses this by integrating security practices into every stage of the delivery pipeline:
- Shift-left testing — static analysis, dependency scanning, and secrets detection run automatically in CI pipelines, catching issues before code is merged.
- Shared security standards — developers understand the security requirements they are building to; security teams help define them and review for compliance.
- Continuous compliance — policy-as-code tools enforce security controls at the infrastructure level, reducing reliance on manual reviews at release time.
- Clear escalation paths — when a developer finds a potential vulnerability, they know exactly who to contact and how, removing friction from doing the right thing.
Security is ultimately a dimension of software quality. If it is not built in continuously, it will be retrofitted under pressure — and retrofitting produces shortcuts. Those shortcuts accumulate into the kind of technical and security debt that becomes a crisis rather than a backlog item.
Putting It Together: Building Your Elite DevSecOps Team
The four principles above are mutually reinforcing. Precise performance measurement shows you where you stand and motivates targeted improvement. Strong developer experience removes friction that slows elite performance. Psychological safety enables the open collaboration and honest feedback that improvement requires. Shared security ownership ensures that what you ship quickly is also trustworthy.
The research is consistent on one point: the technology stack matters, but it is not the primary constraint for most teams. The harder and more important work is building the culture, the practices, and the shared sense of responsibility that let everyone on the team do their best work.
Elite DevSecOps teams are elite in a way that directly serves the business: they deliver what the organisation needs, quickly and reliably, and they keep it secure. For organisations competing on software, that is a durable advantage.
Key Takeaways for Engineering Leaders
- Use the five SDO metrics as your baseline for measuring team performance — they are objective, comparable, and business-relevant.
- Invest in developer experience at both the tooling and cultural levels; high-performing teams require both.
- Treat psychological safety as an engineering leadership responsibility, not an HR initiative.
- Define security ownership explicitly at each stage of your delivery pipeline, and build automated enforcement where possible.
- Recognise that speed and reliability are complementary goals — the practices that enable one tend to enable the other.