Avoiding Burnout and Overload Using Cognitive Systems Engineering

Transcript

Shane Hastie: Good day folks, this is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Dr. Laura Maguire. Laura is a specialist in cognitive systems engineering. Laura, welcome. Thanks for taking the time to talk to us today.

Dr. Laura Maguire: Thank you, Shane, for having me.

Shane Hastie: My normal starting point is who's Laura?

Introductions [00:24]

Dr. Laura Maguire: Well, I am a cognitive systems engineer, which is a fancy way of saying I look at how people think at work and I look at the challenging and often hidden aspects of how we operate in complex, fast-moving, uncertain, time-pressured work environments. And as a cognitive systems engineers, I am very interested in understanding all aspects of both the physical environment that we operate in, the tools and the automation that we work with and how that can either help or hinder our ability to perceive the world around us, and to reason about what those kinds of changes that we're seeing, what that might actually mean for our goals and our priorities. And typically, cognitive systems engineers use all of this research and use all of this data to design better toolings and better work systems. And that can include things like procedures and practices as well as the design of teams, team structures, and task sequencing as well.

Shane Hastie: That almost sounds, dare I say, slightly mechanical. I’m biased and making assumptions, I was expecting to hear psychological safety and all of that, but no, you're talking about processes, procedures, physical design. How do those all swing in together?

Explaining cognitive systems engineering [01:51]

Dr. Laura Maguire: So it's both the physical and the cognitive world. So a lot of software design, interface design, interaction design is a part of what we do, but we think about the human situated at work. And so, you and I both live in a physical environment. We interact with our software and with our computers in a physical environment. So that's going to be a big part of how do we design work systems that allow people to interact and to function at the highest level. Where a lot of cognitive systems engineering came out of was looking at high-risk, high-consequence type work environments, so these are places where the consequences of human error or of confusion or mistakes getting made, they're quite high. There's the loss of very expensive assets like the International Space Station. There's the potential for environmental degradation, like perhaps on an offshore oil rig, or there's the potential for catastrophic loss of life. A pilot in a cockpit carrying four or 500 passengers.

And so this history of how we look at work and how we handle and treat the cognitive aspects, the thinking aspects, the sense-making parts of work have carried through to the current applications of cognitive systems engineering, which is looking at all kinds of high-value work. And so I include software engineering in high-value work, in the sense that software engineers are responsible for building, maintaining and operating some of society's critical digital infrastructure. And even if it's not operating at that level, it is still services and software systems that we rely on for our comfort and for smooth collaboration and coordination, and those things are really important as well.

Shane Hastie: I was almost seeing, I suppose, two layers there. There's the cognitive load on our engineers building the products, but also the products that they build going out into the world.

Dr. Laura Maguire: Yes, absolutely. So an example of what you're describing there is something like an infusion pump in a hospital setting for a healthcare provider. That is a physical piece of equipment that is carrying out very important life-critical functions, but the software that's involved there has to be kind of human and machine interaction happening there. And the way that that software is designed can either can confuse the operator or it can help the operator very quickly make sense of is this normal operating conditions? Is the task that I'm carrying out being done appropriately? Or is there something wrong and do I need to correct there? And so this thinking about the world in a very integrated way helps us to minimize the amount of error that takes place when we are working with technology mediated work.

Shane Hastie: You mentioned you've been doing some interesting research. Do tell.

Research into incident response and incident management in software service delivery [04:58]

Dr. Laura Maguire: Yes, so much of my work over the last six years has been looking at incident response and incident management in software service delivery. And so a lot of what I've been looking at there is how do software engineers typically notice that there is a problem within the system? And we have observability, we have dashboards, we have a lot of tooling that helps us to see anomalous or unexpected events within the system. And then we use a variety of sources to make sense of that and to think about what are our goals and priorities here? Do I know exactly what's going on, and so I need to act very quickly to be able to repair a service like a performance degradation or a service outage? Or is this something that I'm not sure about, and so I'm going to gather some more information, maybe let the service be degraded for a little bit longer so that I can understand what's happening?

And the reason why this is such an interesting area to study for cognitive systems engineers is that most large-scale software systems these days are continuously changing. They are very complex and adaptive in and of themselves, and so the amount of cognitive work that it takes and the types of cognitive work that it takes to maintain these systems gives us a lot of insight into how do people in other domains, other occupations reason about operating in these same kinds of complex systems. Because at the end of the day, software engineers are people. They have similar kinds of cognitive processes that you might see in some of those other kind of high risk, high consequence domains that I was describing.

