I made my teams work numerous weekends — and I still regret it
My role in burning out people until Scrum confirmed my belief that it was wrong
“You said that the project would be finished by September. I hold you to that. You WILL end the project in September. This year.”
I felt cornered. The original plan was indeed to finish the project end of September. But that was before the plan hit reality. New insights about the complexity of the product already prompted me to address this issue at the previous Steering Committee. There my proposal — to add an additional two months to the project plan — was vetoed. Instead I was instructed to find ways to “win time”, while keeping the original scope. I failed to find these ways. So here I was — at the next Steering Committee, mid April — with nothing to offer. And our CTO was fuming with anger.
“I’m really sorry about this. But we simply can’t deliver the project faster. All our specialists are already working on it, so we don’t have the option of adding more people (I really hate the word ‘resources’). You also determined that every planned feature is important, so there’s no option to reduce the scope. Our hands are tied.”
“No they are not. The teams could work during the weekends. If everyone would do this for six weeks with full focus, you would have gained half a month. Probably more. It’s simple math.”
I tried to refute this statement: “It’s not this simple. Studies have shown that people can’t possibly be 100% productive for such a long period. Some even argue that a 40-hour working week is too long. We will probably deliver less instead of more due to errors that we simply can expect to occur.”
“I work 80 hours a week. Why is it so hard for employees to do the same? It always blows my mind. I expect the same from them. Where’s the commitment from the teams?”
I could now fuel the fire by bringing up that he also sees dining and golfing with fellow CTO’s as work, but this would not serve the cause.
I felt I had no choice than to tell the teams that the Steering Committee expected us to work during the weekends. When I brought the message, I secretly hoped they would refuse. They didn’t. Some were outraged. Others were lethargic. Some people were excited. But somehow they didn’t appear to see (or were afraid to say) that my request was a stupid one.
Joe, one of our best developers, pleaded that he couldn’t possibly tell his wife that their trip to Barcelona had to be cancelled. She would never forgive him. I told him that he’d get an exception for that weekend.
Then Rita said: “What about me then? I promised my daughter to watch her football match. It’s the season final.”
Andy spoke up too: “Me and my friends planned a GoT binge watch weekend. I value this as much as Joe values a weekend to Barcelona!”
Judy responded: ‘What’s this? Instead as approaching this as a team, you all look at serving your on cause. We all need to adapt to make tough choices.’
We couldn’t do this without Joe, Rita and Andy. So it was obvious that we couldn’t start working weekends right away. It would be postponed by two weeks. But the message had already achieved one thing: it broke the team spirit.
The first weekend
It was the second Saturday of May and I was sitting at my desk. I couldn’t think of a thing to do. But as I had instructed the teams to work during the weekends, I felt I had to be there too.
The teams started on a more positive note than I expected. There was even a sense of camaraderie. As if they were chosen ones, the heroes to save the company.
I even started to think that I was wrong and the CTO was right. Perhaps it didn’t hurt to do this once in a while.
Three weekends later, the tide had turned. People had been working 20 days straight and this was plainly visible. They were tired, they were grumpy.
But even worse: we hadn’t been able to win time at all. The teams had delivered as much in 60 hours as I would have expected them to deliver in 40 working hours. There were several factors that played a role here:
- Work stalled when there was unclarity about what to do, only to be answered by someone that didn’t work during the weekends.
- People simply weren’t able to focus on their work as they did when they worked 40 hours a week. They feared to be punished for taking a break, so instead they just stared at the monitors of their laptops mindlessly for hours. And who could blame them?
- When they were coding and testing, people couldn’t fully concentrate either and became sloppy. Hence they made mistakes. Serious mistakes that required repair, putting even more pressure on the project.
Meanwhile the CTO continued to praise the efforts of these teams, stating that they are an example to the rest of the IT department. With that he willfully ignored my warnings. He simply didn’t want to hear them.
So here I was. Managing a project that was doomed to fail. With a team working weekends because I told them so. I had believed that this stance was required, despite knowing that it would not lead to better results.
The breaking point
We were in week 6 and was it Tuesday 11 o’clock. Joe still hadn’t arrived. While he promised to be there to do the deployment to the Integration Environment. No one else could do this.
Rita responded: “He just texted that his doctor instructed him to stay home. He appears to have a burn-out. I think we lost him for a long time.”
“This is terrible. Both for Joe and for us. What can we do now?”
“If you want to know what we can do to rescue our project, then it’s either to wait for Joe or to have someone else to do the deployment. But that will delay things by weeks”, said Rita.
“But it’s not only Joe. I’m also totally exhausted and I’m not alone. We can’t do this anymore. And did you know that Andy quit the company yesterday? He was fed up with all of this and decided to go without even having found a new opportunity. How’s that for a token of your decision to work during weekends?”
I had no choice but to pull the breaks. It had to stop here. I organised an emergency Steering Committee session and explained the situation, urging for a decision to give the teams a break. And then continue the project at a sustainable pace. Even the CTO was now convinced that we didn’t have any other choice. He had to accept the delay.
In the end we managed to close the project in March the next year, so even several months later. But at least we delivered valuable software. At an enormous cost. All the overtime we had put in the project was for nothing. Even worse: we made additional costs, put people’s health at risk, saw great people leave and still didn’t reach our planning targets.
Around the same time Joe returned to the office and I am happy to report that he is still as important for this company as he was. But he will not accept to be squeezed as he was during the project.
Now I am a Scrum Master in another company. We still have to deal with expectations that can’t be met and then still people suggest teams to work overtime. Most of the times the Development Teams will reject this and come with alternatives, like:
- Reducing the scope of the release;
- Alternative solutions to deliver similar expected value;
- Accepting that we require more time;
We know that our product environment is complex. This entails that we have to take learning into account. In Scrum this is called empiricism: transparency, inspection, adaptation.
We also embrace the Scrum Values of Courage, Commitment, Focus, Openness and Respect. People are respected for having the courage to be open, discussing the tough issues like changes in expectation. We commit to delivering products of the highest value, but understand that we need to work at a sustainable pace.
Sometimes though I have to step in to raise the understanding of a Product Owner, a Development Team (member) or a stakeholder. I then bring forward my experiences as described in this article and how working overtime structurally had an opposite effect of what we wanted to achieve. I think you can agree that it had a disastrous effect.