Designing Effective Cross-Team Dynamics For Platform Teams
Discover how to transform platform teams from bottlenecks into powerful enablers.
A few weeks ago, I drove from Vienna to Salzburg on the highway (known as the "Autobahn" in Austria). It was just before Christmas, I was in a holiday hurry, and my main goal was to arrive in Salzburg as quickly (and safely) as possible. The Autobahn was, therefore, an obvious choice: its multi-lane roads and high-speed limits made it the ideal route for a swift journey. While I could have taken alternative streets (keep in mind that using the Autobahn in Austria requires a toll), the Autobahn best suited my needs. Moreover, if my objectives had been different—such as exploring the countryside or enjoying scenic drives—I might have selected entirely different roads.
Although this example might seem trivial, it illustrates an interesting dynamic also present in software development: certain teams provide infrastructure and operations (the Autobahn) for other teams, who then choose to utilize—or bypass—this infrastructure to achieve their specific goals.
We typically distinguish between two types of teams. There are teams that produce code that represents the end user’s domain. In this post, we call these sorts of teams application teams. In contrast, there are teams that produce an environment for application teams to operate in, most often by providing the infrastructure needed to execute their code. In a sense, they are the teams building and maintaining the highway, while application teams are responsible for transporting people efficiently. We call the second type of team platform teams.
When Platform Teams Become a Bottleneck
The dynamics between application teams and platform teams are often complex. While in some smaller contexts, application teams build and operate their software solutions without needing other teams to help, they usually develop their software on some platform - be it on a cloud platform, embedded platform or operating system. The responsibility of platform teams is to manage these platforms.
Platform teams can be internal (within the same company) or external, such as when application teams utilize a public cloud platform. For the remainder of this post, we'll focus on the dynamics between application teams and internal platform teams, though much of the discussion also applies to external ones.
Platform teams play a pivotal role within organizations by delivering central infrastructure, which can inadvertently position them as potential bottlenecks. To prevent this, platform teams must navigate particular challenges and avoid specific pitfalls.
TicketOps
Organizations should avoid delays caused by application teams waiting on platform teams. This often happens when platform teams rely excessively on manual processes to deliver infrastructure and services. For example, an application team may need to release a new service version but must first submit a ticket to the platform team to reconfigure the production environment. Waiting for the ticket to be resolved creates significant friction within the organization. This not only leads to finger-pointing and debates over prioritization and misalignment but also slows down the application team's delivery speed.
This reliance on tickets and manual work for the interaction between application and platform teams is often framed as TicketOps.
Governance
While it is understandable that platform teams fear application teams adopting a wide variety of tools, frameworks, and programming languages—which can lead to a disorganized and unmanageable ecosystem—the primary method used to address this complexity is often governance. Governance typically involves imposing strict rules to limit technological diversity, primarily through safelisting approved tools and technologies.
However, this approach has two significant drawbacks:
First, strict enforcement of current technologies can severely hinder the adoption of new tools and methodologies, disregarding the specific needs of individual teams. This rigidity transforms the platform from a value-adding resource into a burden for development teams, ultimately stifling innovation and limiting the organization's ability to adapt to emerging trends.
Second, teams with unique requirements that do not fit within the governed solutions may find the platform overly restrictive. This can lead them to seek workarounds or wait for platform teams to implement necessary adaptations, which can slow down delivery speed and reduce overall efficiency.
Over-Engineering and Thick Platforms
When platform teams attempt to implement and support a wide array of technologies, infrastructure, and configuration options, they can quickly become overwhelmed by the sheer number of capabilities integrated into the platform. This not only makes the platform harder to use but also increases the burden on platform teams to maintain the complexity, keep everything up-to-date, and respond to a broad range of change requests from application teams.
Addressing Challenges in Team Dynamics
The issues discussed are primarily social in nature, presenting themselves as technical symptoms exacerbated by technical inefficiencies. To effectively tackle these problems, the central question should be: What do application and platform teams truly need?
Adopting a team-first perspective is essential for resolving these challenges. We need to focus on designing valuable and productive interactions between platform and application teams. A useful framework for this is outlined in Steven Pinker’s book “Drive: The Surprising Truth About What Motivates Us”. Pinker identifies three key factors that motivate individuals and teams:
Autonomy: The ability to make decisions, reflect on them, and adapt as needed.
Mastery: The opportunity to perform work and receive feedback to improve skills.
Purpose: The sense of working towards something achievable and worthwhile.
Let’s explore how we can address each of these areas to enhance team dynamics.
Autonomy
Just as I prefer choosing my own route to a destination, autonomous teams need control over their solution space and the authority to make decisions within it. They must also be able to gather and incorporate both external and internal feedback, as well as prioritize their work within their areas of responsibility.
Often, the dynamics between application and platform teams can impede the autonomy of both, especially when responsibilities are divided between development and operations. For instance, application teams building software and then handing it off to platform teams for operation can undermine the responsibility and autonomy of all involved.
Let’s look at two strategies to increase autonomy:
Self-Service
Self-service interfaces should be the primary mode of interaction between application and platform teams. By leveraging self-service tools, development teams can provision the necessary artifacts and infrastructure provided by the platform team—ranging from databases and middleware to container infrastructure, documentation, and entire application/service blueprints. Self-service interfaces have two essential properties: first, invoking the self-service interface does not require or cause manual work from the platform team. Second, application teams manage the lifecycle of the provisioned artifacts, including creation, updating, and deletion. The platform team provides blueprints and tools for the application team to make handling those artifacts easier.
In contrast to the TicketOps approach, where application teams depend on platform teams to perform tasks and wait for ticket resolution, self-service interfaces clearly delineate responsibilities. Platform teams focus on providing a seamless developer experience, while application teams handle their own infrastructure needs using the provided tools - the self-service interface is then merely a tool they use to make their jobs easier.
Team APIs
Team APIs are a valuable tool for making interactions between teams more explicit, thus increasing autonomy. As I have written in “The Power of Team APIs: Streamlining Cross-Team Interactions”:
By formulating a Team API, development teams can publish typical and deliberately designed interaction points for other teams. It contains everything about the team that other teams need to know to contact it and provides context to make interactions more productive. Usually, this means
describing what the team's responsibility is: what modules or features are they responsible for?
answering whether the team provides value to end-users or development teams (e.g. as a platform or enabling team)
listing what the team provides for other teams. This could be technical concerns like an API or social aspects such as consulting.
stating how to reach the team
describing what the team is currently working on and what other teams it relies on to achieve its goals.
(Check out the post for an example of a Team API).
Platform and application teams can use Team APIs to define their interactions and establish a clear-cut separation of responsibility. Platform teams specifically should mention what self-services they offer and when application teams should contact them, e.g. to communicate improvement ideas for the platform.
Mastery
Creating exceptional products that teams are proud of and users love is one of the most fulfilling parts of software development. Achieving mastery, both individually and collectively as a team, is crucial for reaching these goals. Here are two approaches to foster mastery within application and platform teams:
Lower Cognitive Load
Cognitive load refers to the amount of information an individual or team can process at any given time. It exists on an individual but also on a team basis. Each team has a limit of complexity they handle reliably and sustainably. Multiple things increase team cognitive load, for example the complexity coming from programming languages and frameworks (also called intrinsic cognitive load), the complexity of tools a team uses to approach tasks such as continuous deployment or monitoring (also called extraneous cognitive load) and the complexity of mastering the domain (also called germane cognitive load).
To enhance mastery, teams should minimize intrinsic and extraneous cognitive load to foxcus on germane cognitive load. Teams should be as good as possible in mastering their domain since this is the area where the users of their product derive the most value from. A team that is heads over in details of their technical setup is much less effective than a team that can focus on writing value-adding business code.
Therefore, both application and platform teams profit from focusing on their domain. For application teams, this is mostly the business domain of the application they are building and for platform teams this is the technical domain of the infrastructure they are maintaining. Further, platform teams can help in lowering the cognitive load of application teams (the extraneous cognitive load specifically).
Your Platform Is a Product
Platform teams should treat the platform they build as a product, with developers as their customers. Just as those maintaining a highway strive to provide the fastest and safest routes, platform teams should aim to maximize the developer experience.
Adopting a product mindset involves
gathering requirements for the product: engaging with application teams, observing they issues they are facing and looking for opportunities to lower their cognitive load
developing a product ownership: prioritizing tasks and assigning product ownership roles to ensure the platform evolves in line with user needs.
gathering and incorporating feedback: Continuously seeking and integrating feedback to improve the platform, as detailed in my post “Course Correction: Implementing Effective Feedback”.
Purpose
Purpose in software development arises from striving towards meaningful goals and recognizing the positive impact on users. Application teams often experience this directly by seeing how their software enhances users' lives. Platform teams, while their users are developers, should also find purpose in making their developers happy and effective. There are two important things that platform teams can keep in mind and use as tools to improve their sense of purpose.
Making developers happy
Platform teams should monitor developer satisfaction using metrics like the Net Promoter Score. This involves regularly surveying developers to gauge their likelihood of recommending the platform to other teams, providing holistic feedback on the platform’s effectiveness and areas for improvement.
Thinnest Viable Platform
Based on the term “minimum viable product”, platform teams should strive to create the thinnest viable platform that delivers value to users. Instead of building a huge platform up-front and only later recognizing that developers don’t want to use it, strive to build a platform iteratively and incrementally: start with the smallest, most impactful features that address user needs, build, gather feedback, and refine the platform incrementally. … rinse and repeat.
By doing that platform teams will find that they are much more effective in building a platform their users want - with constantly and continuously delivering value along the way.
An overview
To summarize the strategies and tools discussed:
Conclusion
Designing effective interfaces between platform and application teams is challenging, but crucial for organizational success. By carefully crafting self-service tools and fostering autonomy, mastery, and purpose, platform teams can transform from potential bottlenecks into powerful enablers. Implementing the strategies outlined in this post will help you move closer to achieving a harmonious and efficient team dynamic, ultimately driving innovation and productivity across your organization.
Further Reading
If you want to learn more about cognitive load and the dynamics between application and platform teams, I recommend the book “Team Topologies” (they use the term stream-aligned teams as a more specific term for application teams who are aligned to a value stream).
I have compiled a few ideas and practices in the realm of platform engineering over at my companies website (in German 🇩🇪).