The concept of Platform teams is taking hold in a world where change and new methodology are the only certainties. There is a growing need to handle internal products and services in a controlled and efficient manner within organizations, and Platform teams are at the forefront of the solution.
Platform teams create and maintain an organization’s Internal Developer Platform (IDP) while developing and improving the business's tools. These teams are quickly becoming the key to success for many companies due to their ability to react quickly, provide needed services for other internal teams, and scale with the organization’s growth.
We recently hosted a webinar about Platform teams with Nigel Kersten, the field CTO at Puppet. He’s responsible for bringing product knowledge and a senior technical operations perspective to Puppet field teams and customers, working on services strategy, and representing the customer in the product organization. He’s co-author of the annual State of DevOps Reports published by Puppet.
In the webinar, he covers key findings from the 2021 State of DevOps Report by Puppet, putting them into a broader context and looking closely at the role of platform teams and their importance to an organization. This article takes a brief look at Nigel’s insights and ideas.
What are Platform teams?
Elite tech companies use Platform teams to ensure end-to-end developer self-service. These groups build internal workflows to create a smooth development and deployment experience for all involved.
As Puppet defines them in the 2020 State of DevOps Report, “Platform teams provide the infrastructure, environments, deployment pipelines and other internal services that enable internal customers (usually application development teams) to build, deploy, and run their teams.”
The Platform team approach shifts the business method away from siloed teams with an unclear understanding of the teams’ role within the organization. Instead, a collective group collaborates to craft a streamlined, communicative model with opportunities for feedback. The net result focuses on the outcomes, providing solutions to internal teams, and more communication.
The three levels of team organization
But throwing a team together is only part of the battle. For Platform teams to be effective, businesses must strategically organize them to ensure everyone is on the same page.
“Most companies have an idea of where they should end up: lower friction, the fast flow of software delivery, and higher quality outcomes. The problem is that they don’t know how to get from where they are now to there. Getting rid of the scar tissue of old code and outdated processes ties up valuable time,” Nigel states.
To assess where a company sits in the gap between its current state and desired outcomes, we can ask questions around established DevOps key metrics like
- What’s your mean time to recover?
- How quickly can you deploy software?
- How quickly can you respond to change?
- What’s your failure rate?
The answers to these questions determine whether they are at a low, medium, or high level in team organization.
Some immediate impact changes for companies scoring low on the scale include creating a single version control system accessible for all developers and encouraging everyone to have their information in the version control.
There are a lot of companies that are “stuck in the middle,” having implemented some valuable processes but still not completely optimized. Nigel claims this is because “they’ve optimized for the team. An individual operations team or development team might be doing very well. Still, the organization hasn't optimized as a whole.”
Companies using Platform teams operate at the higher end of the organizational performance scale, as they've dealt with many of these issues and have a system in place to identify and solve problems.
DevOps and Platform teams are NOT just automation
With the increasing popularity of DevOps, some misconceptions have arisen. “If you’re doing automation, using infrastructure as code, taking any of these approaches, then you’re doing DevOps, and that’s just the technical aspects. With Cloud, organizations rebrand sys admin or sys operators as Cloud engineers and say, ‘We now do DevOps,’” notes Nigels.
“In terms of automation, it’s not really possible to do well at DevOps without a high degree of automation,” continues Nigel. But analysis shows it’s not predictive of DevOps success, and improving automation alone does not guarantee an improvement in DevOps.
Additionally, Nigel argues that “organizations that are good at DevOps, are good at communicating between teams, and optimize the pipeline across parts of the software delivery cycle are better at using Cloud. They are better at using the elastic consumption base - all of the advantages that Cloud can give you.”
However, it’s essential to remember that although companies that are good at DevOps tend to do better at Cloud, those things are not synonymous.
DevOps and Platform teams aren’t the Cloud
Corporations moving to the Cloud is inevitable. But suppose a company is not good at managing on-premise? They’re not going to be good at managing the Cloud either. As Nigel says, “it’s the same work with a faster feedback cycle, with more pressure, more change, more work that needs to be programmatically done rather than manually done.”
Some smaller companies recognize that shifting workload to the Cloud is not cost-effective for them, perhaps because it’s heavy with data or they’re completing many inter-regional transfers. Those companies seem to be bringing things back on-premises to stick with a system they’re familiar with using.
The people who are good at automation, DevOps, and the Cloud, are generally also good at moving workloads around between different environments because they either use a Platform team approach where there’s an abstraction in place, a highly automated process, or both.
Platform teams engage both automation and the communication process
It's essential that employees can focus on their job and work efficiently. “If you have entirely autonomous DevOps teams... they’re going to own the infrastructure they build on and how they’re going to deploy and manage everything. That may do a great job optimizing locally for that value stream team, but it doesn’t optimize for the whole organization,” adds Nigel.
Businesses are increasing the cognitive load for their auditors, their IT asset management team, and all governance issues around cost control and security. This creates problems with switching from one group to another.
The platform team approach creates a single place where all of the concerns regarding infrastructure and everything below it are solved for developers.
Making Platform teams work
Moving from a local business group structure to a Platform team mentality isn't easy. Still, the long-term reward of a unified, easy-to-understand corporate model for development is worth the effort.
The Team Topology method is an option for exploring the internal organization of teams within a company and arranging them in a way that allows them to deliver software effectively. The book Team Topologies by Matthew Skelton and Manuel Pais first introduced the concept.
The idea defines four fundamental topologies.
The four teams are comprised of:
- Stream-aligned team: the group aligned to a designated flow of work (typically a business stream)
- Enabling team: the group tasked with removing obstacles from the stream-aligned team’s path and detecting any missing capabilities
- Complicated Subsystem team: the individuals called when extreme mathematical, technical, or calculation expertise is needed
- Platform team: a force of other team types that help accelerate stream-aligned delivery by developing a compelling internal product
The Platform team builds the internal platform that accelerates delivery by stream-aligned teams. These groups handle that entire portion of the business domain from end-to-end while working with other team types (Complicated Subsystem teams, Enabling teams).
Nigel highlights the Platform team’s responsibility to collaborate with other groups. “One of the core ideas around the Team Topologies model is, does the team have a purpose and a clear understanding of the team's responsibilities to other teams? It sounds basic, but one of the biggest inhibitors to success inside large organizations is not knowing what teams do or what they should deliver.”
He continues, “In highly evolved teams, more than twice as often as low evolution teams, the team has a clear understanding of their responsibilities to other teams, clear roles, plans, and goals.” In short, businesses cannot achieve a significant transformation until they have these things in place.
When it comes to a Platform team and value stream teams, it's essential to clarify what the developer teams are allowed to do. These sorts of decisions are difficult to make without the groundwork of the team’s responsibilities and the different teams’ interactions. Team topographies offer a detailed map that guides companies to top-tier organization.
“Higher evolution organizations have a smaller number of team types. Businesses at the lower end of evolution tend to have every single kind of team with unclear responsibilities between them,” adds Nigel.
Platform teams for smaller businesses
According to Nigel, there is a scale below which it doesn’t make sense to run a fully-fledged platform team. “If the organization is smaller, what are the things related to dependencies to deliver an application - infrastructure, governance, business readiness process, or change management?”
If a company has 10-15 developers, the overhead of running a Platform team may not outweigh the benefits. On the other hand, giving developers a more direct experience may still be of value. It likely depends on the developers, the applications, and the organization.
Nigel also advises, “Even at small levels, there is almost always something that the company can be providing as a common layer across things.”
Preventing silos in the Platform team model
The Platform teams model has an important role, delivering to users internally or externally via self-service. A lot of time is spent collaborating with users at the design phase. “Collaboration is expensive - it’s not the best way to do efficient, at-scale interactions between teams. Delivering things via a service, like an API, is a more efficient way,” notes Nigel.
A Platform team approach needs a product-centered mindset and needs to think about users as though they were a market. “It’s about thinking about how to solve their problems, not just providing raw access to infrastructure,” claims Nigel.
When organized efficiently, the teams can receive early feedback from users and have feedback loops between product producers and consumers. This feedback comes back to the platform team instead of becoming siloed.
Big picture and the future of Platform teams
While it’s important to actively deal with immediate problems and grow the team model to a point where companies can effectively deliver software, future planning is crucial to a company’s survival. It’s essential to look down the road and consider what challenges or changes in scale will affect the organization and how Platform teams help tackle those challenges.
The Golden Path Approach
Many developers define the Golden Path as the narrow and supported way to build something, whether it’s a backend service, website, or data pipeline.
Larger businesses can fall into the trap of the “we built the thing, you have to use it or else” mentality. Teams need to trust that developers are good at writing code and will come up with ideas that might be better than the existing ones. Teams should pull new creations into the platform and company Golden Path if they show a high usage rate.
The job is “not just defining what is going to be built, making sure it’s built well, and then stepping away,” says Nigel. “The team needs someone to take on the marketing role and evangelize it/sell it by letting users know that you’ve solved their problem and asking for feedback.”
How businesses are embracing the Platform teams model
Companies are starting to talk about the Platform teams model in the same way they spoke of SRE, GitOps, and various other flavors of the month. Big analyst firms are talking to senior executives, saying they need a Platform teams model. More and more people are saying this is the way to scale out. Additionally, employing an elite Platform team mitigates the risk of the wrong adoption and ensures that teams have an efficient, streamlined system to use.
The future looks bright for those specializing in being a platform engineer, becoming a product manager, and platform teams succeeding at using a platform well inside an organization.
The future of infrastructure
Looking four or five years out, fewer and fewer organizations will run their own infrastructure anymore. What will this mean for platform builders and those who work in the ops field? Vendor management will become more critical. Infrastructure engineers will work with independent platforms, and product managers will develop architecture and make everything work together.
Summary
As Nigel outlines, Puppet’s 20201 State of DevOps Report demonstrates that Platform teams are critical to DevOps success at scale. Platform teams are vital because they bring everyone together and produce systems that work for all users.
Platform teams provide an innovative and scalable way to keep your teams working together and allow feedback loops to improve your internal processes. Their ability to react quickly to change, create solutions that work within the organization, and create meaningful and organized change enables companies to grow and scale instead of being left behind with technical failures.
Read Puppet’s full report here or watch our complete webinar here.
