The Two Branches of DevOps Standardisation

Throughout the development world, we are seeing two competing approaches to DevOps maturity: developer empowerment or business focusing. Both models aim to ensure that their organisations are able to increase their developer velocity, ship securer code, and be able to respond to feedback and demands, but take diametrically opposed approaches to do so. 

In this article, we explore both approaches: where each excels, what challenges they create, and how they manifest in real development teams. Drawing on data from SlashData's 30th Developer Nation Survey (which reached more than 10,000 developers globally in summer 2025), we'll show how these philosophical differences translate into concrete security practice adoption patterns, and why organisations should choose based on their specific context rather than industry trends. 

Developer Empowerment, Autonomy and Visibility

Those who follow the developer empowerment model focus on ensuring their developers are knowledgeable, informed, and have autonomy and visibility over their DevOps processes. Organisations adopting this approach typically value developer satisfaction and retention highly. This model hopes that recognition of experienced developers desire to control their toolchains and their resistance to imposed limitations will create happier developers who are willing to experiment freely. The organisations can provide guidance, approved vendor lists, or internal documentation, but ultimately they leave the decision to the ground-floor developers. 

The challenge with this is consistency. Security practices may vary between teams, which can lead to blind spots. While individual developers, or teams, may have high levels of visibility into their processes and build up deep familiarity with security practices, the lack of consistency can lead to blind spots in the organisation-wide security posture. Adding to this challenge is that knowledge can become siloed within teams, with successful approaches not being shared with others. At its worst, developers who lack security experience can have their autonomy instead become a liability rather than an asset. However, while decentralised approaches to security risks gaps, it also allows developers to react very quickly to new vulnerabilities without having to wait on a central platform team. 

In our current examination, this can include developers who are provided a curated list of tools for their selection and configuration (34% of professional developers). This leads to a slightly higher adoption of IDE security checks (32%), pre-commit hooks (20%), and container-scanning(28%) integrated into their CI/CD pipelines, as they are selecting the tools that they interact with during development. 

Business Focus: Abstraction and Efficiency

The other approach is business-focused, where the goal is to abstract away the concerns about security, infrastructure, deployment, and other DevOps processes behind an IDP or a controlled list of tooling configured for them (27% of professional developers). This aims to allow the developers to focus more on addressing business needs, and their core responsibilities, rather than having to consider wider aspects of the software development lifecycle. This approach emerges from different organisational priorities, including consistency at scale, meeting compliance requirements, or protecting specific business interests, even if it means constraining developers' choices. This can become especially true for companies with hundreds or thousands of developers, where complete heterogeneity of tooling can create maintenance headaches. In addition, organisations that want to prioritise their developer time on product differentiation, or need to onboard developers rapidly, a centralised process supports both of these.

This aims to allow the developers to focus more on addressing business needs, and their core responsibilities, rather than having to consider wider aspects of the software development lifecycle.

In practice, this can manifest as developers interacting with an IDP with abstracted interfaces. When a developer might deploy to staging, they may not be aware whether this instruction triggers Kubernetes, ECS, or Cloud Run behind the scenes. Within this approach, security checks happen automatically in the pipeline, where developers see the results but don’t necessarily configure these themselves. With these developers, we see higher rates of SCA (29%), DAST(26%), and IAST (27%) practices built into CI/CD pipelines because these happen behind-the-scenes for developers, which are benefitted by having highly centralised platforms. 

However, despite the benefits to organisations, and developers, these systems risk creating ‘black box’ problems. If developers don’t understand what is happening behind the abstraction, they can become less effective at debugging, and have a shallower understanding of security practices. Additionally, platform teams can risk becoming bottlenecks, with every new tool or feature request platform team time. This can leave developers unable to work, or risk them engaging in shadow IT and compromising the goals of centralising security practices

The False Choice

Neither approach is inherently better or worse than the other. Every few years thought leaders emerge to declare that development teams should shift-left or shift-right as the ‘correct’ way to do development, or to unlock previously unimaginable benefits. However, the reality is that simply shifting doesn’t actually do anything, and it is instead the processes, practices, and culture within organisations and development teams that have the largest impact, and centralising or decentralising are just mechanisms to achieve this. 

What matters instead is for organisations to consider other factors that will motivate them, and what capabilities it instead needs: faster feedback loops, comprehensive security coverage, developer satisfaction, or operational reliability. Some of these benefit from centralisation, and others from distribution, and organisations frequently blend aspects together to meet their specific needs. 

What to consider when choosing a DevOps approach  

Rather than asking 'which approach is better?', organisations should ask 'what does our context demand?'.

Consider:

• Organisational size and growth trajectory: A 50-person startup might start with curated lists, knowing they'll need an IDP at 500 people

• Team security maturity: Less experienced teams may need more guardrails; senior teams may resent them

• Regulatory requirements: Financial services or healthcare often require centralised control and audit trails

• Cultural values: Does your organisation optimise for innovation speed or operational consistency?

• Platform team capacity: Building an IDP requires sustained investment—do you have the people and time?

Your choice isn't permanent. Many organisations start with developer autonomy and gradually centralise as they scale. Others go the opposite direction, decentralising after realising their IDP became a bottleneck. The key is being intentional about the trade-offs you're making and regularly reassessing whether your approach still serves your needs.

Our team of analysts can help you decide on the best option, using concrete data to help your decision-making. Let’s talk and find the solution that works for you. 

About the author

Liam Bollmann-Dodd

Principal Market Research Consultant at SlashData

Liam is a former experimental antimatter physicist, and he obtained a PhD in Physics while working at CERN. He is interested in the changing landscape of cloud development, cybersecurity, and the relationship between technological developments and their impact on society.