We’re Hiring!

New Bamboo Web Development

Bamboo blog. Our thoughts on web technology.

But where does the buck stop?

by Sam Whiting

I hear it said quite regularly when a hierarchical culture meets a more open, autonomous one: "The problem with agile/Scrum/[take your pick] is, where does the buck stop?"

The unspoken thinking underlying the complaint is this, I think. Traditional, hierarchical organisations have some of the greatest impact in the world - pick any national government or multinational corporation if you want an example to illustrate this point. Their success depends on certain features of their organisational structure, like the way responsibility, credit and blame are allocated - namely, at the level of the individual. Any new 'method' must conform to hierarchical standards of responsibility, credit and blame.

People who are used to applying the carrot (money, power) or the stick (shouting, disciplinary action) to individuals often find these tools are just ineffective on empowered teams. Sometimes agile/Scrum/[take your pick] gets rejected as a result. Other times you see targets set for each for individual within an empowered team, thus re-enabling responsibility, credit and blame on an individual basis; an awful mishmash that pleases no-one.

Let's proceed from this brief anatomy of a culture clash to an autopsy. What happens when a project goes wrong?

Project Autopsy

Imagine (or perhaps, remember) the typical thought patterns of a hierarchical organisation confronting a failed project:

A particular activity - e.g. business analysis - didn't happen, or it wasn't done well enough. That's because no single individual had responsibility for the task. Let's hire a Business Analyst, whose job that'll be from now on. Hey presto, now there's a place for the buck to stop! We can apply carrot and stick to them and prevent future failures.

It can be similar when the organisation engages in forward planning - identifying all the points where something might go wrong, parcelling them up into job roles.

I've certainly seen this approach in action, and it's mental. It's backwards engineering a business from presumed failure! It's also not particularly nice for the people who hold the buck-stop roles.

My Conclusion: Role vs. Responsibility

I started by saying that hierarchical organisations have massive impact. In general that may be true, but in complex projects where knowledge workers are required and there's a lot of uncertainty around - like building software which, lest we forget, is eating the world - the impact is largely in the papers, who are loudly shouting about the huge mess that has been made!

The role-based approach I've described above actually has the opposite effect from what is intended. That's because by explicitly making an individual accountable for just one aspect of a project, you immediately excuse everyone else from having to think about it. The "it's not my responsibility" circus begins.

In a complex system, one set of eyes - one person in one role - cannot see the whole problem. Complex systems require everyone involved to care about solving the problem: in a short, they require shared responsibility. Conversely, when you assign responsibility by role, each person will only act on what directly prevents them from being blamed for anything.

The conclusion I draw from this is that it's important to distinguish between a role and responsibility. It's perfectly legitimate to identify a skill that your team lacks. But for motivated, empowered knowledge workers, it's crucial to allow teams to add this capability to themselves. Shared responsibility is the best antidote to jobsworth syndrome I've ever seen.

And beyond that, doesn't it just make sense? Wouldn't you prefer to set up your business for success, rather than so you know who to blame when things go wrong?