Entertained By Deception

When you watch a movie and see dinosaurs chasing people across a field, do you think to yourself "That's pretty amazing!", or do you think to yourself "This isn't real."?

When you watch a magician perform on stage and step out from a tiny little box that could not possibly fit the magician's body, do you think to yourself "That's pretty amazing!", or do you think to yourself "This isn't real."?

When a movie showcases special effects, or a magician performs on stage, the deception of the senses leads to amazing entertainment. If we later learn how the movie's special effects were created, or we wrap our brains around figuring out just how did that magician appear out of that tiny little box, the amazement subsides. We may be impressed by the special effects methods, or impressed by our own explanation of the magician's work, but we are no longer nearly as amazed or entertained. We arrive at "This isn't real."

Behaviorally, we suspend disbelief and allow the deception to amaze us and entertain us, and it can be a thrilling experience. Knowing that we can be thrilled in this way, this may explain why we suspend disbelief when we invest in and follow the financial and housing markets. We all want that thrill, so we suspend disbelief: we don't learn how the investments are being made, how the investments are constructed, who is constructing them, or even wrap our brains around figuring out just how did house prices rise 10% during the year. We are happy just to allow the deception of sharp upward market movements to amaze us and provide us with a thrill.

But after the movie, or after the magic show, if someone came up to us and said "Hey, that wasn't real, you know.", we would respond "Yeah, so?" without feeling like we were suddenly slapped back into reality. So then why in 2008, when someone came up to us and said about the financial and housing markets "Hey, that wasn't real, you know.", we feel like we've been slapped?

The next time you watch the financial and housing markets climb so quickly and steeply that they lead to record highs in record time, will you still think to yourself "That's pretty amazing!", or will you think to yourself "This isn't real."?

The Exception-Tolerant Organization

Everyone by now knows of the Pareto 80/20 rule and where it applies to conducting business on a daily basis: people spend 80% of their effort on 20% of the issues. Many of these issues are exceptions to the normal course of business, and do warrant greater attention and effort. But the 80% of the effort spent begins to take away attention and resources from handling the “normal” 80% of the issues a business faces on a daily basis, the very issues that keep the business alive. This can manifest itself in an organization slowly at first, like an insidious virus that attacks from the inside out.

By the time an organization realizes that its ability to handle the “normal” issue has been compromised, the gross margins have declined and the organization has lost its competitive edge. But an Exception-Tolerant Organization has learned to rise above this, to make 100% of their effort effective on 100% of their issues while keeping pace with changing conditions. This post introduces the Exception-Tolerant Organization (ETO), and subsequent posts will cover the major principles in greater detail.

First, what does it mean to be Exception-Tolerant? Today’s management consultants and management thought leaders preach the mantras of embracing change and embracing uncertainty. Being able to embrace change and embrace uncertainty are indeed important. But being Exception-Tolerant is about taking these embracements and bringing them into the practicality of day-to-day business. Being Exception-Tolerant is not about solely reacting to business events and then making on-thy-fly adjustments into your workflows and systems just to keep above the water level.

Being Exception-Tolerant is about anticipating these business events and proactively building workflows that allow both people and systems to adapt and adjust smoothly, sometimes within minutes or hours of the exception occurring. In current-generation software development tools, there are language constructs that allow you to anticipate the exceptions that may occur during processing, and build a framework to handle them. Since we can do this with software, why can we not create these types of constructs in our own business processes, and with our own people?

We can, but only if we have the facilities and communication channels to do so. An Exception-Tolerant Organization (ETO) has the Exception-Tolerant people, the Exception-Tolerant business processes, and the Exception-Tolerant technology to proactively execute during times of change, uncertainty, and exception.

Exception-Tolerant Organizations:

- embrace change and uncertainty while systematically executing their business

- build the communication pathways, business processes, and technology features to handle exceptions systematically

- emphasize their strengths and compensate for weaknesses by working together and communicating openly

- practice daily Risk Management

- do not tolerate waste, stifling of innovation, or inflexibility

And when ETO’s practice the above effectively, they turn out to be exception-al organizations, not exception-less. For if you are exception-less then you don’t stand out and cannot be exception-al in business.

Can your people, your processes, and your technologies tolerate the physical, logical, internal and external events and forces that cause exceptions to your business to occur? Can your people, your processes, and your technologies adapt within minutes and hours to update, and perhaps even create new necessary business processes?

In other words, are they proactively built to execute during times of change, uncertainty, and exception? Or do they solely react?

Do you want your organization to be an Exception-Tolerant Organization?

Getting Our Hands Dirty

During my career I've gained deep experience with financial software development, management, and leadership. But for many years I also provided on-call after-hours and overnight system support, first on a rotating-schedule basis, then 24/7/365. From this I learned the most critical details of what works and what does not work regarding data architecture, data transmission, business workflow, information flow, and human communication pathways within an organization. Learning these critical details often requires us to get our hands dirty, as this true story demonstrates:

