I first read Team Topologies in 2021 (a present from one of the best managers I ever had). But it had been on my wishlist for a little while, ever since I did a talk with Matthew Skelton at Agile Yorkshire. Our talks complemented each other very nicely that evening, but I discovered that the work that Matthew and his co-author Manuel Pais had done went way beyond my ideas, creating what promised to be a comprehensive set of patterns for how to organise software teams.

And yet at the time, interested in Conway’s Law and how to consciously architect people systems to drive the architectures which organisations need, I’d been developing a similar but different model – mine more specific, and based on an architecture layering model – TT more generalised, and topological. I was interested to understand how these two models related to each other, so I wrote to Matthew and we discussed it via a Google Doc. I’ve transcribed it here, with his comments inline. You’ll see that I’d made some unconscious assumptions which Matthew was quick to spot.

I hope you find it an interesting discussion!

---

Hey Matthew,

I hope you’re well! Sorry it’s taken me a while to get round to writing this.

Matthew says…

It’s great set of questions, Andy – thank you!

Would you be happy to turn this into a public Q&A article or something?

I definitely would. I think lots of these things would be interesting for other people

So first up – congratulations again on an amazing piece of work. Team Topologies is clearly the culmination of a monumental effort, and thought, and experience – and the amount of praise I hear for it regularly is testament to that! I thoroughly enjoyed reading it.

For some years I’ve been thinking about this stuff, and so when your book came along (and of course I watched your talk when we presented together that time) I was really interested to see how it aligned with the thinking I’d been doing. And the answer is that it absolutely does – but there was something I’d been mulling on for some time which I’d hoped to see a solution to, but I didn’t. At least I don’t think I did!

So I’ll be really interested in your thoughts on it, and see if you can help.

For many organisations, websites and apps are the primary channel for interacting with customers, and often these are seen as differentiating products which benefit from having in-house software engineering teams working on them and owning them.

There has also, for some orgs, been an appreciation that having those teams operate autonomously and independently means a faster rate of innovation (reducing contention and cost of coherence as per the Universal Scalability Law).

This means carving things up into “vertical teams” who own their own stacks.

So far so good.

But we have to draw a line somewhere. How deep can your vertical slices go?

Autonomy and independence must have a limit somewhere.

Matthew says…

The limit is determined by team cognitive load and speed of flow.

Yes I agree. Among other things?

For one thing, you can’t allow teams to be completely independent because you would end up with spiralling costs.

Just for the purposes of this, I’ll give two concrete examples. Let’s assume we’re talking about an ecommerce company:

1. If the company ingests data from third parties for the purposes of product pricing, then you only want to pay for that once. You don’t want dozens of teams each paying for their own connections just to ingest the same data.

Matthew says…

Maybe. But the company may find it better to pay for separate subscriptions rather than build and maintain a unified internal view of that data. There is no automatic “a single source is best” approach.

I definitely agree. I made that assumption for the purposes of the discussion – but yes, in reality we should never make that assumption. It’s a trade off.

2. You don’t want every team to build their own authentication systems for customer auth and service-to-service auth. Those things require specialist knowledge, and they’re expensive to engineer – you only want to incur that cost once.

Matthew says…

Again, this is an assumption that does not necessarily hold. Typically, yes – you’d want a very small number of auth systems, but the driver to reduce duplication should be team cognitive load, not de-duplication for its own sake.

Yeah, again I agree. Other reasons for de-duplication might be to reduce operational overhead across the board. Or to make it easier to move people between teams. Or just to reduce costs.

And of course, it’s not just about cost.

In the first example, you also care about consistency. You don’t want differences in the data ingestion and processing to result in customers seeing different prices for the same thing as they go through basket/checkout say.

Matthew says…

Now this is an important driver, and this is where you could get a Platform team to offer something compelling that individual Stream-aligned teams are unlikely to be able to build.

