Considering the Exception-Tolerant Organization in 2009

After almost five months into 2009, how are things going for you and your organization? Well, I hope. But perhaps you now have to do more with less. Perhaps you need to find a new way to profit, keep the status-quo, or just survive. Perhaps it is time for your organization to become an Exception-Tolerant Organization (ETO).

Today’s management consultants and 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?

For more on the Exception-Tolerant Organization, please see this post.

The Exception-Tolerant Organization - Roundup

The series of posts on the Exception-Tolerant Organization (ETO) can be found here:

- Introduction
- Part 1
- Part 2
- Part 3
- Part 4
- Part 5

I look forward to expanding on this topic and other critical issues uniting business and technology in 2009!

The Exception-Tolerant Organization - Part 5

As explained in my introductory post on the Exception-Tolerant Organization, ETOs do not tolerate waste, stifling of innovation, or inflexibility. These are the corrosive agents that prevent an organization from smoothly handling exceptions, maintaining a competitive edge, and operating effectively.

When I was at IBM Research I knew of a research Fellow who would monitor the keystrokes made by his administrative assistants while they were typing, and would spend quite a bit of time with them working on utilizing the fewest keystrokes possible. This is intolerance of waste taken to the extreme, where a few burning trees are saved while sacrificing the forest. Although it is quite easy to disdain waste made at this low level, this is not the kind of intolerance we are discussing here.

While the canonical definition of waste is anything that does not add value, what exactly constitutes waste for the Exception-Tolerant Organization? As previous posts have mentioned, exceptions happen to organizations, to customers, and to people every single day. Those organizations that cannot handle the exceptions and improve from them will fight a constant perception of lower value in the eyes of their customers.

For those who understand the benefits of mapping a value stream, waste would be anything that slows the velocity of movement through the value stream. The inability to swiftly handle exceptions can bring this velocity down to near zero. Being Exception-Tolerant can keep the value stream moving at the pace of innovation.

Waste for the ETO, then, is the set of roadblocks to handling exceptions: inflexibility combined with the stifling of innovation.

Inflexibility is tough to exhibit while being Exception-Tolerant, but is even tougher to recognize in an Exception-Intolerant organization. After all, there are certainly industries and products where strict and rigid standards must be constantly and consistently adhered to (watch-making, food preparation, chip manufacturing, aerospace), but these should not be mistaken for inflexibility. Chip manufacturers, despite adhering to the use of 30+ year old computer code, have been able to find avenues of flexibility in many ways over the past few years - from lower-voltage conduits to hyper-threading to multi-core pipelines.

Stifling of innovation is perhaps the touchiest subject when it comes to organizations who may be looking to become Exception-Tolerant. The urge to suppress innovation is strong in risk-averse environments, and is often exercised in such forms as:

- the boss consistently saying "No"
- a departmental control group demanding that a potential innovative division look and operate the exact same way as the existing divisions
- new ideas whose implementations are unduly laden with process, direct-to-archive documentation, or extreme executive input

The stifling of innovation is often a by-product of culture, and the effects may not be felt in world markets until long after the key culture-makers have moved on. Strong cultures that stifle innovation are not often discovered by the outside until the effect in the marketplace becomes obvious. ETOs, even ones with strict standards, have a tough time saying "No". Inflexible organizations find it all too easy to say "No" and close doors on new ideas and customer needs by stifling innovation.

But with all the good work that we as people do, and all the work that we endeavor to do, how do we let ourselves get into a mode of inflexibility and resistance to innovation? The hard truth here is that we most often become inflexible and stifle innovation when we put self-interests above working together as a team. There is good reason that this struggle is often labeled as the war within.

But the other side of this hard truth is that ETOs are given credit by their customers for handling the exceptions and increasing the overall value proposition. And when credit is given in this fashion, ETOs give their people, who have worked together as a team, every opportunity to take the credit and reap the rewards - thus making team achievement in the best self-interest.

The Exception-Tolerant Organization - Part 4

As explained in my introductory post on the Exception-Tolerant Organization, ETOs practice daily Risk Management. Another concept that sounds quite simple, but organizations find it difficult to sustain due to these key factors:

