Host Intro (Gene Kim)

As Dr. Mik Kersten mentioned this morning, the book, "Team Topologies: Organizing Business and Technology Teams for Fast Flow" by Matthew Skelton and Manuel Pais has been such an important book for technology leadership.

It has given us a language to talk about the design of organizational structures, and gives us such terms as cognitive load as something we must specifically design our teams around. It gave us the four types of team structures, such as stream-aligned teams, enabling teams, complicated subsystem teams, and platform teams.

I think this is such an important book for our profession, and congratulations to both Matthew and Manuel for writing it.

So in this presentation, they will be talking about something that they've been working on, focused on the structure and dynamics of remote work, something made necessary for all of us because of the global pandemic. Here is Matthew and Manuel.

Matthew Skelton and Manuel Pais

Matthew Skelton: Hi, I'm Matthew Skelton.

Manuel Pais: And I'm Manuel Pais. We are the co-authors of the book, "Team Topologies," and we're thrilled to be back at DevOps Enterprise Summit to share some more team-first insights with you.

The past two years have been tough for many organizations as they struggled with remote-first ways of working, and this is partly why we recently wrote the "Remote Team Interactions Workbook," published by IT Revolution. The "Remote Team Interactions Workbook" takes the ideas from "Team Topologies" and applies them in a remote-first context. As the name suggests, the workbook encourages you, the reader, to apply the ideas in your own organization using the exercises and templates provided.

Matthew Skelton: For this talk today, we decided to simulate the use of the "Remote Team Interactions Workbook." Manuel and I will play fictional characters at a fictional travel company called Footprint. They are struggling with remote working but discover the "Remote Team Interactions Workbook" and decide to apply some of the ideas. See if you can tell who is who under the makeup and disguises.

01Role play: stream-aligned team engineer tries to find database help

Okay. So what do I need to do today? Let me fire up my task list and see what I've got to do. So here we go.

What's going on? Oh, this is already done. We've migrated the Foobar to the new cloud environment. That's fine. And Sam is doing the new deployment pipeline configuration. That's fine.

What's this? New database in the cloud environment for Waypoints. This is the one for me. I'll add myself there. Yeah, it sounds like about size three. That's not a problem. What are the details? We need 10-times scalability. Can the infrastructure platform or database teams help? Yeah, that would be nice, wouldn't it? Because I don't really know about how to configure this new database in the cloud environment. Okay. Well, sounds fine.

We've hit our WIP limit of two out of two for the doing, but that's okay. This sounds like it's small enough. Where can I find out how to make this happen? Well, let's have a look in Slack now. Which of these channels do I need to go into? Is it the infrastructure team? Is it the database team? Is it our now-platform team? I don't know. What have we got? Architecture, Cassandra, data, data design forum, data import, old databases discuss. Is this it? DB permissions. What's this for? Diagnose database permission issues. No, it's not that. Kubernetes.

I have no idea which channel it's in. What can we do? Can we go to data, data design, database, data. This is annoying. How do we find out where we can get some help from? Database, channels, databases, design. No. What am I supposed to do? Where do we find this stuff out? What else can we search for? Database. DB, database.

Let's have a look, team channels. Well, what's this? DB provisioning. Provision databases. Pluto requests. Why is it called Pluto requests? Why is the channel called Pluto requests when it's all about database provisioning?

Join. Let's see what happens in here.

Hi. I am working on walking tours. I need to provision a new cloud database. Can you help? I should spell it properly. Let's see what happens.

Okay. It would be kind of cool if the name of the Slack channel was a bit more descriptive. Maybe I can send them some details about this book that I've just been reading, this "Remote Team Interactions Workbook." Where has that channel gone again?

By the way, it would be great to have a channel name that is a bit more linked to DB provisioning. Big smile. Check out this new book I have picked up recently. It has some useful tips on channel naming.

Let's see what else, because I've got the copy somewhere here. Where is the bit that I was going to read? Here we go. Team-focused conventions for chat tools. This is the bit that I remember from before. Page 34. Let's go down to page 34. Find that. Page 34. Here we go. This is the bit. Team-focused conventions for chat tools.

