Dynamics between Team Topologies and Wardley Maps

by

The representation of a Wardley Map or a Diagram with a team topology is a static representation, but the key aspect are the dynamic aspects that happen around that snapshot.

Let’s start with a map about a platform ecosystem

This map represents a platform ecosystem where the clients (anchor marked with a compass) access to configure, deploy and work with solutions, and the builder of the place tries to build, nurture and evolve the ecosystem to enable its own survance.

Some basis about the map:

  • The client is a company that offers its own services to its end users through the platform.
  • These services are run at process levels by employees of the company: Business Process Owners (BPOs), technical people (developers, product managers…).
  • The ecosystem is heavily attended by Business Process Owners that work with the documents and process being managed in the applications (solutions). Their are high level specialists in their industry.
  • The ecosystem enable your own solutions or third party solutions that are consumed from a marketplace.
  • The security levels at ecosystem perspective have different layers where each client has its own private space.
  • The platform has a set of teams building applications, automation to reduce the maintenance activities and data services to enable the data flows and software flow to go from development to production.
  • Customer feedback is gathered in different way. Certain feedback is turned into features or changes, others are turned into innovation projects.
  • There are components related to practices and knowledge. All of them are combined in the map to reflect the importance of them in the well functioning of the ecosystem. Industry knowledge is specially important to have and keep teams up to date to it is relevant, so why not to have in the map?
  • Several components have been marked as pipelines to show that granularity and reflect the fact that, for instance in the case of applications, you can have some of them in their genesis or other that are products.

Determination of team types

In a big context like this, the representation of the teams have been done at the main perspective, which is right and wrong. It’s right because it represents the prevalent types, but is wrong because some of the teams (for instance solution builders) are very different and they are not always stream aligned teams.

In fact depending on the stage of a customer (new client, existing customer or legacy client) the type of teams are different.

Where are the dynamics then?

The dynamics at this level are mainly in the types of communications the different teams have. They are not static, they evolve and you could even track how the dependencies between teams evolve.

Let’s start with the predominant communication types

This is the representation of the predominant types of communications, but they are the ones for what the client is stable and have been more than 2 years working in the ecosystem.

After 2 years, the client is expected to have:

  • Several solutions in production,
  • An experience BPOs team running the business.
  • A stable developers team.

This is in some way the target scenario you look for when you start engaging a client.

The communication types are different for these clients is in the first 2 years (transition and transformation).

Note that:

  • There are more collaboration and facilitation.
  • Some dependencies have 2 types of communications. This is done to highlight the importance of collaboration and also respect some basis (in terms of X-as-a-Service).
  • Here it is not represented, but you have to consider that in this stage the number of innovation projects are very low or directly zero. And the communication between the client developers team and the ecosystem team is very heavy.
  • Many of these dependencies have on the backstage several training programs that enable the people to have the minimum knowledge required. This is in fact another map just about knowledge.

I have isolated the Team Topologies components, it’s confusing if you do not stop more than 5 seconds on the diagram, but once you compare in detail you can see the differences.

The stabilized phase is not a static phase, the business use to suffer transformations and external changes that provoke the need of adapting at least the communication types.

Takeaways

As program manager, to have clear the business perspective of the activities being handled is essential.

This not only mean that the work has to be done, but has to be communicated and reported (2 completely different things my friend). Keep high level stakeholders with a clear view about where are the bottlenecks and how we are working to reduce them is essential in my day to day.

As usual, any constructive feedback is welcome.

Leave a Comment