Jessica Cregg: [00:00:00] Yes. Let’s talk about building better teams a topic that I’m sure we all have an opinion on, especially after the great remote workforce move. If you’ve got any thoughts hit us up on Twitter, pop them in the comments, where. Where to contribute, but I’m really intrigued to see what’s worked best for you.

And what’s worked well for you for your teams, but here’s a couple of ideas that I’ve studied. I’ve picked up some kind of thoughts. I’ve got some suggestions, so yeah. Let me know what you think. So when something goes wrong, what’s your first instinct. Do you tend to ask for help? Because that’s totally okay.

Be forgiven for thinking that collaboration is the way to solve your problem quickly, easily, and without friction. We always hear the M’s two heads are better than one and a problem shared is a problem halved, but. Going beyond language. There, there are really, there are so many ways that this idea that [00:01:00] collaboration equals a better solution faster seems to be the accepted answer.

If you’re moving something heavy, more arms equals more power, right? If you’re building something big and complicated, more hands equals more brain power. Now, unfortunately this isn’t always the case. What’s the case. If you are a villager in the popular game, age of empires two if you’ll recall to get the best way to get a structure, but really quickly is to just assign everyone that you have to the task it had and get them building.

Now, when it comes to digital infrastructure that exists outside of video games, things are slightly different for several reasons. In the mythical man month it’s a collection of essays are widely referenced throughout tech. The idea of a man month is this fictitious unit of time that ties the progress.

A group of people can make relative to their quantity and subsequent time takes them to it creates like a static figure around it the man month. You can tell this. Collection of essay that was published quite some time ago and should be updated to the person month that I [00:02:00] digress. But yeah, the idea that the number of people and the amount of time required to get something done can be interchangeable as commodities.

That’s only true if you are those villages and age of empires. If the tasks, if the work that you’re working on can be sectioned off into sub tasks without any interaction, without any communication. And sure you can just get on with all of it. When a task cannot be partitioned due to its structure or complexity, the application of more effort has no impact on the schedule.

Software development. It falls in between these two in the, in between these two categories. Tasks can be partitioned, but we need communication in between each subtask. We can’t just all assign everyone to the same repo and get going. We really need to define every, define out our tasks, create our create our user stories.

Talk about testing and we really need to be able. Put our heads together and chat about our project. But in these [00:03:00] situations the best possible outcome doesn’t even come close to a trade in, even trade off between people and hours now is widely accepted. The intercommunication is where the majority of the work lies.

So if the task that you’re working on it needs to be separately coordinated. The effort required to complete that second of work increases at a power of end to. The power of N minus one over two. So that’s so in real terms, what that means is three times sorry, three people will take three times as much interaction as two to get the work done and that.

Increases at a near exponential rate. As you can see here, the more people that you get involved in your task, the later it the later it’s going to become the later the software’s gonna be delivered. Things only get compounded when you have two or more people in a meeting. If you’re looking at department wide meetings, suddenly things grind to a halt and we’re required to context switch.

We’re introducing friction into our. We know [00:04:00] this is I’m sure this has happened to you. The result of this leads to the effort of communication, counteracting, the division of labor, it put it’s. We end up putting more effort into communicating than we do into the task that we’re actually getting done.

Anyone who’s become a senior or risen throughout risen in their, in, in their path will know that. When you step up in terms of seniority meetings become a necessary evil and quickly take over your calendar. This projected time, it really shows Brook’s law in action, which is the the idea that just adding manpower to software projects just makes prove stands to make them even later.

But if we’re going to talk about laws, we can’t talk about organizing people without mentioning Conway’s law. And this is our pathway to resolution here. So for anyone unfamiliar with Conway’s law, it’s a concept that the ways that we organize, they impact our, the products that we create in an [00:05:00] indelible manner.

It was, this was an effect that was observed a long time ago, but essentially It was seen when eight people were put on a task to create two compilers, they were separated out into a group of five and a group of three. And funny enough, the group of five created a compiler that had five stages five phases rather.

