% fortune -ae paul murphy

Waste bubbles

I'm very disappointed in the lack of answers to last Saturday's question - so, please, look past your own political biases to consider the actual question, ok?

Now, since answers are the order of the day, let me tell you about the number one thing that comes up in discussions as we work toward figuring out how to change a whole bunch of different business systems. It's the claim that because the existing systems and processes contain lots of terrible inefficiencies and waste, they can be fixed by eliminating those.

I have a theory about this: that when the best available people do the best they can to implement policy, the waste and inefficiencies in the system they produce reflects the degree to which the policy fits the problem it's intended to address - not the skills or commitment of the people involved.

If, for example, your intent is to provide a few thousand users with secure, reliable, desktop computing, then a Windows policy produces tremendous waste and inefficiency in everything from networking and help desk services to user time and executive access to information - but those inefficiencies are not a result of incompetence or malfeasance on the part of the implementers or users, they're a result of the decision to prefer PCs over Sun Rays and thus ultimately a result of executive hiring preferences and the organizational role set for IT.

Ever hang wall paper? Once you've got a couple of bubbles trapped under a sheet squishing them out in one place generally just causes them to pop up somewhere else - often fatally creasing the paper in the process. Business process repair is just like that: if you see a process that has obvious waste bubbles and good people have been trying to squeeze those out for years, then you need to decide if those bubbles are significant within the scope of whatever you're trying to achieve. If they are, the answer is always to change the policy first, never the people - and only after you define the new policy do you ask whether the people you've got are the right people to implement it.

The bottom line on this is that it's generally the policy makers, not the implementors, who're to blame when systems and the business processes within them don't work out as expected. The question, therefore, that I keep asking people who grab the podium to denounce so and so as an idiot and this or that as retarded, is first whether they understand where the particular bubble came from, and second whether given the constraints the various idiots pointed at work under, it really is possible to do better - and, so far, not a single accusation has survived the question.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.