Adaptavist: Why culture is king for successful self-service developer tools
This is a guest post for the Computer Weekly Developer Network written by Matt Saunders, VP DevOps, Adaptavist.
It’s becoming more widely accepted that any organisation with a large number of development teams should be investing in self-service tooling.
Analysis from ThoughtWorks and Gartner on platform engineering indicates that providing developers with tools they can use themselves to build software and deploy it autonomously, rather than relying on other teams to perform various tasks, is a significant indicator of high performance. However, simply adding these tools isn’t enough; they need to be paired with organisational and cultural change.
Organisations that attempt platform engineering by simply dropping a suite of tools on teams, and proclaiming them “the standard and only way to do it”, generally fail due to a lack of buy-in, poor awareness, and misunderstandings with how those teams actually work. Avoiding these problems requires a consultative and iterative approach that actually empowers development teams and treats them as proper customers.
This means spending time understanding real pain points, mapping current delivery processes, and validating that new tools genuinely reduce friction, rather than adding more.
Examples of success
Giving teams the autonomy to make their own decisions while using powerful self-service tools safely, increases their satisfaction and demonstrably makes them more effective. The autonomy reduces bottlenecks, shortens feedback loops, and lets teams experiment with approaches that best fit their context, improving overall performance. Organisations such as Netflix and Shopify, for example, have implemented distributed control, resulting in faster innovation, with these findings echoed in the DORA Accelerate State of DevOps report.
Similarly, Google’s SRE practices demonstrate how autonomy can be safely scaled. Rather than relying on gatekeeping, where a team of experts manually triages requests through restrictive approvals, Google uses guardrails which put automatic and well-documented controls around powerful tools. This allows development teams to use them within safe boundaries autonomously.
Tools for success
However, for self-servicing tools to succeed, development teams have to want to use them. Similarly, the teams that are successfully building developer tooling are conducting proper user research, prioritising features, and offering ongoing support. Successful platform teams use a continuously iterative approach, treating developers as proper customers, and refusing to let this work be a side project. They also measure adoption carefully, retire unused features, and make intentional improvements based on observed behaviour, not assumptions.
The combination of proper structured developer feedback, and metrics around usage leads to teams iteratively improving their tooling. Teams succeeding with this approach carefully construct feedback loops to identify improvements to make, increase internal tool adoption, and utilise the resultant metrics to drive engineering management. Collaborative documentation and knowledge transfer techniques, such as wikis, brown-bag learning sessions, and open forums, help onboard new teams as they can learn from their peers.
This shared knowledge base becomes a living asset that scales far better than ad hoc support or undocumented tribal knowledge.
All of these methods lead to a successful shared responsibility for the developer experience among platform teams, product teams, and, crucially, leadership. Organisations exhibiting these behaviours are enabling or helping a cultural shift towards cross-functional collaboration, and an environment where developers can experiment with self-service tools with psychological safety and without fear of blame. All of this opens the door to more innovation and better software. Leaders who reinforce these behaviours signal clearly that platform engineering is not about control or compliance but about enabling sustainable, predictable delivery at scale.
All-in-all, even the best developer tooling won’t have the impact you want it to without careful cultural and procedural changes. Ensuring there’s cultural alignment, and adjusting workflows and decision-making working processes to enable that, is as important as the tools in building a successful platform.