[Off-Topic] Authority vs. Responsibility

Whether you want to apply a new methodology or implement new processes, the number one reason most attempts fail is this: giving the authority for that implementation to an isolated person or team.

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

Companies normally assume — as in every derivation of the infamous Theory X — that most employees have zero capacity to make decisions. So power is given to someone who is imagined to have more capacity to do this. Or alternatively, it’s assumed that a smaller group can decide more quickly and efficiently than a larger group, so process teams and execution teams are separated. In PMI this has a name: PMO. In Six Sigma, they’re Black Belts. No, in Scrum this is not the Scrum Master.

First of all, these people or groups designated to design processes typically have no idea what they’re doing. Whoever doesn’t understand software has no business giving opinions on software development — just as whoever doesn’t understand civil engineering shouldn’t be weighing in on construction. It doesn’t matter if they took courses, are certified, have diplomas, or any of those other inert and ineffective activities. Only those who understand the craft can give any opinion about it. This is not open to discussion.

Second, the person or group handling the process typically has zero responsibility for its results. They couldn’t have any, because it’s hard to measure the outcome of applying processes, especially when they affect more than one team. But the teams themselves are held accountable if anything goes wrong.

And here is the most idiotic outcome of all: by creating a role/department for processes, the company has effectively separated authority from responsibility. That is, whoever has the authority to determine the processes has zero responsibility for the results. Meanwhile, the people and teams who are actually on the front lines — who are accountable for every defect, every complaint, and everything else — have lost the authority to modify their own work in the way they know is most efficient.

It should be obvious: never separate authority from responsibility. Any of these re-engineering processes, carried out by people who have neither the technical experience nor the day-to-day front-line experience, are pure waste of resources. So don’t even try. Instead, give the authority back to the teams, guide them, and put the people who theoretically have more process knowledge at the service of the teams — as advisors, not as authorities. Encouraging self-organization brings much more effective and real results, because finally the person who bears responsibility for delivery will have the authority to choose the best path forward.

And as I always say, top-down, command-and-control methodologies based on techniques to “eliminate variance” will always fail — so don’t bother.

Want to guarantee failure? Appoint a person or group to study what they think is the “best process for the company.” Have them work in isolation, without the rest of the company — the people who will actually have to follow these processes — participating. If you really want to guarantee failure, do it in secret, without much fanfare, with almost nobody knowing. On a given day, send a company-wide memo saying “as of today, this is the new way we work, and that’s that.” Congratulations — you’ve successfully engineered a disaster.