- lack of inertia and momentum
- lack of systematized and/or automated assistance
- key-man risk and blame

Lack of inertia and momentum comes from not instilling review activities into the organization's daily operations. Just asking these fundamental questions on a daily basis goes a long way towards an effective review process:

- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?

For many organizations that rely on reviewing large amounts of performance or other time-sensitive data, having a systematized and automated collation and presentation of this data is key to establishing a daily momentum. The systems and processes supporting them should have the appropriate fail-safes and redundancies to handle exceptional processing cases so that timely delivery (and thus Risk Management momentum) can be maintained.

Automated assistance is also key for the human side as well. In reviewing an organization's performance or exception conditions, leaning on automation can clear our heads of the mundane and manual steps, and allows us to focus on the exception conditions. Plus, what Director of Risk Management wants to arrive at work at 7 am just to push a button, or wait for reports 1 through 10 to finish running and printing before tackling the issues of the day?

Being a Director of Risk Management is a tough proposition to satisfy for an organization. Not only must you have volumes of data and information at your disposal, you must have the prescience to understand what is going to happen seconds from now in both your own building and halfway around the world. A Risk Management Director could be hailed as the heroic steward of the ship that avoids the icebergs of a competitive landscape, or could easily be the goat when the ship is steered right when perhaps it should have turned left.

For an organization, it is easy to both funnel singular responsibility and cast blame on one person when things blow up. But why do this, when after the blame subsides, the organization is still in an unfavorable situation when a risk materializes? Risk Management is one of those cross-cutting activities that the entire organization can practice effectively on a daily basis via continuous review and improvement. Allow your Risk Management Directors to get the support of the entire organization, and the Director will support the viability and competitive health of the organization in return.

The Exception-Tolerant Organization - Part 3

As explained in my introductory post on the Exception-Tolerant Organization, ETOs emphasize their strengths and compensate for weaknesses by working together and communicating openly. If the concept sounds simple, that's because it is simple. But with all of the advanced ways, means, and tools we have at our disposal to collaborate and communicate openly, we still find in today's world places and situations where these fundamentals are simply not done.

Working together involves several cultural practices within an organization:

- Total team involvement from the start
- Proactively seeking the improvement of the organization
- Staying open to new ideas and possibilities
- Shared goals without harmful personal agendas

The first point is easier done than said, but the other three involve a resistance factor to change within our organizations. ETOs have the cultural grounding to foster and promote all four points above. As discussed in Part 2, ETOs systematically implement the communication pathways and processes to support these points.

But as is often the case in life, the greater challenge in overcoming obstacles can come from within ourselves, especially on the last point above. We don't always realize that we are more in competition with ourselves than we are at odds with others, and many times we are better served improving ourselves and overcoming our own shortcomings. Instead, we often put up walls where requirements and miracle solutions are volleyed back and forth, neither ever really satisfying the concerns or goals of the parties on both sides of the wall. But when we take down the walls and mprove ourselves, our best foot is then truly placed forward for the benefit of our organizations. Our strengths become the organization's strongest capabilities to be deployed across the greatest spectrum of benefit. And our weaknesses are compensated for by our continuous self-improvement, by identifying risks early, and especially by communicating openly.

Communicating openly, at its most basic level, involves face-to-face discussion, debate, and sometimes conflict - something that people can tend to avoid, in both their personal and professional lives. But for open communication to be effective, an environment needs to be created by the organization where intense debate and disagreement are tolerated, and conflicts can be satisfying to resolve. The organization should make it clear that it is okay to disagree and debate issues, but the result of each debate should still include a clear decision to move forward along a certain path of action.

As an exercise, have everyone in your organization begin to answer these questions out loud daily. Ideally, everyone related to a project or a core business of your organization should be in the same room (or on conference if necessary):

- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?

For the last question, use some kind of rating scale. Example: have each person rate their confidence from 1 to 5, with 5 being the most confident. Any answers below a 4 should be a cause for concern and those concerns should be addressed openly. The Agile practice called Scrum advocates the daily use of these questions.