And the group of three created a compiler with three phases. So the way that we’re organized has a real impact on the products that we create. And we know that we can’t involve too many people into. The paradigm. But we need to collaborate in order to get things done. So how do we counteract this idea of organizational determinism?

How do we create teams that aren’t hindered by Conway’s law now? I’m sure that you’ve definitely heard of the two pizza. I’ll CR I’ll do a little bit of a recap for anyone that hasn’t heard of it. But the two pizza rule is [00:06:00] a practice at Amazon that dictates that all teams need to be small enough, so they can be fed by two large pizzas.

Great. For the takeaway bill. But instead of turning this idea into the thought experiment around what constitutes a good pizza serving size we should look at this as a guidance for. For team building. Matthew Skelton and his book team to apologies, he supports the idea that teams should be by like a maximum of nine people.

If you can help it. The idea here isn’t to calm people out of free pizza it’s to define what small is and to give it a value. And why is it important to define small and give it a value when we’re building teams? We are creatures bound by limitations, whether your team is composed by introverts extroverts multi-scale people people with the sync specialisms, we have hard limits to the number of people that we can perform qualitative relationships with.

And if we want to work on functioning teams, we need to be able to perform quality.[00:07:00] Strong relationships. So the there is a hard limit for this. So British anthropologists, Robin, Don basses, that the number of quality relationships you can form as human beings is stands out 150. We can recognize more people.

We can interact with a great deal more, but functioning teams require quality relationships. So we know that we need a small. We need to define our number and we need to stick to it. But what’s the criteria that we should go down when we are building our teams, but we need to go by ability and in the DevOps handbook authored by.

Patrick OI. He talks about how SLOs tend to occur when teams become over specialized. Now, as tempting as it can be to fill your team with a diverse group of specialists in a sort of heist movie fashion depending on the group’s focus, this can sometimes lead to people. This can sometimes lead to be strain of communication at the start of a [00:08:00] project becoming overwhelming.

For teams compose a specialist communication like comes with the added difficulty of needing to come up with a shared language and a level understanding for the team. So yes, you need to be able to have your niches, but we need some generalists here. For someone to earn a spot on your team, you ideally want them to have a reputation of a specialist with the capabilities of a generalist.

They need to be able to demonstrate their ability to acquire new skills quickly and and a keen desire to continuously build their knowledge. Now as technologists and engineers, we continually hedge your own abilities to be able to acquire your knowledge. Embarking your team project will require you to enact this in a group capacity.

You’ll need to be able to work together to acquire new knowledge and to build things as a team, as a collective. So you need to have people that are cognizant of their own learning [00:09:00] style. What we’re trying to achieve here is a sense of collective intelligence. So collective intelligence is a fairly new concept.

In that’s being researched, it’s been around for decades. I think with the whole misinformation crisis, we’ve understood what it means to be collectively uninformed, but to be collectively intelligent. It’s described by researchers as a group’s ability to to perform across a wide variety of tasks.

There were some studies carried out on this quite recently using the video game league of legends. This was used as an ideal testing ground because people are paired on ability level that have not got a deep understanding of each other, a deep understanding of each other’s like learning styles. You might think, what has league got to do with work?

Massive online battle arena games are often characterized by the idea that we need to make decisions really quickly. We are in these [00:10:00] intense competitive environments and we have a defined set of time to be able to complete a task. Sounds a little bit to the places that we work in. The speed of decision making in a vast, faster array is only accelerating, forcing us to be in a position to make and modified decisions on a nearly daily basis, to be able to guarantee success.

We need to be able to make decision informed decisions that are a faster rate. And the only way that we can do this is by building a group level of intelligence. The study found that group’s ability to be able to perform well at tasks was largely transferable, meaning that if they could do one thing they could do other things well, too.

