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.

Letting Go Of The Past

A president of a technology organization has been very successful in satisfying a rather narrow vertical in a niche market. Under his guidance, a custom-crafted data warehouse and reporting engine developed over three years has been successfully deployed to his highest profile clients. This reporting engine was the result of a decade of this president's experience and development in this vertical.

The president, seizing on a new but potentially lucrative revenue stream, now wants to apply this data warehouse and reporting engine to a new domain, but one using a new report query methodology with frequent use of highly cross-tabulated data. The president brings in an experienced professional outside the technology team to lead the construction of software to support this new report query methodology.

After a review of the problem domain and the current data warehouse architecture, the team lead demonstrates that the current architecture will not store the data effectively, or quickly execute the queries in the new lucrative domain. The new team lead reports on the expected size and structure of data, and a potential architecture to support storing and executing the new report queries.

The president, disturbed by the team lead's negativity towards the older engine and data model, declares that this is not what he wants. The president tells the team lead to take the current engine and "fix it, make it better, but we can't redo it otherwise we're deviating from our platform. I don't want two platforms. We spent three years building this platform and we must use it."

The team lead, seeing the incompatibility of the current data model, asserts that a new data model and reporting query engine would need to be constructed, and that a new architecture could be backwards-compatible with the reporting queries from the president's current niche market. The team lead provides a working engine and database to demonstrate the new architecture's viability, integration with features of the current platform, and ease of construction to satisfy this new domain.

The president, after conferring with the older members of the team, is more disappointed than ever. But the other members do not have a strong alternative to the new team lead's solution. Not being technical but always willing to contribute technically, the president makes a few technical short-cut style suggestions. One suggestion is plausible to the new team lead, but the others have no connection to the new reporting query engine requirements.

A few of the technical team members take a look at the team lead's work and begin to agree with the team lead. But the president still does not come to an agreement with the team lead's assessment. Soon after, the team lead is off the project, while the president continues to search for a solution.

Should the president expect a custom data warehouse that took three years to construct, and that was fully paid for by the company, to be usable towards every revenue stream the president wishes to tap? Or does the president need to let this go and move forward?

Should the team lead reference the technical knowledge and experience accrued over time to make an assessment? Or, because of the new domain, should the team lead let this go and move forward?

Who is right in this situation? The president? The team lead? Keep in mind that what is most wrong with this situation is that the lucrative revenue stream remains untapped.

It can be difficult for us to let go of our past ideas and our creations in order to move forward, but in some cases this is actually what is needed to make the best of our present state and lead us to our future successes. If faced with a similar decision, do you think you could let go?

Publicity and Heroism in the Workplace

Usually it feels pretty good to be recognized in the workplace or in your industry's community circles for your achievements, milestones arrived at, or just for a "job well done". You may also have had a chance to be lauded as a "hero" for landing that big account, completing that project on time and under budget, or working 36 hours straight to restore your organization's data warehouse up-to-date after a major hardware meltdown.

But have you noticed how the heroes who, say, weather us through a crisis sometimes receive more applause and "atta-boy"s than the heroes who, say, maintain steady but unchanging profits for years? Because of our human nature, we tend to be more attracted to the highs and lows of drama, rather than a seldom-changing sameness, even if that sameness is a positive and profitable one.

To land a major client, one organization had to close the deal and on-board the client within a very contracted time frame. A few principals involved were working 7-day weeks around the clock to the tune of 100 hours a week, while driving their teams to produce quickly for the client. At one point the client became very disturbed by a perceived lack of progress made by the organization in closing the deal. Shortly after the client made their feelings known to the organization, one of the principals mentioned to the client how he had been up all night working on a particular issue with the deal.

While that issue had not been completely resolved, the client was so impressed with the display of effort that they relaxed their expectations enough to accept the organization's progress, and became more receptive to future scheduling adjustments. Unfortunately, the client had not known about the 7-day weeks and 100-hour weeks spent previously. And even if they did, that knowledge may not have impressed them more than the image of one person toiling through the night solely for them. This is a much more dramatic picture indeed.

Some of us may need to work through the night from time to time to satisfy our organizations or our clients. Some of us in certain lines of work can easily work these hours or long shifts in a "business as usual" capacity. In either case, these shows of effort can easily be unrecognized, or worse, taken for granted if they are repeated too consistently. While being lauded as a hero shouldn't be the ultimate goal, make sure you are visible and your quality hard work is recognized.