C-suite talk: the siren song of low-hanging fruit

This story is a case where the everyday world reminded me of the challenges executives face every day, choosing where they will invest their treasure of time and company resources.  The Meyer lemon tree in our south Florida backyard has rewarded us with a big crop this year, literal low-hanging fruit.

Meyer lemons almost touching the ground. Low-hanging fruit

The phrase is beloved of vendors and service providers, promising great rewards for doing easy things. Business cases and ROI studies tell us they are going after low-hanging fruit as soon as you give the go-ahead to their project.

Chances are, you've worked hard and made good choices already, or you wouldn't have that C in front of your title. There's not a lot left that's near the ground.  But maybe we can turn the metaphor around and think of some other lessons to learn from the saying:

• Someone had to plant the tree.  High-reward/low-effort opportunities rarely just appear out of nowhere.  There are cases where the confluence of emerging technologies (tech triggers) makes a new LHF situation appear (web-based applications and cheaper/faster/more reliable network access, for instance, make IT moves to the cloud easier and more rewarding.)  But in many cases, what looks like low-hanging fruit is the result of a lot of hard, disciplined work in your organization--one of the best examples is Master Data Management (MDM) -- heavy lifting,  but it enables a cascade of service-enablement across your entire company.  Leading to the related idea:
• The heavy lifting you do should move the rest of the fruit lower, not buy you taller ladders.  A crucial C-suite mandate is to make things better, not just solve today's problems.  If huge chunks of your talent and money are maintaining burdensome legacy processes or technology, your company may stay upright, but you're just buying taller ladders.  If you're working to simplify processes, mask complexity, and enable a service-oriented enterprise, you're moving the fruit lower.
• Where there is fruit, there are windfalls. Let's think of it this way: there are opportunities to find benefits that fall outside the mainstream: to mix metaphors, the long tail of the crop. Is there a corollary business benefit to be gained by letting small teams explore niche opportunities to repurpose other efforts?  The ability to think "repurpose" is dramatically helped once you adopt the service-oriented model, which relentlessly standardizes core services to enable greater ease of personalization and micro-customization at the user level.
• It doesn't all ripen at the same time. Sometimes, you walk away from a classic LHF situation thinking, "yeah, that WAS a high reward for a relatively small effort." In the IT and business world, one of the clearest today is web-based e-mail: necessary but not a competitive advantage, adapts well to mobile and consumer-driven usage.  Don't turn away once that's done.  The experience of web-based e-mail may enable further benefits from the cloud-sourcing of word processing and other office productivity applications.  Can cloud-sourced productivity apps pave the way for "bring your own device" policies and respond to workforce consumerization?
• On the other hand, should you pick low hanging fruit at all? In 2008 I saw a presentation from a mid-size corporation that had decided to commit to cloud-enabling IT wherever possible.  In the slide showing a grid of the applications in the cloud, corporate e-mail was still in the data center. "Why not e-mail?" asked an audience member, "isn't that low-hanging fruit."  "Yes," said the CIO, "but our existing e-mail works fine.  Why take the time to change it when it's not a problem?  We wanted to concentrate on areas where the cloud could make a real difference for us."  In other words, just because you can doesn't always mean you should.  Web-based mail can make a lot of sense, but in this case, other priorities came first.  No matter how easy an opportunity might seem, sound rules of business value cannot be repealed.

Do you have a success story of an easy win that came from an unexpected place?  How do you maintain focus on long range improvements when there are so many demands to solve problems close at hand? Leave comments, or drop me e-mail.

C-suite talk: can you make complexity disappear?

Building blocks, not jigsaw pieces.
Image from countingblocks.com

In the last of the C-suite articles, I talked about managing complexity, either by relentlessly simplifying processes and applications, or by abstracting a complex service in such a way that it appears simple to those who consume it.  This time, let’s take a closer look at the latter: how to use complexity abstraction and why it’s an underappreciated business tool.

A service oriented enterprise is composed of 4 service tiers (for more on service tiers, see “How Technology Disappears”):

1. Lines of business, end users
2. Service Orchestration
3. Service Management
4. Infrastructure

There are exceptions, but in general, the tiers build on one another: service management uses the products of the infrastructure service to enable service orchestration to serve end users. One of the simplest measurements of success at each level is the degree to which service providers can offer consumers freedom from concern over where the service came from and how it was provisioned. It just works.

This is not revolutionary, but it’s very actionable. By simplifying and standardizing component parts of complex things, the care taken by providers at each service tier abstracts the complex into a simple, consumable product.  How can you do this?

• Standardize: practice strong, almost rigid exception management when customization is requested at lower service tiers.  This is an area, especially in IT, where businesses have traditionally operated backwards.  Your business and your employees are locked down to enable success of highly customized infrastructure and applications, when it should be exactly the other way: very high levels of standardization at lower levels in support of ease of deployment and customization at the user side.  If you are abstracting complex services by standardizing their component parts, you almost automatically guarantee your business is right-side-up here.
• Reliability engineering: Attack the weakest link in a complex process, and do the heavy lifting required to get its reliability up. Think of your car engine: the ignition system and fuel delivery systems were once high-maintenance items that demanded a fairly high level of driver involvement. Today, both are handled by computers. The Bosch computer in my old car has now managed ignition and fuel injection without attention for 22 years. Reliability is a great complexity abstraction if you make it a component of service delivery.
  
• Building blocks, not jigsaw puzzle pieces: each can be assembled into something useful, but jigsaws can only be assembled one way.  Building blocks are the ultimate abstraction, and can create many outcomes from standard shapes. That structure is the metaphor for your abstracted complexity.  If it only has one purpose, it it worth it?
  
• Externalize: instead of creating abstraction inside your own four walls, pay someone else to do it for you, and purchase a consumable service, which appears simple to you as the consumer. This is the province of services like cloud computing, third party payroll managers, and distribution services like UPS.  Their success lies in managing away the complex so you don’t have to.  It’s their core business strength.  Is it really worth it to make it part of yours?  The greater core simplicity you can structure into your business--the areas that don’t justify customization or added complexity--the more opportunities this solution presents.  The explosive growth in enterprise-ready external services and their abilities is also moving favorably in your direction.

The idea is to create a virtuous circle: structuring for managed services enables simplification and abstraction of complexity, which enables greater agility and higher business efficiencies. It sets you up for “one question to rule them all,” namely, “do I have to care about where that service came from, or can I just put it to work?”