The Myth of 100% Utilization: The Neuroscience of Productive Teams

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I get to sit down again with Shannon Mason. Shannon, thank you so much for taking the time to talk to us today.

Shannon Mason: Likewise, Shane. Glad to be here.

Shane Hastie: Well, you and I know each other, but it’s probably a good idea if we tell the audience who’s Shannon.

Introductions [00:58]

Shannon Mason: Other than a troublemaker by training, I’m chief strategy officer here at Tempo Software and responsible for product engineering, GTM, global strategy for the business. Initially, was looking specifically at our product and engineering function, but then expanded my role out. And then, Shane, I know we go way back, but our first meeting, even further back, was when I was running product at Rally Software and then I had a short stint in the DevOps space, specifically at GitLab, and now find myself at Tempo for the last four years, which has been a blast.

Shane Hastie: Cool. And we’re getting together again because we’ve been talking, or you’ve been exploring and talking about capacity and utilization. Utilization is such a mechanical measure, isn’t it?

Utilisation is a Deceptive Metric [01:48]

Shannon Mason: Yes. It’s a rough word. It almost makes folks feel like cogs. And in this context, we’re talking about utilization of your most talented and usually most expensive line item in the organization, the folks that make magic happen and are actually developing code. Although I also tend to think, now since my role has expanded outside of just looking at product and engineering, into the whole thing that makes magic happen from a delivery standpoint. But yes, utilization is one of those words that’s coming up so much right now, too, as we start to think about AI and how that rolls into organizations. But it’s a deceptive metric. High utilization is usually what an organization wants to achieve, and software development busyness doesn’t always translate into meaningful value, and then the true impact oftentimes gets lost. But I do find and have found over the last couple of decades that there is that over-dependency on, like, “All right..”.

A lot of us read The Mythical Man-Month and we bought into that idea of no one has eight hours a day, if they work eight hours a day, where it’s 100% of that time is going to the active development, fingers on keyboard, coding that would occur. We take breaks for lunch. We get sidetracked. Things like that happen. There’s slack that happens in our day. But still, we find organizations are really focused on making sure or trying to achieve some sort of “maximal utilization” of their team. So, every minute, hour, second is accounted for. And obviously, at Tempo, our original roots were in time tracking, which, for me, as an agilist through and through, is sometimes a not-so-accurate metric, right? It’s a governance tool that’s often used. We want to track how much time is going to particular things, but oftentimes effort or just tracking queue time, things like that, throughput tends to be a little bit better representation of where the actual time is going.

The Neuroscience of Cognitive Overload [03:49]

But of course, a lot of organizations, they’re hybrid because of those governance pieces. And I still encounter organizations that are like, “We want max utilization”. And for me, with the background that I have in neuroscience, there’s always a concern, too, from the cognitive overload that oftentimes happens in an organization that tries to achieve maximum utilization of their humans’ thought ability. That prefrontal cortex needs time to relax. And what you see, and I think we don’t talk a lot about this, is burnout culture, which is really predominant amongst a lot of us engineers and software folks and product folks and people that live this life day to day, is that a big piece of that burnout component is that chronic cognitive overload that happens. Context switching, a lot of executive function is required in that prefrontal cortex, good decisioning. And the more tired we get and the more decision-fatigued we get, the worse our choices become and our working memory capacity starts to shrink.

And for me, when I think about utilization in an organization, especially at the leadership level, the director level, folks that are providing the right level of insulation, and especially since we’re talking about culture here, they should be thinking about, “Am I creating the right circumstances for all of my humans to make the best possible choices?” And in that context, 100% utilization is not what we want to go for. We want slack in the system. We want slack in people’s day. We need to give people time to take breaks and really just recover their mental acuity. But also, I’m a big advocate for just structuring those sorts of things. Working in organizations that had no-meeting days, beautiful. Meetings create context switching.