Communicating openly also involves the appropriate use of communication tools. Communications involving urgency or time sensitivity should use direct methods: direct-line phone, internet, and video calls; direct text messages/pages; and of course face-to-face conversation. The use of email and instant messaging, while becoming increasingly mobile and location-independent, should not be relied on for urgent time-sensitive communication. These communication methods often have either multiple inboxes or streams/threads of communication occurring simultaneously, have lengthy queues of messages attached to them, or depend on having your communication device successfully "subscribe" to that message stream. The number of inboxes/threads and the size of the inbox queues are things that you cannot guarantee to be small enough so that your urgent message is received timely. Eliminate this frustration up front by identifying early a reachable line of communication to use for urgent matters.

Some very simple and fantastic exercises in working together and communicating openly (many taking 10 minutes or less to complete with a noisy room full of people) can be found here. While some of these are focused on Agile principles and practices, many of these deal with the core issues of communication and collaboration, and may help to expand your thinking. My thinking was certainly expanded after participating in some of the exercises. My thanks to Michael De La Maza for bringing these to my attention.

The Exception-Tolerant Organization - Part 2

As explained in my introductory post on the Exception-Tolerant Organization, ETOs build the communication pathways, business processes, and technology features to handle exceptions systematically. Where the business processes and technology features are largely matters of construction, the essential communication pathways can often be the component most elusive to an organization.

To relate this to a recent business event: an organization was forming a new business venture, bringing mature and existing technologies and processes in house from one of their partners. In the suite of this venture's features, there was one particularly public-facing feature that was not even close to being on par with the rest. Very early on in the business venture, one principal surmised that this feature had the strong potential to sully the reputation of the organization, and told the other principals of his analysis and recommendations for a course of action. A few principals were sorely disappointed that this was brought to their attention so early in the business venture, as they felt that this "negative" analysis was not what was needed during the venture's "honeymoon" period.

About one year later, the other principals began to see the strongly negative customer reactions to this public-facing feature. When they approached the principal who originally gave his analysis, they said to him "You didn't tell me it was THAT bad." In this case, the communication pathways were cut off early in the venture, perhaps when they were needed the most. And when they were opened again a year later, it was done in a reactive fashion that does not lend itself towards a systematic way to handle exceptions.

So how can you create these communication pathways? You can begin an email thread, as the principal above did, but these threads either are ignored early, or become so long that the interest drops off quickly. You can appoint a single point of contact to receive and dispatch the exceptions, but that person ends up being a single choke point more often than not. Or you can set up a system purely to capture issues and exceptions for review, which relies on people willing to take the few necessary minutes to input their issues into the system. This system can provide an effective entry point for exceptions and issues, if your organization is culturally adaptable to putting an entry, approval, and management process in place. The organization above did go and implement such a system.

Whether this type of system is a cultural fit for your organization or not, a regularly-scheduled gathering of the principals solely for the purpose of reviewing exceptions would go a long way towards getting the effort off the ground. Your organization may need to lighten the "status meeting" load somewhat to make room for this type of gathering. But because of the regular schedule, you are that much closer to systematically handling your exceptions.

As stated above, the business processes and technology features are largely matters of construction. But where business processes are concerned, many organizations focus on constructing processes for project lifecycles, development lifecycles, change control, and administration. These can be helpful in measuring performance when they are not over-engineered, but they are all are intended to handle the "normal" course of business. This still leaves out the what-just-happened, where-do-we-go, and what-do-we-do when an exception does occur.

As a starting point, take the lead from technology support teams. Great technology support teams have an initial point of contact, an exception entry and tracking system, and "run books" that contain procedures written in detailed step-wise fashion documenting EXACTLY what to do when a particular exception occurs. When an exception occurs and is identified, the support team executes the procedures step for step. If there is an exception that they cannot identify, they still have a procedure for this case that may involve contacting someone with more knowledge of the systems.

