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.

Momentum > Urgency

Let’s talk about motivation. More specifically let’s talk about what leadership can do to help motivate a team.

Once upon a time, a director of product management and I were butting heads. Let’s call him J (not his real name, or even his real initial).

J was unhappy with the pace at which the developers were delivering. His usual approach to hastening development was to set arbitrary deadlines to create a sense of urgency.

It wasn’t working.

Despite J’s best efforts at inspiring the developers to work harder and faster, progress was moving too slow for his liking.

I was in an engineering leadership role, so J tried pushing on me to push harder on the engineers. Things came to a head when J said to me, in a tone of utter exasperation, “Come on! You know programmers. You have to light a fire under them to get anything done!”

Well, no. I don’t know that. In fact, I don’t think that’s true at all.

Granted, pressure can expedite delivery. However it comes at a cost, and it’s a cost that’s difficult to measure. Pressure and urgency typically lead people to cut corners. That, in turn, can lead to an illusion of speed that comes crashing down later with delays or poor results. But it might not. It could take months or years for problems to arise out of those cut corners. Further, people who operate under pressure for too long burn out. But burnout doesn’t happen right away.

So from J’s point of view, when he was unhappy with the productivity of a team in the past, he ratcheted up the pressure and got the result he wanted. If there was a downside to his approach, he probably never saw it. He was too far away from the work and from the people doing it.

While I don’t know if J left a trail of destruction in his high-pressure-wake before, I have seen the mess that others who used similar tactics to J left behind. In fact, I’ve spent a good part of my career cleaning up after those messes.

What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency.

Consider another project with a very different team dynamic.

In 2008 or so, I was a programmer on the BringLight development team at Pivotal Labs. Drew McManus was both a company founder and our product manager.

We used Pivotal Tracker to manage our work, so we broke the work into bite-sized chunks, tracked as stories. Drew prioritized the stories. When we delivered the work, Drew tried out the new capabilities, and accepted or rejected the story within minutes. Even when he was out of the office for meetings, he would check the tracking tool frequently to see if there was anything for him to accept.

Drew’s responsiveness had a palpable effect on the whole team. We became a delivery machine.

If we were close to delivering a story and had a few minutes before lunch or the end of the day, we’d push through and deliver the story. We knew it made a difference. More often than not, Drew would have done his acceptance before we got back to the keyboard. There were times Drew accepted a story while sitting in a coffee shop, then demoed that new story to a VC just minutes later.

Each acceptance fueled the next delivery. We never rushed. We never cut corners. (Drew was just as good at rejecting stories as accepting them.) Instead, we worked with a sense of focus and purpose. It also helped that Drew had a strong overarching vision of what we were building, so as we broke down stories to bite-sized pieces, we could still connect them to the larger vision.

Drew and I are still in touch, so I know how the story ended. He and his partners eventually sold the company. Before that, the code we wrote ran in production for years with no substantial defects. After go-live Drew hired a solo part time developer to handle routine ongoing maintenance.

BringLight is not the only time I’ve seen a team benefit from a sense of momentum, it just happens to be one of my favorite stories.

Every time I’ve seen a team achieve a sense of momentum, several things are true:

  • Everyone on the team has a shared understanding of the big picture and what “good” looks like so they don’t burn cycles on unnecessary or non-useful work.
  • The team breaks the work into small pieces (a couple days of work at most) that still represent incremental business value (even if not user-facing features).
  • The team embraces the technical practices necessary to ensure that the code they deliver does what they intended it to do.
  • There’s an engaged and responsive product manager* who is considered part of the team, and who does hands-on acceptance of the work.
  • When the work is “accepted,” it’s done. The entire team can stop thinking about it.
  • The work, and the status of the work, is visible to everyone.
  • The team as a whole has a strong sense of partnership and trust, so the visibility never becomes a mechanism for micromanagement.

There is nothing on that list that’s easy, but it’s worth the effort. Creating a sense of momentum remains the very best way I know to enable long term sustainable delivery. Even improving along a subset of the dimensions in the list can yield huge benefits.

(Oh, and if you’re waiting to hear the end of the story about J, I’m not going to go into details. Suffice it to say that J and I never did figure out how to partner effectively and we didn’t work together for too much longer. In the fullness of time, some time after J left, the team he was trying to pressure did eventually improve their ability to deliver…by developing a sense of momentum.)

* In some cases the person doing acceptance may not have a product manager title or report into the product organization. They might be an engineering manager or a tester. The key thing isn’t the title of the person doing acceptance, but rather the extent to which “accepted” means “done.” If someone in QA accepts a story, but later the team is forced to redo the work because someone in a position of authority had a different vision and is dissatisfied, “accepted” stops meaning anything.