Working in organizations like when I was at GitLab, we had a really well-structured perspective on how we used Slack versus how we used email. All those little interruptions that happen on a day-to-day basis interrupt our ability to create “utilization”. But really, what we’re talking about is productivity, efficiency, those sorts of things. And that requires slack. So, long response to probably a quick question, but this is a tough cultural challenge and one that, I think, between you and I, capitalism puts a lot of pressure on.

Shane Hastie: You’re right. There’s a lot to unpack. But let’s start at what’s happening in our heads, that most basic neurological, brain science-level stuff. Here I am. I’m an engineer. I’m deeply focused on producing code for a challenging problem. What’s happening in my head?

What Happens in the Brain During Deep Work [06:25]

Shannon Mason: Oh, man, there’s so much that’s happening in your head, right? The optical nerves are connecting… We’re not going to go that deep, I promise, Shane. But at its core, and I think Mihály Csíkszentmihályi’s work on flow is very popular amongst those that are doing work, because we’ve all probably felt what it feels like to be in a flow state. The short synopsis of that is, when we have a task and we have generally all of the skills that we need to achieve the completion of that task, and it feels really good, it’s a little bit harder than what our core competency is, but it’s not too hard, and it’s not so simple that it actually becomes boring, right? It’s menial or tedium. As a side note, I think actually one of the big things that AI can help with is the tedium, removing the tedium so that we can achieve flow state much better, focusing on the actual big troublesome work that we’re skilled to do.

So, your prefrontal cortex and your frontal cortex are the ones that are thinking about, “I have three different options here. This one’s the best option because I can reference past experience. I know that we’ve made some changes to potentially our infrastructure. And if we do X, Y, and Z, that’s going to lead to a downstream impact here”. That area of our brain, we tax quite a bit, especially as craftspeople. We’re thinking about all the different nodes and nodules that we need to think about within the network of our organization, our code base, and our products.

And what we find with a lot of utilization is that you end up just putting a significant cognitive load when you have tons and tons of task work. That task work shifts context quite a bit. There’s calculations we can do on the cost of context switching. It’s a real thing that we can calculate and also drive back to, business impact in terms of numbers and dollars. And that all relies on the ability, frankly, for us to be well-rested, well-fed, and able to focus on a task for a set of time that allows us to work through and get to that state where we know we’re in the groove, so to speak.

And this is for all functions, not just engineering, but also, for me, on the strategy side, I get asked questions all the time about, like, “Look into the future and see what might be possible”. Well, if I’ve gone through eight hours of meetings and then the only time that I have to do critical thinking is at night when I’m exhausted, you’re going to get the most decision-disoptimized or unoptimized choices from me because I’m tired, and I’m actually going to optimize for the easiest path out. And that’s one of the things that you see with high cognitive-load burdens, overutilization, is basically the working memory, that’s really part of our prefrontal decision-making function, starts to just get overburdened and then we start making, honestly, bad choices. So, we end up with the simplest solution versus the best possible solution.

Shane Hastie: So, if I am that engineer, what can I do to manage this for myself?

Individual Strategies for Managing Cognitive Load [09:28]

Shannon Mason: I think as an organization, you want to have a culture that includes slack, and that slack is at the team level and the team-of-teams level. So you never want to be thinking, especially since a lot of orgs will look at their total velocity, their total capacity, we never want to be planning to 100%. The flip side of that is, as an individual, I also don’t want to be planning to 100%. So there’s lots of great techniques out there. But I think one of the best techniques, try to spur your own organization to have focused work time days, days where you don’t get interrupted, where we try to… and that’s a cultural thing, we try to minimize interruptions because the interruptions is really one of the things that causes that trouble. Stuff happens, right? System goes down, people need to divert in a way from what they’re doing. But in general, we want to be able to have some focused time.

