I recently came across a short paper titled How Complex Systems Fail, by Richard Cook, MD. It made me wonder if anyone had written a similar piece about how simple systems fail. I couldn’t find one, so I decided to write one. Here’s what I came up with (the How Simple Systems Fail is available too).

1. Simple systems can fail.

While simplicity conveys several benefits over complexity, it does not prevent all failures.

2. Simple systems fail less often than complex systems.

As complexity increases, so does the number of potential failure modes. Simple systems thus have fewer ways to fail than complex alternatives and tend to fail less often.

3. Simple systems fail predictably.

A simple system’s failure has a finite number of potential root causes. Thus, simple failure tends to follow predictable patterns of cause and effect rather than surprising or puzzling pathways.

4. Simple systems fail affordably.

Simplicity minimizes the resources required to recognize the system’s failure, assess causes and remedies, and then apply those remedies. The cost of a simple system’s failure is generally constrained.

5. Simple systems fail transparently.

When a simple system fails, the failure and its proximate cause tend to be immediately obvious and difficult to overlook. With a simple system, post-failure attribution of a root cause is generally straight-forward, clear, and correct.

6. Simple systems fail educationally.

Simplicity makes it easier to accurately diagnose the causes and remedies of failure. This makes it easier for designers to learn from the situation and apply the lesson to future designs, if they chose to do so.

7. Simple systems are more likely to experience single-point failures.

Simple systems tend to have less redundancy than complex systems and thus have greater exposure to the possibility of single-point failures.

8. Simple systems fail comprehensively.

The performance of a simple system tends to be binary – it either works or it does not. Simple systems generally do not run in degraded mode.

9. Simple systems may be inadequate and fail to provide the necessary capabilities.

Simple systems exhibit “weak simplicity” when they fail to meet the user’s needs. This happens when designers emphasize simplicity over value and fail to incorporate the necessary level of complexity. The resulting system is sterile, inadequate, or underwhelming.

10. Simple systems may appear to be inadequate and fail to connect with users.

A simple system that meets users’ needs may nevertheless be rejected by observers who are unable to distinguish between weak and strong simplicity. The system may fail to be adopted by external users or internal sponsors who underestimate the system’s legitimate value.

11. Simple systems fail by becoming complex.

The uncontrolled accumulation of complexity within an initially simple system can transform it into an unnecessarily complex system. This increases the number of failure modes, introduces fragility, and increases the likelihood of failure for what was previously a simple system.

12. Simple systems fail by accumulating and increasing complexity in the larger environment.

A large quantity of interconnected simple systems can result in a complex “system-of-systems,” particularly when the simple components multiply without consideration for their aggregate impact.

 

I was recently part of an awesome panel discussion about the changing role of the Chief Human Resources Officer in this digital age. As an author and technologist who has pretty much zero HR experience, I found the discussion both fascinating and surprisingly familiar.

It turns out, the changes and challenges facing HR professionals (and CHRO’s in particular) aren’t exactly unique. Changing generational demographics, gender inequality, globalization, and digitalization – these are just a few of the factors that HR professionals are dealing with. So is everyone else. It was eye-opening to see how the HR experts on the panel are wrestling with so many of the same issues I encounter in my work with engineers, program managers, and other tech leaders.

One of the main issues we discussed was complexity. Specifically, we talked about the way complexity is disruptive, slows things down, and makes progress difficult. I wrote a book titled The Simplicity Cycle, so that topic is definitely in my wheelhouse.

Whether we’re talking about designing a spacecraft or writing a hiring policy, unnecessary complexity can turn a good idea into a convoluted mess. In both cases, it is important to develop an appreciation for the value of simplicity. There’s something downright beautiful about a truly elegant, simple solution.

Unfortunately, elegant simplicity is really hard to achieve, as one of my fellow panelists pointed out. I couldn’t agree more, and in fact that’s a major theme in my book. Simplicity is hard work. That’s one of the reasons there’s so little of it out there.

