When a Team Does Not Want to Do the Work that Needs to Be Done

Continuing on the theme of motivation…

Sometimes the work that most needs to be done is not the work a team wants to do. Let’s eavesdrop on a conversation between two leaders in an organization that ships enterprise software for an example of one such situation:

“Have you seen the number of support cases coming in for release <x.y.z>?”
“Yeah, it’s bad.”
“Is the server team working on the bugs?”
“No. They’re working on the next major release, <(x+1).0.0>”
“But…that release won’t come out for another year. Even if we could get it out tomorrow, the customers who are experiencing these failures are not going to do a major upgrade to address bugs.”
“I know.”
“So…why isn’t the team tackling the bugs?”
“They want to work on the new features.”

There are several organizational issues around alignment and prioritization evident in this single conversation, but let’s look at the biggest problem that’s front and center: there are unhappy customers waiting on bug fixes, but the team wants to work on the new features in the next major release.

As a leader, how would you get the team focused on the bug fixes?

There are several unfortunately common approaches that I don’t recommend because they won’t work at all, or won’t work well, or won’t work over the long term. In yesterday’s post I talked about how creating a false sense of urgency doesn’t work. As we will see in what happened next, other approaches that don’t work include ignoring the problem and hoping it will go away on its own, and attempting to coerce the team.

The conversation above happened because the leaders closest to the team were hoping the team would start fixing the bugs on their own, without direction or intervention, and they didn’t.

To be fair: if the organization had a high degree of visibility across the board where everyone is working from the same information, and a high degree of alignment such that everyone has a shared sense of purpose, it’s certainly possible that the team would naturally gravitate to the work that leadership also agreed was the highest priority. (Not guaranteed, but possible.) Alas, at the time this conversation took place, this particular organization had neither shared visibility or alignment. So it’s not surprising that the team did not magically turn their attention to the bugs.

I was a relatively new leader in the organization, and I knew I had to push the issue. So I did.

It’s worth noting that the organization had a history of leaders who waffled between avoiding conflict and inciting major blow ups. Leadership interventions often resulted in major drama. The leaders involved in the situation so far were hesitant to wade in because things were not yet dire enough to warrant a knock-down-drag-out fight.

When I pushed the issue, an engineering leader I’ll call B (not his real name or initial) called a meeting with the team and told them to “do it or else.” The team members—all quite senior and all with deep specialized knowledge—responded that they did not appreciate B’s stance, and that they would be brushing up their resumes. In short, B gave an ultimatum, and the team called his bluff. And I gained insight into why leadership interventions often resulted in drama.

It was time to change the approach. Here’s what we did next.

Step 1: Have the “Here’s the Problem We Need to Solve” Conversation

By the time I became directly involved in the situation, tempers were running high on all fronts. I asked for a meeting with the team, and started with an apology for how things had been handled to date.

Then I said: “Here’s the problem we need to solve: we have multiple customers running version x.y.z who are experiencing serious problems. It’s not a crisis yet. But we can’t wait for version (x+1).0.0 to do something.”

And then I sat back and listened.

Sensing that I wasn’t there to issue an ultimatum, the programmers opened up, and I learned two critically important things:

1) The programmers admitted that working through the bugs would be a painful slog and they didn’t want to do it.

2) They didn’t think it was that important because the new architecture they were working on would eliminate the source of most of the bugs. They genuinely believed that the highest value work they could do would be deliver the new release as soon as possible.

When I further explained that even if we could deliver the new release the next day, customers would still demand that we patch the previous release, the team saw the flaw in their logic. The new architecture was incompatible with the older code base. No matter what we did, we were going to have to address the bugs in the older, cruftier, more error prone code base.

The thing about the “here’s the problem we need to solve” conversation is that it’s an actual discussion. I wasn’t talking to the team, I was talking with them. I gave them a piece of the context they didn’t have; they gave me a piece of the context I didn’t have.

Together we came to the conclusion that we had to do something in the current release, and not wait for the new architecture.

Step 2: Create Momentum

Although every programmer who worked on that product had access to the bug reports coming in from customers, they usually only saw the issues one at a time. They rarely looked at the entire support backlog to see the magnitude of the pile of open issues or the patterns. 

On the rare occasion when a programmer did look at the large pile of customer reported bugs, it seemed like an overwhelming pile of unsolved problems across all areas of the product (the server being just one). Any given programmer wading into the pile would find themselves up to their eyeballs in issues they didn’t know anything about. Anyone who ventured into the big pile ended up throwing up their hands in despair before finding something else to do where they could feel productive.

We were in a self-reinforcing cycle: the pile of open issues felt insurmountable, so no one wanted to tackle it, so it grew larger, and the larger it grew the more insurmountable it felt. We had to break the cycle.

The solution wasn’t just to get people access to the data; they had that. Rather, we needed to create visibility that would support a sense of momentum.

We started tracking open customer issues by team, and by severity. We set a goal of driving down the open highest severity customer issues for each team down to 0. Product leadership partnered with support to make sure each team knew about the support cases that were relevant to their part of the code base. Individual product managers prioritized the most critical bug fixes and made sure they were delivered in maintenance releases. Every week the numbers went down. Eventually the effort took on a life of its own. The pile felt surmountable; over time we conquered it.

Note that this is not a story about how awesome metrics are for driving behavior in an organization. That would be a dangerous lesson to take from this story. Metrics are a double-edged sword. If you manage people by numbers, you get number-based compliance. High severity issues end up reclassified as “medium” with little to no justification. People squabble over whether or not something is a bug just because they want their numbers to look better.

When we started sharing a dashboard of bug stats, we made sure that no one was rewarded for achieving a low number, or penalized for having a high number. We celebrated together when the numbers went down, but no one’s performance assessment was tied to the numbers. Further, the numbers were just a proxy for the list of issues. Although we all looked at the same dashboard of numbers, the real information was in the list of issues rather than the count of how many issues. Week after week, seeing the list get smaller felt much better than just seeing a number tick down.

It’s All About Transparency and Respect

As a leader, your job is to inspire people to do their best, working toward a common objective. You could try “rah rah” cheerleading, or coercion, but neither approach will forge the same kind of relationship or results as creating a culture of transparency based on mutual respect.

Start by assuming that the people you are leading are smart and well-intentioned. They will do the very best they can under the circumstances to deliver the highest value they’re able.

When you need to intervene to change course, assume it’s not because people aren’t doing their job. Instead, assume that your team does not have something they need, or that they see the situation differently from you. Then have an open conversation. Start with “here’s the problem we need to solve.” Make sure you are aligned on the problem statement. Then work together, sharing information and perspectives, to determine how to move forward.

There may come a time when no matter how much information you share, the team still disagrees about the best path forward. If that happens, it’s OK to say: “I’m going to need you to trust me on this one. We need to go this way…” 

That moment is the ultimate test of leadership: if you lead, will they follow?

By having treated the team with respect, not asking for blind obedience but rather including them at the table when making a decision, you are very likely to have earned their respect, and they are much more likely to follow you when you most need them to trust your judgment.