What makes a good platform engineer?

Give me T-shaped ops folks and UX specialists says IBM CTO Paul Briscoe

The list of reasons why organisations don't always achieve the hoped-for value when migrating to the cloud is long, including legacy tech, outmoded ways of working, and a lack of collaboration between teams and departments.

Paul Briscoe, CTO for hybrid cloud transformation UK&I at IBM, is building a consultancy service to help customers get the most out of cloud migrations. The new service builds on IBM's recent acquisition of hybrid cloud consultancy Nordcloud, as well as his team's expertise in DevSecOps, automation and platform engineering.

Briscoe, an IBM distinguished engineer and veteran of 30 years including 19 at Global Technology Services (latterly spun off as Kyndryl) is very much on the consultancy side of Big Blue's business. This, he says, enables him to take a vendor-agnostic view of cloud platforms and tools and to use whatever is most appropriate. "The whole point is to help clients accelerate their journey to cloud."

Creating common ground

In large organisations, it's common to have multiple teams and individuals using the same tools and services but in different ways, or conversely, doing very similar things with different tools. This situation, the result of a lack of collaboration, can easily lead to wasteful duplication of effort, with small differences soon hardening into impenetrable silos.

Enter the platform team. Their job is to curate a set of common tools and services used by multiple teams and make them available on a self-service basis. The basic idea is that the platform team creates value for developers and DevOps engineers, who in turn create value for customers.

Platform engineers are much in demand, but what makes a good one? First and foremost, a broad range of experience, says Briscoe. As such, the role presents an opportunity for those with an ops background to shine.

"I always come back to the T-shaped model. You want generalists [with a specialism] who can then turn that into something which can then be reused by another team of people," he says.

"For me, it's the operations teams, the people that are normally left behind, who actually add the most value and who also have most to gain. They've already seen the T-shape, they know how to do 24/7 operations. If you create a platform that doesn't have that, you're going backwards quick."

UX specialists are another vital component of any platform team, Briscoe continues, joking that in his career he has created "platforms that were technically brilliant but unfortunately completely unusable." Self-service for the masses demands interfaces that are intuitive, attractive and consistent.

Thus far, platform engineering teams have mainly been the preserve of large, regulated organisations, including the financial institutions with whom Briscoe has worked for much of his career. But there's nothing magical about them, he says. As a practical way of instituting best practice, the underlying principles apply to "Mom and Pop firms using a few AWS services" just as they do to a global bank.

"I think certain principles are the same for any size of organisation. You want developers to be consistent; you want their code to be manageable going forward."

Applications are not islands, they all fit into a greater ecosystem, and being able to see this big picture, to maintain observability is vital, he says. Adopting a platform approach allows organisations to standardise the provision of common tools, taking the weight off the developers' shoulders.

"You need to be reusing a set of assets. They've got to be secure, and they've got to be resilient. I don't want the developers to be thinking about some of that stuff."

Cleaning up the mess

While the general principles are universal, it's in large, complex organisations that platform teams offer the most obvious benefit.

"We've seen certain financial services who have created the same thing in multiple different areas. If they'd just taken half a step back and actually created a platform team, thought about observability, thought, 'How do I cost that? How does that work with finance? What does that do? How does it all fit together?' they would have saved an awful lot of money."

It's not just the financial side. The practical and organisational problems of teams and departments going their own way becomes painfully apparent when it comes to cloud migrations.

"There's no consistency other than the end point and the starting point: 'I've got an application I need to move it to cloud' - that's the only commonality they've got. They've got different CI/CD pipelines, different platform ways of working, differences in how they charge back."

This technical and organisational baggage is sadly ubiquitous, he says, and working through it prior to a migration is a significant part of the job.

"To be honest, that is the majority of my conversations at the moment. How do we clean up a lot of that mess because it's making it too hard to get the value from cloud."

To learn more about platform engineering, join us on 25th April for DevOps Live 2023.