Just get back to those folks in here and put a suggestion here. See page 34 in particular. Look at all this stuff here about platform team data. Platform team. So what we could do is, example: the channel could be called, we'll go like this, Platform Team Database Provisioning. Let's see what they say.

Pause. What's happening here? The channel names in Slack chat were not intuitive, making it difficult for the person in the stream-aligned team to find the right channel for the Database Provisioning team. This is an example of where poor design of the online space adds to team cognitive load. Luckily, the engineer had read the "Remote Team Interactions Workbook" and so suggested that the channel be renamed based on the naming conventions in the workbook.

02Role play: platform team engineer treats the request as onboarding

All right. I finished updating that document. I think it's time for lunch. I just want to check Slack one more time.

Oh, there's a new request or message in our Pluto request channel. Let me see if I can answer that quickly. Hi, I'm working on walking tours. I need to provision a new cloud database. Can you help? Yes, that's exactly what our DB provisioning service is for.

So, sure. What I can do is send them to documentation. I mean, it's available on the wiki, but I can send a direct link to the onboarding document, and that should make their life easier.

Here we go. Get link. Copy link. Done. Here's the direct link to DB Provisioning Onboarding Guide. Okay, that should help. Let me know if you have any issues. Okay.

There was something else here. Okay, I'll have a look in a moment. I don't want to forget to update our team API because this means, yes, as I thought, this team wasn't using our service yet. So that means we have a new customer using our service. That's the Walking Tours stream-aligned team onboarded. So starting today, it's the 9th of May, 2022. Last net promoter score rating, not yet, because they have not filled in any surveys yet for our customers. Okay, cool.

I'll ping our team later this afternoon so they know we have a new customer to take care of. And what else was there? Something about channels.

It would be great to have a channel name that is a bit more linked to DB provisioning. Check out this new book I've picked up recently, "Team Topologies Workbook." It has some useful tips on channel naming. "Remote Team Interactions Workbook" by Matthew Skelton and Manuel Pais. So, see page 34 in particular. Example, channel could be called like this.

Okay, why would it be called like this? Okay, let me have a look at the book. In fact, if I'm not mistaken, I think I bought the PDF version of that book not long ago. Yes, in fact, I have it here with all my other books that I have stored.

Okay, so let's open that. "Remote Team Interactions Workbook." Using Team Topologies patterns for remote working. Okay. So I don't have time now. What did they say? See page 34 in particular, and here's an example. Okay. So let's go to page 34. Team-focused conventions for chat tools.

Okay. Many positions allow free rein within a chat tool. Okay. Why is that a problem? Huh. Define a set of conventions to improve predictability and discoverability. For example, include the team name and type of team in the channel. Okay. Yeah, I guess that makes sense.

We had Pluto, which is the name of the team, but yeah, it's not really very meaningful for people who don't know what the Pluto team does. And so what they're proposing is Platform Team Database Provisioning. Okay. That'd be good.

So let me rename the channel. Okay. Save changes. Everything else is the same.

So in going back to the team API, I know we have the channels listed here. This is our team, Pluto channel. Pluto request was for other people to send us requests, so now we've changed it to Platform Team Database Provisioning. Yeah, I can see that's much clearer for other teams to figure out where they have to ask for things. That was a nice idea.

Pause. What's happening here? The engineer in the platform team assumed that the stream-aligned team just needed to be onboarded. They updated the team API of the platform team to reflect the new customer but did not expect any collaboration. The Slack channel for the platform team was renamed to follow the conventions in the "Remote Team Interactions Workbook."

03Role play: stream-aligned team clarifies the expected interaction

Well, I'll tell you what else I should do in here. So we now know that we're going to be collaborating with the platform team on database provisioning, so let's update our team API to show exactly this. Platform team, DB provisioning, collaboration. What's the purpose? Well, the purpose is really kind of explore how the DB can handle 10 times scaling. And I don't know, it's going to take something like maybe three days from the 10th of May. Okay, so that's now updated in our team API.

That's cool. So what else have we got? What else did they talk about back in this channel? Let's have a look through replies. Okay, so you've done that. That is great.

