Recently I walked into a sprint review meeting with a software development team that was in the middle of integrating AI into one of their company's core product offerings. Now, it seemed to me as I observed their leader, that he was holding on by a bare thread and that he thought there was a real trade off. Either race through rapid change and come out the other side with a new product or have a healthy team.

Now, they were mid project and they were deep in it. You could feel it in the room, the tension, the fatigue, the sense that they were barely holding it together as they went around the room and shared their updates. Everybody was rushed, nobody made eye contact and people looked, well, nothing short of defeated. And yet from a methodology standpoint, they were checking all the boxes. Two week sprints, daily standups.

The agile process was humming along and from the outside it looked like they were doing everything right. But on the inside, the wheels were coming off the bus. The innovation felt chaotic, the pace was relentless and burnout, well, it was just around the corner. Now, this wasn't a failure of methodology or talent or effort. This was a failure of structure.

In this episode, we're going to unpack what was happening beneath the surface with that team and how a small change, a tweak, if you will, made the shift, made the difference that they needed as they approached their work. And they this shift, this tweak brought focus, calm and even a little bit of excitement back into the work. Now, if you're a leader and you're trying to drive innovation without breaking the backs of the people who work for you, this one's for you.

And I don't care if you're leading from the side or leading from the top of the org chart, you don't have to choose between innovation and stability. Innovation and a healthy team. Now, in UX design there is a concept called chunking. It means breaking down large or complex ideas into smaller, more manageable pieces. Now this aligns with how the human brain processes information and remembers things. So it's a beautiful way to organize work and it makes information easier to process, makes things easier to remember. This is why we have phone numbers that start with a three digit area code, then a three digit prefix, then a four digit number. When we chunk it down into those smaller units, it's easier to remember.

It's a way of essentially making something overwhelming feel more doable. So as we think back to the software team change does not have to feel like chaos. And when leaders use design principles like chunking well, they can create stability inside of large innovative projects and that can foster adaptability without burning out their teams. Now that's what we used with this team. And over the next 20 minutes, I'm going to show you how it can work for your team and you yourself as well.

So let's just take a step back. Why is this even happening? Well, we all know that everybody is asked and tasked to do more with less, whether it is one team doing the work of two, or one person doing the work of two or three. Because a lot of times these days with cutbacks happening in organizations, somebody might get promoted or move into a different position and then they don't get backfilled.

In fact, that person who gets promoted oftentimes still has to take on their old work, either for a period of time until that gets either transferred to other people or backfilled or, or sometimes just forever. So today's teams and individuals are asked to build more, do more, work harder, work faster and innovate continuously, especially with tools like AI. Because either the AI tool needs to get integrated into the product, as it was the case with this software team, or we're just expected to do more using AI and be able to work faster.

Now, the tools and methodologies like Agile in this particular case, promise adaptability and they promise to be able to be flexible in the face of change. But when applied without some nuance and some critical thinking, and really some design thinking and UX thinking, they can feel nothing short of relentless. So most teams who are failing or are struggling are not doing so out of resistance to using the methodologies or because of the methodologies themselves. They are drowning in unstructured and poorly paced change. Now, we can't necessarily predict change, we can't control change, but what we can do is, well, we can use UX thinking in the face of change to help make our work more understandable and in this case to chunk things down.

So let me tell you the full story of what was going on with this particular team when I walked into that very first meeting with them. So they're a mid sized engineering organization and they're working on a B2B SaaS software product. So if you don't know what that means, don't worry about it. Just know that the company had recently decided to integrate AI into that product based on what some of the competitors were doing and based on trying to stay leading edge in their field. So, you know, things like smart automation, predictive recommendations, that kind of thing, the kind of thing that their customers were beginning to expect because they were seeing it in other products and in the marketplace. So the announcement was exciting. The software engineering team was super stoked to get behind AI and to start learning AI in a way that integrated with their product.

So the engineers were curious and energized. Well, at first, but the excitement turned to exhaustion quickly. They were already operating in these two week sprints that Agile methodology is known for, and leadership saw that as fast. But you know, integrating AI wasn't necessarily just a feature change. It was a fundamental paradigm shift to how their product worked. And from an engineering standpoint, the software developers had to completely think differently about how to integrate AI that was going to basically do some of the repetitive tasks for the user and shortcut some of the things that were already built into the product. So it was a fundamental rethinking of how this product worked. It wasn't just like tack AI on the side and everything's fine.

So it required upskilling, testing new APIs, adjusting their mental models for like literally how the product work, all while keeping up with the pace of change and the rest of the existing work. Now Sprint. By the time they reached Sprint three, now that's only six weeks into the product project, the team was fraying at the edges. And as their standups got shorter, you know those meetings where they report out how they did and what they were going to do next, they also got more tense. The retrospective meetings at the end of the two week sprints started getting canceled. You know, just this once, we'll cancel it. People were showing up late or not showing up at all. And one senior developer who was seen to be like, absolutely core to this project, had asked to be reassigned.

