Latest / Complexity Cogitators Podcast / #013 - Team Cognitive Load
Transcript
- Joakim von Prónay: Is team cognitive load something you should actively manage for? Is it an organizational design criteria worth optimizing for? Recently, this concept awoke some old grievances of mine. So that is what we are talking about today on complexity cogitators. My name is Joakim van Bronij and together with Marco Ahumada-Juntunen, we try to make sense of organizational behavior. Michael. Marco: Your game Joakim von Prónay: Good to see you, how are you? Marco: I'm very good. I just realized we're doing kind of an inverse Pokemon thing where we say each other's names instead of our own. Maybe we should switch it up next time. Joakim von Prónay: Maybe, but routines and what do you call it? Rituals is important. Marco: you're right. I think we should stick to that ritual. Joakim von Prónay: Yeah, I think so too. In the summer heat that has hit us, one thing that has been occupying my mind for a couple of weeks now is the idea or the concept of team cognitive load. Because I saw, I think I was watching a talk and team cognitive load was just mentioned in passing. Essentially, I was not the main topic of this talk, but it was mentioned and It didn't bother me per se, but it awoke some old grievances I have. And I would like to maybe both air my grievances and then perhaps be challenged to see if I have a too narrow view or what my problem is essentially with the T-cognitive load as a concept. Marco: Yeah, I like that. Grievances. That makes for a spicy premise. Joakim von Prónay: Good, good, good, good. But maybe just to paint the picture. Team Cognitive Load, very broadly speaking, I'm no expert on it. So maybe that's why I have grievances with it. I have dismissed it as a concept based on my own experience. And then I haven't dug into it deep enough, perhaps. But Team Cognitive Load is essentially... the idea of limiting the scope of an engineering team or a team in general, so they can focus on the work or the tasks that are most important to fulfilling their mission essentially. And just a quick... name dropping of some theories that is included in the concept of team cognitive load is cognitive load theory, cognitive overload theory, information overload theory, capacity theory of attention, resource allocation theory, and attentional control theory. So these six are the main ones that are kind of baked into this. And I'll read one thing One practical thing that is supported by these six theories is that the premise that the teams have a real finite cognitive budget. And when the budget is spent on unclear roles, excessive context wishing, poor tooling, information overload, or anxiety inducing environments, there is less left for the teams actual problem solving and innovation. I mean, I think that sentence or those two sentences most can... nod and agree with. That sounds reasonable. Well, let me challenge the last sentence there. If you have all of those problems... If you have excessive context switching, you have an anxiety inducing environment, you have unclear roles, poor tooling, then focusing specifically on team cognitive load is not addressing the fundamental problems in the organization. I think this is one of my grievances. Yeah, it might be a useful theory, a useful concept as a lens to view the organization. But if you specifically go in to try to address team cognitive load, then I believe you are looking in the wrong toolbox to solve the fundamental underlying problems. think that's okay. So that's a little bit of an overview and maybe one of the main, the starting point of my grievances. But what is your, what is your take? Marco: Well, my exposure to cognitive load theory is more or less that which my influences are from the book Team Topologies, which I think according to the mapping you provided maps to cognitive cognitive load theory. Yeah mm and and it's more or less only that that I have in my toolbox. So whenever co the conversation about cognitive load comes up, that's the that's the framework I reach for to understand it. Joakim von Prónay: Yep, I hear you. Marco: And generally from a a software development team perspective. Joakim von Prónay: Yeah, so those are the main organizational contexts that I have been in as well, technology and software development, Marco: but I mean it what I mean by that is it's probably applicable to other kinds of roles and categories of professionals in the in in the same industry, it's just that I've applied them How to organize for software development teams in particular. Not necessarily leadership teams and that kind of stuff. Joakim von Prónay: to also continue my grievances or my criticism to this as a concept, as for practical implementation purposes in organizations and in teams. One of the anti-patterns I've seen when these things have been on the organization's mind and they have been tried to be addressed, sometimes through team topologies, sometimes through other frameworks and other means, is that essentially the management teams or the manager layers of the organization connected to the teams that than actually have to be creative and innovative and solve difficult problems. It turns into some sort of dysfunctional paternalism, where they remove context from the team in the name of reducing cognitive load. So you make decisions on behalf of the team and say, you don't need to know this because your job is this other thing. So there was already a judgment in there by someone else on behalf of you. So you don't have to be included in it or be bothered with making that judgment yourself. that's the main implementation. Marco: Mm. Joakim von Prónay: I have seen of it in my experience. Marco: And this paternalism, does it sometimes because I'm trying to put it into my own contexts? does it sometimes look more like not separating them from context but telling them what it is? So instead of you go figure out what the business context is for this problem, I have instead chosen to define it for you. So here are the requirements, here are the so something like that. Okay. Joakim von Prónay: Yeah, I've seen both. I've seen both, but Marco: Mm-hmm. Joakim von Prónay: yes, absolutely. It's like you don't have to be bothered by doing this work or understanding this. Here is a spec sheet for you. Mm. Marco: So I've lowered your cognitive load by removing this problem space from your scope so you can focus on your other things. Okay. Joakim von Prónay: Yeah, exactly. Exactly. And take into an extreme, you will be handed a checklist that you just do one task after the other. Like it's in that direction, essentially. Marco: Right. Joakim von Prónay: And here then, from the few teams, the few engineering teams that I have seen over the past decade that I would deem high performing that I have worked with. this is not an issue. Like you don't have to tell them what's relevant to them or not. You just have to include them and make them aware of everything that's going on. And they are perfectly fine to make the judgment themselves. And mature teams and high performing teams, they know what their task is. They know what their mission is. They have enough understanding of the context to be able to say, this is not relevant to us. Marco: Mm-hmm. Joakim von Prónay: And if they're not sure, they won't invest the full team's time to go and figure it out. They will send one person to say, maybe you can join that. And then you can see if it's relevant to us. If not, it's not. If it is good, then we invest further. Marco: So this makes me think about there being two different axes of the cognitive load thing. I I feel like the the the the part that you're talking about, let's call it verticality. So how deep into your business context does a team need to be informed or able to inform itself to make decisions about how it solves business problems, right? So If there's a management layer isolating the team from the business context and from the data and from well reality in that sense, then that's kind of a a vertical cut. Like i it's an organizational design limited to sort of reduce the verticality of the competitive load. And so yeah, I agree that's kind of a pert paternalistic protection of the team's attention. Joakim von Prónay: And what would be a horizontal axis? What would the horizontal axis represent? Marco: Well, the more focused on a certain domain or category of business problems, let's say that we have a payments team. If they can only work with payments, that's a horizontal sort of definition of the scope. but how much do you need to know about how payments are made? How much do you need to know about PSPs and whatnot? So that's the context of the business problems that they're solving. But as soon as we say, okay payments team. You're now also going to b be working with I don't know. developing the search function of this application. So you're the sales and search because that sounds fun to say, but suddenly we have this horizontal drift in a whole new set of business problems to understand. Joakim von Prónay: Mm. Marco: and suddenly that verticality starts looking very expensive because Yeah, you're gonna have to be concerned with a whole lot of different problem domains. because those two domains are so different, there's probably very little overlap, maybe in a technical point of view, but the business problems might be different enough that you need to learn a whole new set of concepts and probably a whole new set of stakeholders because there's different people interested around that and that will thrash your attention. Joakim von Prónay: But isn't that just a problem of scale? size of the organization, size of the product. Marco: Mm-hmm. Yeah. I mean Joakim von Prónay: Because I'm, I'm agreeing with what you're saying, but I also see that as, I mean, a a startup with a small product just starting out. The tech team is one person on top of everything. And then once you scale, need different organizational paradigms and structures and processes. Marco: Yeah. So then one way of looking at it is okay, so we have this one team doing all of the techy stuff. How much do they need to know and how do we make sure that they have that knowledge? Some organizations solve it by integrating the business understanding into the operations of that team. so they have a more direct access from that group. Other organizations might say that I am the important hippo. I talk to all of our customers and then I will let you know what their customers say and you just implement on that so then you have this kind of vertical split of of concerns. Take that far enough and you get This classical split between thinkers and doers of the business and IT. Joakim von Prónay: Yeah, I hear you. hear you. Marco: I don't think it's only a a question of scale. I mean, for some organizations it seems to be a question of economics. So these this these are this is the size of the development organization we have decided to afford. which means that some of these poor teams need to be solving very different problems. So some of these organizations don't have a product but a a different flora of products or systems to support the the business in in different ways. So some observations in my travels is teams that have a set of disparate, very set of systems that solve different problems, sometimes with the same technology and that's why they're bundled into the same group. but they don't form a coherent mass of business process support. Joakim von Prónay: I'm thinking here. all of these things and all of these challenges. Is team cognitive load a useful enough concept to use when identifying and designing essentially designing for reducing team cognitive load? And I'm at a point at this point in the conversation and historically as well, my opinion is no, I don't see how it adds anything uniquely valuable. that is not covered by looking at the same fundamental problems from different angles. essentially that then by accident will solve for team cognitive load anyway. So I think that's my main grievance. Marco: Mm-hmm. Joakim von Prónay: in this context, of course. Marco: I'm about to pr in this context, sure. So I'm about to produce a tick of some let's see you let me know the temperature of it and then let's see if I after our conversation I will be ready to still stand behind it. Joakim von Prónay: Well, in the current recording studio I'm in, it's 31 degrees. So that's the temperature. Marco: Well, let's see if we can raise it. Joakim von Prónay: Please, please no. Marco: No. So the take then. Having a cognitive load as an organisational design goal is about as useful as having agility as an organisational design goal. Because the list that you had before, and let's see if if I how are right I get it, but excessive context switching, poor tooling, information overload and anxiety inducing environments, yeah. All of those I would say are symptoms that make cognitive load harder. So you're not actually targeting Joakim von Prónay: environments. Marco: Cognitive load per se when you're working with it, you should be talking about how do we work with these things instead, because their impact on the cognitive load of this development team is negative. But you don't start with the question of how do we measure cognitive load and lower that. It's nice to have the right kind of load for the team and the right kind of expectations and understanding of their context. and those things might be easier to have you give them a a broader set of responsibilities if the stuff around them work better, if you're better organized around the team. So I would say the goal should rarely be to work with it directly, but it does offer an interesting lens for symptoms. Joakim von Prónay: Yeah, this I can agree with. so maybe this has been, I'm just speculating now, but maybe this has been why I have been skeptical of it in the past, when the different people I've been working with has talked about it as a goal in itself. Marco: there's some heuristics for Joakim von Prónay: Maybe. or hindsight bias. Marco: Yeah, possibly. But that being said, I've often made the the observation or my diagnosis of a context is that this team is cognitively overloaded. Joakim von Prónay: Yeah, no, I like that because as you said, it's another interesting lens to use when you identify symptoms. And that I can agree with. Marco: But my experience, given that is organizations are rarely aware the way they design teams because that's that's the thing you do right you you choose a set of competencies and you give them a responsibility and then you shape how they understand that is kind of organizational design especially if they're not empowered to do that themselves through a sub-selection I wish organizations would be more aware of these things because it especially when it comes to like the horizontal versus the vertical aspects of Responsibilities or missioning, Joakim von Prónay: Yep, yep, yep. Marco: But take take me back to that talk. Can you remember what triggered you or sort of threw you into these thoughts? Joakim von Prónay: No, was just a mention of designing organizations for Flow. Marco: Hm, by Susan Kaiser, right? Joakim von Prónay: Yes, exactly. And in that, using different theories and different models and different tools to design organization for architecture for flow, is what she talks about. Yeah. So essentially it is about organizational design and looking at the processes and how they work together and how everything integrates. in that, she just mentions team cognitive load as a passing by thing. Marco: Yeah, that's the title. Alright, yeah, this is the book where team topologies meet worldly mapping meets what was the last part? domain-driven design. So how to sort of tie those things together for organizational design purposes. Joakim von Prónay: Yes, exactly. Yes, exactly. full with very interesting texts. nothing, no criticism towards that at all. But it was just the team cognitive load really just awoken old, as I said, my old grievances. Marco: Right, and I see that probably came up in the sort of theme topology section and the main dream. Yeah. Joakim von Prónay: Yep. Exactly. Marco: So what what would be some effective strategies Suppose that we design an organization or we were in a situation where we've observed this, how would we what would be an approach to to work with or understand these things? Joakim von Prónay: I like the picture you painted earlier about the vertical and the horizontal axis. That to me, the picture that appeared in my head when you talked about the vertical and the horizontal, essentially integration or area of responsibility for the team's products or the team services. That kind of just put me into the business context. What is the business context that this team and this team's products are operating within? it somehow also connected with or went hand in hand with a team's circle of influence. So essentially can you map the vertical and horizontal circle of influence? Well a circle is a circle, maybe has both vertical and horizontal. A three-dimensional circle would be a ball. But essentially, you draw the picture of where your circle of influence and perhaps where your business integration, what that looks like? Because that would as a starting point, that would give you a good picture of, where do we need to be included and informed and how much would we need to be aware of? Marco: Or as Joakim von Prónay: That was just the thing that came to mind. Marco: One thing that came to my mind, I'm surely you surely you've seen the J John Cutler's old infographic. I think it's probably ten years old or something by now. different line different rows of I don't know what to call them, team maturities. where the highest row is like a set of handover columns, so from opportunity selection to requirement planning design and so on until deployment and and running out into the world. And then gradually moving down and and this team boundary expands more and more over these columns until the bottom one which is called the product team that is responsible for everything from opportunity selection to running it so that's like the full full vertical So that's what I I was thinking. Joakim von Prónay: Yeah, no, it rings a bell when you mentioned it. Yes. And I can also imagine what that image looks like. But what would be interesting then is that from a maybe a one dimensional, two dimensional view on team cognitive load here, the product team in this example would be essentially overloaded. Or the question would rather be to turn it around. How would you then reduce or manage a product team's cognitive load. I mean, I'm nodding and saying that is of course possible. Marco: Well, I think if we look at the two directions from if we imagine the middle of this spectrum to be writing the code, since we're talking about software development teams, traditionally that activity has been isolated from the thinkers of the business side, defining the business problems, producing requirements and pressing them into the team. One strategy of doing that is actually empowering the product manager to go out and understand the business themselves without middle hands and actually having the mandate to choose opportunities, right? So a kind of business perspective autonomy for the team. And the lower end of that is bel below writing the code is actually running it and keeping it running and understanding it. So this is where DevOps ideas come in. So how do we empower the teams to operate their stuff without being dependent on other parts of the organizations without also being overwhelmed of having to understand the hardware and all the levels up until whatever is running the code and how to get the code running. So If we assume that perspective then it's a combination of how do we rem reduce the I think the word is the germane cognitive load. No. This is the extraneous cognitive load Which is all the the stuff that you need to do to just get your work out into the world and make it run. Sort of hyper simplified. I think that's one key part of the puzzle. But this also completely ignores the conversations about the social system that this activity takes place in. That also requires cognitive load. And this is where we get to like the team relations, safety aspects. if they're worried about Well, what would what are they going to say about my review? then that's also something that you're spending your cognitive capacity on that's not You know, strictly productive. Joakim von Prónay: Yeah, absolutely. And I think once, once more, poor efforts I have experienced have essentially tried to limit. cross team interaction or inter team interaction. Marco: Mm. Joakim von Prónay: the purpose of, no, you should just focus on your own things. but that's an important part. You never know what you will learn tomorrow and who will plant an incredibly important idea in you. Marco: But the thing is that is a strategy to reduce cognitive load if that's what you're looking to do, but it has the the negative effects of reducing that team's ability to adapt to reality because it's dependent on some central centralized information organ or whatever to make decisions. So if you're looking to use another buzzword then Agility is if you're looking to have an agile organization or an adaptive one, then that is probably not the move to make. Joakim von Prónay: No, probably not. I think once again, as you said, managing for low team cognitive load is as useful as trying to achieve agility as a goal in itself. It should guide you on the way of some sort of positive benefits or, or desirable outcome. And I. always try to argue for. We start with outcomes and then we move backwards. Marco: Nice. So it seems my take remains standing. Joakim von Prónay: I believe your take remains standing. I think I have also been challenged enough that I'm ready let go of some of my grievances and loosen up my negative view on cognitive load as a concept. Marco: It's always nice. Joakim von Prónay: And as you said, it's a useful lens to try to understand symptoms, but it's not a goal in itself. which is probably what I have experienced in the past when people try to use it as a goal. Marco: Nice. That might be a good place to end the episode, I feel. Joakim von Prónay: I think so. I have the same feeling. Marco: Then let's leave it at that. And just and I shall wish you an an excellent and slightly cooler weekend. Are we going on a summer break now? Joakim von Prónay: Let's leave it at that. Okay, cool. Marco, thank you for the conversation. Marco: Nice. Thank you, a pleasure as always. Till next time. Joakim von Prónay: Until next time. Thank you for listening to the whole episode. If you enjoyed the conversation, please consider leaving a review and sharing the episode with at least one other person who you believe will also enjoy it. It truly helps us reach more people. And if you don't follow us already, please consider subscribing to our Substack on complexitycogitators.substack.com. And if you have a topic that you want us to talk about, drop us a message. We are more than happy to receive suggestions. Bye for now.