And then, if you don’t work in an organization that kind of understands the cognitive load and cognitive burden is a challenge to your own productivity as an individual and thusly to the ability to get shit done, pardon my French, as an organization, then you want to start doing time blocking in your calendars. And it’s been around forever. It’s one of those things that everybody recommends, but it is great, right? Like, “I’m going to block this time, and this time is to get work done”. There’s some great apps out there that will help you do that sort of thing. And what you’re looking for is to give yourself enough time to get into context, to find flow state, to do the work. And that actually takes more than 20 minutes. It takes more than 30 minutes. So, you want to give yourself a good couple of hours to do that focused work if you can. I know that’s not true for everybody’s landscape, but that’s one of the things that… Find those blocks of time.

The other thing that I recommend, if you have an organization where you do do a lot of jumping from meetings, context shifting, having those times where you’re like, “I check in on Slack at this time. I silence those notifications”. Because one of the things that our brains do with the notifications, dings and pops, they’re designed to distract us because the applications want us to go use the applications. They want utilization. But those dings and those pops and clicking on those buttons actually gives us a little bit of a serotonin boost, a little dopamine hit. And so, we feel this tendency to, like, “Oh, I got to go check”, because every time we do that, it’s like, bling in our brain. So, finding ways to quiet those notifications so that you can find that quiet time.

And then, if you do live in the back-to-back-to-back-to-back-to-back landscape, which does happen sometimes, giving yourself basically the grace to know that your context switching is going to impair your decision-making. So maybe don’t make any big business-critical decisions if you have nine hours of meetings back-to-back because you’re going to optimize and you’re going to probably do a suboptimal choice making in that context. So, maybe that’s not the day that we decide whether or not we want to move from a monolithic infrastructure and how we’re going to do our services breakdown. Maybe that’s something that we reserve for more of that thoughtful, quiet time where we can actually give our brain the ability to think.

Shane Hastie: And if I’m a mid-level leader, a team leader, that sort of, I don’t have authority to change everything about the organization, but how can I make it better for the people that I do have within my scope of influence, at least?

Leading Teams: Creating Protective Culture [12:47]

Shannon Mason: Yes. If you have a team that you’re working with or teams that you’re working with, you can set team culture. Because the team culture is determined from organizational values that are usually set, organizational culture. But team culture or “tribal culture” usually is something that’s unique to the group and informed by the broader system that they work within. And so, I think that leaders have the ability at all levels to be able to set the expectation of how they protect their own team. And that’s one of the things that I think the leader can do. They can do those things and show those examples.

A global decision to have one of those days per week be a working day, a no-meetings Monday, perhaps, or a no-meetings Wednesday, that’s something that an individual can do and then say, “Hey, for my group, on Wednesdays, we don’t do meetings. So our team’s going to start rejecting those meetings if you schedule them”. Something bad happens and there’s a customer mission-critical thing that’s happening, of course we’re going to follow our standard protocols and processes and stuff for P0 issues. But in general, this is a day that we don’t do things.

The other things that leaders can do is there’s this interesting dynamic between you want to have slack in the system, but we don’t want to have too much idle time. Idle time is actually detrimental to morale. And I think one of the ways that we balance slack and idle time is prioritization and actually using the tools that we have to understand throughput. We were talking a little bit about this before we started chatting, throughputs, queuing time, understanding queuing theory. No one really wants to wait because an idle individual feels like they’re not doing or practicing their craft, and their craft is their purpose for going to work, right? Building something amazing that customers are going to love.

So, there’s definitely a component here where we don’t necessarily want to have too much idle time. It starts to lead to disengagement, but you need rest. And so, an awareness of how long does it take for work to actually move through our system is really good. And then understanding whether or not there’s enough slack for people to think about how to solve problems, which are two separate things, but they’re a little bit related to each other. One is about processing, and the other one is actually about movement of work and the feeling of forward momentum that the team gets. And it’s true.

