Exploring team dynamics and the role of Internal Developer Platforms

Member post originally published on the Mia-Platform blog by Giovanna Monti, Full Stack Developer, Mia-Platform

Entering the world of a fast-paced tech company can feel like diving headfirst into a sea of complexity, where understanding the organizational structure is often a secondary concern.

I hadn’t given much thought to this topic until it popped up during one of my regular meetings with the Platform Engineering guild at my company. During the discussion, I realized I knew very little about team organization and collaboration, but I also came to understand that the presence of an Internal Developer Platform (often referred to as an IDP) can have an impact on how teams are structured and interact, based on its adoption stage.

This article aims to explore team organization strategies within IT companies, highlighting how the adoption of an IDP can help shape team dynamics toward efficiency and cooperation.

Team Topologies: Understanding your Company Structure

The first question I asked myself was whether there were patterns in team organization in IT companies, because it seemed like everyone was doing it differently. The “golden” organizational structure is hard to find. I discovered the functional structure, product-based structure, matrix structure, and many more. But how can all this be rationalized, with a focus on the IT field?

That’s when I came across Team Topologies, a framework for organizing and structuring software Development Teams to improve flow, communication, and overall effectiveness. Developed by Matthew Skelton and Manuel Pais, it defines four team types and three possible ways for them to cooperate. This model provides a higher level of abstraction compared to the detailed models I found, because all kinds of teams in a company can be remapped to Team Topologies’ four team types. In fact, remapping is the first recommended step for a company adopting this model to identify possible pain points in the current structure and make informed decisions for improvement.

In Team Topologies, the primary type of team is the Stream-aligned Team, which is aligned long-term to a particular business area of the company, whether it be a product, service, or any enduring part of the business. This is contrary to project teams that exist only as long as the project is ongoing and disappear upon its completion. Stream-aligned Teams are the most common team type and everything revolves around them: they follow a “You Built It, You Run It” approach, meaning they handle all aspects of their work without hand-offs to other teams.

The other three team types all contribute to the smooth functioning of the Stream-aligned Team.

• Enabling Teams reduce cognitive load and increase flow in Stream-aligned Teams by providing expert mentorship and helping them adopt new tools and technologies. They offer specialized knowledge and detect missing capabilities without owning any software components themselves.
• Complicated Subsystem Teams manage parts of the workflow that require specialized knowledge and expertise, often because they are too complex for Stream-aligned Teams to handle on their own.
• Platform Teams provide foundational services and tools, enabling the Stream-aligned Team to deliver work faster and more effectively without reinventing the wheel. They handle infrastructure configurations and automate trivial tasks, reducing complexity.

Platform Teams and Development Teams

Here comes the realization that it all sounded familiar: when discussing Internal Developer Platforms, we often end up talking about the Platform Team, which builds and evolves a platform to reduce developer cognitive load and enhance Developer Experience, and the Development Teams, which use the platform to carry out their tasks with ease, focusing solely on feature implementation and delivering the best possible value with speed, consistency, and quality.

The remapping here is straightforward: the Platform Team in IDPs corresponds to the Platform Team in Team Topologies, and the Development Teams are the Stream-aligned Teams.

When we talk about IDPs, the Platform Team is responsible for developing, maintaining, and evolving the Internal Developer Platform. Their goal is to provide a set of tools that Development Teams within the organization can use to work effectively. The Platform Team plays a key role in supporting efficient software development and deployment within an organization, providing a solid technological foundation to build upon.

The Development Teams, instead, are the ones that deliver features end-to-end, leveraging the functionality provided by the IDP to focus solely on implementation, while the platform handles tool and infrastructure configuration. This allows these teams to concentrate on delivering high-quality features quickly and consistently.

Different Needs Require Different Interaction Modes

As mentioned above, Team Topologies defines three main types of team interaction:

• Collaboration: Teams join forces for a period to achieve a specific outcome, such as handling a critical incident, or combining expertise to lay the foundations of a new complex project. Collaborative efforts are typically intense, bringing together diverse skills and perspectives to address complex challenges or explore new ideas and solutions. This is often temporary and focused on a particular goal, meaning it should end as soon as the goal is reached.
• X-as-a-Service: One team provides well-defined, standardized services to another team with a self-service approach. The consuming team is decoupled from the service-providing team, meaning they can work independently without waiting for support or resources. This interaction model supports ongoing, stable relationships where one team offers specific capabilities or resources that other teams can use to enhance their productivity and focus on their core tasks.
• Facilitating: One team helps another team improve in a certain area, such as adopting a new technology or overcoming specific challenges. This interaction is often temporary and highly focused on transferring knowledge, skills, and capabilities to the receiving team. This could be achieved via training, coaching, or hands-on assistance.