For the second example, something like auth will be a focal point for various audits (PCI, GDPR, SOX, ISO27001 etc.) so it’s beneficial to have a single standardised approach at least.

Matthew says…

Again, the benefit is not in a single approach. The benefit is in being able to audit the approaches and have confidence that they are compliant.

The singleton is a shortcut but an often painful one.

Yes. Again, there are trade offs.

And then of course, there’s cognitive load. You want your teams to focus on solving differentiating problems – innovating on things which make the company competitive – not all building and maintaining their own auth solutions.

(I’m going to assume for the purposes of this that there’s a good reason why the company doesn’t want to just buy such an auth solution off the shelf).

Matthew says…

A separate auth solution might be the thing that one product needs to be competitive. 🙂

Yes I suppose it might be 😀

How do we solve these problems? It feels like there’s an obvious solution for each example:

1. We get a single team to ingest the data from the third party, and then make it available for other teams to consume. (Maybe the team would do some simple processing on the data if everyone would need to do that same processing).
2. We get a team to build and own a single auth system, and make it available to other teams to use.

What I’m wondering is whether there’s something else to consider. So let me talk you through it.

I’d propose that it’s helpful to identify two sets of domains:

• Experience Domains, which depend on:
• Business Domains

Now they might not be the best names (naming stuff is hard!) but I would define these as:

Experience Domains

Comprised of teams which primarily provide products to the end customer – i.e. the website(s) and app(s). Let’s call them Experience Teams.

They aggregate and compose data and functionality provided by the Business Domains to create rich and compelling experiences for customers.

The stacks that these teams build are entirely use-case-specific, and entirely independent – no other teams should depend on them.

In these domains we optimise for rapid innovation.

Business Domains

This is where the two teams I described in my examples would sit. Business Domains are comprised of teams which provide commonly useful, self-serve, data and functionality to other teams (internal customers). For our ecommerce company we can imagine Business Domains like “Product”, “Customer”, “Promos”, “Marketing Content”, and so on.

They might take the form of RESTful services, or Kafka topics, or web sockets, or some other interface – but they’re fully productised with proper documentation, versioning strategy, feature requests, backlog/roadmap planning, published schema and so on.

The data and functionality they provide should be canonical, and generally useful (not use-case-specific). The whole design and purpose of these domains and systems is that other teams can and should consume from them and depend on them – solving the problems of duplicated cost, consistency (and also sometimes cognitive load). They’re where most Experience Teams’ vertical stacks bottom out.

In these Business Domains we optimise for re-use and stability.

Matthew says…

In TT Platforms, we optimize for flow within the Platform and optimize for Developer Experience outside the product.

It’s the same patterns at different zoom levels – fractal.

Optimising for flow within and devex without. That’s an interesting insight – I like it.

However, don’t we want to optimise for flow everywhere?

I think that re-use isn’t what I mean here, on reflection. I think what I was trying to get at was “avoiding duplication”.

For example: In the Experience Domains we might store the same pricing data many times (in a view-store approach, where each team has its own copy of the data it needs, in a format which suits their use case). And we’re happy to do that so that those teams can go fast, operating independently.
But in the Business Domains, we want a single source of truth to be made available – e.g. there’s one definitive place to go to get pricing data.

The reason for talking about stability here was to call out the fact that these Business Domain teams have multiple consumers. They’re a platform.
For example, if our pricing service breaks, then that could potentially affect most of the website.
So we want to optimise for stability.

By contrast, up in the Experience Domains where we see the highest rate of change (new features pushed out all the time to try and boost sales) we can afford to experiment more, and move faster, because these teams are independent and therefore a failure has a limited blast radius.
So in the Experience Domains we optimise for rate of change (or, as I phrased it in this doc, rapid innovation).

So what I’m saying is that within a platform, I believe that we should call out optimising for stability. Not just flow (which I think we want to optimise for everywhere).