One product owner explained the mood to me as chaotic and completely demoralizing. And that's when I showed up on the scene. So in my first conversation with the team, what stood out? Again, it wasn't resistance to change, it wasn't resistance to the methodologies that they were using. It was simply overwhelm, complete and total overwhelm. They weren't pushing back, they were just trying to keep their heads above water. Now I asked a basic question, what's the shortest cycle of meaningful progress that you could sustain? And someone laughed and said, three hours. We all had a good laugh. And in fact, that was great at breaking the tension.

We talked it through a little bit more and we settled on three days. So instead of doing two week sprints, we restructured their sprint model into what we called micro cycles. And their microcycles involved three day sprints so three day cycles focused on one tangible thing. Test a new model, build a mockup, evaluate an API. Just one tiny slice of that whole software product, integrating AI into it. And again, sometimes it was a fundamental rethinking. Sometimes a three day sprint was just simply rethinking and whiteboarding things and not a single line of code got written. But at the end of each three day cycle, we did a quick 20 minute check in what worked, what didn't work, what was next.

No formal demo of any software that anybody built. Just learning and momentum. And something shifted almost immediately by the second cycle, that's only like a week and a half in. So six days in, the team was showing up on time. By the third cycle, they were smiling again and laughing and joking with each other. And someone said, this feels like what it used to be like when we did hackathons, you know, late into the night, intense, but fun. Now, by shrinking the unit of work from two weeks to three days, we also shrink their anxiety. We made space for progress and for processing.

We made space for new understanding and new mental models. We made space for the fundamental changes that were happening to this product. And the innovation didn't slow down, it sped up and it got smarter. And most importantly, people started to feel like humans again, not Sprint machines. Now let's tease apart what we did now on a fundamental level. To take something from two weeks, that would be a 10 day, you know, if we're looking at a five day work week, a 10 day sprint, and we chopped that basically into a three day sprint. Now when we look at that and then apply this idea of chunking to it so we can really understand what we did and why we did it. We need to dive into what chunking is a little bit more because I want you to really deeply understand this concept.

So chunking originally comes to us from cognitive psychology and from user experience design. And it is the idea that we group content or steps and in ways that reduce cognitive load for the user and improve processing. So again, I use the, the example of phone numbers before, that's the classic example of chunking a 10 digit number down into 3 digit, 3 and 4 digit chunks. If I asked you to memorize a 10, 10 digit number, it would be much more challenging than if I gave you a phone number that was already pre chunked. Now, again, from a user experience design process, this doesn't just happen with phone numbers and simple pieces of information. It also happens with how we design things on screen, how many steps we put on a screen. And we use a generous white space on a screen, maybe putting only two or three steps on the screen, and then you go to the next page where you get another two or three steps, which is much more manageable for the human brain than to see a long page of things that you have to scroll through. And there's 10 or 12 steps on the same page.

So, so that's how we use it in user experience design. And why does it work? Well, it really does mirror how human attention and human memory work. Our memory, our short term memory especially, works better in these smaller chunks. And it reduces overwhelm, it increases clarity because you know, you only have this one small thing to do or remember. And it builds confidence because people can complete those smaller units even more, much more easily than they could complete a much larger thing. So if I asked you to memorize a three digit number, you'd be able to do that, no problem compared to if I asked you to do memorize a 10 digit number. The same thing is seen with asking People to remember five words for 30 seconds. People can remember five words for 30 seconds at a much more overwhelming rate than asking them to remember 10 words, like twice as many words at half the amount of time. So 10 words for 15 seconds, people will fail much more often than being asked to remember five words for 30 seconds. Again, classic example of how the brain works with chunking.

Now let's apply this to your leadership. Whether you're leading a technical team, leading from the side, or leading a non-technical team, what you want to do is don't just break up the project, but break up the change. Because again, change is coming at us so fast, it's coming at us faster than we can really handle. So it's not just breaking up a project into lots of small steps. It is fundamentally shifting how we conceive of and think of the change that's coming at us. So absolutely shrink your timelines and shorten the loops, just like we did with that group.

Taking a 10 week, 10 day sprint, rather two week sprint, 10 work days and shrinking that down to three days. And you also have to make some space in there for emotional and mental recovery. Because a three day sprint is perhaps even more taxing than a two week sprint. Because a three day sprint, oh man, that feels doable. Just like the software engineer who joked that, you know, they could manage a three hour sprint, but if you were doing a three hour sprint or a hackathon, which they also referred to, that's a very short period of time. And you push really hard. So when you change the sprint interval from two weeks to three days, people are intuitively just going to push themselves harder because they know it's only three days. Just like think about the sport of running, the pace at which you could run 400 meters versus the pace at which you're going to run a marathon are two very, very different paces.