Oh, there's some more replies in here. Here's a direct link to the DB provisioning onboarding guide. Let's have a look. Okay. Yeah, but I don't need an onboarding guide. What I need is to work together with the people in the platform team to deal with the fact we need 10-times load, 10-times scalability on the database. We know the database doesn't work. Why they just sent a link to the onboarding guide is not what I need.

Pause again. What's happening here? The engineer in the stream-aligned team was inspired by the channel renaming by the platform team and renamed their own channel based on the workbook conventions. They also updated the Team API for the stream-aligned team to share the expected collaboration phase with the platform team.

04Role play: the mismatch becomes visible

All right. Back from lunch. Let's see what's next. Just checking Slack.

Oh, hi. Good work on the channel rename. We have copied it and put it in our channel name, Stream Walking Tours. Oh, cool. Nicely done. And how can we work towards getting 10X scalability in the DB? I'm not sure why they're asking this. I had already sent the document earlier. Well, I can send it again.

Get link. Copy link. All right, I'm not sure. I think I had shared some onboarding link earlier. It had examples on how to set up for different scenarios. Here we go. Maybe they also haven't seen that the document lists the different endpoints you might need. And don't forget to use or create a new API key for requests. Would be, for example, get DB instance, and then pass the API key, whatever there is, ABCDE, 12345. Of course, replace with the actual API key. All right. I hope that helps. And now I'm going to go back and check my Trello board tasks.

Pause. What's happening here? The engineer in the platform team still assumed that they just needed to onboard the stream-aligned team, but the onboarding details did not address the 10X scalability issue. They were expecting to use X-as-a-Service interaction with the other team.

All right, let's see if we can get this collaboration going. What's going on? So back to Platform team. Sorry, here's my message. How can we work towards getting 10X scalability? Let's see what they say. I think I shared the onboarding link earlier. It has examples to set up for different scenarios. Yeah, but what? The document has different endpoints. Don't forget to create or use a new API key, blah, blah, blah, API key.

Yeah, but this is not what we need. It's not about onboarding. We need to work out how we actually can make this database actually scale completely differently. Okay. Let's see. Could we jump on a quick call? I think we need to discuss in more detail.

05Role play: video call and Team API alignment

Stream-aligned engineer: Hi.

Platform engineer: Hey, how's it going?

Stream-aligned engineer: It's all right. Yeah, it's been a long time, hasn't it?

Platform engineer: Yeah. Since that migration project in the office.

Stream-aligned engineer: About two years, maybe more.

Platform engineer: About two years. Two good years. Good to see you again.

Stream-aligned engineer: Yeah, nice to see you. So, thanks for your time. I just want to just share some details about this database stuff.

Platform engineer: Sure, cool.

Stream-aligned engineer: I'll just share my screen. Here we go. This screen here. It's about the waypoint stuff. So waypoints are this stuff from before, but we've now got these guided walking tours. So self-guided tours with a mobile app, and the waypoints are specific GIS data, geographic data, different parts around the city. Anyway, the key thing is...

Platform engineer: Yep.

Stream-aligned engineer: ...we're expecting to need 10 times scalability, or 10 times...

Platform engineer: Whoa.

Stream-aligned engineer: ...the volume of requests compared to before. This is the key thing. And so we need to just try to work out whether that's even going to work based on what you've got.

Platform engineer: Yeah, that's quite a strong requirement there on scalability.

Stream-aligned engineer: Yeah, it's quite a lot bigger than we've seen before...

Platform engineer: Yeah.

Stream-aligned engineer: ...because there's literally like 10 times the number of pings from the mobile device, whatever. So anyway, this is our team API board here.

Platform engineer: Mm-hmm.

Stream-aligned engineer: So as you know, we're expecting this collaboration to take maybe three days.

Platform engineer: Oh, we were not expecting any collaboration actually with your team anytime soon, to be frank.

Stream-aligned engineer: Ah.

Platform engineer: So we thought you were just going to use the service and follow the documentation examples. So if you want to open our team API for our platform team, you'll see that we didn't have that planned.

Stream-aligned engineer: This one here? The Team API DB provisioning?

Platform engineer: Yep, that's it.

Stream-aligned engineer: Okay. Okay, so your team API.

Platform engineer: So you can see, yeah, we have some collaboration going on with the...