We can notice that the two latter team interactions aim for cognitive load reduction: most situations involving cooperation aim to reduce the (extraneous or intrinsic) load weighing on the Stream-aligned Teams’ shoulders. This is also one of the main goals of Internal Developer Platforms, which generally aim to hide complexity in order to improve DevX.

Another critical goal of IDPs is promoting self-service, mirroring a key principle of Team Topologies, which advocates for limited direct cooperation, favoring asynchronous and independent work.

So why is self-service so important? Well, from the Stream-aligned Team’s perspective, the ability to solve problems and access resources autonomously can lead to higher satisfaction and a better overall experience. For Platform Teams, on the other hand, it is crucial to adopt scalable interaction modes with Development Teams, to avoid getting submerged by service requests and the constant demand for hands-on support. Lastly, from the company management point of view, self-service reduces organizational costs and the need for extra resource allocation.

IDP Adoption Phase and How it Shapes Team Interactions

In the following paragraphs, we’ll try to put what we learned until now into practice, understanding how different interaction patterns can be leveraged for successful IDP adoption.

Adopting an Internal Developer Platform is not a one-time event but a progressive journey that profoundly influences how teams interact and collaborate. The success of the IDP is defined by how many teams adopt it, so the Platform Team has to make sure that Stream-aligned Teams can make the best use of the platform and understand the advantage of integrating it into their workflows.

Initial adoption stage

In the early stages of platform adoption, the Platform Team should focus mainly on getting Development Teams to integrate the platform into their daily work. The driver of the change is the Platform Team, but the actual owner of the impacted codebase is the Development Team.

Generally, Stream-aligned Teams already have their own workflows and are not motivated to change to adopt the platform’s capabilities. That’s because the required effort is likely high, and they won’t receive tangible benefits right away, so they’re induced to de-prioritize the migration to the platform over other more urgent activities.

In this phase, the Platform Team has to ensure that adoption is carried out effectively. Filing tickets to the Development Team is theoretically a scalable and manageable approach, but it might fail because the Development Team fails to prioritize the tasks or struggles to understand how to adopt the new platform.

That’s why, at this stage, close collaboration is often preferred: the Platform Team may often assume the facilitating role, helping Stream-aligned Teams understand how to use the new tools and services being introduced. This might include frequent direct support to ensure a smooth transition to the new platform, even temporarily embedding one or more members of the Platform Team into the Development Team to ease the transition.

This hands-on approach ensures that Development Teams can quickly overcome initial hurdles and start seeing the benefits of the platform.

Scaling Stage

As the IDP starts to stabilize and its adoption spreads across more teams, the Platform Team’s focus shifts towards enhancing its capabilities and accommodating a larger number of users. The difference with the previous stage is that interactions revolve around the Development Team’s needs: they have a goal to reach, and they are leveraging the platform’s features to do so, while in the first stage the driver of the change was the Platform Team.

With a more mature IDP, the interaction model often shifts towards the X-as-a-service approach. The Platform Team provides standardized services that Development Teams can consume independently. This reduces the need for constant direct interaction and allows Stream-aligned Teams to access the tools and infrastructure they need without delays.

While the primary interaction mode is self-service, there might still be a need for facilitation when new features or significant upgrades are introduced. The Platform Team may offer guidance and support to help Stream-aligned Teams make the most of new capabilities.

Platform evolution stage

In the final stage of IDP adoption, the platform is fully integrated into the organization’s workflow, and its use is ubiquitous.

The interaction modes are characterized by increased autonomy and occasional collaborative efforts for innovation: Stream-aligned Teams are highly autonomous, relying on the standardized services provided by the Platform Team (X-as-a-Service collaboration), which can still take on the facilitating role when needed.

Occasionally, the Development Teams might propose to integrate new features into the platform. This is the opposite of the first adoption stage because the Development Team drives the change, but the Platform Team owns the codebase. In this case, the Development Team can file tickets to the Platform Team or directly contribute to adding new features and improvements to the platform.

The bottom line

As we’ve learned, Team Topologies and Internal Developer Platforms both champion the principles of self-service and cognitive load reduction, guiding organizations toward more efficient and autonomous workflows.

Team Topologies can help in categorizing different team types and defining clear interaction modes, providing a structured approach to improve team dynamics and reduce unnecessary complexity.

Similarly, the adoption of an IDP promotes self-service by enabling Development Teams to access tools and resources independently, without constant hand-holding from the Platform Team. This independence is crucial for minimizing cognitive load, allowing teams to focus on delivering high-quality features swiftly and effectively.

Through the progressive stages of IDP adoption – from initial close collaboration to widespread autonomous use – the focus remains on empowering teams and simplifying their workflows.

By aligning the strategies of Team Topologies with the adoption of an IDP, organizations can create a synergistic environment where both frameworks reinforce each other’s goals. This alignment fosters a culture of efficiency, innovation, and continuous improvement, ultimately driving successful software development practices.