In the previous episode, we covered organizational culture, including why posters aren’t the way to change culture, crucial theoretical foundations from Douglas McGregor and Ron Westrum, the impact of arbitrary deadlines, and why feedback keeps organizations healthy.
This episode examines Platform Engineering and the persistent debate between mandatory and optional adoption strategies. The episode was inspired by data from our Future of Platform Engineering report.
Watch the episode
You can watch the episode below, or read on to find some of the key discussion points.
Watch Continuous Delivery Office Hours Ep.12
The rise of mandatory platforms
Mandatory platforms have been an issue in the past, with platform producers and consumers diverging dramatically on whether a platform is successful. Part of the perception gap comes down to platform teams losing the adoption signal: if everyone must use the platform, you’ve lost a way to discover gaps and flaws in what you provide.
Since then, platforms have become broader. Platforms now have almost 6x as many features as they did when the perception gap was present. As platforms take on tasks that developers truly appreciate, like security and compliance, the gap between producers and consumers has closed.
You might think of this like the difference between being forced to use a bicycle to travel both before and after the invention of the bicycle saddle. Riders are far happier to be forced to cycle when they have a cushioned seat.
Alongside the dissipation of perceptual differences, it turns out mandatory platforms outperform optional platforms in terms of goal attainment. However, there are many factors contributing to platform success, like monitoring developer satisfaction and regularly eliciting feedback to help improve the platform.
The other factors of platform success have more impact, and you should still consider optional adoption, but combined with mandatory policies. That means development teams have to meet the same standards they would meet if they adopted the platform, which makes platform adoption more appealing and less likely to cause conflict or friction.
Not just more features, but the right ones
The most common number of features baked into a platform was four, but that has grown to 24. Platforms are getting broader, and these wider platforms are more successful than the tiny ones of the past. Despite this link between platform breadth and goal attainment, it’s important to bear in mind that the volume of features alone is not a sufficient strategy, and that choosing to solve the right problems is the path to success.
Maintaining regular contact with developers, lightly assessing their satisfaction with the platform, and dedicating time to conversations that shape your platform’s direction are all part of the high-performance platform playbook. The usefulness comes from solving the right problems, and you need to focus on developer needs to make the right choices.
Platform teams are rediscovering many of the capabilities of the State of DevOps research and its associated model, like Lean Product Management, which prove useful in building platforms as internal products.
The invisible platform dilemma
Unsurprisingly, platforms that meet more goals have higher budget safety. They are showing a return on investment, so they can be confident in maintaining their funding over the long run. Platforms that fail to meet their goals are more likely to have their budgets redirected to other initiatives.
Platform teams need to show the value back to the organization in terms the organization understands and for measures it cares about. With AI initiatives soaking up money, some organizations will start reallocating funds and focus, leaving platforms underfunded or dropped.
Some of the best platforms will be invisible in daily use because developers don’t have to keep interacting with them. These boring, invisible platforms are the most valuable, but the least visible. Providing metrics and proof of value for these platforms will keep them funded.
Happy deployments!
Continuous Delivery Office Hours is a series of conversations about software delivery, with Tony Kelly, Bob Walker, and Steve Fenton.
You can find more episodes on YouTube, Apple Podcasts, and Pocket Casts.
