Platform engineering can make development teams more productive by enabling self-service for developers, so that they’re not stuck waiting on IT tickets for days or weeks on end just to set up some infrastructure needed for a project. But in order to realize the benefits, it’s important to set the platform engineering team up for success by ensuring that they have the necessary skills, structure, and working processes in place.
“Having a solid team makes the experience a lot easier for the people receiving and the people building the platform,” said Ryan Cook, senior principal software engineer at Red Hat.
Luca Galante, VP of product and growth at IDP company Humanitec and organizer of PlatformCon, believes that one of those important skills is the ability to have a product mindset, approaching things from a continuous development perspective based on a tight feedback loop with the teams they are building the platforms for, rather than building and shipping software and then being done with it.
RELATED: IDPs may be how we solve the development complexity problem
“It’s really about seeing developers in a different light, which is the internal customers, and we’re serving them and solving their pain points,” Galante said.
Cook agrees with that, adding “understanding what the teams need, what the people building the platforms need, is the best way to be successful.”
Communication is also key, because platforms interact with everything — and multiple teams — in an engineering organization. This includes developers, infrastructure and operations (I&O) teams, security teams, architects, executives and more.
“In order for everybody to be on board, there needs to be a driving internal marketer on the platform team that effectively aligns the development of the platform and the benefits that it drives to the vested interests of the different stakeholder groups,” Galante explained.
For instance, a development team that is experiencing long waits from the infrastructure team could be sold on a platform by being told it’s going to reduce wait times and improve developer experience. It could be sold to the security team as something that is going to enforce governance and policy by default. And it could be sold to the infrastructure team as something that is going to reduce the need to do manual configurations every time a developer needs something.
Thus, there needs to be someone on the platform engineering team who is able to articulate and communicate these benefits to the various stakeholders, so that everyone understands this is a worthwhile endeavor.
A third important skill is deep technical capability and understanding, said Zohar Einy, CEO of Port, another IDP provider. He explained that it’s important for a platform engineer to have an understanding of how the components of the company’s technical stack are set up, what development tools are being used, and so on.
“They need to have a very good understanding on how things are wired and how the platform is built behind the scenes,” he said.
Red Hat’s Cook believes it’s a good idea to have different people with different areas of expertise, like someone that’s really good at telemetry or security, or development or virtualization – or whatever it may be.
“We all have this unique expertise, but the same goal, and I feel that expertise helps because it gives the ones that are experts in their space the confidence to continue to be experts there, while it gives the other folks breathing room that they don’t have to become experts outside of their individual realms. So everybody kind of leans on each other, which creates a good, friendly relationship internally with the team,” he said.
Specific roles that make up a platform team
According to Galante, there are four main roles that all platform teams should have: head of platform, platform product manager, platform engineers, and infrastructure platform engineers.
The head of platform is ultimately the person that is going to motivate and sell the platform to higher-ups in legal and compliance, finance and the executive suite. They are responsible for explaining the value that platforms can have, and to “make sure that they see the platform as a value driver, as opposed to a cost center.”
They will also continuously update those stakeholders on the progress throughout the platform’s life cycle.
The platform product manager is the person responsible for making sure that the platform is actually made. They’re also there to facilitate compromise for the different stakeholders, like making sure that the security team is happy because security is enforced by the platform or that the architects are happy because the platform fits within the broader enterprise architecture.
They are also responsible for making sure that the end users — the developers — are happy with the platform and actually want to use it. According to Galante, there is a fine line between abstracting away the underlying complexity of the infrastructure while also keeping enough context for developers to do their jobs properly.
“You want to provide developers with paved roads and really intuitive ways of interacting with your increasingly complex tool chain … But at the end of the day, they’re still engineers. They want to be able to still have some level of control and context around the work that they’re doing. And so that’s what the platform product manager is really focused on,” said Galante.
The final two roles are the platform engineers and infrastructure platform engineers. The reason for the differentiation is that platform engineers are the voice of the developers they’re building for, while infrastructure platform engineers are the voice of the I&O team.
According to Galante, there can often be so much focus put on improving developer experience, but it’s important to make sure that the needs of the I&O team are also being considered.
“You can think of the platform essentially as a vending machine that you’re maintaining, growing, and providing as a service to the rest of the organization,” he said. “And so that is where it’s very important to have this kind of role of the infrastructure platform engineer that oftentimes can come from the infrastructure scene and build that bridge to make sure that both perspectives are represented on the platform team.”
The job types that transition well into platform teams
Einy believes many existing roles can transition well into the platform engineering team, such as DevOps engineers, technical product managers, and SREs.
According to Einy, DevOps is a spectrum, and there may be DevOps engineers who are more infrastructure oriented and ones that are more experience oriented. He believes that the ones who were responsible for the user-facing processes can translate well into a platform engineer.
“In the past, the platform engineering responsibility was part of the DevOps responsibility, but now it’s like it went to an entire role of its own,” Port said.
Cook added that DevOps has likely felt the pain of what it takes to release and maintain software, so they can bring what they’ve learned to the table.
Einy believes that technical product managers would also do well on a platform engineering team, because they are used to needing to have deep technical knowledge of their products.
And finally, SREs translate well into platform engineers because they’re responsible for quality, making sure that the MTTR is low, and improving the overall resiliency of an organization.
“One of the main values for platform engineering is to create the standards and to maintain the resiliency and efficiency of things,” Einy said.
Now that a team is in place, what’s next?
Once the platform engineering team is established, it’s important to have strong collaboration within the team, and also with the stakeholders they are building for. In terms of building a good platform engineering culture, Cook recommends establishing an environment where the engineers are respectful of each other and of each other’s time.
He also added that by bringing in different experts to the team, they will by nature start to depend on each other and get to know each other. “Having those smaller teams with the expertise kind of helps on the friction side, because they’re in it together,” he said.
When it comes to collaborating with the different stakeholders that the platforms are being built for, that platform-as-a-product mindset comes back into play. This collaboration should be a continuous loop, not a one-and-done approach.
According to Einy, platform engineering teams should be conducting surveys, which means they need to know how to run a good survey, which entails knowing what questions to ask, setting goals for the responses, and then finally being able to digest and understand the results.
He added that it’s also good to be doing data analysis on usage of the platform, who is using it, what parts are getting used, how often it’s used, etc.
“Again, talking with the people, not in a structured way, but creating some kind of closed group of people that can represent the wider audience and collecting feedback from the field,” Einy said. “I think that these are the things that they need to do continuously to know that they are solving the right problem for the organization.”
Cook added that when he started working at Red Hat, they hosted a “complaint fest” where the development teams came to them and let them know what was wrong in an open, constructive way. He said that developers were a bit hesitant to speak up at first, but once one person started the discussion, that broke the ice for the rest of the team to be open with what’s wrong.
“If you can let everybody know that you do really care about the concerns and you are trying to fix them, they’re going to be a lot more willing to use your product than if you just do it without them,” Cook explained.