And secondly, the measure of a group’s intelligence is impacted by their individual attributes and the manner in which they’re organized. So very similar to Conway’s a lot, now the things that can make us collectively intelligent are social perceptiveness, a moderate level of cognitive [00:11:00] diversity.

So we all need to be able to learn in different ways and understand different areas of a product or projects and large amounts and E of communication and the equal distribution of that communication. It can’t just come from one person down. Most notably, however, they noticed that decision equity and verbal communication didn’t equate to a higher level of collective intelligence.

So in fact, the inverse is true, but that just found that the most, the teams that achieved collective intelligence and retained that as a as an ongoing team, they had the least Nu The chat that they used in their chat boxes to communicate with each other. It was the smallest and volume around the most successful teams.

What does this mean? It means that they, it means that these skilled players spend to sorry, these skilled players tended to spend less time communicating by preference. [00:12:00] They’re good at the game. And that’s where they wanna spend their time. They minimize context switching and they engage in nonverbal cues, almost instinct.

Again, this sounds very familiar. This is what we find with software engineering context. Switching can pull us out of the of our of our problem solving capacity. It can kill productivity.

What we need to do here is we need to be able to enable taste at communication. Now, aside from being a very recent word answer, taste at communication is the idea of it’s the manner of recognition that leads to shared understanding. So what we are looking for here is. Nonverbal cues that are understood and communication patterns that are repeatable in the context of a company.

This means advocating for observability measures, automation, and opting for metrics that everyone genuinely [00:13:00] understands. And of course, creating psychological safety so that people can ask questions. Organizations are. People all the way down. This was communicated in Nigel Kirsten’s most recent set of DevOps survey, the 10th anniversary of which was last year.

We are just essentially, we’re just groups of people stacked on top of each other and companies are of course, groups of teams working together. Now in this report, we found.

The best performing teams, don’t just work to collaborate, but they define the types and order of interactions they, that they have. Now, this may sound like overkill, but when you remove the cognitive load that people on to go with each interaction, they have, they gain the ability to be able to focus on the best way to perform at the task in hand, instead of worrying about whether or not they’re asking the right question in the right manner, in the right arena.

Sharing these Rob creating robust systems and sharing them in a uniform way [00:14:00] across teams can lower the stakes and help us to push towards better being better teams and organizing ourselves in a near autonomous fashion.

So here’s a bit of a model. I’ve been talking a little bit about studies and theoreticals, but this is a model that was of overcommunication that was put together by Marissa Goldberg, an expert on remote working styles. And here she demonstrates how we can give the most critical information, a life cycle within the companies that we work in that we’ve.

Let’s take a step back. We’ve got our team, we’ve got our strict number. We know how we want people to earn a spot in our team. Now we need to talk about how to organize and how to function within that team. So let’s say we’ve got some information that we need to share. We need to prep our team and let them know that this information is coming.

We need to be able to detail the information and know and [00:15:00] let everyone know the context of that information. What does it mean? How does it, how is it gonna affect everyone? We need to be able to line up the right speakers, resources enable deep dive. So people know that there are the resources to be able to ask more for more questions.

They’re not gonna get us when you do open things up for discussion, it’s not just going to be a, let me get back to you about that. We need to be able to come to these arenas prepared with a. An expert or someone who’s working on the thing that they’re proposing on launching, and then we need to be able to listen to feedback that we get.

We need to open the forum for discussion, take the feedback that we get from the rest of our team on board, create the equity around communication, and then create a reference for this for this data to live a single source of truth. And then lastly, we need to PR create a cadence where we are revisiting that information over and over again.

Is it monthly? Is it a quarterly check in? We need to [00:16:00] make sure that people know that this thing that we’ve created it lives and it has a life cycle.

Now the common goal here is to achieve understanding.

As as Daniel said here once famously said that when we should aim to create software that fits inside your head things get complicated quickly. We can’t we can’t expect change not to happen. We need to be able to lean on the eye. The fact that. Things will get more complicated as we grow and growth is a constant.