And one of the things that I noticed over the last year in particular is the ways in which the stress and uncertainty and the volatility of what's been happening within the tech industry, how that's starting to influence and impact cognitive work, particularly how it affects attention, how it affects our ability to communicate and collaborate when there is fear about losing a job, when there is uncertainty about when the next round of layoffs might be coming in, and when there's been a lot of emotions after a layoff or after a big reorg or restructuring. This can make it really hard for people to concentrate at work and to feel safe at work as well. And so this new approach that I've been thinking about is how do we take some of these same kinds of models and these same kinds of methods that we use to understand cognitive demands and how work can get very challenging and what overload means from a cognitive perspective and can we apply that to these very emotionally demanding times? And it turns out that you can.

Shane Hastie: What does that look like?

Voices from the research [08:00]

Dr. Laura Maguire: So there's three main concepts from the field of cognitive systems engineering that really apply here. And the first one is around identifying boundary conditions. And when I was doing some of this research and I was talking to software engineers, they started telling me the ways in which things were impacting them. And if you don't mind, I would love to share some of that with you-

Shane Hastie: Please.

Dr. Laura Maguire: ... because I think they explain it a lot better than I could.

How am I feeling? It feels like now it's just a matter of time. And even though I was relieved I wasn't laid off, I got scared. I know there's more layoffs coming and now I wake up every day wondering if today's my day to get cut.

So a lot of fear there. And another engineer that I spoke with talked about the pressure that she felt to stay at work and be at work, even though she recognized she needed a break.

Honestly, I just want to be able to take a few consecutive days off at a time this summer with without feeling like I am totally screwing my team over or having to work twice as much before or after and not have everything fall totally behind on the project. I know that it doesn't all rest on me and I trust my team, but I also just feel this huge responsibility that I'm letting them down if I'm not always there, and I can't keep that up forever. I know that I need to take the time off and if I don't do it's actually going to hurt us in the long run, but even a single day feels nearly impossible right now.

Another theme that started to come up was the strategies that people are using to typically manage with very stressful circumstances. They weren't really having the same effect.

I do feel okay most of the time, but I've been spending time with my friends, the friends that have also been laid off or also are struggling with anxiety. I know this is part of a larger cycle and it's supposed to end sometime soon, but unfortunately it's everywhere. Everywhere I look, like LinkedIn, Twitter, most of the media, everyone's reporting it, and it feels like it's affecting everyone everywhere almost.

What I started to notice from these interviews and from talking with different folks, that there was a very real impact. The emotional demands of the current environment was having a real cognitive impact on their ability to concentrate, their ability to focus attention, their ability to rest and recharge, to deal with the pressures of trying to do more with less in the current climate. And I think this is a very common feeling right now within the industry. And so I was looking at some of the strategies and some of the models that we use within cognitive systems engineering and thought this actually can be adapted to understand the emotional demands as well.

Pushing against the boundaries of stress and pressure [11:34]

The first strategy that I think is relevant here is a Danish researcher named Jens Rasmussen proposed this model for how we think about risk and how we think risk is managed over time, and he proposed this idea that we all operate within a trade space. And the boundaries of that trade space is things like cost and schedule, time and money are hard constraints that we have in the world. And then he proposed that the third boundary there was what he calls the line of technical failure, and what I see as our ability to cope. It's our line of emotional failure. And what Rasmussen said is that we constantly have these pressures within modern work environments to then save time, save money, and so that exerts these pressures in this trade space and has you move closer to your own boundary, your own emotional coping boundary. And obviously crossing those boundaries is not a good thing, and so we often put in place countermeasures to keep us away from those boundary conditions.

And so the countermeasures for things like going over budget or over time is project check-ins, it's work estimating. And those help us to understand where we are operating in that trade space. But when it comes to our emotional capabilities, like we heard in those examples, the countermeasures that we have, taking PTO, spending time with friends and family, being able to rest and recharge, those may not have the same effects. And so we're constantly moving closer towards the boundary. And so the trouble with boundary conditions is that when we're operating in normal conditions, these are typically well modeled. We understand the performance of the system within normal operating conditions, but the closer we get to the boundary, the less predictable it is, so we don't know what impact the way a failure is going to happen, and we don't know what impact that's going to have on the rest of the system.

An example of this is when you start to hear people say, "Oh, I'm operating pretty close to the edge here," or, "I'm getting pushed to my limit," these are examples and these are indications that people are operating in their emotional boundary condition. Is that something that you've experienced in your career over the time, Shane?

Shane Hastie: Oh, yes. I was just thinking, this sounds to me a bit like what we would call burnout.

Dr. Laura Maguire: Yes, absolutely. So one of the things that I think is really great about this model for helping us to try and understand when we're in these emotional boundary conditions is it gives us the sense of understanding when we're in a drift to the boundary. And so we all have this abstract idea of, "Oh, I'm under pressure," but we can start to look for and recognize signals that we might be getting closer to our boundary. So an example of some of those for me is when I start pouring myself a cup of coffee in the morning and setting it down and then completely losing it in the two minutes between when I've poured it and when I've actually sat down at my desk. It is I forget appointments more readily, I am a little bit more irritable, I'm late for things or projects start to get... I feel a lot of pressure to get them produced.