Handling exceptions in this way leaves little guesswork as to how to initially react. For many exceptions, recovery is a matter of reacting safely and sanely first, and then following the steps. So for your organization's exception-handling process, write down in step-wise fashion what people should do when there is an emergency exception, a impactful exception, and a minor exception. Every detail, including which people/departments should be contacted, the appropriate time frames to wait for responses, and any system or documentation entries should be noted. As a bonus, when you are out of the office and someone is covering for you, they can cover for you as effectively as possible during times of exception by following the steps.

For those of you who dislike process and procedure, keep in mind that the exception procedures exist to assist you, not to burden you. Your brain-power is most needed for problem-solving during the exception period - not remembering to make entries in systems A, B, and C; and worse, not remembering to notify people critical to your business. Another point of assistance is rendered when you can collect data from your exception-handling system and analyze the types and frequencies of the exceptions that occur in your organization. This may lead to some business insights your organization may otherwise not have reached.

Technology features for handling exceptions will be covered in a later post, but it is sufficient to say for now that your technology features that handle exceptions should interface and operate just like the technology features that run the normal business.

The Exception-Tolerant Organization – Part 1

As explained in my introductory post on the Exception-Tolerant Organization (ETO), ETO’s can embrace change and uncertainty while systematically executing their business. There are two keys here to making this a practicality:

- Being able to systematically execute the business

- Having an entry point in each business process for welcoming the change and uncertainty once an exception event occurs

First, ETO’s are able to systematically execute their business. There is a system for each business process that the ETO’s people follow to execute, manage, and report on their business. This is not as complicated as it sounds, as there are systems everywhere in business: accounts payable, software development, computer machine and image preparation, accounting. And when the ETO’s people understand that the systems exist to support the major ideas and goals of the organization, no system is considered too mundane to be ignored, improved, allowed to decay, or allowed to bloat in size. There are many books and references on the web related to understanding the importance of systems and business processes, so I will not expand further here.

If your organization is not systematically executing your business, but rather executing in an ad-hoc and undisciplined fashion, it can be difficult to embrace any changes or external events. Your organization is already dealing with so much noise and individual solutions to regular business issues ---that it will not be able to differentiate an exception event from a regular business event. Note that this can be an advantage when looking to create a system, in that your best ad-hoc process may work just as well for handling an exception event as it does for conducting your regular business. If you find your organization in this situation, use your best ad-hoc process as a starting point for implementing a system that can be executed repeatedly without fail.

Second, each one of an ETO’s systems and business processes has at least one entry point for addressing an exception or a change. Organizations need a way for someone to bring an event warranting change or representing uncertainty to the business’ attention. As an example, Toyota production workers are able to stop the line when they see a problem during the production process. Stopping the line is their entry point.

Entry points for processes that must be executed daily and on-time can be more difficult to see with the naked eye. As an example, an investment portfolio that must be valued on a daily basis - one or two issues with the price of an investment can make the portfolio's reported value wildly inaccurate, and become grossly misleading to a fund manager's investors. The system of valuating the portfolio must have an entry point where exceptions with prices can be raised, diagnosed, and handled. The identifying and handling of these exceptions is a systematic process itself, often assisted by robust technology. The entry point can be an automated review of the portfolio, followed by an exception reporting tool with a pricing exception report as a backup.

An entry point for an organization experiencing a problem with internally-developed software is a help desk department, which has rules and procedures around when it is available to take calls, and its expected turnaround time when responding to issues and exceptions. In other words, it is a system. Other organizations may have a developer, system administrator, DBA, infrastructure engineer, or manager as the entry point for problems. All of these technologists have different schedules and structures to their day, and can serve as an effective entry point - when they are available. Business principals may even feel more comfortable going to them directly, as they feel that the technologists are closer to the solutions than the help desk professionals.

This often ends up being more effective from time to time, but less systematic. Technologists are often steered away from their scheduled and time-sensitive work to handle exceptions, particularly after-hours and overnight. But here is a situation that calls out for leveraging a system so that effectiveness can be assured every single time the entry point is used. Being exception-tolerant allows us to handle these exceptions without negatively impacting regular business. This will be continued in Part 2.

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?

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