If you look at both of those things, then typically what you’ll see is velocity increase. And that’s one of the things that I also think leaders can look at, is just like, if you’re doing protection of time, we can’t also ignore bottlenecks or things that create idleness within the group that’s actually detrimental to morale. And then, if it’s detrimental to morale, it means it’s detrimental to velocity because people disengage. And if they’re disengaged, that’s detrimental to retention. They’re going to leave and go somewhere else.

Shane Hastie: There’s a delicate balance between slack and idle time. Let’s dig deeper into that. So, you mentioned idle time is the waiting for. Why is this not slack? I can take the time there.

Understanding the Difference Between Slack and Idle Time [15:52]

Shannon Mason: Yes, different concepts. I often kind of come back to the GYSHIDO principles that are out there. I forget the group that came up with them, but I love them. There’s one that they have, which is basically… Well, they have a bunch, but they’re like, “No meeting isn’t a standing meeting”. All our meetings are standing. Maybe all of our meetings are planking. Those are the fastest meetings I’ve ever been in. But they have a concept in their principles, which is, “No one should be waiting for your part”. Like, “You should not be the thing that’s stopping someone from moving their part forward”. And that’s probably the best description of idleness that I can pull in. It’s just like, if you’re waiting for the thing to come, whether that’s a decision, whether that’s your part of the piece, your expertise is maybe front end, if you’re waiting, then that’s idleness. That’s just time where I am delayed because I know it’s going to come and I need to be an immediate receipt of that so I can move my part forward.

Slack is a little bit different, right? Slack is specific time that we all understand is used for incubating new ideas, for digging into how we’re going to potentially implement something. It’s providing space that the group knows is available just in case we do start to do something new and all of a sudden something that we saw was going to be a small effort is now a medium-sized effort and that work has now grown and ballooned. So, slack is more about innovation, learning, space to breathe, and then idleness is more about waiting and delay. And those are two different concepts. But sometimes you can see organizations will think about, “Oh, we’ll build slack into the system because we know there’s a lot of delay that happens”. And good Lean principles, good Kanban principles, as you know, would tell us if we’re waiting. That’s, one, not slack, and two, is usually a symptom of a broader systemic challenge that we should probably solve.

I remember way back in the day, before the advent of really great delivery on demand and pipelines, one of the big delays that we all had, especially those of us that were fast to SaaS, was deployments. Like, “I’m going to set this to go and then I’ll wait”. And hopefully we’ll all go, “Okay”. And then maybe two, three hours later, everything’s kind of run through testing, we’ve gotten those things. And it’s just like, those are the sorts of things that we want to investigate. Those things still exist in organizations now. Like, I remember, in another past life, a 200-step deployment process for our cloud-based applications that I had to go through and get thumbs up from our internal governance organization around, where I’m like, “This makes absolutely no sense. We’re adding in a week’s worth of work to something that should be happening through really easy checks and balances that we can actually automate and program”.

So, I took that a little bit broader, Shane, than what you were talking about, but the difference between slack and idleness for me is waiting. One is conscious choice that we have, and the other one is we’re actually just stalled.

Shane Hastie: To fix the system.

Shannon Mason: Fix the system. The system will show you where it’s messed up. I mean, it’s surprising. We love ignoring where the system is telling us there’s a problem. Throw more people at it, add another step to the process, which usually ends up slowing things down more.

Shane Hastie: Don’t even do that. When we were chatting before, you raised the point of logical fallacies. What are some of the logical fallacies that organizations are still struggling with, and how do we overcome them?

Recognising and Tackling Logical Fallacies [19:43]

Shannon Mason: Well, I can tell you as a product person, I always have to be conscious and aware of confirmation bias, right? I want to find the information that tells me that, yes, my belief system is correct. But the one that is the biggest, and this is across the entirety of organizations, is, honestly, sunk-cost fallacy, right? “We’re going to invest in something. We have all sorts of little data points that are coming back or maybe even big data points that are coming back that are telling us this is not where we should actually be spending our time, effort, and energy, but we already did so much here, so we should keep on doing it. Perhaps if we keep on doing it, something will change, something will differ”. So, that’s one of the ones that is most predominant in organizations.

