Calculated Obsolescence

Mark Howell —  August 21, 2006

How often have you dropped a program?  Ever found yourself determined to drop a program only to be the first to blink when your decision was challenged?  Why is it so tough to kill a program even when it clearly isn’t succeeding but especially when it is working to a degree?  Those are the toughest, aren’t they?  When a program continues to draw people but really doesn’t line up with what you’re trying to do overall.  Which leads to what The 7 Practices of Effective Ministry refers to as sideways energy.  What a great term for that sense that a program is taking lots of energy to produce, and people are participating, but there really isn’t a very strategic outcome.  At the end of the day these are the kinds of events or programs that are more like cotton candy than anything of substance.  They look large and impressive.  But like my 11 year old says, "it’s really just sugar.  Can I have some cotton candy?"

So what is the solution to the problem of sideways energy?  Peter Drucker suggested calculated obsolescence.  How’s that for descriptive terminology?  Calculated obsolescence.  Here’s what he wrote in the August 5th reading from The Daily Drucker:

"Innovating organizations spend neither time nor resources on defending yesterday.  Systematic abandonment of yesterday alone can free the resources, and especially the scarcest of them all, capable people, for work on the new."

Now, I don’t know about your organization but I know for sure there are some very talented players who are working hard at yesterday’s ideas, keeping those fires burning, making calls, lining up teams, trying to secure budget and make sure there baby is being promoted…long after the program they’re passionate about eased onto that great off-ramp of strategic initiatives.  What will we do about it?  Do we have the courage to systematically abandon yesterday in order to free the resources for tomorrow?  Or will we just impatiently wait for it do to die on its own?

What do we need in order to implement calculated obsolescence?  We need to know where we’re going.  We need to know what it looks like to get there, and what steps lead to there.  And then we need to determine to do only the things that lead to there.  Everything else is sideways.

Mark Howell

Posts