And so when I start to notice these signals, I can recognize I'm close to the boundary and it's less predictable. If I start to have one or two more unexpected events that show up, which when we're doing faster, better, cheaper, there's typically surprises, then I may not be able to control or to manage for those events the same way I would under other kinds of normal operating conditions. So when I'm in these boundary conditions, I can start to say, "Hey, it's actually really important for my overall performance or the stability of the system, the continuity of the work that my team is producing, that I'm able to push myself back away from that boundary." Can you think of examples from your past work where you've been in these boundary conditions?

Shane Hastie: Oh, yes. I think of one in particular where I know I went way over the boundary condition. I ended up absolutely burned out and had to change jobs.

Crossing the boundary into burnout [16:11]

Dr. Laura Maguire: Yes. So that is a really excellent point, because what happens when you cross the boundary is it's not clear whether you're going to have a collapse like you just described, which is, "I cannot function in this environment anymore," or whether you're going to have graceful degradation, or whether you're going to have potentially what cognitive systems engineer David Woods says graceful extensibility. So before we talk a little bit about that, I just want to acknowledge what you were saying there, is that getting pushed into the boundary conditions can often feel like we have no other choices, we can't take time off. As we heard some of those engineers say, we start to feel like, oh, if I'm not pushing myself, the rest of my team is going to suffer around this.

But this is really where I think having this language about being in the boundary conditions and starting to try and recognize these signals, not only for ourselves but for the people that we're working with, can help us to try and change some of that conversation because it implies that crossing that boundary is potentially imminent and that that is a signal that we may have collapsed. And if you have people collapsing and removing themselves, as you had to, from the work environment, then overall the whole performance of the system declines.

Shane Hastie: What can one do as the individual, but also what can leaders do?

Resilient teams manage load and support each other [17:44]

Dr. Laura Maguire: Before I get to what leaders can do, I want to talk a little bit about what the team can do together because as a system engineer, I say, "Yeah, we shouldn't focus on the individual. We shouldn't put this on an already stressed-out and overworked worker to say, well, you just have to be more vigilant about how you're doing and you have to push back." We usually say, "No, no, let's go to the system," and that is typically leadership who has more power, more authority, more ability to influence at a systemic level so that individuals aren't having to push themselves so hard. However, given the current climate, we know that there are also some real hard constraints around how work has to get done in this moment. There's a lot of pressure for many startups, many young companies. For all companies, there's an economic pressure that's very real.

But I want to talk a little bit about this idea of sharing adaptive capacity, which is a really strong principle of resilience engineering, cognitive systems engineering. And effectively, sharing adaptive capacity is thinking about how do we think about the actual capabilities of the system as a whole, not as a collection of individuals per se? Because when we think about ourselves as a collection of individuals, if I'm not doing okay one day and you're actually feeling okay that day, then maybe we can lighten my load a little bit or you're able to support me to bring me back up a little bit more without it taking away from your capacity, your resources in that moment. And so if we start to think about this across a whole team, that people are going to have good days and bad days, and if we can share that, then we can level out this performance variability across the team a little bit more.

And so this idea of sharing adaptive capacity, adaptive capacity, Woods would describe this as being a systems readiness or its potential to change how the system currently fits so that it can continue to fit changing surprises, anomalies and situations. And so effectively what this means is if I'm not having a great day and you're having an okay day, can we adjust in that smaller timeframe? It's not you taking over my job, but it's helping each other on a more micro level so that we can smooth out that performance curve. And one of the things that is quite useful about this idea of sharing adaptive capacity is thinking about how it is that we typically work together and whether those are functional versus dysfunctional patterns.

And so typical patterns, when people reach a saturation point, this is what we see from the literature, is they cope with it in four different ways, and I'll add a fifth one. But the four ways are they'll either drop the tasks because they're too overloaded, and so dropping the tasks means someone else on the team is going to have to scramble to pick it up because they have had no indication that this is going to happen and the work still needs to get done so someone's got to pick it up. They're going to defer it in time. So they'll say, "Can we do this at a later point in time?" Which is usually quite an effective coping strategy if I as an individual and communicating and coordinating with the people around me, particularly when there's work that's very tightly sequenced or highly interdependent.

They will degrade the quality of the work, and so they'll just do not as great a job on it, or they'll delegate it. They'll recruit some other resources to try and bring it in. And so those can be both functional and dysfunctional patterns depending on how much communication and coordination is happening across the system. And so the more that we can talk about, "Hey, I'm in my boundary conditions right now," or, "I'm on a pretty fast drift towards my boundary, I'm going to need to deploy one of these strategies," it gives us language and gives us the ability to ask for capacity from our team members or from our leaders as well.

