Who’s to Blame?

When bad things occur, we often want to blame others for the problem. Blame is comforting in the moment and not useful over time.

I had a conversation the other day with a manager whose team is trying to use agile. “They’re not using continuous integration. They’re not testing enough. I don’t know what to do with them.” He sounded distressed. He was frustrated and blamed the team for not delivering.

I asked him, “What do you measure?”

He responded with “earned value, velocity, story points done,” and a number of other surrogate measures.

I asked him if he used “running, tested features” or working product as measurements. No, he did not. Would he consider alternative measures? He would and did.

The team was still not able to deliver what he wanted them to deliver. However, now he could see why. (The manager had been asking them to work on multiple projects and to do “more” points per iteration. However, the team did not have the people it needed, and with surrogate measures, he did not realize he was the cause of many of their problems.)

When I asked him what he learned, he said, “When I want to blame the team, I should first look at myself. I did not ask them for what I wanted. I was frustrated when they gave me what I asked for, but not what I needed. I need to learn more about this agile management stuff.” (I had expected him to discuss more about measurements, not his reaction. I was thrilled!)

When I am ready to blame others, I also need to look at myself first.

You might find some of these questions better than “Who’s to blame?”:

  • What happened? (A data-gathering question.)
  • What changed? (More data-gathering.)
  • What haven’t you changed? (Yet more data.)
  • How does this issue/challenge/problem affect you? How does it affect me? (What is the meaning to each of us? You might be able to see system-level impediments with this question.)
  • How do you feel about this issue/challenge/problem? How do I feel about it? (What is the significance of this to each of us?)
  • How will we generate solutions for this problem? (Will we work together? Can we? Do we need to each develop a strawman of potential solutions? Can we use the Rule of Three or experiments? Do we have constraints? Guidelines?)

Blame might be the first place you go, emotionally. Okay. Ask yourself this meta-question: Do you want to blame or solve the problem?

If you want to blame others, okay. If you are like me, you won’t get what you want, but you can blame all you want.

If you want to solve the problem, consider the other questions. Add more questions that help you understand the entire problem and what might need to change.

That is the question this week: Who’s to blame?

4 thoughts on “Who’s to Blame?”

  1. Sometimes there’s blame to go all around.

    At my last gig I conflicted heavily with the guy who ran Dev. He subtly and effectively undermined anyone he didn’t like. His team kept delivering poor quality code to my testing team, which kept throwing us off schedule, and I kept holding him accountable for it. So soon he turned his ill attentions to me, and I and my team were being perceived as “not keeping up.” When the company needed to shrink its workforce last summer, it wasn’t very surprising that I was chosen to go.

    I could blame him. Actually, I do, in large measure. I’m very glad to be away from him. But there are some other truths here. One of them that this company’s values allowed a fellow like him to operate. When I discussed with my boss and HR what I was seeing and experiencing, I got shrugs, basically. The last boss I had told me point blank that she saw me as the source of the problem. From their perspective, he was delivering, and that’s all that mattered.

    But, frankly, the other truth is that I felt unsupported and backed into a corner, and responded by behaving passive-aggressively toward him. I regret it. It made things worse and was not coming from the best part of me. And I’m sure now that this is why my boss blamed me. This was an extraordinary situation for me, but if I could rewind the tape I would have simply gotten out when the tables started to turn, rather than trying to fight it to the bitter end.

    1. Jim, I also suffer from hindsight…

      Here’s what I find fascinating about your story. He didn’t do root cause analysis (gather the data) about why you folks were off schedule. I suspect you explained it to him several times.

      That goes to the organizational culture, which you highlighted “the company’s values allowed a fellow like him to operate.” When the other management shrugged, they allowed him to blame you. They did not gather data. Software orgs do this when they think the testing is separate from development. You need both for a product. You can separate the people, and you need both.

      The fact that you felt unsupported was real—part of your data. Yes, you might have addressed the problem differently. Thank goodness we can learn.

      If you are in a blaming organization, it makes sense for you to leave. Unless you can somehow change the culture, it’s not worth the aggravation.

  2. Astrid Claessen

    I find that for some problems (systemic dysfunctions) there is no point in assigning blame. There are multiple causes to the symptoms we are experiencing in organisations.

    Besides that, I’m usually pretty good at assigning blame to myself: because I’m haven’t been able to solve or explain the problem…. but you learn to go easy on yourself as well.

    My challenge is to help other people see past the symptoms so we can address the real causes which solves the problems (or at least makes some problems smaller).

    1. Astrid, hmm, going easy on myself. I’m practicing that still.

      Yes, discovering the root cause is key to eliminating blame. I find that it’s often the system, not the people.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: