About Modifying Commands

In the wake of the current hype about infrastructure platforms, probably everyone has heard about the book Team Topologies.

I won’t retell it now, so if some terms or reasoning below turn out to be incomprehensible to you, I recommend reading it first, and then returning to my post.

Of all the topics covered in Team Topologies, the most obscure topic is the Enabling team, the “modifying” or “transforming” team. I will use the word Modifying Command because the same translation is used in Platen.

In the book itself, many general words are said about her, such as:

Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance

The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area

All this is good, but it does not give an understanding of how to build these teams, and what they will do. (The same can be said about the Team Topologies book itself in general – it is a great and wonderful visionary book, but it has very little practical use)

Let’s try to figure it out.

First, in this paradigm, the main task of the Modifying Team is to pull other teams to the next level of development in some area.
Secondly, and this follows from the first one, it is to form the development paths of other teams.

I see a big problem here in how to fit these tasks into the organization itself, because, depending on the implementation, this very Modifying Team may turn out to be not what was conceived in Team Topologies, but, for example, fire extinguishers, or mom’s snot wipers.

To deal with this problem, let’s try to consider the development path of a certain product team, when it moves from one set of Alpha competencies and delivered practices, to some wider or deeper set of Beta practices, and further to an even more pumped version of Charlie.

Here the team can move to the next level both by itself and with the help of the Modifying Team.

Who cares, but it most of all reminds me of the path of an artifact along the CI / CD pipeline.

Accordingly, it is possible to present the way the Modifying Teams interact with the Thread-Oriented Teams not in the form of some indistinct spots, as they say in the book, but in the form of a very specific scheme that can be discussed.

And most importantly, it already looks like the scheme of any organization, i.e. on the process of converting certain objects that come to it at the input into certain outputs.

In this case, “untrained” commands are received at the input, and “trained” commands are received at the output.

In fact, we got a scheme very similar to the one of the Platform, only the product teams themselves move along the pipeline, not the features. And this pipeline is not technical, but organizational.

If you look at the matter in this way, the questions that we ask will no longer be abstract questions like “what should we do with all this at all”, but more specific and understandable, the answers to which can be turned into a set of very specific decisions and steps:

What will be the development path of the teams? Why exactly like this?
Will it be the same for all teams, or will it be different? Why?
What intermediate states will it consist of?
Do you need a separate command to move to the next stage, or will a video on the wiki and an example of a template for a new practice (something like “Thin Enabling Platform”) be enough?
Do teams have to go through all these states, or can they go through them selectively?
Will there be only one development path for each team, or will there be several parallel paths in different competencies (for example, development paths in devops, in testing, in agile processes)?
What will change for the team as they move down this path?
Why would teams go down this path at all?
Who and how will move them along this path?

Will this vision leave a role for the Modifying Team itself, or will this team turn into several smaller teams? It seems to me that this is not so important if the goals that the organization sets for itself are fulfilled.

What do you think?