A Platform Team Product Manager Determines DevOps Success

Puppet’s “State of DevOps” report has been tracking how companies deliver and develop software for 11 years. So, where have we gotten to over the last decade? For most organizations, the answer is: somewhere in the middle.

In fact, the previous four editions of Puppet’s annual report showed that the share of companies surveyed that are at the mid-level of evolution towards DevOps success hasn’t budged much at all, hovering around 79%.

And yet, there’s also some good news: the proportion of what the report calls “highly evolved” DevOps organizations has steadily climbed, from 10% in 2018 to 18% in 2021.

The researchers who conduct the “State of DevOps” report noticed a trend: companies that are succeeding with DevOps, and reaping its benefits, are likely to have adopted a platform engineering model. The report released on Wednesday took a deep dive into the practice.  Of those survey participants that have adopted platform engineering:

• Nearly all — 94% — agree that having a platform team is helping their organizations better realize the benefits of DevOps.
• More than two-thirds, or 68%, reported that development speed at their companies has increased.
• Most of those respondents who have a platform team report seeing better system reliability (60%), more productivity and efficiency (59%) and better workflow standards (57%).

Platform engineering, as the report puts it, is “the discipline of designing and building self-service capabilities to minimize cognitive load for developers and to enable fast flow software delivery.”

“Platforms,” or self-service models, have been around in some shape or form for years, predating DevOps. But, as Nigel Kersten, technical adviser to Puppet, told The New Stack, they were often “an abstraction that hid the complexity rather than an abstraction that still allowed you to go and look underneath as to what was actually going on.”

Modern platforms reflect the fact that the world beyond is increasingly self-service, he continued, and a recognition that users, including developers, are “a market, and you need to build things that appeal to that market.”

Digging deeper still into the latest report, which collected responses from more than 430 IT leaders and professionals around the globe, another striking fact emerges. Of organizations that have had a platform team for three years or less, 60% identified the need for a product manager; three-quarters of those who have maintained a platform team for more than three years did the same.

As the report stated, the initial benefits of a platform approach are relatively obvious and well-understood across the organization. But, it read, “once those capabilities are in place, identifying and prioritizing the next most valuable capabilities is a much more difficult problem — and one that requires the expertise and dedication of a product manager.”

Where does this leave DevOps as a whole? It’s too strong, Kersten cautioned, to say that DevOps has “failed” in the enterprise. But, he continued, it’s fair to say “things were terrible, and they got fine for most people, but they didn’t become great.”

The Benefits of Standardization

One reason for this, he suggested, was an overly developed suspicion of “frameworks” and standardization amongst DevOps trailblazers. On the one hand, DevOps pushed the idea that self-service was the way to go, while at the same time promoting the idea that developers should use whatever tools they want to.

But Kersten says one of the biggest myths around DevOps was that teams had to pick their own tooling, because “at scale, that’s a nightmare,” given the ever-growing landscape of options.

There are clear benefits to standardization, he said, not least because “in my experience, if you can take that load off people, they write better code, you produce better outcomes.”

And there’s a broader payoff for the enterprise. “Every time you jump from project to project inside an organization, it’s done differently,” Kersten said. “You build the software differently, you test it differently, you release it differently. You respond to incidents differently.”

While much of the DevOps conversation might be dominated by cloud native, Kersten pointed out that the platform model is equally applicable to managing more traditional, virtual machine-based infrastructure, a key focus for Puppet.

“There is still a massive need for solving these problems with relatively traditional applications that are never going to get the investment have been fully rewritten and migrated to the cloud,” he said.

The Role of Product Managers

So, if you’re not explicitly following this path already, where do you start?

Some organizations might be practicing platform engineering without even realizing it. Likewise, someone will slip into the role of product owner, if not explicitly assigned that role.

For instance, according to Ian Miell, a partner at Container Solutions, a cloud native transformation consultancy, “you might start off with two or three techies who want to build a Kubernetes cluster. And they quickly realize that they’ve got stakeholders, they’ve got features to build, they need to put together roadmaps. And someone accidentally ends up being a product owner.”

As you build platforms out across the organization, Kersten said, it’s important to ensure that the feedback loops expand accordingly.

“If you first build self-service for your own team it tends to be a simpler problem,” he said. “You’ve got the feedback loops already. You should, within a team, be talking to each other. Thinking about what you do as self-service and trying to build those abstractions for yourself, then you’re hopefully freeing up time.”

As the platform embraces other teams, “You can’t do platform engineering if you don’t have some way of talking to the people who are actually going to be using the services you build, and working out what their actual problems are, because their problems will be different from yours.”

The “State of DevOps” report’s findings underscore the need for a product manager with these “soft skills” to make platform engineering a success at scale. Sixty-one percent of respondents said strong communication skills were the most important product management skills for a platform team’s success.

Among the other highly prized capabilities:

The findings of the “State of DevOps” study suggest one reason why a product manager is needed to help a platform team succeed: Many IT professionals not only think that their senior management doesn’t understand the value of platform engineering, but many confess to not fully understanding it themselves.

In such environments, a product manager can serve as an evangelist for platform engineering, both within their team and outside of it.

Building 'Socio-Technical Systems'

Taking an explicit product management approach kicks a platform engineering initiative up a gear, Kersten said: “The sort of problems product managers fix are about increasing awareness, setting realistic expectations, prioritizing between different competing priorities across the user base.”

Miell echoed this sentiment. “When you lift the lid on these projects, they're always a mess of dependencies and difficulties and uncertainties,” he told The New Stack. “And someone has to translate that into, ‘We plan in the next three months to deliver next for the consuming teams of this platform.’”

This is a very different skill to simply being an engineer, he said, but it’s a complementary ability: “Without knowledge of what's going on technically, it's hard to do well.”

When it comes to software, Kersten noted, “what we're building are socio-technical systems.”

The problem is that hiring still tends to skew towards the technical side, he said. “We don't look at what we somewhat disparagingly call ‘soft skills.’ We tend to divide the world up into technical and non-technical and focus on one, ultimately resulting in worse products.”

Does that mean established technologists aren’t the best people to take on this product management role, and kickstart their organization’s evolution? Not necessarily, both Miell and Kersten said.

But it might take some imagination on the part of leaders, said Kersten. “Some engineers are really good at this sort of work,” he said. “And I think organizations don't always recognize that they can take strong technical people who are multiskilled and invest in them to teach them how to do other things.”

The result, he predicted, is that “ultimately, what they produce technically will be better.”