[Off-Topic] Authority vs. Responsibility

Whether you’re rolling out a new methodology or standing up new processes, the number one reason most attempts fail is a single move: handing the authority for that rollout to one isolated person or team.

I’ll say it again: don’t create roles like “Process Analyst” or departments like “Process Department.” Don’t give anyone the authority to design the processes that other teams will have to implement. It doesn’t work. Full stop.

Companies usually assume, as in every spin-off of the infamous Theory X, that most employees have zero capacity to make decisions. So the power goes to someone imagined to be more competent at it. Or they figure a small group decides faster and better than a big one, so they split the process teams from the execution teams.

Every method has a name for this. In PMI it’s the PMO. In Six Sigma, the Black Belts. And no, in Scrum this is not the Scrum Master.

The first problem is that the people assigned to design these processes rarely have any idea what they’re doing. If you don’t understand software, you have no business weighing in on software development, the same way someone who doesn’t understand civil engineering doesn’t get to second-guess a construction site.

Courses, certifications, diplomas, none of it matters. Only someone who understands the craft gets to have an opinion about it, and that’s not up for debate.

The second problem is that this process person or group rarely answers for its own results. It couldn’t anyway: the outcome of applying processes is hard to measure, especially when it spans several teams. The teams, on the other hand, are the ones on the hook when something goes wrong.

And here comes the dumbest outcome of all. By creating a process role or department, the company has split authority from responsibility. Whoever holds the authority to set the processes carries none of the responsibility for the results.

Meanwhile the teams on the front line, accountable for every defect and every complaint, have lost the authority to change their own work the way they know is most efficient.

It should be obvious: never separate authority from responsibility. These re-engineering efforts, run by people with neither the technical chops nor the day-to-day life on the front line, are a pure waste of resources. Don’t even try.

Give the authority back to the teams and guide them instead. Put the people who supposedly know more about process at the teams’ service, as advisors, not as authorities. Encouraging self-organization brings far more real results, because the person who owns the delivery finally gets the authority to pick the best path.

And as I always say, top-down, command-and-control methodology built on “eliminating variance” always ends in failure. Don’t bother.

Want to guarantee failure? Appoint a person or a group to study what they think is the “best process for the company.” Have them work in isolation, with no input from the rest of the company, meaning the very people who’ll have to follow those processes.

To really nail it, do the whole thing in secret, no fanfare, almost nobody in the loop. Then one fine day, fire off a company-wide memo: “as of today, this is how we work, and that’s that.” There you go. Congratulations, you’ve just built yourself a disaster.