A couple of decades ago, when I joined Perot Systems, I greatly admired the weekly employee newsletter.

It was entirely prosaic — a text-only email layout-and-design tragedy where bold-face and italicized letters were the boundaries of formatting sophistication.

It was concise and readable, told employees the essentials of what was going on, and, every edition included a story. Not a tale of Ross and how brilliant and fabulous he was, but of a team that had done something that exemplified the company’s aspirations, goals, and values.

Which was far more effective in making sure all employees understood what constituted “how we do things around here” than any mission statement posters, values cards, or other empty gestures.

Perot Systems wasn’t a cognitive enterprise, but its employee newsletter was a step on the right path to making sure whoever made decisions on behalf of the company made decisions Ross Senior and his inner circle would agree with.

It’s no small challenge, and the bigger the company, the harder it is to push and prod the organization so it acts like an organism — a single entity with a single purpose. Large enterprises tend to be more like ecosystems than organisms. Why? Like ecosystems, the component parts of an organization are diverse, self-interested individual organisms — those pesky human beings you’ve probably had to work with once or twice in the course of your career.

Just in case you still aren’t convinced: Your brain, stomach, kidneys, and spleen all have different functions, but they all have the same goal — your survival and success.

Your company’s supply chain, IT, accounting, and manufacturing departments also have different functions, but there’s no reason to assume their managers and staff even care about the survival and success of anything beyond their little silo, let alone agree in any way, shape or form on how to achieve the survival and success of the enterprise as a whole.

One place to start is the golden rule of design: Form follows function, which is to say, understand the problem you’re trying to solve before you start designing solutions.

With a cognitive enterprise, one of the problems you’re trying to solve is how to give customers the impression they’re interacting with the equivalent of a person that acts with intention, not the complex, hard-to-navigate bureaucracy that’s the underlying reality.

There’s no single magic bullet for this. Creating a cognitive enterprise is a tough, tough challenge, as Scott and I discovered while writing the book. One starting point among many: Design the default sequences through which you expect typical customers to pass, and the mechanisms for exiting the default sequences when they don’t fit the situation.

Doing so enumerates what the customer touchpoints are. The next step is deciding what the customer experience should be within each one, for each channel through which customers can interact.

There are, as you might imagine, quite a few different variables to take into account. For example: Should you maximize the number of required touchpoints so as to create a soft, we-care-about-you impression, or should you minimize them so you don’t waste your customers’ time?

The answer, and you knew this was coming: It depends.

For example: If you’re an Emerald Club member and rent a car from National you can walk right past everyone, grab a car, and drive out. National caters to customers who appreciate convenience.

Enterprise, on the other hand, which is part of the same car-rental conglomerate, takes the opposite approach: Someone accompanies you to your car, walking you through every step of the rental process up to and including looking for dings and dents.

Enterprise figures its customers want the personal touch.

Which company is right? They both are. Different kinds of customer have different preferences. What the two companies have in common: Both started with what they wanted their customers to experience, then designed their processes and systems … and educated their employees … to provide that experience.

What else? Three rules:

  • If something interrupts the flow, what changes is the touchpoint sequence, not the touchpoints themselves.
  • Touchpoints are functionally identical, regardless of the channel. What customers do doesn’t depend on whether they’re using the phone, the web, or a mobile app.
  • Touchpoints might initiate or rely on back-office processes, but they do everything possible to hide those processes so customers don’t know anything about them.

Once you escape the one-dimensional mindset that everything is about cutting costs, creating the appearance of cognition really isn’t all that complicated.

In principle, that is. Making all this work in practice is as difficult as business gets.

OODA loops aren’t limited to competing strategies, and there’s more to an enterprise being cognitive than making use of OODA loops.

Sorry for starting in the middle. Regular readers will recall Colonel John Boyd’s OODA loop. For the rest, it stands for Observe, Orient, Decide, and Act, after which you review the results of your Action … you Observe, starting the cycle again.

OODA holds sway in time-bound competitions, where whichever side has the faster OODA loops wins, because the faster side’s actions invalidate the slower side’s observations, orientation, and decisions, forcing it to start over.

But OODA isn’t restricted to competitions, and in fact it’s a decent general-purpose model for cognition, which is why The Cognitive Enterprise — the book I co-authored with Scott Lee on this subject — uses OODA as a general-purpose way of making an enterprise more cognitive.

Time to take a step back, because OODA is a mechanism — a way for enterprises to become more cognitive. It isn’t the essence. At the heart of the concept is that the enterprise acts with intention — it’s akin to an organism that has a purpose and acts so as to achieve it.

Look at two enterprises, one industrial, the other cognitive, as a customer, from the outside in. An industrial enterprise looks like what it is — a collection of processes you as a customer have to figure out in order to do business. If the processes aren’t designed to deliver what you want to buy, you either live with the frustration or take your business elsewhere.

A cognitive enterprise, in contrast, interacts with each customer as if the interaction was a person-to-person conversation. The ability to act with intention in ways that adapt to each customer’s needs is what lets entrepreneurships survive while surrounded by much larger competitors. Cognitive enterprises figure out how to make entrepreneurship scale — not only when it comes to strategy, but throughout.

Take, for example, Amazon’s “Customers Who Bought This Item Also Bought …” and Netflix’s “Because you watched …” features. They’re excellent examples of enterprises being cognitive, right down at the level of one-on-one customer interactions. They follow the OODA model quite nicely, too — they observe what you shop for, interpret your behavior so as to infer your preferences (they orient), decide on what to offer you, and then show you the offer in a persuasive way.

Down at the level of individual customer interactions, the most successful companies right now all seem to be as cognitive as they can be.

Your challenge: Quite obviously, no business of any size can achieve cognition without a lot of information technology, some of which interacts with customers directly, the rest of which supports employees who interact with customers directly.

Is your IT department ready to provide it?

* * *

And on a completely different topic, there’s Delta.

In case you somehow missed the story, Delta had a complete systems meltdown last week, grounding its fleet and stranding thousands of travelers for days.

Delta initially blamed the problem on a power outage, leaving all of us who know anything at all about the subject scratching our heads.

You don’t get to run a data center at the Delta scale without having sophisticated power management. Decades ago, when I was directly responsible for some of this, we made sure we were getting power from two separate substations so that a single transformer failure wouldn’t affect us; this in addition to our UPS and backup generators.

And, we tested all of the above from time to time to make sure they worked — this in a relatively small, 2,500 employee corporation.

Among the many puzzling aspects of this story, two stand out.

The first is that Delta’s explanation of what happened seems to change every day. First it was a power outage. Then it was a transformer. Then it was a failed electrical component that took down the transformer that provided power to the data center. That’s the transformer, not one of the transformers, which would mean Delta’s power distribution system was built with a single point of failure.

Then, maybe, there was a fire in the data center, too.

Which brings us to the second source of puzzlement: I’ve read few complaints about Delta’s ever-changing account of these events, but lots of speculation as to what might have been the “real” problem, even though Delta’s ever-changing account of things is an observable fact while the speculation — which includes the usual Strongly Held Opinions about Why Delta Should Be Ashamed of Itself — is largely fact-free opining.

The view from here: Let’s find out why Delta should be ashamed of itself first.