Show Notes
Let’s put Team Topologies to use. What can it tell us about why some team structures work out, why some struggle, and when we should switch our organisations to be more effective?
Mon-Chaio and Andy scrutinise a software project through the lens of the interaction modes, sensing, and triggers for change that the book introduces. They find that it provides a rich vocabulary to talk about the ills and strengths of your tech organisation.
References
- Team Topologies: https://teamtopologies.com/book
- TTL Podcast BART episode: https://spotifyanchor-web.app.link/e/MY0ihq1VlGb
Transcript
Andrew Parker: Welcome to another episode of the TTL podcast. In this episode, Mon Chaio and I are going to be talking about Team Topologies. Now, Team Topologies is a book by Matthew Skelton and Manuel Pais. And we’re not going to go into the topologies themselves. I feel like that’s been done all over the place. What we’re more interested in is the interactions and more how the team structures, how the topologies change over time. If anyone’s not read the book yet, I would suggest you read the book. I think that for many advanced practitioners there’s nothing groundbreaking in it. Now, this isn’t a slight at the book. I actually think that the book is incredibly useful almost because of that, because what it’s done overall is it has taken Common things that a lot of us in this profession have noticed for a long time and given them names.
And names are really useful because now we can talk about them. Until we have those common names, we don’t know that we’re all talking about the same thing. So I think the book is really useful from that perspective. It gives us that common language, that common way of thinking about it. Now, they do have, the authors do have great insights into how those different concepts play together.
And I think that’s why we’re focusing in on this particular aspect of it. The communication patterns and the changes, the way that boundaries change and what forms those boundaries is what we’re going to try to focus on a bit this time. We’re going to try to keep this as much as we can focused on the actual scenario that we’re talking about. Alright, Mon Chaio?
Mon-Chaio: yeah, and do let us know if we do a good job here. I think we will probably try to do at least a few more books in this season. So, Your feedback about how we do and what we can do to improve that will help us greatly. getting into this episode. Team topologies. team interactions. That’s pretty far into the book, Andy. It’s chapter seven, I believe,
Andrew Parker: It is Chapter 7, and looking at my copy of the book, I’m about, I would say about two thirds of the way through the book.
Mon-Chaio: So, Andy, why don’t you give us a short sort of summary around what are we talking about when we’re talking about team interactions, and what does Team Topologies, the book, say about team interactions?
Andrew Parker: Right, so team interactions are from this idea that you’ve got a group of people who are focusing on something. They work within a boundary. I’m, I’m very much kind of hearkening back to the, to the language that we used from the Bart episode. But I find that language very useful to talk about this. So they have boundaries, and at some points, they’re going to be reaching out past those boundaries , to reach inside the boundary of another team in some way.
And the team topology’s interaction modes, you could say, are, what are the recommended ways that they might reach across those boundaries? These give us kind of constraints as to what those modes might look like. And they, they gave us three different modes of team interaction. One is collaboration. I would describe that as the boundaries between the teams are blurring a bit. They describe it as working closely together with another team. The next interaction is X as a service. And that one, in the software world, gives us actually quite a strong metaphor to work with. We know Software as a Service, we know Platform as a Service, we know Taxis as a Service, Uber we know all these other things as a Service.
And, in the Team Interaction Modes, it’s, they’re consuming or providing something with minimal collaboration. So that’s where you can just say, hey, this is what we do. You conform to that interface and we’ll provide it. So it may be that they’re prov that one team is providing a billing API that other teams consume.
And that’s their interaction is through that API. I can imagine you could say that there’s another way of doing it where the the X as a service is done through JIRA tickets. You produce JIRA tickets and another team ticks takes those on and maybe they’re doing data quality. Assessments. So, you produce a thing saying if you, if you file a ticket in this fashion we will look into it and we will produce back a result in this structure.
That is X as a service. You have a very clear interaction, a very clear method that you’re gonna, gonna work together. And the last one is facilitating. And they describe that as helping or being helped by another team to clear impediments. Now, facilitating and collaboration kind of start seeming very similar, but I think it’s about what the goals are.
What are the aims that these groups have? In a collaboration interaction, the two teams are sharing a goal. In the facilitating interaction, the one team has a goal, and the other team has, like, a subordinate goal. Which is maybe to train them up on how to do that, or to help them get to that point.
But not necessarily that goal themselves. Do you have any thoughts on that, Mon Chaio?
Mon-Chaio: On the surface, Andy, I think those interactions make a lot of sense. I don’t think anybody could look at them and say that they’re unreasonable or that they haven’t seen one of those three interactions in the past in the way that they’ve worked. When you talk about collaboration, for example, I do think even the book mentions that it’s a blurring of boundaries.
They say that I believe there’s a section in the book that says how do, how do they put it? If the goals for one team are only able to be achieved by the work of another team, that’s a great sign that they’re in collaboration mode, for example. The other thing around X is a service.
They talk about the team that’s providing the service, having to do a bunch of work in the. Customer service model, right? In making sure that the consumption of the service is easy to consume. That there’s an easy way to file things like tickets which obviously is less important in the, than is less important in the collaboration model.
When you just turn to the person beside you and say, Hey, I found an issue.
And similarly in the facilitating model.
I thought that We could take an example from my experience in the past, working at a pretty large tech company. Note to listeners, we What do they call it in those crime shows? The identities and details of the incidents have been altered to
Andrew Parker: to protect,
the innocent? Mm
Mon-Chaio: innocent, or in some cases the guilty.
we Don’t judge who’s innocent or guilty here but some of the details aren’t going to be exactly how they happened and we’re not, I’m not going to re, I’m not going to reveal the name of the company or the name of the teams or anything like that, but the scenario is going to be as accurate as I can portray within those boundaries.
So that we can have, again, a discussion, not on a contrived scenario, but on something that actually happened. Or, at least, that’s the, that’s the intent. All right, so getting into it. As I mentioned, this is a fairly large company, so don’t think about a startup.
Think about a company that’s thousands plus multiple divisions. this company has, for a while, Had a mobile application to do video editing. Think about short form video editing, like Tik Tok, or I don’t remember Vine or whatever that was in 2012. Right? do you remember that short lived short form video?
And so they’ve had a short form video editing product on their mobile side for a while with a very, very strong brand and large sets of user cases and a lot of market penetration at one point. This company decided that it was important for them to then create an internal product to edit video for their promote, for their product promotion perspectives.
So think about selling a water bottle or selling, actually strike that, water bottles are not it. Think about selling like a complicated technical product like, I don’t know, a a piano for example, an electronic piano. You might want to have a video that demonstrates the capabilities of it, how it can export music to specific programs the way that it can integrate with soundboards and other instruments, right?
So you shoot these longer form videos, generally higher quality, not in the 15 or 32nd ilk. The company thought, well, we want an internal product to be able to do this because we don’t want to pay these licensing fees for all these other products. And we already have video editing technology on the mobile side.
Why don’t we look into whether we can use some of that technology and just create a team to create this desktop product that can edit video.
Andrew Parker: Mm hmm.
Mon-Chaio: So I think that’s the first stage. Now, I think, is that enough information for us to start to think about team interactions, team topologies, or do we need a little bit more?
Andrew Parker: Well, no, I think that is a good starting point because we can think about, we’ve got one team, it’s well established, it’s got a certain set of technology, and there’s the desire to start up Without even talking about teams yet, there’s the desire to start up this work to produce a new capability within, for the organization, which is longer form, probably similar but different sets of video editing capabilities on much larger files that are going to be geared towards a different audience, more professional video editors than it is going to be geared towards consumer. People just on the street taking a short video and then posting it up onto the internet. So, uh, yeah. I guess the very first question is, in terms of we were talking about interactions, your probably natural thing is, okay, well let’s just get a group of people working on this. Let’s create that team, let’s create that boundary. Now how do they interact with that existing group?
Mon-Chaio: Well, actually, I think the question is even more basic than that. I think the question starts off with You’re right on the base question of we need to create that of people,
Andrew Parker: Mm hmm.
Mon-Chaio: I think the first question to ask is, does that group of people even need to have a boundary?
Andrew Parker: Oh, interesting. Say more.
Mon-Chaio: Perhaps we take four or five people from the mobile side of things who have done it. And we say, look, this is just another feature.
Or another mini product off of your group,
Andrew Parker: it’s a, it’s a project within your group and yeah, staff it up how you see fit, but they’re all part of that group. You’re, you’re just on that.
Mon-Chaio: Right. IF we think about team topologies and team interactions, does that give us a model for how we decide whether we do. That, namely, pulling people out and se Not pulling people out, making it a project in an existing group, versus spinning up a new group.
Andrew Parker: I’m going to say, I think it does.
I think otherwise we wouldn’t be talking
about this.
Mon-Chaio: hmm.
Andrew Parker: We’d be like, well, why are we talking about team topologies then? No, I think it does. And the reason is, so I’m looking at my book. I’m at chapter seven, page 135, and there’s a section here headed collaboration, driver of innovation and rapid discovery, but boundary blurring.
I think what you’re looking for is a very high interaction setup in the beginning.
And this gets to the evolution. In the beginning, you’re creating, you’re creating this new bit of software. This new capability. And, I’m gonna, I’m going to assume that it’s not completely clear that it should be separate,
or that it should be the same.
Because if it’s completely clear up front that it should be separate, then you wouldn’t do this. But if it’s completely clear that it’s actually just two or three features added on to the existing mobile thing. It’s also, like, not that interesting. It’s that uncertainty where you’re going to want to set up a group that is in a high collaboration scenario so that they can work out what are the crystal clear boundaries while they’re blurry.
Mon-Chaio: That makes sense to me. I think collaboration is absolutely the right model that we’re looking at here. I think everyone could look at the three team interaction models and say, this is not the right time to do X as a service,
Andrew Parker: Well, let’s talk about X as a service. Let’s talk about what, what, this is going to now be a hypothetical kind of thinking through it. And I like doing this when I’m thinking about, like, okay, what’s the thing that we, I want to strive for here? I’ll go and talk to people and get their opinions. But I also kind of, I would say, war game it or, or play it out in my head.
So what if it was X as a service? Let’s say we set it up that way. What would, what would happen? What is the service and what is X and who are the teams
Mon-Chaio: the funny thing is I think a lot of companies, especially larger companies, perhaps would default toward this. I find many larger companies love to create teams.
Andrew Parker: Mm hmm.
Mon-Chaio: And part of that stems from this concept of not acknowledging or truly understanding the tax that a team brings. Every time you create a team, there’s actually a tax.
And maintaining of a team has a tax. So that’s another topic for a different podcast.
Andrew Parker: I think part of that tax is an architectural tax. One of the foundational parts of Team Topologies as a book and a concept is this whole idea of Conway’s Law. And to me, the X as a service interaction. It starts to make, it starts to ossify, it’s kind of a loaded word but I’m going to use it for a little while.
It starts to ossify that architecture because you’ve decided that That architectural component, that whatever it is as a service, is so stable and so well known that now the interaction with it is just in this, in this manner. You, you, you kind of stop questioning that boundary. And I think it, it creates that very quick, easy sense of security and that you know what’s going on. Whereas the collaboration will not create that sense of, we know exactly what’s going on. In fact, collaboration uncovers more and more how much you don’t know about what’s going on.
Mon-Chaio: Exactly. And as the authors of Team Topology would say, that is when collaboration is used. When you use collaboration, you must expect that you are going to learn new things. In fact, you’re kind of going to slow down in that way from the things that you, from working on the things that you do know because you’re going to find out a bunch of things that you don’t.
And so getting back to the question of what if we started with X as a service? Think about what the authors of this book talk about with X as a service. Set up clear customer service boundaries, dev experience boundaries. So this group would then say, Oh, well now I have to set up a dev experience boundary or dev experience for you to consume my service.
From the mobile side perhaps, right? So now I have to have clear dashboards around how your builds are doing on my build system. Perhaps I have a cloud API for video rendering, and now, you know, when it’s within my group, it’s really easy for me to just log in with my password and keys, but now I have to have a key exchange system for you, and I have to build out this way for you to revoke keys, cetera, et cetera, it builds a lot of a lot of structure into place, which is fine, I think, when the boundaries are well known.
But if you get those boundaries wrong, and you’ve already built up all this structure, that’s a lot of wasted time, which is why Team Topologies rightly says, don’t do this until you know what your boundaries are.
Andrew Parker: So if we, if we take this example and we think about, okay, X is a service. You mentioned a couple of codecs, but let’s say that we’re taking the example of we’ve decided, oh, you know what? Sure, sure. There’s a different UI, but it’s all the same codecs. It’s all the same. I’m, I’m not an expert in video editing, but it’s all, all of the same stream processing of those, of that, those pixels into different compression formats and whatever else. and so look, the, the mobile team already has all this software. That takes video clips and reformats them into something that’s smaller or something that fits the different dimensions needed on different mobile devices. And they just, they just have this whole server farm. They have this whole system.
And they’ve already got a small group that’s kind of working on that. It’s, it’s part of their large group. But you know what? Let’s turn that video codec system into a codecs as a service. Or trans, what is it? Transpiling? No, that’s, that’s compilers.
Mon-Chaio: Right. It’s yeah. Huh.
Andrew Parker: Transcoding. That’s what it
Mon-Chaio: Transcoding. I was say transcription, but that’s, that’s too, that’s podcaster
Andrew Parker: yeah.
Trans piling is a service. Okay,
Mon-Chaio: no, not, not trans, not
transpiling
Andrew Parker: Transco, transcoding is a service. Oh, trans. Too many things. Transcoding as a service. And we say that this desktop team will just use that. Let’s say we’ve already made the decision that there’s going to be a few services split out. Well, the thing is, is at this point we haven’t even discovered if those are the codecs that the desktop team needs. The desktop team also isn’t going to be trying to Transcode into different aspect ratios and different formats, all at the same time. So, and they’re going to be sending much larger files. Like, they might be working with multiple gigabytes, even terabytes, depending on the length of the videos they’re working with, whereas the little mobile app is probably working with maybe a few hundred megs at most. And maybe that entire system is just not designed around that. It doesn’t have the affordances for that. It doesn’t have an API that works well for it. It assumes that everything just happens in one long stream, whereas you might need to do multi part uploads and, and kind of, like, send them through a bit at a time for a really large file to work well. And, and so it’s just a completely different beast. But now we’ve decided that they should take on a very low interaction model. Where it’s going to take a long time for one side to discover that this isn’t going to work out or what changes are needed. And in the meantime, what I see in those low interaction setups, in the meantime, We’ve set up our teams to probably start hating each other, so they’re going to get angry.
They’re going to be like, this desktop team just keeps making stupid requests and using the service wrong and complaining to us
well, they never spent the time to work out that what is the service that they need.
Mon-Chaio: so there’s quite a bit of foreshadowing there.
Andrew Parker: Oh, is there? I’m just playing it out with the way I think it would happen.
Let’s take a quick step back in order to take a step forward here.
Mon-Chaio: So what the, what the leadership decided is they decided this was not going to be part of the mobile team. They weren’t going to start there. Team interactions might tell us that they should start there.
Because collaboration, remember, if you have two teams that need to collaborate, there is a tax of collaboration. There’s a blurring of boundaries, there’s a slowing down of execution, all of that. So probably the best thing to do, to have done in this case, was to say, look, let’s make this an exploratory project within the mobile side.
Let’s take some mobile experts who already own these codecs and rendering services and let’s let them explore the scale of the problem and whether this is really something that we want to take on. And if we do what the scope of it is that we want to take on, but that’s not what they did, they ended up spinning up a team of external people in order to do work on the desktop side of this people whose experience was around windows, computers, Mac OS computers, that sort of thing, a completely different skill set. Now we’ll have that discussion a little bit later about fracture planes. Right. But. This team then needed to interact with the mobile team, and hence team interactions. And the interaction became, on the one hand, the desktop team thought that the collaboration was, thought that the team interaction was collaboration.
But the mobile side did not necessarily think that the interaction was collaboration. They thought of the interaction as more X as a service. So we already see a problematic gap in communication there. So playing that forward, the desktop team, as they started to use some of these mobile features, and again, remember, this is leadership mandate.
The desktop team could have simply built their own platform around codec rendering. They could have copied the mobile code and spun it off, forked it, and created their own, right? This was not a company where code ownership in that way was super segmented or regimented they could have just gone into git and grabbed the code out, nobody would have stopped them but there was a leadership mandate to reuse code, which we often see at larger and weirdly at smaller companies too, this idea of platformizing too early, but there was this leadership mandate to reuse code ostensibly to save cycles, right?
code’s already written, you save cycles without understanding that sometimes the tax of collaboration is greater than the cycles. of duplicated code, duplicated issues, and all of that sort of stuff. So the desktop side went to the side and they said, Hey, we’re using your thing. There’s a leadership mandate to use it, but you don’t have these features.
You can’t support 4k video. Your file sizes are too small. Your transcoding cloud doesn’t support the volume that we need. And what did the mobile side say to them? The mobile side said, well, folks, you don’t have a feature. We have a hundred million users a day.
You have zero. So thanks for your request for us to update this stuff. We’ll take it under advisement. Come to us in our next planning meeting, and we’ll try to figure out in the next quarter, how we’re going to deliver, but that’s not how the desktop side is working right there in a. In the Explore, Expand, Extract phase, they’re, they’re strongly in Explore, and they’re trying to work collaboratively.
So we’re already having an issue here. And to your point, Andy, about the teams hating each other, the seeds of hate have been sown. Have they not?
Andrew Parker: Yeah, unreasonable requests, things where like, Oh, you just don’t understand the service we provide. You’re asking for things that that we don’t do. Why, what, why are you wasting my time in this way?
It takes me to a section in the team topologies book where it says interaction modes of different teams should be expected to change regularly depending on what the teams need to achieve. And, yeah, so you need to take those teams along on that journey of, oh, we are, we’re still exploring what this needs to be. Expect a lot of collaboration, a lot of discussion, a lot of interaction on how to do this.
Mon-Chaio: Correct. And if the If there was a clear understanding of the tax that would be necessary with a collaborative relationship and if the mobile side had signed up for that tax of collaboration and agreed that the interactional model was collaboration versus access of service. Some of this could have been smoothed over a lot.
Now we could also say that if the mobile side, if leadership had simply said, let’s have the mobile side, take it on as a project for now. That doesn’t mean it has to stay there forever. Like you were saying, Andy, things change, right?
Andrew Parker: hmm.
Mon-Chaio: also imagine that engineers that had been working together on the mobile problem for years and years and years.
Would have an easier time having these uncomfortable discussions around scaling and adding features Than some other engineers that just were dropped off the street that they hadn’t built these relationships with
Andrew Parker: Yeah, so we, we have so far that they, they were starting off on this exploration journey. And set themselves up down the wrong path by choosing an interaction mode between teams that wasn’t designed around exploration. It was, it was already starting at this, at this idea that they know what they’re doing.
Mon-Chaio: Well, in, in the BART model, one thing that they talk a lot about is explicit agreement around things like boundaries and and activities and, and whatnot. Team topologies, I think, says it less strongly, but I would say that they would mention the same thing Both sides need to agree to the interaction model.
Andrew Parker: Yes. Yeah.
Mon-Chaio: And in this case, both sides did not agree. Leadership may have told both sides what the interaction model was going to be. That doesn’t translate into people on the ground and, you know, the middle management levels, understanding that and actioning that.
Andrew Parker: Yeah. Yeah, and I think in a case like this, it’s coming from this idea, I think it can come from a couple different places, a misreading of the situation. One is the misreading that the path to X as a service is clear. And that we should just set ourselves up for that final state that we believe we should have. And just get rid of the waste of everything in between.
Mon-Chaio: Right. It’s the same thing with test driven development, right? In the lower level, if I just write the code right the first time, then I won’t have to touch it again.
Andrew Parker: Oh yeah, yeah. And I can, and why don’t I just write all of the tests up front?
Mon-Chaio: Right.
Andrew Parker: I’m supposed to write the tests up front, I’ll just write all the tests up front. But, no, the point of it is that journey of discovery and that feedback loop until you get to that point where now it is small incremental additions to a well tested system.
Mon-Chaio: Now in that, in that example, in the small code example is exactly the same things. You don’t know where your boundaries are when you’re starting off and TDD helps you figure out your boundaries. At some point, you know, your boundaries and you can move to a different model where you say, okay, this is a clear boundary.
Same thing with organizations.
Andrew Parker: Yes, absolutely. And I think the other one is the, the one you were talking about Mon Chaio, is this idea of the taxes. The tax of collaboration, and I think sometimes that tax, it’s kind of like loss aversion. That tax gets overblown. in your mind, in, in leadership’s mind, to think, Oh, wow, I, I don’t want to take that on.
We’re going to just do this with the idea that the X is the surface. It just goes faster because they all know what they’re doing. They know exactly what they’re, there’s none of this overhead of the collaboration. Missing out on the idea that the tax on that is that it takes you much longer to figure out unknowns.
Mon-Chaio: And a general thing in my mind, a lot is. All of these taxes need to be accounted for and realized in the minds of senior leadership from CTO all the way down. I think in many companies, especially large companies that have grown out of startups and are starting to slow down, the
Andrew Parker: want the good old days again.
Mon-Chaio: Right.
And the taxes aren’t explicitly acknowledged. And I have seen, in my experience, more than two companies where their response to that is we’ll just get better at it. And that’s not, that’s not the right way to think about it. There’s a systemic tax that exists
and the people that they reward tend to be the people that are spending a lot of hours plowing through the tax.
And so you put the onus on these people to work extra hours and to put different multiple brain cycles behind it because of what I call an abdication of leadership responsibility. Of not defining the right boundaries and quantifying the tax and understanding the tax.
Andrew Parker: But it does bring up something very interesting, which is one of the things about team topologies that they talk about, and I really like this, is that a way of using these models, the idea of collaboration versus X as a service, and the various team structures, A way of using this model is not just for structuring yourself, or saying, this is the structure we’re using, but it’s also for sensing what’s going on, and coming up with ways to respond to that.
And so if you have a setup where you think, oh, these teams should be interacting in an X as a service fashion, but you notice that that’s not what’s happening, or it’s not happening smoothly, Maybe, maybe there’s a lot of, of chatter that you’ve started to notice that they’re talking to each other a lot more than you’d ever expect given that setup.
Mon-Chaio: hmm.
Andrew Parker: It’s, it’s a signal to, to now sense what’s going on and start digging in and understanding why is this happening. Is, is there, have their circumstances changed? Or did we misread the situation when we first set this up and we’ve actually set them up incorrectly? Has that, has something happened, and can we learn from it?
And that team topologies quite often, they, it brings up this idea of sensing. We’ve, we’ve mentioned the Cynefin framework before, which is a lot about sensing and understanding how things are interacting, why different behaviors are happening. Mm
Mon-Chaio: that up, Andy. I love that you brought it back to sensing and diagnosing, because that is absolutely true. It’s not just a framework for how to set things up, but it’s a framework, like all models, you gotta go look, right? You gotta do your gemba walks. when things aren’t working, you have to reflect.
And part of that reflection, to your point, is did we set things up wrong? And leaders have to be cognizant that that’s their responsibility versus what I have seen a lot. These people are having conflict. We see the conflict. Just don’t have conflict. Just do better.
Andrew Parker: Yeah. Just, just, just figure it out. Just fix it.
Just fix it. We’re not going to change the structure. We’re not going change anything about that. Now there is a thing to be said about sometimes what does come out is people are unskilled in particular forms of collaboration.
Mon-Chaio: Yes.
Andrew Parker: and there are things that can be done there, but it doesn’t, I think to Mon Chaio, to your point, it doesn’t remove the tax entirely.
Mon-Chaio: No.
Andrew Parker: If we
have to have a conversation every day about what we’re doing. We’re having a conversation every day about what we’re doing. It doesn’t matter how good I am at having the conversation. It’s still going to exist. It’s still going to be there in some form.
Mon-Chaio: and honestly, we don’t want to get away from this. There are people that are unskilled at having certain conversations. There are people that have uns, that are less skilled at doing collaboration. That is also leadership’s responsibility. And not just middle management, the way up.
And have we developed the right training programs?
Have we set up these people for success? If I’m in an organization where most people are unskilled in collaboration, let’s say, is it right for me then to demand that they get good in three or six months? Or is it more right to me to say, while my organization is in this state, I should change the models until they have the skills to participate in the right model?
Andrew Parker: Let’s leave it there for now and kind of take our example a little bit further where we’re getting low on time. So, after they set up this team and they decided that one was going to be acting as a service and there was going to be this other group separate from them there was confusion about are they doing X as a service or are they collaborating?
What happened next or where did this go next?
Mon-Chaio: Right. So remember, leadership thinks things are going well, right, and they think everything’s collaborating. That’s not what’s happening on the ground. Remember also that we spun off with, we have some internal people that need to do video editing to create promotional videos for our products. Then, leadership takes a look at it and says, you know what?
Wouldn’t it be great if this long standing video editing platform we had on mobile was also available on the desktop? We can think of maybe two or three or four use cases of people both using the mobile product and the desktop product. Maybe there’s a social media influencer who makes small videos, but then wants to incorporate them into their long form videos to put on YouTube or something.
Andrew Parker: Oh, and why should they go and use some product from Adobe to do that?
They should just use our product.
Mon-Chaio: We already have this product, right? And so now this small group that was spun up to do an internal tool for their internal team is now being tasked to create a product to release to the general public. Recall now, of course, that this is still a separate group. They’ve been divided by technology so far, right?
There’s a concept called fracture planes in the book about how you can think about dividing teams. One of the fracture planes they mention is fracturing on technology boundaries. Ostensibly it can make sense. Writing code for Windows and Mac OS machines is quite different than writing code for Android and iOS devices.
The whole build system is different. So that’s how they have, at first, divided. And now they have said, well, you have a team working on desktop. Now create a consumer version, but remember they’re still not the same team.
Andrew Parker: Right. And so now they’re going to start talking about, Oh, we need feature parity.
Mon-Chaio: exactly
Andrew Parker: capability, and you need to implement that.
Mon-Chaio: exactly. There’s a couple challenges here. One is this team is relatively small. It’s still sized for this explore phase. And they add a few more people and they said, well, now you have a few more people will run lean, a favorite phrase of a lot of larger companies. Run lean, do more with less.
Andrew Parker: Mm hmm.
Mon-Chaio: The mobile side had probably 150 people supporting that, what I would call that context boundary.
And by context boundary, I mean, what you have to hold in your head at once of a product’s features and capabilities and the code to support those capabilities and the platforms to support those capabilities. The desktop side was asked to do feature parity with approximately 20 to 30 engineers. And to keep all of that context boundary in their head also at once.
The second thing is, because they’re separate organizations, they don’t have the same product leadership.
Andrew Parker: Mm hmm.
Mon-Chaio: product now, not just the engineering side of it, or not just the code writing engineering side of it, if you consider product part of engineering, product now has to have either a collaborative relationship with product on the other side, they have to have a product X as a service relationship.
Andrew Parker: Right.
Mon-Chaio: And an example of this is the mobile side would say, well, we’re doing this feature where we’re going to allow picture in picture. it doesn’t make sense for it to not show up on the desktop side. So, You got to find some cycles to get this done. Now, not only does the desktop side have fewer people, they also have different KPIs.
Remember, they’re not the same product,
Andrew Parker: Mm hmm.
Mon-Chaio: right? So they have different KPIs. One’s in extract mode on the mobile side, one’s in explore mode on the desktop side. And yet, there’s still this need where mobile will say, I’m pushing this feature ask to you because leadership has given us this mandate of feature parity.
So, perhaps I will pause there and see what we have to say or what we think Team Interactions and Team Topologies has to say about this interesting twist in the evolution of what’s going on here.
Andrew Parker: I, I think, I think going back to the, the, just the fundamental idea of team topologies, one of the things here, Team Topologies is about how do you create faster flow?
How do you not have these terrible slowdowns that a lot of large organizations suddenly find themselves in? And the answer is, you pay attention to what these interactions are, you pay attention to what these structures are, and you notice that just demanding more isn’t going to change the fact that the slowness is coming from a bad, the poorly structured, poorly organized. And not from the fact that, oh, they just, they didn’t want to work hard enough.
Mon-Chaio: Right.
Andrew Parker: And so I would say almost we’ve gotten so far past what the interaction modes of team topologies are that we have to go more back to the fundamentals the flow of value that the company is looking for is Orthogonal to the structure that they have everyone working in at the moment.
Mon-Chaio: you’re right about that, right? The, the challenges of these interactions is coming because of the structure, not because of the people. It’s not 100 percent to zero, but it’s also not 50 50. I say the challenges here are probably 80 percent due to the structure, 20 percent due to the people. The structure is the job of leadership to solve.
That is their domain. And so when they don’t solve that, and they simply say, this is the structure, if you were any good, simply work through it. That, to me, is, again, getting back to the term I use, abdication of responsibility. What Team Topologies does say, though, part of their way of defining boundaries, this isn’t around team interactions, what we’re talking about, this is earlier in the book, is you need larger groups and you need different boundaries when context doesn’t fit, when you get past certain Dunbar’s numbers around how much context a specific group can have.
This was something that was not paid attention to. It was ones that sensed that when you create a larger context for this group, when you say you have to have feature parity with the mobile side, it’s not about how much you can type. It’s about how much you can fit in your head.
This played out by the desktop side, releasing a bunch of software that was super buggy because for every engineer, they had to quote unquote, own seven, eight, 10 features. so you can only spend so much time on one and a bug comes in on one feature and then you do that and then immediately a bug comes in on another.
You’re just squashing bugs. You don’t have time to really take a step back say, let me take a, let me take a think on what this should be because the context doesn’t fit in your head.
. One other thing I will point out, we weren’t talking about team interaction so much, but if we turn back earlier to the in team topologies, they would talk about goals. And because they’re talking about Conway and reverse Conway and about aligning architecturally part of that is aligning goals as well, right?
And so. So, when we realize that the goals are different, or whether we realize the goals are the same, that’s another opportunity for us to take a look at the team boundaries and say, 1. Are the boundaries right? And then 2. Are the interactions correct between the boundaries?
Andrew Parker: And they actually even have something about that, that That when certain things happen, they have this section called Triggers for Evolution of Team Topologies.
Mon-Chaio: Ah, yes.
Andrew Parker: That there’s a few different triggers. I think this is, this is an incomplete list. I think there’s probably many more triggers that you could find, but this is kind of like to get you thinking about it.
Mon-Chaio: Mm
Andrew Parker: to this example, one of their triggers is multiple business services rely on a large set of underlying services.
Now, I think from the example you gave, I think it’s not absolutely clear that that’s what’s happening, but I get the sense that it’s starting to happen. That they’re starting to find all these interactions between each other. And the symptoms that they have are that that there’s limited visibility of end to end flow within their service area. So the desktop team wanting to do stuff but they’re relying on services from the mobile team, or the mobile team at some point probably would end up starting to rely on services from the desktop team. And it becomes difficult to achieve a smooth flow and a rapid pace of change due to the number and complexity of sub subsystem integrations.
And attempts to reuse an existing set of services and subsystems becomes more and more challenging. And the idea is, this is going back to that thing of sensing. There are triggers to cause you to, to, to think, do we have the right thing? Rather than just plowing ahead and saying, well, well this is the structure we have, this is the only thing that makes sense.
It’s to be a trigger for you to, for you to step back and say, let’s rethink this. Doesn’t necessarily mean we need to change something, but it’s, it’s a trigger to say that would be the thing that we need to talk about now is are we, are we achieving what we need to achieve? And if not, how do we change how we’re interacting to help that?
Mon-Chaio: And I love this trigger section because I think a lot of these triggers apply to this situation. I think the software has grown too large for one team.
Andrew Parker: Yep.
Mon-Chaio: is another sensing aspect that didn’t happen in this specific instance with the leaders of this organization. I think the delivery cadence is becoming too slow.
And I would Echo there, not just becoming too slow, but that the delivery quality has become too low, which I think is intertwined with becoming too slow. Instead of becoming too slow,
Andrew Parker: They
just ignore.
Mon-Chaio: terrible quality. Those are two other triggers that are also mentioned in the book that I think apply strongly to this situation and really show, to your point Andy, that not enough sensing was done.
That there was a mandate at the beginning of And then no real will through it to sense and evolve. Instead, simply asking the group to execute that mandate, by all means necessary, without giving them the tools and the levers to pull to make sure that there is effective execution.
Andrew Parker: Alright, well let’s, let’s try to wrap this up now, since we are, we’re going to have a hard time cutting this down into a digestible episode. But Mon Chaio, are there any last thoughts you want to leave people with?
Mon-Chaio: I highly encourage everyone to read it. When I first read it at the beginning, my initial thoughts were, I can’t believe I haven’t read this stuff before.
I thought that these were only things that I was thinking myself, and I had never heard of anyone thinking about it, which obviously wasn’t true. People had been talking about it for a while, right? But I hadn’t been in the circle. So, highly encourage someone reading it.
Andrew Parker: My sum up on this is that it’s, it’s just once again having a model like team topologies, like all of the, the thought in there. gives a really useful way to me to pull apart a situation and have triggers to change behavior.
So I actually like, I like a lot about this book. Similar to you Mon Chaio, a lot of it wasn’t all that new to me,
Mon-Chaio: Mm hmm.
Andrew Parker: but it just condensed it all down into something that I’m like, this now creates a ubiquitous common language that I can use. to start talking to others. And I can say, let’s reference this.
Let’s talk about that. So, I think it’s a, it’s a very useful reference book for discussions about How are we organizing?
Why are we organizing that way? And what triggers might we have to change what we’re, how we’re organized?
Mon-Chaio: Agreed. Yeah, I, I mentioned this earlier. Everyone, I think, should this book a read. And I want to touch on, again, Andy, what you said around the language. You said it now. You said it way back when we first started. The language and agreeing to the terms means that we can have a much more fruitful discussion by agreeing to the same language and the same models.
Mmm.
Andrew Parker: All right, I think with that we will ask that everyone who’s listening to this, if you like this episode, Please like us on whatever podcasting system you’re, you’re using, or pod catching system, I think I’ve heard them called, a system you’re using. Give us a comment, give us a like, or shoot us an email at hosts at the TTLpodcast.
com. We are always happy to receive them, and we want to get your feedback. We’ll respond. We will, we will just be overjoyed . Until next time, be kind and stay curious.
Leave a Reply