I’m very happy for you to correct me on that last point! Maybe flow is part of a trade-off? I can’t think what trade-off though. Is there a situation where we would accept poor flow in order to achieve a more important benefit? I’m willing to believe there is but I can’t think what it would be.

Are these concepts orthogonal to your Team Topologies models? Or is there room for this within them?

Experience Teams sound like Stream Aligned Teams from your book.

But what about the teams in the Business Domains? Are they just Platform Teams? Or are they just another kind of Stream Aligned Team? Or some hybrid?

Or something else entirely?

Matthew says…

Most teams inside a TT Platform will be Stream-aligned – they are aligned to value streams inside the Platform product.

But from the description here, most Business Domains will be best served by adopting a Platform as a Product approach.

This makes sense, thank you

Cheers,

Andy

---

So there you have it. As ever, Matthew sees to the heart of the matter! My learnings from our chat are:

1. There are no fixed rules on where you choose to make teams independent and therefore allow duplication – the verticals can be as deep as you like. It always depends on organisational context.

2. It isn’t a given that having a singleton system, or approach, is the right thing. I think that enterprise architects often jump straight to this assumption because it appears to be simplifying the organisation, and offering economies of scale. But doing this has side effects you might not want in some areas of your organisation, such as introducing contention. In the model I presented here, the places you want that standardisation are in Business Domains, and the places you don’t are the Experience Domains – but as Matthew explains, even this isn’t always the case. Again, it always depends on organisational context.

3. The Platform teams in Team Topologies aren’t necessarily building technical platforms. These could be business platforms offered as a product to Stream Aligned teams. For example: A service offering authoritative APIs or streams of data or business events, or services to carry out operations which a stream aligned team isn’t best placed to do itself – as in the data feed and auth examples Matthew and I discussed.

I hope you found this interesting and useful. Please let me know your thoughts below!

---

Further conversations with Matthew…

After I posted the initial version of the above, Matthew and I continued to chat… In the spirit of sharing, (and this new format which Matthew has dubbed “blogcast” 😁), here’s what we discussed. It turns out that a) I have more learning to do on TT, and b) our models do in fact align perfectly as regards avoiding dependants if you want to move fast! 🏃‍♀️

---

Andy Butcher 5:07 PM
I realised that there’s another learning I took from our discussion, which I’ve just appended to the post.
I wasn’t clear when I first read TT that Platform Teams could be building what you might call “business platforms” rather than just “technical platforms”. So in other words, if a company requires an authoritative service for performing pricing calculations to be made available to its Stream Aligned Teams, that would be provided by a Platform Team in the TT model.
Being a techie, the word Platform always makes me think about technical platforms first and foremost

Matthew Skelton (He/Him) 5:09 PM
Yeah, in retrospect, “Platform” was a bad word but we couldn’t think of anything better.

These days I say “flow platform” or (better) “Innovation Accelerator”

Andy Butcher 5:11 PM
Yeah I like that. Basically anything which allows the Stream Aligned teams to focus exclusively on their value stream, rather than trying to do heavy lifting which someone else could specialise in.

Matthew Skelton (He/Him) 5:17 PM
Slight nuance: a Stream-aligned team might choose to take on some non-domain activity in order to remain decoupled and independent.

Andy Butcher 5:19 PM
Yeah – they’d have to make a decision on the trade-off between independence versus reducing cognitive load

Andy Butcher 5:30 PM
I’m still mulling on the naming. Platform: Suggests a single thing which you must build on, and has tech connotations. Foundational Team: not much better but it’s not tech at least. Innovation Accelerator: I like it, but it’s not obvious what it means in practical terms.
I’m trying to think of a name which conveys the idea of something Stream Aligned teams could use if they want to, which would take away cognitive load or effort, and which are designed to be shared (i.e. designed for multiple teams to depend on).

