When process goes bad

Imagine this scenario... you've discovered a way to add one thing to your product that will double its usability. Just like that. And it's not a big deal to add. Or so you thought...

You bring it to your manager who discusses it with other people (people you're not allowed to talk to directly... you know, chain-of-command and all), and the answer comes back, "No". Why? "It just won't work with Our Process."

The systems, policies, procedures aren't set up to incorporate your proposed change, and nobody's willing to think about changing things. It would just be too disruptive. It would make too many people uncomfortable.

And we wouldn't want that.

Obviously there are times it doesn't make sense to shake up your hard-fought, well-tuned systems. Where the tradeoff doesn't justify it. But you all know what I'm talking about here... the times when NOT changing makes no sense. Or at least it makes no sense to those outside. Those with a perspective not colored by inertia, bruised from past experience, or threatened by new (and potentially better) views.

Too many times I've heard "upper management" assume that when employees (or users) insist that what the company is doing makes no sense (e.g. a policy that punishes customers or pisses off employees), it must be because the employee just doesn't get it. The employee doesn't have all the facts and doesn't see things from the "higher" perspective of management. The employee doesn't see the Big Picture.

Sometimes... sometimes that's bullshit.

Sometimes the employee or user is the only one who DOES "get it". Sometimes it's the lower-level (or at least more user-facing) employee who really knows how damaging a company's policies can be, or where the points of leverage really are. Sometimes it's the user who has a basis of comparison -- who hasn't bought into the company's worldview so long that they can't see any other reality.

I don't want to be too specific with names, but here are some examples I've experienced recently:

* A particular mechanism for annotating code in a book or manual would dramatically improve usability for the reader/learner. But the documentation department can't do it because their ancient desktop publishing system won't support two "layers" intersecting. Usability (and even innovation) takes a back seat to an old production system for which many cost-effective alternatives exist, but... it would still mean change and learning curves and discomfort amongst the production staff.

* A large software company decides to go after one of its biggest outside evangelists because the big software company has a policy that says "if anyone is going to make money from training on our products, it must be us." Stupid. Stupid. Stupid. (And from a systems persepctive, pretty much the worst thing you can do.)

* A bestselling author has found a way to reduce technical errors in first printings by as much as 70%, at no cost to the publisher using a peer review system that involves volunteers. But the publisher's copy editing process cannot cope with the shift in timing and granularity of copy edits (despite the fact that the average technical book reader considers tech errors about 10x worse than grammatical errors). [FYI - I'm not talking about O'Reilly or Osborne]

* A fast food company demands that all clerks MUST "upsell" the customer, regardless of the customer's order. That means even when the customer does order a drink and fries to go with their meal, the order clerk is required to ask the customer if they'd like some other [insert specific thing] to go with it. That demans the employee and pisses off the customer, but The Policies leave no room for judgement calls about when it is or is not appropriate to upsell. It's always, end of story. Besides, it's not like a fast-food clerk has enough of a brain to make a good decision about that anyway. Right?

* A large software company insists that the documentation team not use contractions in their writing because "they don't translate well." So, they suck the life out of the user documentation to compensate for the poor quality of translators they use.

* A word processor that insists on capitalizing the word boolean as Boolean. Or that insists the code line:


public static void main (String[] args) { }


is actually:


Public static void main (String[] args) { }


* A software company's editorial staff that has all the control with none of the technical knowledge... who takes a book on web technologies and manages to turn HTTP POST into HTTP Power On Self Test. And who thinks that a database that's not normalized is actually... a somewhat unusual database". (Yes, that's a true story.)

* Don't get me started on all the stupid customer service related policies companies have that make no sense (well, at least not if they ever want those customers to come back) for things like returns, refunds, repairs, etc.

Gosh, I guess I decided to return to blog world with a little rant : )

So... think about your policies and systems and procedures and process. I have this terrible fear that I'm going to be doing the same thing -- justifying staying with a production process -- even when it would be better for the user (or the author) to allow for more creativity, flexibility, and change. If today's business mantra is "change or die", we should all be looking for ways to make sure we don't fall asleep in the comfort of our working systems. And boy do I know how seductive those comfort zones can be...

As Jayne Howard (and others) have said,"If you are not living on the edge, you are taking up too much room."