And again, that's where we get the concept of sprinting in agile methodology is you can sprint faster than you can marathon. So this was even, you know, taking that to more of a micro sprint level. So people are going to push themselves harder even if you don't tell them to. And this is a little, you know, I don't mean for you to use this from an underminded, sneaky way, but people will push themselves harder than they would in a longer interval. Now think about all the different applications in which you can use that as a leader, whether that is shrinking the time. Maybe you're not necessarily shrinking the time, but you're shrinking the list of things for people to do. Because as whether it's somebody looking at their job description or, or somebody looking at their actual to do list, sometimes the tasks seem a mile long. So if you're a manager and you're struggling with somebody who's feeling overwhelmed and close to burned out or burned out, just ask them like, okay, let's look at your whole project list, let's look at your whole to do list and let's maybe just pick three things and over the course of one workday, just work on those three things and if three is too many, break that down to one or two.

Because if we can get some momentum going with these shorter time intervals and shorter to do lists, it's going to breed confidence and that confidence is going to help our enthusiasm and help us mitigate against burnout. So shrink things and chunk things however it most meaningfully makes sense for you and your teams. Now again, what changed for this particular team is we shifted from two week sprints to those three day mini cycles and in every three day block they had one clear goal or one clear experiment. And then they did a quick retrospective meeting at the end to talk about what worked and what didn't work. So 15, 20 minutes short. Now we also built in a little bit of wiggle room, slack if you will, to have for documentation because they needed to document what worked and what didn't. So they weren't repeating experiments that failed or if they had failed, that they could with that documentation learn from that failure and as we like to say, fail forward. They could also just regroup and celebrate a little bit when they had a good breakthrough.

Now again, their metrics didn't drop. In fact, their decision quality, the quality of the product, everything improved and the burnout indicators went down. People were just also a lot more like joyful and happy to be at work. And people reconnected with why the project mattered. And they reconnected with the excitement of being at the forefront of integrating AI into one of their company and the industry's products.

So let me give you some tactical takeaways for leaders. First of all, some signs that you might be chunking things too big. So some signs to watch for to know that it's time to use this idea of chunking and chunk things down into smaller bite sized pieces.

If you've got missed deadlines or deliverables, if your team is emotionally flat during meetings, if there is no time to reflect or recover between deadlines, if you've got that sense of quiet quitting and disengagement on your team, well, those are all signs that it might be time for you to chunk things down smaller. So what I want you to try, I want to give you a few specific things that you can try. First of all, redefine your sprint lengths or your deadlines. If you're not in an agile software methodology and you are like what is she talking about with sprints? Sprints are just these two week intervals that software teams use to get a certain chunk of work done. So if whatever deadlines you're using are getting missed, it's time to change the deadlines. So break that project or whatever that deadline is down into smaller component parts and put shorter deadlines on them. So smaller units of work with more frequent deadlines. Use mini retros or retrospective meetings more often. And by many I mean like literally 15 minutes. Set a timer, put the timer up where people can see it.

If you're on Teams or Zoom, it's easy to put the timer right on the screen so people can see that time ticking down. If you're in a conference room, you might put a timer up on a whiteboard or project up onto a screen or even just have a mobile device in the room with a timer counting down so we know exactly how much time we have left so we can keep that meeting on pace and make it really, really quick.

Protect cognitive white space because it's cognitive overload that makes us feel overwhelmed and disengaged and demoralized so we don't want that overwhelm and that cognitive overload. So instead, we need to think about using white space. Now check out episodes, a couple of episodes of my podcast that I've done on white space, episode 160, which was titled five reasons you need white space on your calendar, and episode 210, White Space on your calendar and your brain. We're going to link those up in the show notes so that they're really easy to find. But making sure your team is structuring white space into their calendar on the individual level and on the team level is huge in terms of, like, being able to take a breath after making or missing a deadline.

All right, now I gotta leave you with a call to action leaders. Whether you are leading from the top or the side, you are designers of experiences, you are experienced designers, and structure is your medium, how big are the projects? How big are the deadlines? How long do people have to work on things? That is the medium that you get to play with as the designer. So I want you to ask yourself, could this be smaller? Could this be clearer? Could we feel better doing it this way? Okay, so take a look at whether it's a project or an entire team that you're managing or even your own to do.

List for those of you who are individual contributors and leading from the side, and ask yourself, could I cut this down into smaller chunks? Could I make this clearer and more specific for myself or for my team? And might I feel better about doing it this way?

Again, my friends, innovation is not a race. It is a design challenge. It's not about chaos. It's about clarity in motion. And we are all in motion these days, often faster than we wish we were. But using the processes that we've talked about here today, and specifically that idea of chunking, you can chunk down that chaos into manageable parts that the human brain can wrap itself around, and you can get more items across the finish line faster.

All right, my friends, if you enjoyed this episode, please share it with a friend. Because there is so much overwhelm in the world right now. I know you've got somebody in your world who would benefit from hearing this message, too. So please help me out and help them out by sharing this message with them. All right, my friends, until next time, be well.