If we don’t understand the software that we’re testing, we’d likely to resist the number of times that we test. Is anyone who’s read the book accelerate will know that optimizing for team performance can be done by tracking these four key metrics. All of which you want to lower side from deployment frequency, which you wanna be as high as [00:17:00] possible.

But if the software that we’re working on doesn’t fit neatly within our heads. If we’re working with too big, a batch sizes, if things are getting too complicated for the team at hand, then these metrics will have a near finite value. We’d like you to distrust our tests. We won’t have the confidence to deploy.

And when our systems do inevitably fail, because incidents will always happen, we won’t have the understanding or the or be able to access the knowledge that we need to be able to restore them. Using tooling to have our backs in these instances can allow us to roll out changes with ease and safety.

And I know that this is not a specific launched directly talk, but an example of this is one of the integr integrations we have with honeycomb. Now if the data that you’re working with is showing instability or Anomali anomalies there’s You’re going to distrust it, but if you’re able to use integrations to your advantage and set up automatic updates to where people check, say, if you’ve got [00:18:00] a slack integration for for your for the outcome of your tests or for your deployments, you’ll be able to know what’s happened where it’s, where.

Deployment sorry. What’s happened when your deployments have happened? I can’t use mouth word today. I’m so sorry. what I’m trying to say is that integrations can take the guesswork out of what you’re doing. When you user toggles on and off a flag, in the instance of launch darkly, you can see who toggled that flag and which flag it is.

And what’s.

This helps us to all operate from the same version of the truth all while increasing the confidence that we can have in our systems and processes while lowering the stakes and the cognitive load that we’re working with, what we wanna do is we want to lower the cognitive load that we are undertaking with each action.

We wanna strengthen our systems and make sure that we create patterns that are susceptible and open to change in a way that is [00:19:00] expected and anticipated. So I’ve gone over a lot in this 20, 30 minutes, but as a TLDR, what we’ve learned in the past couple of years around operating good teams is we need to keep them small.

We need to define a specific number. We need to select members by the same standardized. Acceptance criteria. We need to queue people up to enable taste at communication. We need to have integrations involved in our workload. We need to make sure that we are using observability and monitoring to our To our advantage.

And we are standardizing the communication patterns that we’re having. So people know how to share what changes. And lastly, we need to make sure that we are minimizing cognitive load for everything you don’t need to tell people things that they already know the way to instill confidence is over time.

And we can do that by keeping the tasks in a more software, small [00:20:00] and. Keeping our teams contained. So thank you very much. I’m afraid. I’m sorry. This has been a little bit mouth wordy. If you’ve got any thoughts or any questions, I really welcome them. As you can tell, this work is very much influx, but I’ve got some resources and oh, and not, I’m not going to open the resources.

I was actually just going to bring up this last slide,

Brian Rinaldi: which you unshared your screen somehow.

Jessica Cregg: I

Brian Rinaldi: know today. Yeah.

Jessica Cregg: Today I am not doing today very well, but if you wanna do today, better than I have, then you can go to this web address, get hold of the slides.

At your own leisure and do so well, pair wearing a free pair of socks. So just [00:21:00] socks.

Brian Rinaldi: Wait I socks.

Jessica Cregg: I know I didn’t have them.

Brian Rinaldi: whoa. Yeah. These socks now. I, yeah. Okay. So I have this shirt, but I don’t have socks. I love getting socks. That’s like my favorite swag. They’re the most useful

Jessica Cregg: aren’t they?

Brian Rinaldi: Yeah.

Yeah. So that was despite the mouth wordy things it was, that was great. I love hearing all the research you did on the topic and. I guess one of the first thoughts that came to my mind and by the way, anybody who has questions, please post ’em on a chat or, and ask a question module as we go here.

