How to Help Teams Interact in a Remote-First World - A Team API Role Play Example
In the new remote-first and hybrid workplace, many organizations are struggling to catch up with new tooling and ways of working. Many are discovering for the first time that the physical office was covering up poorly defined teams and poorly defined areas of focus, threatening their DevOps transformation efforts and the overall health and success of their business.
In this talk, learn how the Team API can be an effective tool to improve the experience of teams that need to interact in a remote setting. What information do they need? Where can they reach us? How can we help them? And how can we evolve the Team API to reduce misunderstandings and turn confrontational situations into productive, valuable insights?
The authors of the acclaimed book Team Topologies - Matthew Skelton and Manuel Pais - explain and then simulate the use of the Team API pattern using a role play scenario between two teams. They show how an evolving Team API can help to turn confrontations into positive interactions, clarifying expectations and helping teams to work effectively in a remote-first or hybrid context.
In their new book, Remote Team Interactions Workbook, published by IT Revolution, Matthew Skelton and Manuel Pais, coauthors of the highly popular Team Topologies, provide proven patterns for a successful remote-first approach to teams. Using simple tools for dependency tracking and patterns from Team Topologies, such as the Team API, organizations will find that well-defined team interactions are key to effective IT delivery in the remote-first world.
Founder at Conflux, Co-author, Team Topologies
IT Organizational Consultant, Co-author of Team Topologies, Team Topologies
As Dr. Mick Kirsten mentioned this morning, the book team to apologies organizing business and technology teams for fast flow by Matthew Skelton and manual pace 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 platforms, 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.
Hi, I'm Matthew skel
And I'm Manuel PA. We are the co-authors of the book team to apologies, 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 top for many organizations, as I 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 toes 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
Well, this talk today, we decided to simulate the use of the remote team interactions workbook manual, 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.
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? So, oh, this is already done. We've migrated the flu bar to the new cloud environment. That's fine. Uh, and Sam is doing the new deploy Python computation. That's fine. What's this new database in the cloud environment for points. This is the one for me. I'll add myself there. Yeah, it sounds like about size three. That's not problem. What the details we need 10 times scalability can the infrastructure platform or database teams help, you know, that would be nice. One to, cause I don't really know about how to configure this new database in the cloud environment. Okay. Well, sounds fine. We've hit our whip limit of two out of two for the doing, but that's okay.
This sounds like it's small enough. Look at where can I find out how to make this happen? Well, that's sort of a look in slack now, which of these channels do I need to do? I need to go into, is it the infrastructure team is the database team. Is it now platform, team? I don't know. What have we got architecture, Cassandra data, data design forum, data import hold databases discussed. Is this it DB permissions? What's this for diagnosed database permission as used? No, it's not S I have no idea which channel it's been. What can we, what can we do? Can we go to data, data design database, this data versus annoying. How do we find out where we can get some help from data base channels, databases, desire? No. What am I supposed to do? Where, where do we find this stuff out? Where else can we search for database D DB database, have a look through channels. Well, what's this DB provisioning, provision databases, Pluto requests. Why is it called Pluto requests? Why is a channel called Pluto request? When the channel, when, when it's all about database provisioning, join, let's see what happens in here. Hi, I am working on, uh, walking towards, I need to a new cloud database. Uh, can you help? I should spell it properly.
Uh, let's see what happens. Okay. Uh, I mean, it would be kind of cool if the name of the slack channel was a bit more, you know, descriptive I've been, maybe I can send 'em some details about this book that I've just been reading this remote team interactions workbook, wheres that channel again, by the way, it would be great to have a channel name that is a bit more leads to DB. Big check out this, check out this new book I have book up recently. Posting has some useful tips on channel naming. Let's see what else? Cause I've got the copy somewhere here. Where is the bit that I was gonna be? Here we go. Team focus, conventions for chat tools. This is the, this is the bit that I remember from before page 34, let's go down page 34. Find that page 34. Here we go. This is a bit, I was team focus, conventions for chat tools. Just get back to those folks in here and put, uh, suggestion here. See page third, four in <inaudible>. We've got all this stuff here about like platform, team data platform team. So what we could do is, uh, for example, a channel could be called like this platform team, uh, data.
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 streamline 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.
All right. I finished updating that document. I think it's time for lunch. I just wanna check slack one more time. Oh, there's a new request or message in our P request channel. Let me see if I can answer that quickly. Hi, I'm working on walking towards an it provision and new cloud database can help. Yes. That's exactly what our DB provisioning service is for. And so sure what I can do. I send them to documentation. I mean, it's available on the Wiki, but I can send direct link to the onboarding document and that should make their life easier. Uh, here we go. Um, get link, copy, link done. Here's the direct link to the visioning on boarding guide.
Okay. That should help. Let me know me know if you have any issues. Okay. Um, something else here. Okay. I'll have a look in a moment. I don't wanna forget to update our team API because this means yes, as I thought we, this team wasn't using our service yet. So that means we have a new customer using our service. That's the walking tours, streamline team onboarded. So starting today, it's the nine. So may 20, 22 last net promoter score rating. Not yet. Cause 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? Um, it would be great to have a channel name. There's a bit more link to DB provisioning. Check out this new book I've picked up recently.
Ologies workbook. It has some useful tips on channel naming, uh, remote team interactions workbook by Mathis Goman page. So, uh, C page three, four in particular example, channel could be called like this. Okay. Why, what 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 had it here with all my other books that I have stored. Uh, okay. So let's open that remote team interactions with book using <inaudible>, which is patterns for remote working. Okay. Uh, start enough time now. Um, what did they send? See page 34 in particular. And here's an example. Okay. So let's go to page 34 in focus, conventions for chat tools. Okay. When your positions allow a free reign within the chat tool. Okay. Why is that a problem? Huh? Define set of conventions that improve predictability and discoverability, for example, include a team name and type of team and channel. Okay. Yeah. I guess that makes sense. Uh, 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 Pluto team does. And so what there's pro proposing is platform team database provisioning. Okay.
That'd be good. So let me, uh, rename the channel. Okay. Save changes. Everything else, uh, 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 requests was for other people to send this request. 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, uh, 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 streamline 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. Um, well I think what else I should do in here. So we now need that. We now know that we're gonna be, we're collaborating with the platform team on provisioning. So great. Our team API to show exactly this platform team to provisioning called what's the purpose or the purpose is really kind of explore how DB and handle 10 times, uh, scaling. And I dunno, it's gonna take something like maybe three days from, uh, 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 of look through repliers okay. So you've, you've done that. That is great. Um, oh, some more repliers in here, here's the direct link to the DB provision. So here's the direct link to DB. So there's onboarding guide. Let's look okay. Yeah, but I don't need, I don't need an onboarding guide. What I need is need to work together with the, with the, with the people platform team to deal with the fact we need 10 times, 10 times kind of low 10 times scalability on the database. We know database doesn't work, Why they just sent, 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 streamline 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 streamline team to share the expected collaboration phase with the platform team.
All right. Back from lunch. Let's see. What's next? Um, checking slack. Uh, oh, hi, good work on the channel rename. We have a copy in, put it in our channel name stream walking towards. Oh, cool. Nicely done. And how can we work towards getting next capability in the DB? Uh, I'm not sure why they're asking this. I had already sent a document earlier, but I can send it again. Get link, copy link. Hi. I'm not sure. I think I had shared onboarding link earlier. Had examples on how to set up for different scenarios. Here we go. Uh, maybe they're also, haven't seen that the document list, uh, different end points you might need, You might need and don't forget to use or create a new API key for requests Example, Uh, would be for example, get B instance and then pass the API key, whatever there is B C D 1 2 3, 4 5 Of course, replace with the actual API key. All right. I hope that helps. And now I'm gonna go back and check my travel board tasks,
Pause what's happening here. The engineer in the platform team still assumed that they just needed to onboard the streamline team, but the onboarding details did not address the 10 X 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, how can we, so my, how can we work towards getting tenability? Let's see what say, I think I shared the onboarding link earlier. It has examples to sell for different scenarios. Yeah. But what the document list, different endpoints don't forget to create or use a new API key, blah, blah, blah, API key. Yeah, but this is not, it's not about onboarding. We need to work out how we actually can make this, uh, make this database actually scale completely differently. Okay. Let's see. Uh, could we jump, make call? Um, I think we need to discuss in more detail. Hi.
Hey, how's it going?
It's all right. Yeah. It's been a long time. Isn't it? Since that migration project in, in the office
About two years, maybe more
Two years years. Good to see you again.
Yeah. Nice to see you.
Um, so thanks. Thanks for your time. I just wanna just share some details about, about this, um, the, this database stuff. Cool. I'll just share my screen. Uh, here we go. This screen here, it's about the way point stuff. So way points are, you know, this stuff from before, but, um, we've gonna got these guided, uh, so I've got these walking tools, which our self-guided tools with mobile app and the way points are specific, you know, um, GS data, geographic data, different parts around the city. Anyway, the key thing is we need, we we're expecting to need 10 times scalability or 10 times the volume of requests compared to before this is a key thing. And so we need to just try to work out whether that's even gonna work based on, on, on what you've got.
Yeah. That's a, quite a, a strong requirement there on scalability.
Yeah. It's quite a lot bigger than, than we've seen before. Cause there's literally like 10 times the, the number of pings from the mobile device, whatever. Um, so anyway, um, this is our team API, uh, board here. Mm-hmm <affirmative> so as you, you know, we we're expecting this collaboration to take maybe three days. Um,
We're not expecting any collaboration actually with your team anytime soon to be Frank. Uh, so we thought you were just gonna use the service and, and follow the documentation examples. So if, if you wanna open our team API for our platform team, you'll see that, uh, we didn't have this
One here. DB provisioning. Okay. Okay. So yourt API,
So you can see, yeah, we, we have some collaboration going on, so collaborate
Tools, but not walking tools. Uh,
Yeah. They need a small change, uh, to the API. And so, um,
And you're not expecting to interact with us at all.
Not at the moment. Yeah. Yeah. Okay. So, but yeah, I understand what, you're, what you're saying about scalability. That's kind of a interesting challenge cuz we haven't had that request before. Um, 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 fairly major change and then we can, we can go from there and see what else. Okay. We need to do if we can move on by ourselves or if we need to collaborate longer.
When did you, were you expecting to collaborate again?
Well, we, we, we made an assumption <laugh> is classic mistake, but anyway, we made an assumption that we'd be able to do it basically from today.
Oh right. So this week is gonna be a bit difficult. We have some training coming up and um, okay. What about, would you be available next week? Thursday, Friday, maybe. Yeah. We can make
That work. We can outta
Work. Okay. So let me, so just so we are in sync, let me update the, our team API. So we're yeah. Expecting to collaborate with you. Um, so collaboration, um, looking
The 10 time scalability of the database.
Yeah. So it's not fully defined what we, what we need to do, but we know it's initial kind of collaboration to figure out, uh, what, what is gonna need to be involved. And so we said, uh, a couple days start with that's the, um,
I mean it, it might be in two days might be enough, but, but at least we'll get some idea of, of what's. Yeah. We'll get some idea of what's what's needed over those two days.
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 onsite to remote working. The names of channels in slack were unclear are 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 slack without any conventions for the names of channels in the workspace.
It was difficult for the streamline 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 streamline 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 streamline team now felt more confident about asking for help in the right channel.
However, the streamline 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 streamline 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 mismatching expectations at played here. The streamline 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 streamline team, which is a reasonable assumption. Uh, but in this case turned out not to be valid after discussing with streamline team, the platform team realized there was value in adopting a collaboration mode to help redefine certain aspects of the service because the streamline 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 overcommunicate using just enough written documentation. The examples we have given well defined chat, channel names and effective use of the team API helped 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'll find many more techniques and exercises to help you adopt defective remote first ways of working.