Thinking about the B-word recently … it seems that Bureaucracy doesn’t solve any problems; all it does is organize the solutions you already have, to make them more effective.
Which I think is why bureaucratic procedures MUST be updated, changed, revised, and replaced on a regular (almost frequent) basis. I vaguely remember that Lou Gerstner’s book on how he saved IBM in the 1990’s had some details on why bureacracy is good, and what it is.
It’s also why most attempts to introduce bureacracy fail to have any beneficial effect, and instead waste the time and energy of everyone involved; not because bureaucracy sucks (which is the impression most people get, quite understandably), but because it exposes and highlights all the other problems those organizations already had but were doing nothing to solve.
Sadly, in my experience the process usually seems to go something like this:
- Have a bunch of tricky but not impossible problems
- Management and/or staff lack one or more of the time, skill, experience, or courage to deal with them, or (for one of those reasons) grossly underestimate the scale of the problems
- Someone introduces bureaucracy to try and “solve” them rather than actually summon the energy or the courage to do the solving part themselves
- Bureaucracy takes lots of effort to introduce, and SEEMS to end up “making things worse”, because it exposes more eloquently the problems, so that more people see more problems than they saw before
- Management write-off the bureaucracy as a waste of resource
- Management ignore the problems that are now painfully, glaringly, obvious (as revealed by the bureaucracy)
- Management never does bureaucracy again, blames all the existing problems on bureaucracy, and hopes that by ceasing to do any bureaucracy those problems will gradually go away of their own accord.
If you introduce bureaucracy without knowing HOW and WHY it will solve your problems, then you are relying on nothing more solid than blind hope. Hope is not a strategy.
One reply on “Bureaucracy”
That totally makes sense to me, and I now understand why I’ve seen code review fail in so many places.
The bureaucracy of code review brings to light problems in the code, the team’s personality, coding standards, architecture standards, rewrite procedures and even the basic most basic assumptions on how code should work. If the team can’t agree on that, they’re not going to agree on it in code reivew, and they’ll blame the review, rather than their actual coding process.
That’s actually very eye opening for me. I’ve known for a while that you can’t take crappy coders and good process and expect good code, and (in my opinion) you can’t necessarily take good coders and crappy process and expect good code. Joel (on Software) harps on this all the time. Sill, I’ve never really seen anyone really explain why in a way that makes perfect sense. This explains why. Good process doesn’t solve your problem of crappy coders, and actually tends to expose the problem. However, it can heavily improve the output of good coders by allowing them to spend their time more effectively.