I’ll be sure to ask them. One of the questions that I had was you were talking about so a little bit about some of the skills of teams, especially when, keeping them small. But there was a lot of like skills that I feel like, and not to divert onto a very. Big touchy topic.

I feel like we don’t interview for the [00:22:00] skills we interview for, like for the skills that make teams successful. We interview for a lot of, not we, as in launched darkly, but as an industry, we interview for a lot of how to, how do you know, trivia type questions about code, right?

Like it’s and. That don’t really get at the problem that makes teams effective, which is how they collaborate, not how much trivial knowledge they have about the language that they’re using. I don’t know if you have any thoughts you wanna chat about that or if any of the research talked a little bit about how you can build these teams, how you find people who can make them successful.

Yeah.

Jessica Cregg: It’s. It’s a really difficult thing to measure because we. One of the biggest things that was highlighted in this, in the study, which I stumbled over my words Whil I was trying to talk about was that self-awareness is having a [00:23:00] good understanding of how you learn and how other gives you an understanding of how other people learn.

And it means that you are able to mold your communication style, to fit the team that you are embedded into. . Yeah, that’s a really tricky thing to to measure because if you give some something, someone, something new to master, like if you give someone a tech test that’s based on a, an area that they don’t know very well, they can simply Google it and look it up really quickly.

So it’s quite difficult to,

Brian Rinaldi: Yeah. Yeah, I agree. They could, Googling is definitely a good job skill anyway. true. Yeah, and I think, but I get your point. It’s hard to measure some of those things in an interview. There’s not like a interviews and the whole process of recruiting someone.

It’s a very limited amount of time. Even with like now we have companies have four or five, six interviews, but what are we talking about? Handful of [00:24:00] hours total, right? Like how much can you really know about somebody’s learning styles and their personality and their, in that short of time, you’re making guess.

Jessica Cregg: Yeah, exactly. But I think one of the biggest shifts that we’ve noticed is. Accept is accepting that we’re not gonna be able to pick up that information in the interview stage we might not be able to interview. We’ll be able to interview someone who’s a good fit, but we won’t necessarily know that they’re a good fit unless until they’re on the team, working with the group of people that they need to be working on.

And it’s that kind of idea that production data can’t be faulted. You’ve got to be able to live in that state of reality. So I think the fact that we’ve destigmatized the idea of switching jobs. It’s been quite positive because you can sometimes only figure out if you are built for an environment by being in it and making that an okay process to opt out of after X amount of months is

Brian Rinaldi: yeah.

Yeah. [00:25:00] Good companies do I think not only give people opportunities to move around, but also you have to have a good, I think it’s up to, at that point, the manager to kind. Recognize people’s strength, play, help organize a team in a way that re plays into people’s strengths, right? Like definitely.

Because you will always have different personalities and strengths on the team. And it’s hard. It can be hard sometimes I think, to factor all that in when you’re trying to build a team and allowing people to move around gives you the opportunity. I think your point of smaller teams, if you have smaller teams, you actually have ability to move people around a little bit easier.

I think then because they can move to a different team that maybe they’re a better fit fit on.

Jessica Cregg: Exactly. And I think I think that’s why we see the squad model validated by a bunch of in a bunch of studies and just in real life in general like having several squads United around a small problem, and then creating teams that enable other teams [00:26:00] is a really great way of being able to make sure that things can stay quite.

Open to change. If if eight people is becoming too much for a certain pro product. Okay, great. We’ve got a series of other teams that we can look at. Yeah. Yeah. What are your thoughts on the squad model? Do you like it?

Brian Rinaldi: I, no, I think it’s great. I think, like you said, it keeps the team small and focused on a particular problem and allows people to move to things that.

Interesting to them, right? Allowing you to switch a squad and say Hey this problem sounds really interesting to me. I’m like particularly passionate about it. I can move over to this squad and focus on that problem. So I think, and even sometimes, if you’re on a particular thing and you’ve been made have been working on it for a long time and you’re like, I need new challenge and just being able to switch to something different is helps.

