Interim Platform Team

The messy middle of supporting external and internal customers.

https://github.com/aleixmorgadas/awesome-engineering-strategy

I recall a situation where a team behaved as a Stream Aligned Team and Platform Team Grouping, supporting external and internal customers and handling the situation with a manageable cognitive load, at least for some time.

I want to share a common situation that multiple organization faces—the messy middle between end desirable states.

The context

We were working on a B2B2C product, with multiple teams and business units involved. I remember that we had to collaborate with teams outside our business unit, and it caused a lot of interesting dynamics that I aim to explain in this post.

Let’s define the product as:

Our product help organizations be more competitive by offering them benefits for their employees, making their organizations more attractive to talent than their competition.

Model

Team structure

In the beginning, we had two different teams, each owning a user persona and, therefore, a user experience split by platform.

• B2B Team owned the employer user persona, a web portal user experience.

• B2C Team owned the employee user persona, a mobile user experience.

Architecture

The architecture reflected the team structure, we could see how Conway’s law impacted the design of our systems.

When we have teams with their own OKRs and incentives, we tend to make architectures that help us to maximize autonomy in our local context.

And as you guessed, there was a lot of duplication and misconceptions between those “Product API” services that implemented the bounded context partially.

DDDing the context

We have a shared bounded context between two teams, with their own priorities and incentives.

Flow of change

We identified that we have two stream-aligned teams owning their own user journeys end to end. It seemed a great team organizational structure at first, but using the interaction modes from Team Topologies we could see that something was off.

The product needed a forever ongoing collaboration between both teams. Any learning or product improvement made by one team created the need for the other team to catch up.

And what if we add another product…?

Moreover, when we started adding a second product to offer to companies, which caused the B2B team to grow to support:

• Continue the development of employer user needs such as employee management.

• Continue improving product #1 for the employer user persona.

• Start implementing product #2 for the employer user persona.

The B2B team had a forever-increasing cognitive load and became the bottleneck to shipping products.

Redesigning for Fast Flow of Change

Even though there weren’t handoffs between teams, they required an ongoing collaboration without an ending date. That’s why it’s important to not only visualize your flow of change using Team Topologies’ fundamental team types but also add the team interaction modes to identify any smell that prevents a fast flow of change.

Capability gaps

We are looking for teams to own products end to end, which means supporting both user personas, the employer, and the employee.

In order to do that, we needed to train the team on web application development in React. That’s why we created a short-lived enabling team to fill the cross-functional team capability gap on React before we can propose the team own the whole product experience.

Architecting the domain for Fast Flow

Interim Platform Team

If we offload the pressure for the rebranded B2B team as Web Portal Team, by removing the responsibility to deliver the web user experience of different products and we focus them on two things:

• Employee management. (External-faced user)

• Offer a great experience for teams to deploy and integrate their micro-frontends into the web portal. (Internal-faced user)

We can achieve:

• Stream-Aligned Teams delivering product experience end-to-end, for mobile and web applications.

• Adding a new product and a team will be faster as they won’t depend on the Web Portal Team to deliver their part.

• By adding new products, the web portal platform will help make the process more straightforward and reduce costs in the long term.

• Proof the value of a Platform as a Service approach to leadership to gain support before we need to scale the solution when more internal teams are consuming the platform.

The messy middle

A stream-aligned team that starts providing some sort of platform, might get stuck in the middle of the transition if that team doesn’t get the proper leadership support to become a Platform Team.

Sometimes, we get stuck in that middle situation, and, being honest, is it bad?

When should you start a Platform Team?

A stream-aligned team supporting external and internal customers isn’t ideal but isn’t terrible in certain situations.

A stream-aligned team supporting one internal team is doable, and two as well. Fifteen internal teams? Hard to make a good job here.

I have been exposed to this situation several times when growing teams in early-stage startups to Series A and B. You have some team members that know a little about Infrastructure, CI/CD, they create that initial platform for other teams to consume.

It might start as a small wiki page with some IaC templates, and, when the organization starts growing, they will be the ones starting the first Platform Team.

Our situation was a fractal, it repeated at a Tribe level. We had a platform grouping at an organizational level. We repeated the same patterns at the tribe level with four teams involved.

Our situation was that we didn’t have yet enough internal clients to start an official platform team for this area of the business. Yet, being intentional helps to be ready by when the teams’ cognitive load reaches a certain threshold to start the official platform grouping already puts the evolution of the organization for success.

The team gains experience at a smaller scale about what it means to support internal clients and, as an organization, you already know who are the people that would continue supporting the best external clients and who will move into the platform. Reducing the overall risk of starting a platform team.

Keep measuring cognitive load

There is a nice spot in between supporting one team and supporting ten. As an organization, we might not have enough resources to start a dedicated platform team, that’s why Interim Platform Teams are present in our industry, we just might not recognize them as such.

The critical aspect of Interim Platforms Teams is to measure their cognitive load before it reaches an unmanageable state what would:

• Burnout people, not only the Interim Platform Team, stream-aligned teams that consume that platform as well.

• Prevent fast flow of change due to providing a bad experience to the platform consumers.

Summary

• Use team interactions to detect teams’ dynamics that prevent fast flow.

• Before we start a dedicated platform team grouping, we might have already a stream-aligned team acting as an interim platform team.

• People gain experience on how a platform looks like before aiming to commit full-time. Helping gain trust with your organization’s leadership.

• Measure teams’ cognitive load to prove that the interim platform team helps stream-aligned teams to ship value faster and reduce their cognitive load.

  • And be sure you are measuring the interim platform team cognitive load as well to sense when is the right time to start a fully dedicated platform team.

Meme for you