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.

The Transition from Product to Solution

When selling enterprise class systems, there has been a very long standing shift from products and a product focused mindset to solutions and a solutions focus.

Interestingly, this trend is not new. The first "solution selling" literature for technology shows up very early, around 1975. The reason I find this interesting is that almost every enterprise class technology company seems to go through this model. I have not done an exhaustive study, but my personal experience is that "young" companies are very focused on their technology and making a better widget. As they and their market matures, the focus changes inevitably to solutions and solutions selling.

The reason I bring this up is because it seems that most companies who sell into enterprises sooner or later realize that selling a complete solution and focusing on core business issues within their target customers helps them to realize better sales and makes their accounts "stickier" over the long term. This transition many times starts with the sales or consulting organization but inevitably seems to percolate down into the engineering teams. The funny thing is that engineering’s first response to this change is to simply take products and rename them solutions despite the fact that they’re not actually solutions. If you sell an accounting software package, it magically becomes an accounting solution overnight.

Naturally, customers are not actually fooled by this behavior. For this reason, the word "solution," like so many others in our business has become completely devalued. This is a shame. Personally, I am a big believer in the solutions orientation. I think that this comes from my background in enterprise consulting and then as a pre-sales engineer. When you talk to customers every day, it becomes really apparent that customers are trying to buy solutions to their business problems. Unfortunately, that’s not always what we’re selling. That causes a disconnect between the customer and the vendor. Some sales organizations respond with marketing. "Our product is the solution to your problem." Marketing is great, but it doesn’t address the key issue here. Products that are designed from the inside out are difficult to sell because they don’t take the user’s perspective into account.

This is not to suggest that product organizations should simply take user input at face value. This also leads to bad products because in reality most users don’t really know what they want. This disconnect between stated want and actual customer NEED is difficult to discern in many cases. The truly great product organizations seem to simply KNOW what customers really need even when the customers don’t realize they want it.

Aside from the "just be really smart" plan, how do product organizations focus their efforts on the correct features and meld those features into a true solution for their customers?

One, obviously, is orientation. Are you solutions oriented in your approach? Does the overall customer solution drive your product plan? This is an interesting consideration because it seems like the simplest part of the puzzle, but in reality, it’s very tough. What normally happens is that product teams tend to focus narrowly in order to get things done. Building software is really hard and you have to specialize to do it well. In larger organizations, this leads to people on the product team who develop tunnel vision in order to ship their particular product or feature. While shipping is very good, it is useless unless your product serves some greater purpose. For smaller companies, it’s sufficient to be a one trick pony. Especially if that trick is really, really good. Look at Google. I would love to have their problem of "only" a single multi-billion dollar business. However, for them this is a huge problem. Fundamentally, Google has only one product, search. Everything else at Google must serve that master. This colors their view of the world to an extreme degree. It is very difficult to step away from that and do something completely new but still be loyal to the success that made the company possible. You have some really brilliant people at Google and yet they have failed to develop a second multi-billion dollar business. Same with Facebook but they are a bit younger. Only time will tell if these tech titans will become true powerhouses with multiple billion dollar businesses.

Compare Google to Apple or Microsoft. Apple (with a little help from Microsoft) was able to survive a near death experience after losing the PC war to Microsoft. Now, they are incredibly dominant in the personal electronics business to the point that they have basically killed Sony (remember they invented mobile audio). Microsoft has pioneered several businesses that have become multi-billion dollar businesses. While everyone knows about Windows and Office (and yes, you must count them separately) some people forget about the enterprise business with Exchange, SQL and SharePoint. Xbox is also the dominant platform in the gaming business despite tough competition from Nintendo and Sony. Both Apple and Microsoft have managed to create new businesses related to but outside their core competency and to make them successful. How is this possible?

In the case of Apple, I believe it is the core focus on the design of their products and the overall user experience. In consumer electronics, this was sorely lacking before they came along. I had several MP3 players before the iPod came out but none of them offered a complete experience that my grandmother could use. Instead of focusing on how much storage or how fast it could rip an album, they focused on the core solution which was to acquire and play music for the consumer.

At Microsoft, I witnessed the shift from product to solution first hand. The transition was not easy and it took several years, but today Microsoft as an organization understands how to build and sell products to their core Enterprise IT audience. For example, instead of competing with VMWare head on with Hyper-V, they chose to focus on the management aspects of Private Cloud. Microsoft quickly realized that in the end the Hypervisor is a commodity feature just like file and print. It is management and other usability issues like pricing that will determine the winner in the Private Cloud age. This is not a new playbook for Microsoft. In my day, the key competitor to Windows Server was Novell NetWare. In those days, Microsoft faced a heavily entrenched competitor with what was arguably a better product. NetWare was a great file and print platform. The obvious tactic would have been a frontal assault where Windows simply copied NetWare features. Instead, Microsoft made their file and print solution "good enough" to be reasonable and focused on running applications like SQL Server and Exchange on Windows Server. Now you had only one platform with a common set of tools to do everything. By the time Novell realized what was happening; Windows took away their core market.

We used to refer to this as the "technology fallacy." The fallacy is that the best technology wins. In reality, that is only one small piece of the puzzle. Technical excellence does not usually lead to market dominance. There are endless examples of better technology losing out to price or convenience. Look at Beta vs. VHS…. Or SMTP vs. x.400… Or even (sorry guys) Windows 3.1 vs. Mac. The Mac was way ahead of Windows at the time and yet they lost. They just could not compete with 100 hardware providers all killing themselves to lower the equipment cost by a dollar. In the end, the cheap PC clone killed the Mac as a serious threat to Windows. Was the PC better? No way in hell. But they sold millions of them because they were cheap and they got the job done. Yes, I am aware that iOS is causing a comeback in Mac land, but in the days of PC vs. Mac, the PC won and Apple nearly went bankrupt. Apple is an iOS company now, the Mac is a sideshow. Just look at the numbers if you doubt this.

So, how do we apply this lesson to our business and why should we, as IT people care? It goes back to concept or orientation. Are you oriented correctly? What business are you in? Are you and your team oriented correctly to make that core business successful?

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. And 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.