I think so. So I think it, it gets at your, you talked and I, Meg had a question I wanna get to, but it gets like you talked about [00:27:00] specialization being overly specialized teams, being like individuals on team being can be problematic. But I think, when the team is, has a focus, right? Like you can be generalist within a smaller.

Focus area, right? Yeah. Does that make sense? Exactly. Yeah. So it’s not like I’m expecting you to know everything about everything I’m expecting to know everything within the small domain that your squad is focused on. Anyway Meg had a question for you. Do you have any advice about virtual team building?

As far as the interactions that aren’t directly work related with remote work, you can’t pop out to lunch with a coworker, run into someone in the hallway, have a quick chat. What, if anything, would you do to replace that?

Jessica Cregg: That can be, oh it’s so frustrating because nothing can be spontaneous anymore, which is great in a way.

But but yeah, you need to. The way that I’ve started to comp to, to design for that is I’ve started [00:28:00] creating a bunch of coffees and reg like regular, like 15 minute meetings of people that I otherwise wouldn’t usually work with. And repeating them by a weird on a weird cadence.

So they’ll happen like once every three weeks and once every two weeks or. Them up a little bit. And that way you can try to mimic spontaneity. Yeah, it’s a difficult one. Have you how have you made it work, Ryan? Oh,

Brian Rinaldi: it’s hard. I, this I’m a terrible person to answer this question because I’ve been remote for well over a decade.

So I often have, I’ve had jobs where I’m really just. Interacting, mostly with chat, via chat with people. . But I do feel like like things have things changed with the whole pandemic and people moving more remote and cuz even then back then I was remote, but I could go into the office and everybody was there and I may show up every once in while.

Whereas now it’s. You go to the office and there may be a handful of people there, and you may [00:29:00] not ever really get to interact that way with people that you have to work with on the team. I do think like we have the virtual coffees that, for teams as well as like larger groups that are great ways to get to know people outside of the, the scope of what you’re working on and.

Those conversations, I think are important to the general productivity of the team because one of the things the pandemic at least taught me in terms of how people work is, cuz I, while I’ve been remote, I never worked for companies where I never met anybody. Like I never actually in personally interacted with a single person on the comp at the company.

And it turns out that you have very little attachment to people who you. Haven’t really gotten to know on a personal level. So if you’re just there working on tasks all the time, you really okay I it’s hard to form an attachment to the company and to the people and the people’s really what, honestly, you end up staying, at least for me, that’s what you [00:30:00] stay for.

You stay for the people, you may like the company, but you stay for.

Jessica Cregg: Definitely. Definitely you can use a bunch of tools like donut, and like integrations to try to mimic those. Like how often you’d see those people that you would form better connections with.

But I think part of it is like you have to have a tolerance for it to be forced. At the start, like a lot of what I’m I went over in the presentation. A lot of it is about overcommunication in the first instance, and that can feel really awkward and it can feel like you’re stating the obvious and it can feel like you are being really clunky at first, but you need to be able to get over that hurdle to be able to create patterns that people recognize.

Yeah.

Brian Rinaldi: Yeah, I agree. And when I bring up Meg, who I asked the question earlier mentioned, and I think this is also important, like having connections, even outside of work, like she talked about virtual coffee, which is another group that just brings a bunch of work developers together just to chat[00:31:00] And, and I think it’s good, cuz you can talk about some of the issues you’re facing and maybe some of the problems even technical or work related or just those, I think now more than ever less and the things are all very good.

JJ Thornton had a question. I said, he says, I work for myself and I’m nervous about employing someone as the person that I employ will have significant impact on di on the dynamics of my work. Give my own personality quirks. Have you any recommendations on filtering people based on my own character flaws so that I may be able to avoid discomfort in the long term.