Stream-aligned engineer: So you're collaborating with the Guided Tours team but not Walking Tours?

Platform engineer: Yeah, they need a small change to the API. And so...

Stream-aligned engineer: And you're not expecting to interact with us at all?

Platform engineer: Not at the moment.

Stream-aligned engineer: Yeah. Okay.

Platform engineer: But yeah, I understand what you're saying about scalability. That's kind of an interesting challenge because we haven't had that request before. I hadn't realized it was a fairly different use case. So what we can do is, what I propose, maybe we can book in a couple of days to collaborate since it's a fairly major change, and then we can go from there and see what else we need to do, if we can move on by ourselves or if we need to collaborate longer.

Stream-aligned engineer: Okay. Yep.

Platform engineer: When were you expecting to collaborate again?

Stream-aligned engineer: Well, we made an assumption, which is a classic mistake, but anyway, we made an assumption that we'd be able to do it basically from today.

Platform engineer: Oh, right. So this week is going to be a bit difficult. We have some training coming up and... what about would you be available next week? Thursday, Friday, maybe?

Stream-aligned engineer: Yeah, we can make that work.

Platform engineer: Okay. So just so we're in sync, let me update our Team API. So we're expecting to collaborate with you on collaboration. Sometimes there's a red looking at the ten times scalability of the database. Yeah. So it's not fully defined what we need to do, but...

Stream-aligned engineer: Yeah.

Platform engineer: ...it's initial kind of collaboration to figure out...

Stream-aligned engineer: Yep.

Platform engineer: ...what is going to need to be involved. And so we said, maybe days.

Stream-aligned engineer: Couple of days to start with.

Platform engineer: I think that's the... It might be enough, but at least we'll get some idea of what's needed over those two days.

Stream-aligned engineer: Yep.

Review: what happened

So what has just happened? We've seen how two teams working remotely initially found it difficult to work together. You've possibly been part of or observed similar situations in your organization, especially when transitioning from on-site to remote working. The names of channels in Slack were unclear and not really discoverable, and there were very different expectations between the two teams about how they needed to work together.

But after reading and applying some ideas from the Remote Team Interactions Workbook, the teams found it much easier to work together in a productive way. So let's review what happened.

First, the company had adopted a chat tool, Slack, without any conventions for the names of channels in the workspace. It was difficult for the stream-aligned team to find and predict the right channel to use to collaborate with the platform team. Besides being slowed down by this lack of direction, the cognitive load of the stream-aligned team increases as the communication patterns with the platform team are not clear.

The platform team then decided to adopt some simple naming conventions for their Slack channels, as well as update their team API to clearly describe the purpose of each channel. The stream-aligned team now felt more confident about asking for help in the right channel.

However, the stream-aligned team was surprised with the platform team's reaction to their request for help. They were expecting to agree on a schedule for collaboration with the platform team, but the platform team seemed keen to simply point them to documentation and examples. The stream-aligned team expected collaboration mode but was met with more of a kind of providing-a-service response from the platform team. Clearly, there was a mismatch in expectations at play here.

The stream-aligned team then had an aha moment when they looked at the platform team API and realized they were not really expecting to collaborate. There was no such interaction listed in their team API. Initially, the platform team had assumed that they should use X-as-a-Service interaction mode with the stream-aligned team, which is a reasonable assumption. But in this case, it turned out not to be valid.

After discussing with the stream-aligned team, the platform team realized there was value in adopting a collaboration mode to help redefine certain aspects of the service, because the stream-aligned team had a novel use case. And so the platform team evolved their team API accordingly as well.

The Remote Team Interactions Workbook helps you to design and define the ways in which teams interact. We recommend that you use the team API approach to define and communicate responsibilities and team focus, track dependencies using simple tools, and remove blocking dependencies, and over-communicate using just enough written documentation.

The examples we have given, well-defined chat channel names and effective use of the team API, help to avoid teams getting stuck or confused and wasting time. The physical office was covering up poorly defined teams and poorly defined areas of focus, threatening the overall health and success of their business. In the Remote Team Interactions Workbook, you will find many more techniques and exercises to help you adopt effective remote-first ways of working.