But there’s another piece to this puzzle. While excessive complexity is indeed a formula for failure, simplicity is not always virtuous either, per se. One panelist pointed out that in the name of simplicity, many HR departments institute standardized procedures that are ugly and ineffective. Sure, they’re simpler (for the HR folks), but they are a step backwards compared to their more complex alternatives. They are less complicated but also less good. I again found myself nodding in agreement.

If we put those ideas together we can readily see why the standardized approach so often fails. The simplistic, standardized solutions are ugly because they are easy. That is, the people who design and implement these one-size-fits-all solutions have often failed to do the difficult work required to produce elegant, beautiful simplicity. The result is simple, yes. But not in a good way. It’s a shallow simplicity that doesn’t convey the goodness and value we need.

Should we reject simplicity entirely? Must we settle for a hugely complicated approach to our processes, policies, or technologies? Of course not. This just means we ought to avoid overly simplified approaches that are the product of superficial efforts.

It means we have to do the hard work involved with reducing complexity and simultaneously increasing goodness. If the simple solution we produce is not beautiful, we’re not done with it yet.

I believe in simplicity. Simplifying things is generally a good idea. But like any tool, mastery of simplicity takes time and practice. And like any tool, simplicity can be used badly. So as we work to make things simpler, whether we’re talking about technologies, organizations, or processes, it’s important to pay attention to whether our simplifications are deep improvements or just superficial window dressing.

Chanute almost did not include Le Bris’ story in his book Progress In Flying Machines because although this glider was actually built and flown, the only account Chanute could find of it came from a romance novel in which the author “had mixed up a love story with the record of the aerial experiments.” He eventually found an out-of-print non-fiction book that he felt more comfortable with, and so he told the story.

Le Bris was a French Naval captain who, in 1857, played with a dead albatross and became convinced that he now comprehended “the whole mystery of flight.” Inspired by the bird’s wing, he built and flew a series of gliders.

The 1857 model pictured was essentially a canoe with wings. It measured 13 feet long and 50 feet across. He set the apparatus on a horse-drawn cart, and once the cart driver got the horse to a full gallop, jerked a fastening rope free and rose to “a height of nearly 300 feet, sailing about twice that distance over the road.”

Unfortunately, the rope, which was still attached to the glider, whipped around the body of the cart driver and lifted him into the air, leaving him “howling with freight and anguish” but fortuitously provided a helpful counterbalance and stabilized the craft. You can’t make this stuff up.

Le Bris had hoped to spend two hours in the air and apparently could have done so, but when he noticed the poor driver’s situation, he managed to descend safely and put the poor guy back on the ground. Unable to re-ascend, Le Bris landed and damaged one of the wings.

LESSON: Don’t exclude a good story just because it’s in a romance novel, particularly if the novelist swears he didn’t make it up.

Want more tips & tools? Click the image below

In 1865, as a young man living on a farm in Algeria, Mr. Mouillard would often go out into the fields to experiment with a set of wings he’d built, out of sight of those who might make fun of him. Today we would recognize his apparatus as a proto-hang glider, although unlike modern gliders, the operator of this device stood straight up in the space marked C.

He didn’t have much luck at first. Then one day, after several failed attempts to fly, a sudden gust of wind picked him up and carried him along roughly 12 inches off the ground. This unexpected success scared him witless, and afterwards he wrote “oh horrors!… my feet did not come down to earth! I was skimming along without the power to stop.” Apparently in his enthusiasm to fly he’d neglected to include any sort of mechanism for slowing down, steering, or landing the thing.

The wind eventually subsided and he returned to terra firma, breaking his wings but fortunately leaving his body intact. He breathed a big sigh of relief and immediately measured the distance between his take-off and landing spots, which he determined to be 138 feet.

Incidentally, that’s 18 feet longer than Orville Wright’s first flight.

LESSON: Plan ahead and have some idea of what to do if things succeed. Also, once you’ve recovered your wits from the horror of success, be sure to measure your flight.

If you’ve ever played with a rubber band-powered model plane, you have Alphonse Penaud to thank for it. In 1871 he was the first to use “strands of twisted india rubber” to drive a propeller, and his simple little models were crucial to figuring out things like how far along the fuselage to place the wings.