The money pit. I was talking with our CEO this week about that, the money pit, just kind of like, we’re just tossing stuff in there. And oftentimes those are hidden work, too. Those are hidden initiatives, side things that maybe an executive is trying to push through. Or they’re actually big things that we invested in as an org, and the signs and signals are telling us that we should pivot. I think with the sunk-cost piece, one of the challenges that we have naturally in product and engineering, which is, we want to build things that people use. It takes us time to figure out how to build great solutions. And once we get those out, when the signals come back that tell us maybe this isn’t the right particular direction, it can be really hard to accept that we should shift.

I actually think we throw pivot around quite a bit. Pivot really is related to sunk-cost fallacy. It is hard to pivot, because, “I’ve done so much work in this area. My team and I have been in the trenches building out new infrastructure. We built an entire services layer that’s pulling in all of our data from all of these different systems, and now we have to stop it?” And I think that’s where leadership also pops in to start talking about, like, “Okay, here’s why. Here’s what we learned. It’s not failure, it’s learning. And here’s how we’re going to take these learnings and we’re going to shift them over into what comes next so that we can actually do things that people love to use”.

Shane Hastie: Important question I haven’t asked you today.

Capacity Planning and Strategic Alignment [21:48]

Shannon Mason: I think one of the things that’s interesting, especially since we’re talking about culture and engineering, product engineering, is around how we help our organizations, broader organizations, teams, leaders, the marketing team, for example, understand the general work that needs to just happen in engineering and then also how we keep that alignment with strategy. One of the things that is big for me, at least, is always thinking about the capacity plan. One of the fascinating areas, at least for me from a neuroscience standpoint, is how people plan, how organizations plan. And it’s usually very optimistic.

And historical capacity data is really interesting because it should inform how we move forward. But a lot of people ignore it, which is part of the reason why at Tempo, we’re really interested in working on AI as it associates to this. So, how do we add intelligence on the plans that organizations make, the people that are associated to getting the work done, the shape of that work, and then projecting out with some level of accuracy the fidelity of a plan so that we can drive the conversation of, like, “Hey, this actually fits in the plan based off of everything we know about how your organization works and this doesn’t”. Plus, we also need to add in slack because there will be surprises. And we need to add in, for lack of a better word, just general maintenance, things that we need to do to just update and keep the system running fresh, active, happy. And then, how does that align with where usually the business comes in, which is like, “We want new. We want more. We want build-on, feature, this stuff”.

And that’s one of the areas where capacity is really important. So thinking about what you actually have. And capacity can be done in literal hours, that’s another conversation about literal hours, another discussion, can be done in effort. Sizing is usually the best way to think about this with relative effort. And then, just for the folks that are listening, effort, complexity, doubt, the bigger those buckets are, the bigger the work is. The smaller those buckets are, the smaller the work is. Still true. But one of the things we’re really excited about is adding intelligence to all of the patterns that are out there around how organizations execute and then helping to guide a team to create the actual feasible achievement of a plan based off of risk tolerance in an organization and risk tolerance on the team. And that’s one of the things that we haven’t chatted about yet that I’m really excited about.

Shane Hastie: Shannon, a lot of stuff to think about there and some great advice. If people want to continue the conversation, where do they find you?

Shannon Mason: So, if they want their Zeigarnik effect, their aha moment that happens from having a little idleness, happy to connect with folks on LinkedIn. Try to keep it simple for folks. And then every now and then, I’ll post something that usually has to do with the intersection of brains, people, and how organizations think about plans and executions, because that’s definitely one of my areas of fascination.

Shane Hastie: Thank you so much for talking to us today.

Shannon Mason: Likewise, Shane. Always great to see you, and let’s not wait too long next time.

Mentioned: