The fundamental attribution error and accountability

A while back I was talking to a manager who complained that “no one” in his organization was “accountable.” Of course, he exempted himself form that category.

This manager, (I’ll call him Tom) feels like he’s accountable— he knows that if they people creating software products don’t get their work done, he’ll hear from his boss, and it won’t be fun. So, Tom schedules meetings, hands out plans, talks about urgency and exhorts other people to do their work.

I asked Tom to draw me a picture of how the work was organized in his company. It was quite a tangle. The development groups (UI, DB, middleware, apps, test….) live in silos and report to different functional managers. The project managers sit is another organization, from where they coordinate project work across the development groups. Each project manager manages four or five projects. The development folks are likewise forced to multitask, as they spread their time and attention across a similar number of problems (and have 4 or 5 project managers telling them what to do).

The senior managers change their minds about priority—at the project level—every few weeks. Every one is busy, but not much gets done. Given the picture Tom drew, I was not surprised that Tom feels frustrated.

But Tom’s answer is that they need better people in the project manager and development roles—people who will be accountable.

Tom is not an anomaly. Many managers I talk to believe other people have no innate sense of accountability (what ever that means) and that no one holds them accountable. In fact, most people—regardless of where they stand in the hierarchy—feel that they are held accountable; sometimes they believe that others are not.

How can this be?

Accountability, the way Tom talks about it flows one way. There’s no sense of mutual accountability or partnership. The person telling the story is doing his job; others are not. The manager tells other people what to do, and they are supposed to do it—no matter that the deadlines are madness, people are forced to multitask, the goal is hazy, the requirements shift by the minute, and the folks doing the work don’t have all the skills to do the work.

When people aren’t “accountable,” I wonder what gets in the way of accomplishing work and makes the appear to be “unaccountable.” I wonder if the managers see their job as creating an environment for people to accomplish work. Or whether they think their job is telling people what to do, and then blaming them (read: “holding them accountable”) when organizational obstacles get in the way. And I think about the fundamental attribution error: When “I” don’t finish work or complete assigned goals, it’s because external circumstances prevented me from doing so; when you don’t finish work or complete assigned goals, it’s because of a character flaw—no sense of accountability, in this narrative.

When I look at Tom’s picture, it’s clear that the majority of the barriers are of management making. Deadlines, multitasking, unclear goals , shifting requirements and priorities, hiring unskilled people or failing to adequately train people are all management issues. But somehow that doesn’t come into the assessment of accountability.

When managers do their part and create work systems that makes it easier—not more difficult—to get work done, they usually find that suddenly they have people who are accountable. Accountability is about negotiation and partnership; it is not a cudgel to blame people for not meeting unilateral demands.

Esther,
An important post. There are a few common with “traditional management” making us struggle in agile transitions (blame culture/accountability in your story, incentives, budgeting etc). I’ve seldom seen one of them stated as clearly as in your post.
We can do as many agile practices as we want in our teams – if the systems (and their management) don’t change we’ll not get more effective.
Thanks!
Olaf

Even before you get to Agile practices, you should, I claim, visibly set both the goals, numerically, and how progress toward them will be measured, explicitly. Then you can use Tom Gilb’s Impact Estimation tables to choose the next (quick) steps to undertake. Now Agile is useful.

There are other great tools that Agile ignores. For example, John Shook’s “The A3 Process at Toyota – Managing to Learn” shows a great way to avoid the problems endemic to brain storming and group meetings by conducting a series of one-on-one sessions with involved parties. That avoids all interjetions of “That’s ridiculous!” involving loss of face and bowing to power.

Secondarily, let every communication down a hierarchy facilitate at least “Why?” and “What about x?” in the other direction.

Thirdly, employ at least one Inspector General (Gadfly) (Nitpicker) (Royal Fool) with, say, a guaranteed one or two year posting and guaranteed publishing access to the Board of Directors AND to the Shareholders.