Chanute called Penaud “a very ingenious man,” and described his model as “quite successful upon the small scale on which it was tried.”The most important feature of this apparatus is that it “showed experimentally that it furnished automatic equilibrium.” That’s huge – maintaining equilibrium was one of the most difficult, persistent, and deadly problems faced by early aviators.

Unfortunately, Penaud’s impressive achievements and important insights were not recognized by his peers. Discouraged by being “criticized, decried, and misrepresented,” as well as dealing with a painful medical condition, he took his own life at the age of 30. I think of him every time I fly a rubber band powered toy plane, and I hope you will too.

LESSON: It’s possible to do big science with small, simple experiments. Also, haters gonna hate, so shake it off.

It’s not easy to stand out for being weird in a crowd of 19^th century flying machine inventors, but in 1877 a French engineer named Melikoff managed to do so. Chanute described his device as “a sort of screw parachute composed of two hyperbolic paraboloids united by their concavities into a sort of cone or pyramid.” Gosh, why didn’t everyone think of that? This 374 pound device was intended to actually carry a person, although where this person would sit is not clearly shown in the drawing.

 

Chanute says very little about this proto-helicopter except to note that it did not work and it was odd. In less than half a page of text, Chanute actually uses the word “oddity” twice, explaining “the apparatus as a whole is scarcely worth experimenting with, and has been chiefly described because of its oddity.” And that’s why I love it – because it’s awesomely weird.

At a time when no flying machine had ever worked, it just didn’t make much sense to copy what everyone else was doing. And Melikoff was clearly not copying anyone else. A true original, he set a standard for aviation weirdness that nobody has even touched for more than 100 years.

LESSON: Be weird! Try an odd approach, particularly if everyone else’s conventional approaches are all failing.

The internet can’t seem to make up its mind about who coined the phrase “chase two rabbits, catch none.” Some people say it’s an old Russian proverb, while other attribute it to an anonymous Navajo wise man. Me, I’m pretty sure that piece of advice originated with the great hunter Elmer Fudd, because whoever came up with it clearly did so during rabbit season. Or was it duck season?

Regardless of its provenance, the rabbit saying is a good principle to keep in mind when we design things. Just as a pair of rabbits will readily elude capture by heading in opposite directions, conflicting design objectives lead to empty hands Whether we are building a strategy, writing code or creating a PowerPoint presentation, a distracted design will not satisfy any of our goals. The plan will be muddled, the code won’t compile, and the charts won’t communicate. Usually this is because chasing too many rabbits makes things more complicated than they need to be.

What does this look like? Consider the two charts below: the Army’s infamous “Afghanistan Stability / COIN Dynamics” slide and a chart from the U.S. Air Force Chief Scientist’s Global Horizons briefing. I’d be hard pressed to say which chart is worse, but in either case that’s a lot of rabbits to chase.

There is a better way, and it begins with being decisive, with establishing clear objectives and resisting the urge to run in opposite directions at the same time.

To quote from “The Simplicity Cycle,” when we are centered and focused, we can more easily avoid getting our design wrapped up in entangling complexities because our vision is clearer.” In contrast, “being unfocused and frantically confused degrades our work and fosters unnecessary complexity in our designs, as we flail around and add components in the blind hope that some of them will make the design better.”

The key to outsmarting those rascally rabbits is to cultivate a discipline of choosing. Chase one rabbit today, then go after the other one tomorrow. Yes, there is a risk of picking the wrong one, but temporarily pursuing a less-than-optimal goal may be the only way to find out which option is better.

It is important to choose wisely, but the most foolish choice of all is to divide our efforts between contradictory goals simply because we couldn’t make up our mind.

(This post first appeared on SmartBlogs)

“I know the people on the phone can’t see this, but …”

By the third time our meeting facilitator offered the same apology, I began to suspect we were doing something stupid, or at least ineffective. But most likely stupid.

I’d been through this before, of course, on both ends of a telecom. We all have. Dialing in remotely to a meeting where wall charts and whiteboards are used but not broadcast can be an exquisitely frustrating experience. The people in the main room can see what’s going on. They can post sticky notes on the wall and move them around. But the remote “participants” — and I use that word loosely — can only listen and imagine. Except for when the audio is bad or the speaker turns away from the microphone, in which case they can do less than that.

