Are You Focused on the Wrong Thing?

As an IT organization, I submit that you are probably thinking and worrying about the wrong things.  The idea that you are fundamentally an engineer and that you provide technical support to the organization is getting very outdated.  The traditional IT organization was created because of the mind-numbing complexity inherent in early computer systems.  In the 1970’s it was not uncommon for large shops to write their own operating systems or transaction processing systems.  This type of task is hugely complicated and requires a skilled and dedicated team to pull it off.  The results were similarly huge.  The ability to go from paper processing of customer records and billing transformed American businesses. 

Unfortunately, we as IT folks have found more and more technical complexity to dive into.  We’ve been able to focus on distributed computing, private Intranets, custom developed internal portals and all manner of cool things.  Thus the ABILITY to solve complex technical challenges has resulted in our WILLINGNESS to solve them.  It’s a bit strange really, and reflects the rapid pace and relative immaturity of our business that we still operate this way.

Think about other core services that our parent companies consume.  Do they operate this way?  Perhaps, if it’s truly core to your business.  FedEx, for example does all their own maintenance on all their jets and trucks because they feel that’s core to what they do.  On the other hand, the corporate pool car program has completely faded from the American corporate landscape as folks realized that their employees already had cars.  In our business, the IT organization is quickly moving from a necessity to something that you can probably do without.  This motion of technology from leading edge to commonplace and dull is normal for us, but the underlying business model change required to reflect this obvious change is much harder for us to internalize.

The implications of these changes are still beginning to trickle down into the operational philosophies of our IT organizations.  Things that “were always done that way” are usually incorrect simply because they’re old.  Any standard or process in your organization that is more than a year old should seriously be looked at.  After all, the technology you are supporting has changed.  Why shouldn’t your operational procedure change along with it?  I think that I don’t need to belabor this point.  If we are honest, we all understand that we are in a very fast moving business and that we need to be adaptable to change.

If we accept that basic fact, then we begin to see the core of the problem.  The reality is that technology is changing way faster than our organizations can adapt.   This means we either get picky in which things we implement or we are continually chasing the latest bright, shiny object that comes across our field of view.  This implies a very strong set of filters that prevents us from chasing things that don’t have high value to our organizations.  It is the development of these filters that I think we can generalize and discuss outside the context of each particular organization.  It is almost impossible for me to say if a particular technology or architecture adds value to a particular organization without spending some quality time with that org.  On the other hand, I think that we can establish some ground rules that will help you drive things like technology evaluation and prioritization.

Not surprisingly, the answer revolves around the question of WHY.  Why are we doing what we are doing?  The “BECAUSE” part of your answer is usually where we succeed or fail.  The “WHAT” part is where spend most of our time but turns out to be one of the least important parts.  The reason is that WHAT we are doing becomes pretty meaningless if we are doing the wrong thing.  Take an extreme example.  Let’s say I asked you to build a bridge.  A really big bridge.  Let’s say we started talking about stressed concrete, suspension spans, all kinds of cool stuff.  We get really into it and decide to build a suspension span.  The best suspension bridge in the world.  What’s missing?

Why are we building the bridge?  Let’s say we are building the bridge to connect two towns of 100 people each.  Total expected traffic is 10 cars a day.  Did we build a good bridge?  Not really.  And what happens if we build the bridge with railroad tracks for higher density.  But, there is no railroad within 100 miles of the bridge.  Was that a good idea?  Yes, extreme example, but you get the point.  It’s the context that matters.  Why are we building this bridge?  Who will benefit?  How will they benefit?  How will their lives be better after we’re done?  Can we do the same thing for half the cost in half the time?  Perhaps they’d prefer the simpler answer if they knew they could have it in six months instead of six years.

In our case, the context is much more complex than just driving a car over a bridge (with all due respects to traffic planners and engineers out there).  We all drive cars and at some very basic level this example makes sense to us and some of the more obvious errors would never get made (build a railway bridge where there is no railroad for example).  In the technology business, very obvious errors like that get made all the time.  We buy hardware to support applications that never get used.  We solve problems that don’t really exist.  We write white papers that nobody reads.  Part of this is due to complexity.  As enterprise class IT organizations, we are usually serving a very complex business.  It is simply not possible for us to understand the complexity of even the simplest Fortune 500 class business.

One way to deal with complexity is to model the complex system using simplified concepts and abstractions.  Naturally, this exercise is in its self dangerous because the abstractions can lead to error if the model is wrong.  To correct for this, we need to ASSUME that the model is wrong and continually course correct based on feedback mechanisms.  By assuming error in the system, we allow for forward progress but recognize that our process is not and cannot be perfect.  Thus the concept of “continuous improvement” made so famous by the Japanese.  We assume that our process, our assumptions and our plans are flawed.  We proceed anyway and then see where problems crop up.  By remaining nimble, we allow ourselves to respond to the largest threats and allow potential threats to go unaddressed since they never actually occur in real life.

All of this thinking brings us, of course, to the Customer Centric IT organization.  In a customer centric IT organization, we obsess over our overall customer experience.  Are our customers happy?  Why or why not?  What are the top ten issues customers are reporting?  What are the key pain points that they haven’t addressed?  And this is where it gets messy.  You need to really understand your customer in a fundamental way.  They only way you can do this is by spending time with them.  Call them focus groups or just taking people out to lunch.  If you do not have a direct and personal relationship with your target audience, you will never understand them.  If you do not understand them, your ability to predict their needs will basically be zero.  And it is the ability to PREDICT their reactions that we really need to develop here.  IT isn’t magic.  It isn’t cheap and it isn’t quick.  If we simply react to expressed user requirements we will never achieve our goals of driving the organization forward.  It is the ability to PREDICT their responses in advance that separates the truly great organizations from the mundane sort that we’re all trying to avoid.