When the Heat is On: Motivating a Team With Tight Deadlines and/or a Heavy Workload

-

Sometimes a team has tight deadlines or a heavy workload. Or both! I've encountered this in nearly every position I have held, although it wasn't usually a constant but more of a phase. For example, I worked at a startup where the team was tasked with redesigning the website and refactoring the web app at the same time. They had trouble in the past delivering consistently, so I led them through an Agile transformation as well, and they became a scrum team. This allowed us to begin to get a notion of their capacity for work. However, pressure was on to the get a large amount of work done in a very short time period. Here's how I approach the situation.

First, we acknowledge reality. It doesn't do any good to pretend that the pressure isn't there. Recognizing as a team that we have a lot to do and not a lot of time to do it makes the situation clear for everyone, and relieves some of that stress of feeling like the burden is unseen.

Second, I work with the product owner and engineering lead to clarify what matters most. While the business might be saying it all matters equally, we can't function that way. The work needs to be broken up into doable pieces, with the highest priority items floated toward the top of the product backlog. Oh, and don't forget to have a clear Definition of Ready on each task/story. 

Third, I put on my scrum master hat and work to remove obstacles so the work can be done. Often that means being the person who goes to another team we have a dependency on to advocate for the work to progress. Other times it involves appealing to more senior management to unlock a pending decision that's holding up the works. Whatever it is, it's my role to clear the way so project work can proceed.

Fourth, and very importantly, every win should be celebrated. If a feature is delivered, then flag it with leadership and congratulate the team. Highlight any members who especially contributed to this success. I know a manager who told me and colleagues over lunch that he never thanks team members for doing their job. What a demotivational manager! And when the project itself is completed, this should always be recognized by senior leadership over the area of the business. It doesn't cost anything to the business to say thanks for work accomplished. 

Fifth and finally, this can't go on forever. That is, the work can't remain burdensome in the long term. The team needs to be able to find a good work/life balance so that they can maintain a dependable velocity and thus a consistent sprint capacity. Asking them to work overtime all the time puts strain on their personal lives and their own health and well-being. At a startup where I worked the CEO told us that he expected some of us to come in on weekends. He didn't mean during a crisis or a big push...he wanted this all the time. There cannot be an endless crunch, because it is simply unsustainable. 

In the end, managing through periods of heavy workload or tight deadlines isn’t about pushing harder—it’s about leading smarter. By facing reality together, prioritizing what truly matters, removing obstacles, celebrating wins, and protecting the team’s long-term well-being, you create not just short-term success but also the trust and resilience needed for future challenges. Sustainable delivery comes from balance, not burnout, and it’s our responsibility as leaders to ensure teams can thrive while delivering meaningful results.

Popular posts from this blog

The Dual Faces of Technology: Enhancing and Replacing Jobs

-
Image
Automation has been on my mind a lot lately, more immediately due to a book I read , but also because of the looming reality of artificial intelligence. To understand what's involved, making the distinction between replacing technologies and enabling technologies is crucial. As we traverse the timeline of the 20th century, we observe how each type of technology has distinctly influenced employment. Automated technologies have transformed industries by replacing manual labor with machines. Consider the automated switchboards introduced in the early 20th century. Previously, telephone operators manually connected calls using physical connectors on a switchboard. With the advent of automated switchboards in the 1920s and 1930s, many of these jobs were eliminated as calls were routed through electromechanical systems. Similarly, in agriculture, the introduction of mechanical harvesters like the combine harvester in the 1930s drastically reduced the need for manual labor. These machine...
Read more

The Technology Trap: Capital, Labor and Power in the Age of Automation (Book Review)

-
Image
In his compelling book, " The Technology Trap: Capital, Labor, and Power in the Age of Automation ," Carl Benedikt Frey offers a sweeping examination of the historical and ongoing impact of mechanization and automation on society. Starting with the onset of the first Industrial Revolution, Frey deftly navigates through the evolution of technology up to the modern age of artificial intelligence, presenting a nuanced view of how technological innovations have reshaped labor markets and power dynamics. Frey categorizes technological innovations into two types: enabling technologies, like the typewriter, which enhance worker productivity without displacing the labor force, and replacing technologies, such as robotic machinery in factories, which eliminate certain job roles altogether. This distinction forms the backbone of Frey’s analysis, as he explores the varying implications of each type of technology on different segments of the workforce. The book traces a historical patter...
Read more

Deputy Product Owners

-
Image
"The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner." - The Scrum Guide There are a lot of ways in which my approach to Scrum differs from what's in the official guide, and since that document refers to Scrum as 'immutable,' let's just call what I do 'Notscrum™.' In Scrum, there is only one product owner per team. That person is the sole person responsible for the product backlog, and the person who advocates for the work to be done. In Notscrum there is one product owner, but there can be multiple deputy product owners. Here's how it works. When my program at Viacom was first forming I met with the then-director of the Library & Archive group and learned that while he set the priorities on work done, the archivists were organized in three distinct areas with a team lead ...
Read more