There are plenty of tools and technologies designed to improve interactions among geographically dispersed teams, and some of them are quite good. But there are also barriers to using each one.

Sometimes the barrier is money. Even a token fee might be more than a team cam pay, either because they lack funding outright or because their bureaucracy does not provide them with an easy and timely mechanism to authorize the small payment. There are simply too many steps, too many approvals required to justify the small expenditure. Interestingly, there are usually no approvals necessary if we want expensive employees to spin their wheels in unproductive meetings.

In other situations, particularly for government and military projects, the issue is security. The discussion itself may be entirely unclassified but local network restrictions still prevent users from installing unapproved software or logging in to certain sites. The process for gaining approval to use these tools can be difficult to uncover and even harder to follow. Even if a dedicated and persistent team leader jumps through all the necessary hoops to secure permission for using a collaboration service at one location, someone else will have to do the same thing for any other locations that want to join in. So we end up using a party line circa 1960 and repeatedly apologizing to the people on the other side for our inability to communicate.

Surely there’s a better way. I confess I did not think of this specific solution in time to use it in the aforementioned workshop, but afterwards, it occurred to me that we might mitigate this particular headache using a simple strip of cloth.

Here’s my plan: The next time I find myself in a telecom where the main group in one location is trying to collaborate with a handful of invisible partners on the other end of a telephone wire, I’m going to put a blindfold on someone in the main location. For optimal results, we’ll pass the blindfold around the room until everyone has had the opportunity to spend five or ten minutes in darkness. I do mean everyone — even the boss, even the scribe, even the facilitator. Absolutely everyone. Even me.

The point of this little exercise is to foster empathy for our distant partners who can’t see what’s going on. When we have a first-hand experience with not being able to see, when our ability to understand and contribute to the conversation is restricted, we will be more likely to take positive action to include the whole group — including the people who aren’t physically in the room. Also, the sight of someone sitting at a table wearing a blindfold will serve as an unavoidable reminder that the visuals are not equally available. The best part is once we put the blindfold on, we’ll discover that “the people on the phone” includes me. That changes everything.

Perhaps the idea of deliberately blindfolding people will be intolerable to some. Perhaps they feel it would be too disruptive, would slow down the discussion and would reduce people’s effectiveness. If that is the case, one might ask why we put up with ineffective telecons in the first place.

Of course, our friends and colleague who are visually impaired already know what this is like, and businesses are supposed to make reasonable accommodations. Being blind and being on a phone are two vastly different situations, to be sure, but I think the same principle applies and can shape our approach.

The bottom line is that teams work best when we are all engaged, when everyone makes an effort to ensure everyone else can contribute. Teams work best when nobody is left out and all involved have empathy for each other. Teams work best when we understand each other’s limitations and strengths alike. And sometimes the shortest path to fostering such empathy is a simple strip of cloth.

(This post first appeared on SmartBlogs)

Inspired by the anatomy of a crow, in 1890 Mr. E.P. Frost built a “steam-bird” whose feathered wings were 30-feet long, from tip to tip. The apparatus weighed in at 650 pounds, not counting the pilot, and the illustration shows various positions which the wings would assume in flight.

In Progress in Flying Machines, Octave Chanute explains this design was unable to take off because “the maker of the engine failed in his contract to secure the necessary power.”

Frost’s machine had an inadequate lift-to-weight ratio, which as every Monty Python fan knows is what prevents European swallows from carrying coconuts to England. Just as a five-ounce bird cannot carry a one-pound coconut, a flying machine must produce sufficient lift to overcome gravity’s pull on its mass. Frost’s device didn’t do that, so there it sat, safely on the ground.

This was a common limitation of flying machines, and many inventors tried (unsuccessfully) to build or purchase a lightweight engine that also provided sufficient power to get off the ground. But the real reason Frost’s machine did not fly probably had something to do with the fact that feathers are less important and helpful than he thought they would be.

LESSON: If your engine can only lift 300 lbs, don’t build a 650 lb machine. Also, skip the feathers next time.