Wow. Okay. That’s an interesting question. That’s hard. Knowing your own limitations and trying to form a team that will be successful around it.

Jessica Cregg: Yeah. I don’t, I, to be honest, I don’t think you can, there are, there’s a reason why we, there’s a reason why we [00:32:00] can’t get out of our own way. There’s a reason why we go to other people to check things that we become like code blind to. I think it’s really easy to I think you do need to solicit someone else’s help in these kind of scenarios, because they’re gonna be able to probably give you the advice that you, it would take you years to.

To stumble across yourself.

Brian Rinaldi: I think if I understand you correctly, I think that’s a great idea. It’s not, you have to interview them, you have to like, get to know them to see if you’re gonna work together well, but maybe get somebody else who knows you. Is that what that’s?

I’m assuming that yeah. Yeah. You get somebody else who knows you to also interview them, even if they don’t work for you, just be like, I need third party’s advice on who, who knows me and knows how to work with me. On whether this person would be a good fit that’s yeah. That’s great advice.

I think that’s really good advice, especially cuz you’re small and it’s you, it can be hard to make that judgment on your own, right?

Jessica Cregg: Definitely. Yeah. It can feel like it must feel like such [00:33:00] like a, like an important decision if you’re going to be spending so much time and so much, that’s your right hand person.

Brian Rinaldi: Yeah. Can be difficult. There’s this is not a question per se, but I guess if you would you like a copy? The speaker deck option goes away. If you select the required, where did we meet? So yeah yeah, glitch on the page.

Jessica Cregg: Oh, no. Okay. Tweet us and then I’ll get you like a PDF version.

We’ll sort it out, but

Brian Rinaldi: yeah. You’ve got so get your socks and then we’ll share the deck out. Yeah. Yeah. That’s good. But yeah, you can flip or go in and launch argument, flip the flag to change it.

Jessica Cregg: Yeah. Sneak in.

Brian Rinaldi: Yeah. I think that’s all of this was really great advice. I think, it’s can be difficult, especially like remote teams. And like I said, being able to judge, like who, who works better, like having that flexibility that you talked about, I think is super important because when you’re in an office, [00:34:00] some of that stuff works itself out naturally, whereas.

when everybody’s remote and on different schedules and this and that you need it. Some of it has to be forced, right?

Jessica Cregg: Yeah, exactly. And yeah, we need to. We need to see a pattern to be able to expect it. It’s really difficult talking about teams in this way because everything feels so everything’s so abstract.

, and it’s so much easier when you’re talking about a specific project and a specific, we built this thing and here’s how we work together on building it. And speaking in all these anonymized terms can feel really conceptual and tricky and theoretical, but But the advice comes down to the same sort of, so the scenarios all seem to expose the same sort of issues that we need to be able to define our interactions and know how we’re going to see information and know who we’re going to be able to speak to.

And that only comes from overcommunicating in the first instance. And then we. Just hopefully rely on really [00:35:00] robust systems.

Brian Rinaldi: Yep. Yep. Our play league of legends together, ,

Play league of legends together.

Jessica Cregg: Have you been playing any gig games recently? You’re a halo fan from what I can remember, right?

Brian Rinaldi: Yeah. Halo, destiny. Yeah. Apex legends. Hey, not really apex legends a little bit more of a team based thing. But yeah, not, I don’t, I’ve never played league of legends. So it was like, I don’t know that I know the how that applies. You know what I mean? Like I’ve, I don’t know the interactions on league of legends, so I don’t know how people.

Collaborate, but I get the analogy made sense, but I also I don’t know the game. Yeah.

Jessica Cregg: I think I need, I think it would be a better, I think something like Overwatch or like team Fort or something where that you have really specific different characters that you jump into is a much better.

Yeah. Analogy. So I dunno if anyone has any really good like video game studies that they found. Hit me up. This [00:36:00] has just become a recent obsession of mine. So

Brian Rinaldi: all right, Jess.