I mentioned the fifth coping strategy, and that one is one that I find myself employing an awful lot and it doesn't always work very well for me, and that's digging in. And that's typically gritting your teeth and dropping your shoulder and just really pushing into the work. And as you described earlier with your example from your work, that only lasts for so long, and so we have to be thinking about these other kinds of strategies that we can use that are overall better for the system performance.

Shane Hastie: So this means that on the team we've got to really focus on that communication, having the language, but then genuinely listening to each other and supporting each other, and possibly proactively asking each other, "How are you doing?"

Communicating our condition to fellow team members [22:49]

Dr. Laura Maguire: Yes, absolutely. So you're bringing up a really good point there, which is the earlier the indication that there is a problem, that we're in a drift, the more range of strategies that we have or the more options we have for how to cope with that. But it's also really hard to say, "I'm not doing okay." And we also think about ourselves as being like, "Okay, well I can get through this. I just need to buckle down and keep pushing." But that often doesn't work as well as being able to say, "I'm having a bit of a day today. These are the things I'm going to be working on, but I know I'm distracted or I'm preoccupied, or I'm feeling the effects of accumulated fatigue from not having time off, and so I just kind of want to let you know that I'm in that zone."

Some teams will use their Slack icons to be able to say, "I'm in yellow, or I'm in red today," as a little bit of a flag to tell others that they're not doing that well. But to your point, communicating and being a little bit more explicit to the extent that we're comfortable doing and saying, "I think this might be one or two days where I'm going to have degraded," and I'll say, "performance," because we are people, not just performance machines. But being able to talk a little bit about what some of the pressures and the demands that we're experiencing are helps us to reorganize that work across the team a little bit more readily.

Leadership can support dynamic reconfiguration [24:21]

So the third, you asked a little bit about what can leadership do, and from a researcher perspective, this is a really exciting idea for me. And it's about this idea of dynamic reconfiguration, and that's of the human resources, but also of thinking about how we organize and structure work more readily. And the reason that I find this very interesting is that increasingly the boundaries of the actual system, what's your software? What's my software? If it's third party or if it's an internal system, those need to be quite fluid and they need to be quite adjustable because of the interdependencies between different aspects of the system. And that also goes for different functional aspects of the team. So customer support and the SRE team may need to be able to dynamically reconfigure to say, "Hey, we're getting a lot of information from our customers about a problem that they're seeing. It's quite slow for us to use these ticketing systems from customer support. Maybe we can start to pull them into our Zoom calls when we're having an incident."

Or someone told me a story recently about their company deciding to run a Super Bowl commercial, and they dynamically reconfigured within the organization and said, "Hey, this is a very integrated all-company approach, because what happens from the marketing side of things and our customer support side of things is going to be very integral to the system performance as well," and so they started to work more closely and more collaboratively across the team. So I think that in terms of what leadership can do, I think getting a little bit more flexible in terms of how to exchange resources from different teams, how to think about the ways in which things like deferred maintenance or choices about what features to prioritize, what the downstream and upstream implications of those are going to have on the wellbeing of the team and the amount of pressure and stress that they feel, those factoring in the emotional aspects of the software engineering can help to alleviate some of that pressure. Even though we are going to have to be working hard, we are still in quite a constrained environment.

And then the last thing that I will say about this dynamic reconfiguration is my hope for industry is to start thinking about intra-organizational collaboration as well. So I talked a little bit about the ways in which our dependencies create this need for a different kind of organizing that may not typically be the standard. And in my dissertation research, I actually saw a number of examples where engineers from both sides, and I was studying incidents predominantly, and so engineers on the vendor side and engineers on the client side were trying to independently debug what was happening. And some of the things that they were asking for, "Can you run these diagnostic tests for us?" were actually exacerbating the problem itself.

And so instead, they began to say, "Okay, we need to start thinking of ourselves as one unit, not as either sides," and so they would break down those walls and start to interact more directly. And these are the kinds of changes that have to take place in order to respond in real time to very real issues. And so my hope is that as an industry, we start to think about how some of these barriers around how we work together may not actually be in the best interest of the cognitive and emotional parts of that work for the people involved.

Shane Hastie: We've been hearing more and more recently about cognitive load. This is an early indicator of, I hope, ongoing conversations about emotional load and how we deal with that deal. There's a lot here, a lot to unpack. If our readers, listeners want to continue the conversation and hear more, where do they find you?

Dr. Laura Maguire: I am on Twitter @LauraMDMaguire. I'm on ResearchGate. You can take a look at some of the work that I've done there. And I am also on LinkedIn, and if there are things in the conversation that have really resonated for people, I would love to continue the conversation.

Shane Hastie: Laura, thanks so much. Really appreciate your taking the time to talk to us today.

Dr. Laura Maguire: Thank you, Shane. It's been a pleasure.

Mentioned

• Dr. Laura Maguire on Researchgate and on LinkedIn