Andy Butcher 5:34 PM
It’s a purely academic exercise because of course the term Platform Teams is what you went for and I’m not trying to rewrite TT 😂
But I wonder whether “Self Serve Teams” conveys the right sort of idea? It implies something you can consume if you want to, not necessarily a tech resource.
Or just “Service Teams” – although of course the word service is very overloaded. But still – it conveys the right sort of idea.

Andy Butcher 5:40 PM
One of the things I was trying to achieve with my Experience Domains and Business Domains, was to clearly state which areas of your architecture you can consume from or depend on, and which are NOT designed to be consumed from. Your Stream Aligned teams, for example, would be massively slowed down if another team started depending on one of their APIs.
I can think of one very well known company which has a horrifically tangled web of dependencies in some places, making changing anything unbelievably complex and risky.
So for me, one of the defining features of a Platform Team in TT is that it’s designed to be shared (i.e. have multiple dependants/consumers), whereas Stream Aligned Teams are definitely not. Would you agree?

Matthew Skelton (He/Him) 5:45 PM
Hmm, I would not say that a TT platform is designed to be shared. The sharing is more a nice side-effect of good design 🙂

But your points about “things that are good so consume internally” versus “things that should be consumed externally” feels right. It’s about having a single customer focus.

In my work from now on I will likely use the term “innovation accelerator” rather than “platform”.

Andy Butcher 5:49 PM
Perhaps the word “shared” is misleading. A TT platform is designed to be used or consumed by multiple internal teams?

Matthew Skelton (He/Him) 5:53 PM

Nope: a TT platform is designed to improve flow and reduce cognitive load in at least one (but possibly ONLY one) Stream-aligned team.

This gets away from the re-use fallacy.

🤓

Andy Butcher 6:33 PM
But if it’s designed to do that for “at least one” SAT, then by definition it’s designed to be used by multiple SATs?
What am I missing?
The “re-use” fallacy. Yeah absolutely with you on that. It absolutely is a fallacy!
I’m going to stop using that term

Matthew Skelton (He/Him) 10:21 PM
There can be value in a TT platform even if just one team uses it. So there is no need for a platform to serve multiple teams.

In practice, however, if a platform is providing useful services, we’d typically expect it to have multiple customers. But it’s not essential nor is it the driver or raison d’etre of the platform.

In my view.

Andy Butcher 8:06 AM
Interesting! So should Platforms be designed such that they can be consumed by multiple consumers?

Matthew Skelton (He/Him) 11:30 AM

That’s like saying “Should products and services be designed so they can be consumed by multiple customers?” – mostly, yes, but if if’s a pilot customer or a special case, then we don’t want to force multiple customers too soon.

Andy Butcher 11:59 AM
That makes sense 👍

As a SAT, if I think “we could really do with X to reduce our cognitive load” and a Platform product exists for X, but hasn’t yet been designed for multiple consumers, it would be a valid approach to discuss consuming from that team? (The Platform Team in question would have to do some work to get their Platform product ready for multiple consumers)

Sorry for the noddy questions – just trying to make sure I get it

Matthew Skelton (He/Him) 1:02 PM
100% this yes!

Are you going to add these extra questions and answers to the blog post? 😁

Andy Butcher 2:35 PM
Yes I think I will!

I’ve got another question though 😁
What if the SAT I mentioned above realises that a different SAT has an API (for example) which gives them what they need and helps reduce their cognitive load. Would it be a valid approach for them to start consuming from there?

My immediate thought on that is that the answer should be “no” because as soon as someone depends on you, your flow and independence are impeded.

Matthew Skelton (He/Him) 2:44 PM

Well, it’s a signal that there is some value to be consumed. If the SAT is happy to do it – and it’s only one other team – it might be fine for a while. But as soon as you get like 3 or 4 teams consuming, it will become a drag on flow, so it implies the need to abstract the API via a platform (or start to treat the SAT as being inside a platform grouping).

Andy Butcher 2:56 PM
Okay cool – that definitely aligns with my thinking 👍