One company’s hot-stove issue of the day was the paper problem: "We're spending so much on paper! Most of our paper reports are printed overnight at 5 am. Why do we print out so many reports overnight?" To be sure, this problem represented a sizable cost during a company’s belt-tightening period that required the Business and IT to conscientiously team together to get to the heart of the issue.

The long-tenured business-side Managing Director and the recently-hired CTO sat in the same room with a few key people from both Business and IT, to discuss the issue with the overnight support specialist responsible for collating and distributing the reports. After a few discussions on the purpose of the reports and the distribution lists, no clear solutions were presented. It was then the CTO declared, “Well if I have to come in at 5 am and see what is going on myself, then that’s what I’m going to do!”

A week passes by. Did the CTO make a call to action, or come in at 5 am? No - not even once. But one developer did not have to come in at 5 am to examine the company’s internal report-generation schedule and discover several large reports being generated and printed in duplicate, all delivered to the same recipient. In just a few hours after that meeting, the development team removed the duplicates from the report-generation configuration, alleviating some of the printing headache and cost beginning with the next night’s report run.

But the developer went further than that, as he had done previously when investigating IT problems in his company - he DID come in overnight and got his hands dirty. He sat with the overnight support specialist and analyzed when the reports were actually electronically delivered, how the specialist was collating and distributing the reports, and documented their purpose. After reviewing the developer's findings, the Managing Director agreed that most of the non-duplicate printing and distribution justified the cost for the time being, until the Business could get a paper-less business process in place.

When the buzz of the CTO’s declaration died down, the CTO was not willing to get his hands dirty. And what could have been a defining and inspiring leadership moment ended up being an action-less statement. But one developer took the lead, providing some immediate relief, but also investigating the problem in-depth and providing a basis for discussing a long-term solution. The developer was recognized by the Business for his leadership, while the CTO moved on from the company shortly thereafter.

The developer here learned that getting your hands dirty can produce results, and that leadership often requires that we get our hands dirty when investigating problems and formulating solutions. As today’s Leader – are you willing to get YOUR hands dirty?

The Intersection of Business and Technology

What does the Intersection of Business and Technology look like?

Is the Intersection a shining Emerald City, where goals, ideas, and feedback are freely shared? Where IT principals understand the business and drive the technology to satisfy the business first, even before designing and deploying Greatest System Ever v10.0? Where business principals are sympathetic to the needs and specifications required for effective IT? Where regular partnership and joint accountability are merely business-as-usual, rather than a rarely-employed practice?

Is the Intersection a tall and wide impenetrable wall, where business goals are not shared, but volleyed back and forth between Business and IT? A place where business principals throw their problems over the wall as they hope and wait for a technology solution – any technology solution - to their operational problems and inefficiencies? Where the business principals rejoice when something – anything - has been thrown back over the wall for the first time in weeks or months? Is what they receive a true solution to their problems, or is it merely what the IT principals dictated as sufficient for the business without the ability or willingness to deliver more?

Is the Intersection a single blinking yellow traffic light, encouraging people to slow down but not stay around long enough to take a good hard look at what is being achieved or what is even possible? Or is the Intersection merely a desolate, unvisited crossroads whose only sign of activity is a tumbleweed traversing in the breeze?

When organizations establish their own Intersections, many treat the process like it is a Burning Man festival – that is to say, an exercise in temporary community. Principals from both Business and IT congregate for a few days to a week - often offsite - where they proclaim cooperation through rigorous presentations and sessions, show off their latest projects and business plans, share meals and shake hands, and then disband. When they return to their places of work, they often end up going back to the same or older practices, procedures, and policies - without making much progress. The partnerships do not survive the offsite event, and the joint accountability never materializes.

What does the Intersection of Business and Technology look like in your organization? How do you want it to look? Do you want merely the synergy of the temporary community without further partnership, the safety and protection from accountability that the impenetrable wall provides, or the shining Emerald City?

However you want the Intersection to look, one thing is certain: much like the Burning Man festival, the Intersection will contain only what you take with you.

A blog is born...

Welcome to my latest venture! This is the place to read about and discuss why effective leadership in uniting Business and IT goals and groups is so crucial for organizations, as they thrive and work to maintain their edge in a competitive marketplace.

This blog will cover:

- topics on leadership and unity of Business and IT groups of thriving organizations

- real-world anecdotes of effective (and not-so-effective) technology and business leadership

- people profiles and topics, to consider some outside viewpoints

- what it means to be an Exception-Tolerant Organization (ETO). I will flesh out this concept and its principles and practices in the coming days.


Who should read this blog:

- technologists of all levels looking to make a greater impact in their work and their organizations, and actively working to sharpen their growing edge of leadership

- business owners, executives, managers, and associates seeking more fulfillment and assistance from their IT groups and partners in accomplishing their business objectives


I hope that the blog will provide insight and open up a dialogue to improve leadership at all levels of an organization as we face the challenges ahead of us in the rest of 2008 and beyond.

Happy Reading!
Jason Sliss