% fortune -ae paul murphy


Compromise is generally considered to be a good thing: you have one agenda, I have another, but a compromise provides the middle road we can both support. Right? Not always, and almost never on strategic or design issues.

In both cases a compromise means that somebody's holistic vision of what something could look like, work like, or become gets hacked up to produce something that meets neither side's needs. How bad this gets depends on your criteria and how resilient the original design or strategy is: a couple of Macintosh holdouts won't disrupt an all Microsoft client-server infrastructure, but a single metallized plastic bucket of artificial flowers will destroy the design integrity of a stone and wood setting.

I see the consequences of this all the time in business strategy development: you can no more affect significant business change without creating short term winners and losers than you can make an omelette without breaking eggs, but the people who see themselves as short term losers can often compromise the implementation and thereby force a scenario in which the client organization picks the steps it likes while discarding the harder stuff -and eventually blaming me when this idiocy leads to disaster.

The classic IT version of this is simple: I tell client executives that they can save money while improving reliability by switching to Unix -warning them repeatedly that assigning their existing Wintel staff to the job is asking them to prove themselves wrong. Since most senior managers know that people are people first and professionals second, they understand that people who see Linux as the biggest threat to their social and economic well being aren't going to prove its value by making it work cheaply and reliably, and so they usually agree to bring in some new people. But then what happens? The IT people prevail at implementation time -getting management to compromise on responsibility because IT management argues that they're not Windows experts, they're Computer Professionals - and besides they've got the big gun, the ultimate self fulfilling prophecy: the fact that they can't find properly qualified Linux staff.

The inevitable result, of course, is that Linux proves to be as unreliable, difficult to use, and expensive to support as they said it would be - leaving the organization nicely inoculated against the next attempt to introduce a more efficient technology.

The rule seems to be that once people become willing to engage in reasonable compromise during the implementation of an integrated strategy or design, the disaster becomes almost inevitable - but what's personally most frustrating about the process is simply that everyone later remembers who conned them into trying the strategy or design that got compromised, but nobody even remembers the compromise that caused the disaster, never mind who brokered it.

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.