I recently tweeted this after mulling over the differences I’ve seen while working with various clients. Some of them have practically been begging people to slow down, finish less with higher quality, and to take time out to read. Others are so scared that they don’t produce enough, that people are running in every direction trying to get something done, while finishing practically nothing, and learning even less than nothing in the process.

Of course, the first tweet I received in response was from JB Brown, at Nordstrom’s Innovation Lab. Since “Innovation” is well, what they do, they like to read a lot and… apparently…are fond of statistics:

To me, the benefits of giving teams the time to read is self-evident. But I thought I’d let the people actually giving their staff the time time to read speak for themselves.

Simon Marcus: COO of the Library Corporation

I encourage people to read at work for the same reason that I encourage them to write things down. Reading and writing give you time and room to think. Mostly at work people think they are supposed to be DOING ALL THE TIME. But if they aren't thinking, the result of all that doing can be a whole lot of nothing.

I love when I am reading and stumble on a word or a phrase that sends me spinning off into one of my own real world problems or opportunities. I love it even more when it happens to other people, but the long range value of reading at work is that it slows people down and makes them more thoughtful and intentional about their work.

Lastly, a word about why we encourage people to read AT work (instead of just expecting them to read on their own time). If I think that something is important enough to ask people to do it, I owe it to them to give them time to attend to it. This is part of the larger effort we make to respect people's time AT work. Reading is Work in Progress (WIP), just like everything else we ask people to do. We try to avoid making work WIP slip over into people's home life. All of that isn't to say that I don't love it when I find out that people have gotten the reading bug and are reading on their own time too. I find that the reading bug can be contagious. Eventually, about one out of three people who we encourage to read at work seem to start reading more on their own time. When I hear that someone who "never reads" has started reading, it makes me smile from ear to ear.

Jabe Bloom - CTO of the Library Corporation:

I have 2 general concepts for why reading is important at work.

1) Technical Knowledge is more valuable the earlier you can apply it. For many of my developers ensuring that they are constantly retooled is one my most critical tasks. Encouraging them to read helps them to maintain a “landscape” view of the technologies they are using so they have a better chance of “finding” the right tool at the right time. Exposing developers to a wide range of new and interesting thoughts is a good way to inoculate them against complacency and “I have a hammer-and-everything-is-a-nail-itus”.

2) I think.. more critically... Having an open environment at work where individuals can be SEEN reading, activates the social space as a learning environment.

More and more studies of cognitive science support a concept of ritualized changes in thinking patterns... transforming from one way of thinking to another.. I think that having people read at work, helps them to think in a “learning activated” mindset.

3) Encouraging employees to read AT WORK, sends a clear message that we EXPECT and VALUE learning in the work environment. Employees aren’t expected to keep up on changes to the industry on “their own time.”  Our encouragement of reading at work has seen an increase in;

1) Teams’ abilities to communicate internally and with other teams via shared vocabulary

2) Increase in individuals sharing learnings and source materials.

3) Decrease in defect rates, especially escaped defects.

Jason Montague, the Director for Application Development at RW Baird:

As you've stated, a staff that is willing and equipped to read is a staff that understands the need for continuous improvement.  In that regard, reading, reflecting, and learning is crucial.  To understand why, let's simply look at one of the most common reasons given (to me) for why some don't read.

"I learn enough through experience!  Everything I know I've learned through the school of hard knocks.  What could a book *possibly* tell me that I can't get from experience?"

While it's true that experience is likely the most powerful means of learning, the sad truth is that we don't have as much experience as we think we do.  As I've learned (in books no less) most of us rarely have "20 years of experience".  We typically have one year of experience FOR 20 CONSECUTIVE YEARS.  That's right.  If we reflect on our past, occasionally we have brand new experiences that indeed teach us quite a lot.  But for the bulk of our past, we tend to repeat what we know over, and over (and over) again.  In that way, I would argue we need to step outside the boundary of experience-based learning and learn from others collective experiences.  You do that in books, articles, websites, blogs, and yes, tweets.

As you might guess, it's important that your teams are "willing" to read.  Just as important, they need to be "equipped" to read.

As employers, we can help control the second of these two statements.  Our obligation while building learning organizations is to model behavior, challenge assumptions, infuse an attitude of curiosity, and generally create conditions that allow (and encourage) people to read and reflect.  After all, as adults, quiet reflection is critical to our growth.  We are therefore obligated to not only "allow" people to read at work, but to encourage and incentivize them to read at work as well.  In that way, each employee becomes a well spring of "new" ideas, and a potential catalyst for infusing those ideas in our organizations.

It’s $2.99, or free if you have Amazon Prime.

This is the first in our new MemeMachine Series, which will be little eBooks like this that introduce a topic and begin discussions.

Here’s the writeup for it from Amazon:

Business runs on decisions. Recently, we've discovered that people aren't the great decision makers we thought they were.

Business relies on estimates, plans, and projections - and we all know how accurate they tend to be. Careers are made, careers are broken based on accurate estimation and planning.

But what if the successes and failures of these projects were not based on the prowess of those making the plans? What if success or failure were more often the result of a more complex set of events?
Why Plans Fail directly addresses our ability of to plan, to forecast, and to make decisions.

Written by Jim Benson, an urban planner, software developer, and business owner who has planned and built everything from small software projects, to houses, to urban freeway systems - Why Plans Fail is told by someone with much skin in the estimation and planning game.

This short work is the first in the Modus Cooperandi Mememachine series - which looks specifically at underlying issues that directly impact the success of teams, companies, and individuals. The Mememachine series is meant to start conversations and advance discussion.

Quote 5: Nancy: They wouldn’t send us any money! They said we’d spend it on DRUGS! Sid: We would!

Before Gary Oldman was an arch villain all the time, he played Sid Vicious in Sid and Nancy - a roll where he had to lose so much weight that he was hospitalized. The complexities of life were too much for Sid Vicious, but the simplicities were not lost. The simple model of Sid and Nancy’s lives were not lost on Nancy’s mother, who refused to send her money because they would spend it on drugs.

That was a simple system.

A system that allowed the provision of a best practice.

No money meant they would not spend it on drugs.

The money part of the equation was simple. But Nancy’s mother’s relationship to Sid and Nancy themselves was not.

The Simple solution was immediately useful to Nancy’s mom. Not sending money is instantly successful because it’s only criteria is satisfiable by Nancy’s mother and the only solution is instantly provable. “They did not spend this money on drugs because I never sent them this money.”

If Nancy’s mother was interested in keeping them healthy, she could have sent them things other than money that were not spendable. Things like food, plane tickets to somewhere they could get clean, or new clothes could be sent in lieu of money. Yes, they could be sold, but that would be a little harder than just using the money. That is Sid and Nancy in the complicated domain. Sending food would be a good practice - but it would not be guaranteed of success in the way that a simple solution like not sending money would.

In order to get success, she would need proof beyond the obvious. She would need reporting. Since both Sid and John Lennon were living in New York at the time, she could have had John go and watch Sid and Nancy eat the food she sent instead of the money. John could then tell her something like, “They ate about half the food and spat the other half on the floor.”

Nancy’s mother could then alter her techniques to suit.

But, the system that Sid and Nancy were caught up in involved drug addiction, bad decisions, the music industry, hypocrisy, betrayal, tribal behavior, paranoia, and branding. So we have a very complex system now. Regulating the food intake would likely be better if Nancy’s mom were to get a manager for Sid that really cared about his well being. That might get Sid and Nancy to detox, make them some money, and decrease their paranoia. Who knows, maybe off heroin they might actually even make good decisions.

This, however, is a complex system and one that involves a lot more work to conceptualize, implement and measure success. Indeed, the success of that might also require people to buy Sid’s solo album - which they did - but not until after Sid was dead. So, keeping Sid from dying would also be something to add to the project plan. Since Sid had just finished an album that made the top 40 for albums in the UK and included many big names, his feelings of him against the world made staying alive challenging.

In the complex world there are not best practices or even good practices. There are emergent practices. These are harder to control. For a while, having John Lennon checking up on Sid might work pretty well. (At that point for about a year). But then you lose your Lennon to give you reports. They system then has to change. You cannot hire a new Lennon.

When we start to look into the tortured psyches of Sid and Nancy, we get into the chaotic domain. Nearly every day, we’ll have new processes to deal with paranoid, psychotic, or drug induced episodes. We’d be responding to the seemingly random events that Sid and Nancy would subject us to.

This is all based on the Cynefin model we discussed earlier.

Systems Thinking is Awesome Because It Does Not Tie Us to a Particular Model

Since I was a boy, I have been listening to Miles Davis’ Bitches Brew. I have listened to it on high-end audiophile vinyl and very expensive systems. I have listened to it on cassette tapes in the car. I have heard it on CD, on iTunes, on Rhapsody. I think that Pharaoh’s Dance is one of the most incredible tracks ever put down.

Every sound system I listen to it on reveals different elements of the work. Heightened attention to high end, low end, mid range, clarity, depth, warmth, brightness - every system reveals a different experience.

Every venue I listen to it in reveals different elements of the work. In a dark room, it surrounds and embraces the listener. At the office, it pulls work along making it part of the music. With others, having a conversation, it invites pauses in conversation and seems to insert its own wisdom.

In systems thinking, we have access to any model of looking at a system we wish. We can using mechanical, humanistic, collaborative, creative, Tayloristic, abstract, punitive, rewarding … whatever fits the situation.

Ideally we understand that whatever model we employ is simply that: a model. As a model it is going to illuminate some things and cast shadows on others. Being tied to no particular model allows us to see the illuminations in one, shift our gaze and then see it in others.

Each model, each system, changes how we experience the components of the system.

Systems Thinking is a Trap Because it Builds Nested Dependent Models

In the 1990s, I was working on a large, regional transportation project in Maricopa County, Arizona, I mentioned to the City of Phoenix that we needed to have coordinated signal timing along Indian School Road - a major thoroughfare in the valley. They laughed and said that could never happen because “Those %$#*s in Scottsdale intentionally time their signals to screw us up. Every time we retime to make the roadways flow, they change theirs just to ruin it!”

So I went to Scottsdale and said, “Hi, we need to have coordinated signal timing on Indian School Road. They laughed and said that could never happen because “Those %$#*s in Phoenix intentionally time their signals to screw us up. Every time we retime to make the roadways flow, they change theirs just to ruin it!”

The two cities had gone all Hatfield and McCoy, because they’d developed systems that pre-supposed that the other city was going to mess with their signal timing. In reality, both cities we simply optimizing their networks to internal and not regional traffic.

Their models were at odds. The fun part here is that no model was right, but both models had impacts both on the quality of the product (smooth transportation flow) and of the psychological well-being of the workers at both cities. Both were angry at the other city. Completely unnecessarily.

As we’ve discussed in this series, the trap of systems thinking doesn’t necessarily come from systems thinking but from us … the users. The people. The gray matter that is susceptible to so many biases, short deadlines, client demands, and life goals.

We’re not expecting the complicated to become complex or the simple to become chaotic. We would like to do our job - and job is often seen as finite. We do a thing and then move on to the next thing. So when the processes of a company or a team naturally migrate due to changes in context, they can easily shift from one domain to the next.

Much like in Simon’s Tank Hard Drive story, we build these models inside other models. We assume, more importantly, that the models in which our new models are nested, will remain stable. As we begin working with our models, those in other areas may interfere with them

Photo by Tonianne

We love a good story

Systems Theory is Awesome Because it Gives Us Great Stories

In The Silence of the Lambs, Hannibal Lechter controlled conversations by using the power of story and insight. When we combine a good narrative with an innate fear and the glimmer of salvation, we can win arguments, engage teams, and even win elections.

Stories become the groundwork for positive change. Without stories, we would have no work flow diagrams, no value stream mapping, no Personal Kanban, no relevance. Stories are the most accepted, highest value business communication tool there is.

Systems thinking builds powerful process and change on accepted stories about how we work, how we’d like to work, and the challenges of getting from one to the other. It gives us a forum and formats to discuss them and it comes with tools to help us find the subtext and backstories that make the stories work.

Systems Theory is a Trap Because it Can Give Us Easy Stories

In The Silence of the Lambs, Hannibal Lechter controlled conversations by using the power of story and insight. When we combine a good narrative with an innate fear and the glimmer of salvation, we can win arguments, engage teams, and even win elections. The problem is, the story doesn’t always need to be relevant, just plausible.

An example of this might be Jim Collins and his team of researchers who wrote the bestseller “Good to Great”. Good to Great is, itself, an excellent book that gives food for thought around willingness to radically change in the face of adversity and how that might lead to corporate success. We highly recommend the book for examples of companies that were willing to use their might and more than a little ingenuity to survive certain economic destruction

However, Good to Great spawned a generation of business owners who took it to be a recipe book - a virtual guarantee for business success.  They didn’t quite understand the nuances that lay underneath the stories. The stories were engaging and plausible, therefore they must have repeatable (copyable) wisdom.

The implications were that if you acted like the companies described in the book, you would become “Great”. What people neglected to realize was that other companies tried the same innovative techniques as the companies in the book, and failed. The companies in the books also have had a hard time weathering the latest economic storm. So, while Collins’ intent was to provide readers with a systems thinking approach to building a great company, the book ends up being interpreted by readers as a how-to manual.

Daniel Kahneman in his book “Thinking Fast and Slow” notes that we as people really like narratives. We love a good story. So, therefore we end up giving incredible weight to a good story. So much so, that we believe the story is likely simply because it is believable. Good to Great is filled with excellent stories that, taken in the aggregate, seem to ensure that engaging in those behaviors will result in assured success. The stories are plausible, so plausible in fact so as to convince millions.

Probable? Not so much.

Systems thinkers can easily get caught on the wrong side of the plausible / probable divide. We describe systems and then begin to act on them as if the systems are real. But we don’t know that for sure. Every system we devise is an hypothesis. It needs to be described, observed, proven and then reproven over and over again. Why? Because not only does business context change, but the systems themselves are part of a nested series of other systems that directly or indirectly influence the system you’ve put in place.

By now, exasperated good systems thinkers are saying that this endless questioning is the very heart of systems thinking and that there are safeguards in place to protect against being overly focused on a narrow or erroneous view. Unfortunately, in the real world our cognitive biases tend to team up to make this purist application of systems thinking little more than an ideal. If we are able to keep these biases in check - that’s wonderful. But it is unlikely. And as good systems thinkers we should at the very least recognize that our own biases influence our systems.

My friend Simon Bennett has a story he likes to tell about working security for the military. In the 90s, they had put new computers in tanks and these computers had hard drives. The hard drives were having some problems, so Simon and his crew pulled them from the tanks and sent them back to the manufacturer to see what they could do.

Mind you, these tanks take some serious jolts which are very hard on hard drives.

The hard drive manufacturer, when they received the hard drives could not believe the amount of damage the drives had taken. They tried a few variations of hard drive design, but kept receiving back horribly damaged drives from Simon’s team.

Now, when you have a storage device that has ever touched classified information, it gets marked with a physical label that reads DIRTY. Dirty equipment needs to be handled and shipped in very specific ways.

After six months of utter confusion, Simon and his team found out that the drives they were sending back to the manufacturer were going through a team that specialized in the shipment of dirty equipment. When this team saw that the drives were going out to an unsecure location, they opened up the drives and took a chisel and destroyed the surface of the hard drive to make it unreadable. Then they put the hard drive back together, packaged it neatly in bubble wrap (so it wouldn’t get hurt) and shipped it on its way.

So, when the manufacturer received it, they’d open the drive and find a completely destroyed hard drive. Then they’d call Simon and his team and say “WOW! This thing is obliterated! What happened?” And Simon would say, “Well, it was just used for a few weeks in the tank.”

Simon and the manufacturer had a system in place that they thought was working for them. They were completely unaware that a second system was actively working against them.

While this is a rather extreme example (and certainly a plausible story), my point here is that when we get comfortable as systems thinkers with the systems we work in, we can overlook additional systems. Indeed, we may well have described a system so plausible as to be defensible for quite some time - until one day it inexplicably fails us.

Photo by Tonianne

Collaboration from Tonianne and Jabe Bloom

What? You think that’s big? Basically for this one, I could quote all of Annie Hall. It’d be a 110 page title.

There’s another scene in the film where Woody Allen’s character approaches a happy looking couple and asks them, basically “why are you so happy, what is your secret to success?” The woman says, “I'm very shallow and empty and I have no ideas and nothing interesting to say.” The man says “I’m exactly the same.”

It seems that creativity and innovation require at least some bit of inner turmoil. Systems thinking allows us to make sense of this turmoil and create structures to both harness and liberate our knowledge workers. However, it can have some side-effects.

Systems Thinking is Awesome and a Trap Because It Can Smooth Out the Rough Edges

Human beings are chaotic. The more we think, the more we learn. The more we learn, the more we grow. The more we grow, the more we change.

Imagine, if you will, a large company with 30,000 employees. Now imagine a small company with 5 employees. Which one feels the impact of its constantly changing population?

They both do.

But large companies can spread the impact of those changing people over a large surface area, if you will. Large companies also excel at instituting dehumanizing processes that devalue individual change.

They hire systems thinkers to help create these dehumanized systems by figuring out what the best methods of production are and enforcing these methods. This Calvanistic approach worked well in the industrial era when people could do to work, execute their mechanistic commands, watch a car, bread or a box-spring mattress pop out the end of the assembly line, and then go home.

There are some in the Agile software community who have dismissed kanban and systems thinking as “Tayloristic”. Taylorism sought to use performance measures to manage, predict, and enforce assumptions about product execution and completion. In its execution, Taylorism became quite dehumanizing.

The kanban for software community has in-turn dismissed this accusation a scurrilous lie. But the aspects of Taylorism that are mentioned are real possibilities, and the kanban community is showing its own bias by not even discussing the possibility of Taylorism.

We have already seen where visual controls like kanban have been used to control groups and enforce process, rather than lead to patterns of continuous improvement. Would we as good systems thinkers like to see such misuse stopped? Yes.  Does that mean it does not happen?

No.

While Taylorism may work well for the creation of a predictable thing like a car or a fork, it is horrible for knowledge work and the modern endeavors that rest upon the labor of knowledge workers. The problem here is, those that control companies and many self-appointed systems thinkers do not understand the difference. Also, artifacts like the PMBOK enforce notions of measurable outcomes over adaptive systems.

For the assembly line wolrd, work-life balance was real, because people had bifurcated their lives. The worked at work and lived at home.

That was a huge trap.

But … this was a horrible (though predictable in hindsight) unintended consequence of systems thinking, which was always supposed to be about the people. There were some systems thinkers who were good at making the drudgery of the assembly line merely suck less - they were not interested in creating systems that actively promoted worker well-being (even if Deming was interested in worker well-being).

One thing though:

We are no longer in the industrial era.

The information age relies on a very different machine – the human brain. We’ve learned that happy knowledge workers create more product, make less mistakes, and innovate more. Here, we have some serious systems thinking potential awesome.

Systems thinking can look into knowledge work with an eye much less focused on productivity, and much more focused on happy workers. This systems thinking is very interested in the change of individuals - in their well being as parts of the overall system. This systems thinking knows that team mood directly impacts the bottom line.

Here, systems thinking also knows that Quotes 1 and 2 are important. We want to know where we are building assumptions about the systems and about ourselves. We want to understand how the individuals involved in our enterprise combine to create wonderful innovation and dangerous dogma. We also want to incorporate Quote 3 and understand that knowledge work is all about relationships and introspection. We know that the realities of our co-workers impact the whole system.

Tomorrow’s Quote: Well, Clarise, have the lambs stopped screaming?

Photo by Tonianne

Post Collaborators: Tonianne and Jabe Bloom

(This is part 2 of a 5 part series that starts here)

So, it’s an average day on Dagobah, rainy, hot, humid. Luke Skywalker has just finished some fitness exercises with Yoda and they come across a cave. It creeps Luke out and Yoda says, in essence, “Dude, skip the cave.”

But Luke feels the dark side of the force in the cave and feels compelled to check it out. Yoda is then all, like, “Hey knock yourself out, I’m just hundreds of years old and really smart, you want to ignore my wisdom and go into the cave … by all means.”

So, Luke goes into the cave and runs into Darth Vader, or some Darth Vadery thing, and they have a little light saber duel and Luke cuts Vader’s head off, only to find his own face behind Vader’s mask.

Luke’s own impetuous recklessness is staring him in the face.

This wigs Luke out.

Systems Thinking is Awesome Here Because Most Often We Are Battling Ourselves

When we use systems thinking, we are actively asking ourselves “Why is this working as it does?” If we are good systems thinkers, we open ourselves to all possibilities and expect to be surprised. Systems thinking is all about how to turn normal operations upside-down and see the unexpected reasons for both success and failure.

Therefore, systems thinking is often about our own self-exploration. How was the system I created yesterday wrong? What is my impetuous recklessness?

Systems Thinking is a Trap Here Because We Still Expect to “Win” at Continuous Improvement

As mentioned in the previous Quote, our world-views get in our way all the time. We unconsciously constantly build systems in our heads to explain why things happened. Unfortunately, for us, we build these models at such a rate that we rarely have them disproved. So we feel we are most always right in our decisions and beliefs. Psychologists call this “subjective validation”.

In systems thinking, we have to operate in the real-world. This means we are often asked to work towards some set of end-goals. While we would like to be ideological purists, those who hire systems thinkers would like to actually do something. So they need actionable items that they can understand.

The trap here lies in describing an end-state for the systems thinking effort that is somehow permanent. If people want a set of processes that will not change in the future, that is a trap. If they want a group of people “fixed”, so they will do their jobs better, that is a trap.

I have been to many web sites of many people who claim to be systems thinkers who specifically promise explicitly to map out the real processes of a company and then create new processes that will remain permanent. This limits systems thinking to what Dave Snowden’s Cynefin Model calls the complicated domain. (I will go into detail about Cynefin at Quote #5, until then, check out the wikipedia page).

In most human endeavor today, certainly in knowledge work, but increasingly in manufacturing, we do not operate in the complicated domain, we operate in the complex domain. This is a domain where business process or team process can change from moment to moment. The speed at which new products can come to market, the decoupling of the production of an object from its design and sales, and the rate at which the markets and technologies change make any stolid process unsustainable and dangerous.

Continuous improvement, therefore, becomes a constant effort to be the best that you can be at the design, creation, sales, and re-creation of your product. You don’t “win” at it by completing a final process. You “win” by remaining vigilant.

Tomorrow’s Quote is a long one from Annie Hall

Photo by Tonianne

Post collaborators: Jabe Bloom and Tonianne

Systems thinking, like all tools, involves the tool itself (an amoral object) and human nature (a moral object). Human nature can, from time to time, lead us down some unsavory paths. Now, as with most tools, the tool isn’t necessarily to blame. However, the tool and human nature combine to create predictable patterns of dysfunction.

So, today I am writing about how something I use nearly every day and love. I am writing about how it can be misapplied by even the most skillful practitioners.

Systems thinking encourages that one look at an entire system and appreciate the impacts on that systems on its parts. To illustrate in a simple way, let’s say that Raymond works for MalCo. All his coworkers hate him. “Raymond is a jerk, a buzz-kill, a mean man.” But when he goes home, Raymond’s kids love him. He’s not a mean man. At work, Raymond’s job is to make sure that expense forms are filled out properly. It’s a thankless job. But the job is not Raymond and Raymond is not his job. The system has given Raymond unpopular tasks and he is fulfilling them.

We then tease out elements of that system that could be improved to better achieve the goals of the system or those who interact with it.

In Raymond’s case, having him go around nitpicking about whether the $5 parking fee was before or after work hours is counter-productive and annoying. It even annoys Raymond, so when he shows up, he really isn’t looking for a fight but he is agitated. The goal of the company was never to annoy people, it was to make sure that the company handled expenses in a way that let the company do its bookkeeping and kept things neat. So, what if we came up with a submission process that checked expense forms as they were written and gave people Raymond as an expert that could help them when they ran into troubles with the form?

Suddenly, Raymond transforms from the jerk that says no to the guy who could help you find yes.

So, my first bout with systems thinking was while I was an urban planner. For years there were two wings of urban planning. Transportation and Land Use. They tended to be quite siloed. Then one day, someone got the bright idea that transportation and land use actually were a system and influenced each other rather heavily. In 1994, I was hired to be the “transportation-land use link” by METRO, the regional government in Portland, Oregon. After that, I spent years of my career working directly to promote systems thinking throughout urban planning.

More recently, in 2010, I helped manage the creation of the Human Development Report for Vietnam. Usually HDRs are also very siloed. They have sections on women’s issues, water quality, early childhood nutrition, transportation, economic development, etc. These reports were erroneously seen as “systems thinking” by the United Nations because they contained all the elements of the system. However, the reports rarely highlighted the relationships. So, what we did was get the 24 researchers all working in Google Docs. The researchers could then see, in real time if they chose, what all the other authors were writing.

We then encouraged them to not only write their own sections, but also comment on each other’s sections. The goal being to insert the impacts of, say, a good water supply on early childhood nutrition, or of a good transportation system on access to hospitals. This little change allowed us to create a much more systemic view of each of these previously siloed sections and, therefore, build more holistic and sustainable programs in the future.

So, suffice it to say, I’ve been thinking about systems for quite some time.

The five quotes below are from popular culture and I’ve been really busy lately so my references may be a bit dated. So, sorry about that, it is what it is. If you haven’t seen the films, get them on Netflix or Amazon. I will be doing one quote a day over the next five business days.

Quote #1 THERE IS NO SPOON

Systems Thinking Is Awesome Here Because New Realizations Break Assumptions

This is key in systems thinking. We keep rotating our view of reality to find systems within systems. To find ways that business builds pockets of dysfunction that gnaw away at the ability of the company to succeed. To find ways that a culture gathers dogma that becomes accepted truth long after it is relevant.

We actively question why things happen and try our best not to rest on dogma as answers. (Always trying…) When we do have epiphanies about actual causes for problems, they generally break one or more assumptions people have about their work, their life, or the structure of society.

Systems Thinking is a Trap Here Because New Realizations are Still Based on Assumptions

As human beings, we operate based on a world-view, our own internal system that is based on assumptions and emotional reactions. The trap here is when we believe that the system we are working with can ever be the one-true system. There are always red pills to take to open our doors of perception. There are always other angles to look from.

Systems thinking itself is in no way to blame here. But as human beings, we have a certain tendency to want to view the world from a certain point-of-view. We call these fixed points-of-view “best practices.” They engender static checklists, rule sets and associated punishments. They assume the world is simplistic.

When we build a system in systems thinking we start to fall prey to a variety of cognitive biases that cause us to fixate on certain systems. We find systems based on systems, which can pull us down logical chains of discovery that seem true … but only seem. The patterns feel comfortable. (I come back to this in Quote 4).

The trick here is that even if we realize this to be the case, we still are subject to these biases. So we need to build meta-systems to guard against this. We need to take a regular regimen of red pills to remove ourselves from the system we are actively studying and change our perceptions.

Unfortunately, the appropriate dosage is likely lethal.

We simply must be comfortable, as people using systems thinking as a tool, to understand that, at any given time, our current view of the system is incomplete. Perspective, by its very nature, is looking at something from a vantage point - a point-of-view. There are things behind or inside what we are viewing of which we are unaware.

Ask yourself, what is your point-of-view? Where are the blind-spots?

It is simply human nature to assume that our world-view is correct, however. Therefore most people who actively work in systems thinking routinely fall into the trap of believing the beautiful systems diagrams they have created are anything other than a very useful, temporary fiction.

Tomorrow’s quote “Remember Your Failure In the Cave”....

Photo by Tonianne

This post was with a little collaboration with Tonianne and Jabe Bloom

To a man with a hammer, everything looks like a nail.
~ Mark Twain

If you only have a hammer, you tend to see every problem as a nail.
~ Abraham Maslow

Some quotes become lore. Some quotes become cliché.

These quotes are a warning we all ignore, and may well be another cognitive bias.

We can call it Nail Bias.

We have a tool that we are fond of, or worse yet hate and have invested tremendous money in, and we are anxious to find a use for it. Or, even worse yet, we read an article about some management consultant who has invented an awesome hammer, and we declare ourselves to be nails.

Whack us.

We’ve discussed Expectation Bias, where we interpret information in the light most supportive to our original assumptions. This is also called “Experimenter’s Bias” because scientists (even us amateur scientists) tend to set up experiments that will provide results favorable to their hypothesis.

I have had clients become restless, when I will take them on avenues of discussion that obviously depart from why they hired me. They want kanban. The want personal kanban. Why am I not talking about KANBAN?!

The answer is that kanban is not the solution for every problem and over using the tool will greatly lower its effectiveness. My clients had an expectation they they were going to get a box of kanban upon my arrival, we’d open it, an awesome workflow and team dynamic visualization would float out, and everyone’s work would be done.

That was their hypothesis and when the conclusion started to differ, it caused cognitive dissonance – the slow painful realization that the world is out of sync with your world-view. Nail bias begins to become clear. We had a nail, we set up a kanban, but, rather than being a hammer, it was a flashlight. We could see more and now knew those weren’t nails at all, but screws, rivets, nails, thumb tacks, and a wide range of other unexpected things.

Suddenly, Jim is talking about all these other things. Not nails.

We need the limits of our bounded rationality to become clearer. Bounded rationality recognizes that we only have so much time to recognize a problem, process it against our histories, learn more, hypothesize a solution, and act.

We will always be acting on limited information.

This is inevitable. No one thinks (or no one should think, anyway) that they know everything.

The problem is that since we don’t know what we don’t know, we can’t act on not knowing it. We must assume at some point that we have enough information to act. That assumption is driven by several things including deadlines (a major cause of quality problems), politics, and fear.

This leads us to simplify our choices. We have to create a “short list” of options to choose from because the danger of over-analysis is right around the corner. At this point we walk a fine line between honestly limiting our choices so as to reach a coherent and rapid conclusion, and satisficing.

Satisficing is yet another element in this cognitive soup that makes things easier, more coherent, and less precise. Combining satisfy with suffice was a wise move by Herbert Simon when he came up with the concept in the 1950s. We, as decision makers, must run complex problems through both social and practical filters. We must find rapid solutions that give people what they want, and within reason.

But the target at the center of the of time-to-market, satisfaction, and practicality coordinates is hard to hit – and the bad news is we’re constantly aiming for it with many different concurrent decisions. We are all suffering from decision fatigue – the phenomenon where the more decisions we are presented with, the higher the mental and physical strain they cause. One only needs to watch the rapid aging of any US President after election to see that.

Today, we have many things that vie for our attention, our time, and our decision-making capabilities. Many of us have so many interruptions (each of which involves a decision whether or not to allow the interruption) that non-ADHD people actually begin to exhibit signs of ADHD.* We can no longer close our office door and concentrate because digital conversations do not respect masonry – they walk right in and chime!

When these factors combine with other biases like the availability heuristic (which we’ve discussed) and system justification (where people tend to justify existing systems rather than try to fix things that are broken) … we end up with Nail Bias. In an effort to quickly reach a politically satisfactory, rapid and practical conclusion, we will fall back on what is both recent in our memory and coordinate with existing systems.

In fact, that may well be the definition of the proverbial “box” we are trying to think outside of.

Nail Photo by Bob MacInnes (ironically showing several types of nails….)

1976 Picture of Jimmy Carter via Wikia.

*Source – The Scientific American A Day in the Life of Your Brain, Horstmann, 2009

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

We like to estimate things. “I’ll be there in 5 minutes!" “I will have that report to you in an hour!” “We can do the entire project in 24 days!”

Yet our estimates always make us nervous. They leave us ill-at-ease. We always know things won’t go exactly as we foresee, there will be things that should go right but don’t, there will be unexpected snafus. We know, the moment we create it, our estimate is wrong.

“Plans never survive contact with the enemy” – von Clausewitz

But we hold on to our estimation as necessary. We hold on to our plans as bibles. We hold on to contracts as … well … contracts. And we are surprised when things don’t go according to plan.

“Plans are useless, planning is indispensible.” – Eisenhower

We are running into two problems here. (1) There is variation is every activity and the world is sure to remind you of that. (2) The Planning Fallacy – which is a cognitive bias that shows that human beings tend to underestimate a given task even if they’ve done that task many times before.

The planning fallacy is one nasty little bugger. Already, we undervalue the role of variation in our work and believe we can ascribe one number to a particular task. Beyond that … we actually are predisposed to underestimate even that erroneous number.

Researchers have tested this many times and find a few things.

• People tend to underestimate their own completion times the most
• People tend to underestimate even more when others are present
• People can deliberately underestimate to garner favor or win contracts

These added together create some shaky ground when asking other people for an estimate of time. Some people glibly say, “Well, when they give me an estimate, I double it and that takes care of it.” But this doesn’t solve the core problem – people honestly did not know the variation in their work to begin with.

At a recent client, they compared their estimates to actual hours across a series of projects.  What they found was, if a task was estimated at one hour, there would be four times that estimate was correct, and three that it was not. The incorrect estimates would range between 2 and 6 hours.

For two hour tasks, it was similar. Three times they were correct, four times not – ranging between 3 and 9 hours.

Three hour tasks, a very similar spread.

When they visualized those tasks – they suddenly were able to see the variation in their work. And they were upset!

“We have to get rid of those major outliers,” they said.

But what they were really seeing was the variation in their work. The uncontrollable variation inherent in knowledge work that makes Hofstadter's Law a law and makes the Planning Fallacy a very common occurrence.

Understanding the variation statistically … that gives the team real power. With that they can choose any number of estimation strategies, based on real numbers with real spreads. There will never be one “right” number – because that is prediction and not estimation.

Combine this with Eisenhower’s advice, and we stop planning up front – when these errors and biases will be the most pronounced because of have the least information -and instead re-evaluate plans throughout a project. We make course corrections. We constantly re-adjust. So Hofstadter will still be right, but he’ll be less right than before.

Photo by Mr. Asthma Helper

In Lean there is a concept known as “standard work”. A game around standard work is to define the elements of work to a point that they are standardized and predictable. The theory goes that the highest evolution of management is to understand exactly how something is made will allow us to make a whole lot of it cheaply and with no risk.

At that point you can write a really tight job description and get the absolute best people for the job.

So, we’ve been trying to do this in software for years. Chasing the grail of standard work. First, waterfall ignored it. RUP tried to institutionalize it. Scrum even took a stab at it. Kanban has dangerous rhetoric around it.

So, let’s take a look at standard work.

Below is a quick HD video about standard work, it will fully train you in your new position at Modus Cooperandi.

Standard work tends to be this dull.

For knowledge work, the more systems we create that are this dull, the more we detract from the creation elements of work. For example, one of the repetitive tasks I have to do is accounting. It’s pretty much digging through one pile of numbers and moving them into some other system. It bores me to death and does not, in any way, get me excited to create new, interesting things the rest of the day.

I’ve worked for companies that have gone through ugly ISO 900x processes that have left people with forms to complete to fill out more forms. Very standard work, very soul crushing.

I’ve seen teams whose stand-up meetings have become standard work, in this sense. They show up, mumble perfunctory nothings about what they did and what they are going to do. No one listens to them, they don’t listen to anyone else.

Agile tries to build itself constructive rituals – but they can become staid. Lean tries to help understand variation – but the drive for this can become over standardization.

The goal is to produce value. Producing value is fun. Stand up meetings without a soul begin a day without a soul. Processes that reduce work to ultra-defined chunks, reduce creativity to ultra-defined chunks.

When we are in knowledge work, and the goal is creating new knowledge and artifacts, reducing creativity is reducing profit potential and sustainability.

Beware as you head forward that your process does not kill your creativity – whatever process you choose.

In 1999, during the dot com boom, if you could even describe something plausible you could get people to invest in it – both their money and their minds. I was no different.

At one point, I worked for a company that was creating an in-vehicle computing platform. The concept was that your PDA (at the time this would be their Palm Pilots) could plug into a cradle in your car and, as you drove, magic would happen. You could get stock market reports (this was very important then), maps, weather reports, and your e-mail.

They recruited me away from a job I could have had for life by telling me wonderful things about my new professional life in this bold new company. The CEO had grown and sold two other start ups and this was going to be his third home-run. The CTO was a whiz with a golden touch.

I was being hired to be the liaison between this company and local or state governments – basically to build the first central repository of real-time traffic data in the US. There was tremendous upside and absolutely no risk. What could possibly go wrong?

Weeks went by at my new company. The pace was frenetic. Everyone talked about how amazing the product was. Daily system architecture meetings were filled with manic white-board scribbling. I was furiously working away on my part. We had drawings, schematics, mock-ups.

Today, the magic they were trying to launch has been fairly well implemented. The goal was to say things to your car like, “Show me the best way to get home and avoid traffic.” or “Get me to the nearest coffee shop, but it needs wifi.” Today, 12 years later, you can give some simple voice commands. In 2000, this tech simply did not exist – but no one told the workers at my startup that.

We had planned to launch our wonder-device at the end of the year. It was nearing Thanksgiving. They kept promising to show the device to me and others in the company. Excitement was growing. We were all ready to put these things in our cars.

Finally, we had a demonstration of our device. I walked up to it and commanded “show me traffic for Seattle.” Nothing happened. Someone next to me said, “It only works for his voice.” and pointed to the person next to me.

That man then said, “Up … Up … Select …. Up ….. right … select” ….. “SELECT!!!” … “SELECT!!!!!”. When it didn’t select, he pushed the reset button. “It’s not fully trained,” he said.

The system could barely understand simple commands to navigate menus in a quiet room, let alone complex voice commands in a noisy car. Rather than parse complex sentences, this had to be trained for a handful of common words. I had been lied to.

The shock was too great. I completely lost my composure. “THAT’S IT?!” There was no way this system could ever be ready to do anything at all. It was utter garbage.

No one else in my team could understand why I was upset. They looked at the barely functional prototype and insisted it would become market ready in a little over a month.

When I started working for the company there was about 60 of us. At the height of my time there, we had over 100 employees. When I was laid off we had slightly more than 25. As people left, they were sad that they would not be able to see the awesome launch at the end of the year.

I was there 5 weeks.

The good professionals at this company were victims of several cognitive biases. Let’s examine a few.

The Bandwagon Effect is basically groupthink. People in a group that see others believing something tend to give their compatriots the benefit of the doubt and, soon enough, begin believing it themselves. In this case, people, including myself, assumed that the management of the company was truthful. On that, everyone built up their expectations of what was possible – even though most of them must have known on some level that the technology of the day would not support what was being promised.

What follows groupthink is the institutionalization of the group thought. The Availability Cascade is a system where a group’s collective belief (in this case a car you could talk to) gains credibility as people repeat the promise. Everyone at the company was caught neck-deep in the availability cascade.

And oddly enough, simple old Wishful Thinking plays a role here. The people at my company had been steeped in years of dot com fairy tales. We all would have jumped on a bandwagon and promoted a cascade that promised us each millions.

When we are planning, we are creating expectations. This is normal, expected, and even positive. But as we move forward in projects, we as actors really want them to succeed. The opportunities for the Bandwagon Effect, Availability Cascade, and Wishful Thinking to sway our decision making are many and can be insidious.

Photo by K W Reinsch

In Freakonomics, Steven Levit tells a story of a day care center in Israel that was tired of parents being late to pick up their kids. So, they turned to a market solution: they charged a penalty fee if you were late to pick up your kids.

But rather than lowering the number of late parents, the number actually shot up. Why? Because before there was a social contract that said, “If you are late to pick up your children, you are causing others inconvenience and you are bad.” But if there is a fee, there is now a market contract that says, “It costs you $5 an hour to park your kids here.”

Parents with late kids were no longer bad, they were just taking advantage of a great new service by the day care. That was not the intent of the day care, they wanted less kids after 5 pm. Now they had more. Why?

This is The Framing Effect in action. The Framing Effect says that the wording or the context in which options are presented directly impact (or frame) our selections. In this case, leaving your kids at day care late moved from a social frame to a transactional or economic frame. Parents now judged base on a cost-benefit analysis (Is it worth $5 to run this errand and know my kids are safe?) The fine was seen as a fee.

When we make decisions, the Framing Effect is good in some ways (can provide context, background, etc.) but bad in other ways (today’s context may not be tomorrow’s). Decisions that are made today are therefore at risk of being overly framed by current contexts or biases and not looking out into the future or too far into the past.

Frames themselves are the objects that make up our world view. They can be experiential (social, personal, economic, political, etc) and they can be emotional (based on past experiences, joys, traumas, hopes, fears, etc). If you have been in a situation where a large mean dog attacked you, your frame may from that point on include a fear of large dogs – even if they are friendly.

With this deeper understanding, we can see that frames can be imposed by other people, but also by our own experiences. We use frames to filter our environment, to quickly interpret context, and to formulate appropriate responses.

When we have a team in an office setting making decisions, we are dealing with framing from many angles. First, the information they are receiving may have been presented to them in a framed way. Like the difference in these two sentences:

• Work bogs down at Charlie’s desk.

as opposed to

• Work bogs down when it reaches the QA stage.

Charlie is the QA guy. On the surface, both of these sentences say the same thing – work is bogging down when it reaches QA / Charlie. But when we read the first sentence, we are reading the problem as Charlie. When we read the second sentence, the problem is workflow at the QA stage which involves Charlie, but may not necessarily be due to Charlie.

The Frame (Charlie v QA) (personal v functional) has a direct impact on how people initially process the problem and begin to devise solutions.

Photo by Katie Fergos

My colleague and I were four days into a field exercise for an environmental impact statement or EIS. An EIS is a document every public project must complete to show what the short and long-term impacts would be if it were completed. They tend to be large and expensive. This particular project was very large and the impacts many.

Given that the project was underway and had a definite deadline, no one was willing to slow it down or change its scope. This particular task was supposed to take the two of us about a week to complete.

Four days into this particular task, we found the data we had been given was poor, the people to contact with better data were unavailable, and that the massaging of the new data we couldn’t even get would take weeks.

When we presented the managers of the project with this information, we were told Don’t Slow Down, Just Get It Done.

Get it done with what?

The data you already have.

We were then expressly told not to contact anyone else or extend this particular task.

Back then, we were completely confused as to why anyone would be so totally stupid. How could these managers knowingly ignore that we were using faulty information that would result in a useless report? These weren’t Dilbert characters, they were real live human beings.

Over the years I would watch other seemingly smart people drive their high-tech startups into the ground by insisting that an initial plan or idea go forward despite ample evidence that all that lie ahead was ruin.

What cognitive biases kicked-in to destroy these endeavors?

Irrational Escalation – This is in-for-a-penny-in-for-a-pound-ism. Once people start on a project, they find it very hard to stop – even if the project is obviously doomed or the return will not cover future costs. The managers felt that the project was already underway and even using bad data was better than delaying the project and asking for new data. The bad data (not surprisingly) later resulted in obviously flawed analysis – causing even more expensive and stressful work later in the project.

Expectation Bias – This is a world-view bias. If we believe something, we pick data points that support that expectation. Further, we expect that most data will support our expectations. We had an opportunity to create a research regimen that would yield scientific results. The managers assumed this was all a formality and that any data (good or bad) would support the original plan. This was likely underscored by “experience” that showed that most data did indeed support the original plans (which were likely suffering from expectation bias).

Planning Fallacy – A central issue here is simply that we didn’t have enough time to finish our task. The expectation bias inherent in the people who wrote the initial scope gave us only a week. This led to them, and us, falling prey to the Planning Fallacy which shows that human beings have a strong tendency to underestimate task completion times. On the ground, we saw this playing out. From the manager’s desk, the plan was correct, we were at fault.

Status Quo Bias – This bias says that once we start something, we tend to want it to continue. This is why in Collaborative Management we seek to build an explicit Culture of Continuous Improvement for teams and companies. Making change and improvement the center of the culture makes change the status quo. Needless to say, this wasn’t the case with my project back then.

The upshot here is that biases can gang up on us. Our enthusiasm, belief in ourselves, and assumption that things stay pretty much the same can combine to create seemingly logical decisions that can turn deadly. My managers no doubt reasoned that the project plan took over a year to write by well-informed professionals. There was very little cause for concern that a small part of the project might derail the whole thing.

In the end, our re-work was hardly noticed because other parts of the project became late, with much higher costs. One can only guess that the same forces were at work.

Because things are the way they are, things will not stay the way they are.
~ Bertolt Brecht

Billie runs a shop of 24 workers that have a maintenance contract with a local school system. Over the summer, the shop has been busy, but not overwhelmed. They’ve been making routine repairs at schools around town. The crew is happy.

Billie knows that in one month school will start. The unnoticed maintenance needs over the summer and the impending assault by the returning students are going to drive demand through the roof. This change will not only result in the obvious – a very busy time for the staff – but also in the unexpected. Staff stress will go up, job satisfaction will go down, tempers will flare causing unexpected interpersonal issues, some number of people will be injured, and two or three “really weird” things will happen.

Billie and his team have to be prepared for added work load – which standard work processes can handle. But they also have to be prepared for the human emotional toll and the rise of things that will only present themselves when they do. They don’t know what those things will be – they just have to be ready for something.

We have two choices with change. We can ignore it or we can embrace it. We can not eradicate it. We cannot tame it. Change is both external and internal. We change, markets change, the weather changes, politics change. Everything migrates, shifts, and evolves.

While there is much in these changes we cannot foresee, there is much we can accurately anticipate. Billie knows that tempers will flare and that there will be interpersonal blow-ups. They will always be petty. They will always make him want to shout, “Seriously? This is what you’re wasting my time on?” But Billie can see that its because of stress and change. When these flare ups will happen is a mystery. That they will happen is a certainty.

The two or three really weird things can range from the minor-but-time-consuming (there’s a family of angry cats stuck in the HVAC system at Bernie Madoff Elementary School) to the horrifying (which we really don’t need to envision here). These may or may not happen.

Having no tolerance for change as a manager means that every event not covered by process becomes a traumatic event for all involved. Process cannot deal with the daily operational change, therefore the change is a crisis. That trauma makes people less able to effectively respond to the change when it occurs.

Change before you have to.
~ Jack Welch

Managers need to respond to these types of operational change daily. I’ve never met anyone who disagrees with this. But what I often find is managers wanting to respond to these events with more process. There is no reason after cats appear in an HVAC to create a “Cats in HVAC” rule set. The event itself is unimportant.

What was important was:

1. How quickly was the issue responded to?
2. How quickly did the worker or team devise a fix?
3. Did the worker or team ask for help when they needed it?
4. Were the appropriate people informed of the situation?
5. How was other scheduled work impacted by this unforeseen event?

In essence, what impacts did this change from the status quo have on the crew, the schedule and the customer? Did Billie and his team have a system in place that could elegantly respond to change? Were there existing processes or procedures that slowed response or made it less effective? Was the response to change to freak out and lose control of schedule, communication, and the crisis itself? Or was the response to change to escalate the new event, inform those downstream of the delay, and move forward?

Note: This post is about operational change … there will be others about organizational, market or other types of change.

Further Reading:

Predictably Irrational – Dan Ariely

Drunkard’s Walk – How Randomness Rules Our Lives – Leonard Mlodinow

American Gods – Neil Gaiman

Photo “Unexpected Food III.2: Gourmet Sardine Fries” by Jo Christian Oterhals

Barney McFingers must be fired.

It is two in the morning and Lynda is staring at the ceiling. Barney has consistently slowed the team’s work, he is always an obstruction, and he gets harsh and complains every time someone suggests that he match the rest of the team’s performance. Lynda hates firing people, but the facts are the facts.

By eight a.m. Lynda is writing Barney’s “You Gotta Go” letter. Company policy is to have an exit interview with at least three managers. So she goes to Nate and asks if he will come. He looks startled, but says “Yes.”

She then goes to Joanne, who also looks startled, but says “Yes.”

Lynda then goes to HR to let them know that there is consensus about Barney.

Ten minutes later, Nate and Joanne show up in HR asking why Barney is being fired. They think Barney is not an obstruction, but that he’s been given way too much work to do and is bogged down.

Lynda’s logic was sound. Barney was not pulling his weight and had to go. When she visited her colleagues, she never even asked if they agreed. She just assumed they wouldn’t disagree with such sound logic.

Lynda is a victim of the False Consensus Effect.

The False Consensus Effect is no stranger to the modern worker. We make choices that are perfectly rational and logical given our current conditions. We don’t realize that there are other, equally logical, explanations and reactions that, when examined, could yield a much better outcome.

Logic, as much as we’d like to think otherwise, is impacted by context and we often don’t know the full context of a situation. The current Tea Party movement is an excellent case-in-point. The members of the Tea Party have limited information about the context of their beliefs. In that limited world-view, their claims make perfect sense. Smaller government means less control and more freedom.

That is an airtight argument. You simply can’t argue against it. It’s a logical chain. Therefore they must be right. Therefore others must agree with them. Therefore those that don’t are incorrect.

Unfortunately, the truism does not tell a complete picture. While just about anyone you ask would support smaller government (myself included), only a handful of people are actually in or support the Tea Party Movement. This is because there are many differing views on the role of government in different contexts.

Most people who have been through a disaster appreciate the fact that there is someone to help with clean water and food. A quick search of Tea Party and FEMA shows that disaster relief would be very high on the Tea Party list of agencies to remove. While I’m all for smaller government, having been through a series of tornadoes followed by high heat an no drinking water … I was pretty happy to see FEMA and the Red Cross show up.

In business this happens often, we get to the end of a meeting and ask “Are we all in agreement?” Participants nod and mumble. We take that as a yes, but what was really agreed to? Odds are, the people at the table have lacklusterly agreed to something much less grandiose than is in your mind right then.

False Consensus can be dangerous and expensive. When you are moving forward, ask yourself often, “Am I sure I have buy-in from others?” You’ll find yourself asking and usually getting positive responses. But every so often you will be surprised – your assumptions are not common opinion.

Photo by Tonianne

Years ago, Ricardo Montalban (known to his friends as Ricardo Gonzalo Pedro Montalbán y Merino) understood that our moods were signals. Messages that told people that things were going okay, not-so-okay, or downright horribly.

Below, those things are smilees.

Stupid, simple, immediately recognizable facial drawings.

They are also perhaps the most important business metric you will ever find.

This image below is a team kanban using smilees to note how people felt about a particular task. Upon completion, the person or people doing the work, annotate the ticket with something denoting their mood. We’ve seen people do this with everything from simple faces, to pictures of angry cats or mushroom clouds.

This is to combat something called Availability Heuristic (among other things). Availability Heuristic says that we are more likely to estimate a higher probability of events that we actually hold in our memories. Meaning, if we remember it, we assume it will happen more often than events we have not experienced or previously heard about. In addition, we tend to remember emotionally charged events. So we would be more likely to remember the big wins and big problems over their less emotional counterparts.

This means we tend to focus on very painful or very wonderful (read relatively rare) events that we want to eradicate or experience, respectively. We will get together to discuss the emotionally charged, but rare, events and forget the smaller ones. They become the comme-ci comme-ca of our day – just normal stuff that happens.

But those small victories, those small pain-points are the ones where solution to continue or improve are much easier to envision and act out.

Those smilees measure Subjective Well Being at a very fine level. They say, “How did you feel today? Right Now! At the moment of doing?” That measure can then be used later to review tasks and see what is it in our daily work that really does make us perform better, that really does make us happy, that really does upset us just a little.

When we seek out what to improve as individuals, teams and companies, seeking out the real day-to-day minor victories and small imperfections and understanding their impacts is crucial. This gives us cost-effective, immediate improvements with very high return. It can free us from huge and unnecessary rules or changes to combat the rare, but emotionally painful events – and put them in perspective.

Note: Amos Tversky and Daniel Kahneman discuss their findings of Availability Heuristic in this very utilitarian Powerpoint. And the United States is still trying to catch up to El Salvador in terms of subjective well being.

Images of smilees and kanban by me.

Image of Mr. Roark and Tattoo by posterity.

In 1977 and 1978 there were 1,185 UFO sightings by Brits. Nearly two UFOs a day were apparently buzzing England – one can only imagine it was to get tickets to see Queen at Wembley. What was going on that had the UK’ers looking up from their mushy peas long enough to see UFOs?

They were coming down from a Spielbergian high – in 1977 Close Encounters was released and everyone saw it.

When we put our minds to it, we can create just about anything – including UFOs. In 2009, the Guardian ran an article about what they called “The Will Smith Effect” where sightings of UFOs were remarkably higher in years where movies involving aliens (funny or not) were in the theatres. (Or Dr. Who did something notable.)

Now, most of those who phoned-in a UFO sighting truly did believe there was, if not an actual UFO, a good chance that they did actually see a UFO.

So, the question is … how do we keep UFOs out of our retrospectives? Continuous Improvement demands that we spot ill-suited patterns and deal with them. When we are looking for patterns in our work, how can we see the real patterns and not items that represent our biases, current popular memes, or other false positives?

The UFO-happy Brits had been seeded with an expectation that they would find a UFO if they looked up in the sky. And, the thing is, it was not a very strong seeding. It wasn’t like Prime Minister Callaghan came out and said, “We have been contacted by Aliens, they seem pretty cool, watch the skies for the little buggers.”

So, with a relatively weak seeding, UFO sightings skyrocketed. All of them false positives.

When we tell people in continuous improvement that things can always be improved. Or when we get together in a retrospective and place a not-so-subtle demand that we might be able to do things better. Being good professionals, they go looking for them.

Ideas for continuous improvement still need to be examined and vetted. Teams in the process of continuous improvement should watch that the Will Smith effect isn’t turning out UFOs, as opposed to real, demonstrable opportunities for change.

Image by Buzz Hoffman and his son.

Manager: We’re way behind, why aren’t you working faster?

Not-manager: I have too much to do and am constantly interrupted by the other guys needing detail.

Manager: None of them have this problem, you’re a lazy whiner! Stop complaining and get your work done!

In March, we wrote a post entitled, “You Cannot Yell at a Board with Stickies on It.” That post described how using a Personal Kanban actually helped depersonalize work. Depersonalization here means that when something was delayed or difficult to do, the visualization helped us see that the work was the team’s issue and not a problem or reason to blame an individual.

Our tendency to blame people first is called Fundamental Attribution Error or Correspondence Bias. I like Fundamental Attribution Error because it’s very graphic and, in the work place, apt. The results of this are simple and devastating: when we are part of a team and a team member’s task is not getting completed or if their work is routinely poor, we will approach them with questions like:

“What is wrong with you? Why is your work not getting completed?”

Because we primarily visually focus on the person before us, we are looking for answers regarding that person. Since the person is all that is visualized, the person becomes the problem. Also, since interpersonal issues can be a rat’s nest to solve, we are actively not looking for reasons outside that person. We want the problem to be a personal defect and then order that person to solve it.

Nice, neat, contained, and seemingly logical.

Since the problem is rarely the person, but is more often a policy, procedure, communication breakdown, or random events – we then are not satisfied with the results. Rather than taking responsibility for their horrible personal behavior, the person says, “I’m not getting my work done because the graphic design manager is a jackass and won’t get me the materials I need or give me access to the people I need to talk to.”

This is valid, from their point-of-view. But the manager probably (not definitely, but probably) is not a jackass – the person you are angry with is also engaging in Fundamental Attribution Error. Soon we get a Fundamental Attribution Cascade and blame, disrespect, and distrust proliferates around the office.

As the “You Cannot Yell at a Board with Stickies on It” article suggests, most of these issues arise from ambiguities in communication. In other words, we don’t have clarity into what others are doing, they don’t have clarity into what we are doing, and that creates a ripe field of breakdowns in which to harvest a whole crop of Fundamental Attribution Errors.

In The Correspondence Bias, Gilbert and Malone say:

People care less about what others do than about why they do it. Two equally rambunctious nephews may break two equally expensive crystal vases at Aunt Sofia's house, but the one who did so by accident gets the reprimand and the one who did so by design gets the thumbscrews. Aunts are in the business of understanding what makes nephews act as they do…

In this case, Aunt Sophia presumably has some insights – or some clarity – into the actions and motivations of the boys. The key issue here though is the first sentence: People care less about what others do than about why they do it.

The question is … do we understand why they do it, or do we engage in fundamental attribution error. Without a kanban or something visual to take the focus from the individual and place it squarely on the situation-in-context, all we have to blame is each other. Basically, we get into bias soup here because we’re misattributing a problem in work flow with a person’s character or motivations.

The visualization of work provides clarity to the team to help diffuse this chaos. 

Image by Christian at Redteam.

Life is a sum of all your choices. ~ Albert Camus

When I ask you if you would like an apple, you may say “Yes.” Because you feel that an apple would make you happy. So I place an apple before you and you begin to eat it. And you are happy.

But what if I were to place two apples on the table -- one was the one you would have have happily eaten and the other which is slightly fresher looking.

You will choose the fresher apple and eat it and be happy.

That all makes sense. But, if I asked you, “would you have enjoyed eating that other apple,” you would likely say "No.” Even though in our alternate no-choice reality you were perfectly happy with the apple.

This is a simplistic view of “Distinction Bias.” Distinction Bias says that when we compare things directly, we tend to overestimate the importance of their differences. Yes, the fresher apple was better – but it didn’t make the less-fresh apple unenjoyable.

If there were five apples on the table, you might take a few minutes to examine each apple so that you would be sure you had the best one. Each minute you spend laboring over that decision of mostly-like things is likely waste.

Distinction bias causes us to over-examine and over-value the differences between things as we scrutinize them. Psychologists and economists note that we have two ways of examining the suitability of something. The first is through single evaluation – with one apple, we ask questions like “will this apple taste good?” The other is through joint evaluation – we compare two things and ask questions like “will this apple taste better than that apple?”

That second question is very different than the first. We switch into joint evaluation mode when we have choices and we take the exercising of choice very seriously – even when those choices have very limited impact. We overestimate that impact.

In my house, I have a 32” HDTV which is the perfect size for where we have it. In its space, it is big, has a great display, and is a fine television. The other day I went to Costco and there was this HUGE HDTV, a smaller one, a smaller one than that, and then a really really tiny one.

In cavernous Costco, the tiny display almost seemed comic. Why would anyone buy such a small TV? When I approached it, the impossibly small set was a 32”. The same one that’s in my house, in fact.

When seen in the Costco context, when subjected to joint evaluation, the perfectly suitable 32” option was somehow unsuitable. In a home context, with single evaluation, the television is wonderful.

Today, on Facebook, I was struck by this A/B test apparently put to me by Mark “So sue me” Zuckerburg himself. He wanted to know which place I liked better – Alyssa Lewis’ Seattle Pie Company (which makes some of the most excellent pies I’ve ever had, amazing crusts, wonderful fresh fillings) and Brian Voltaggio’s VOLT restaurant in Fredrick, Maryland (which creates some of the most incredible experimental American cuisine I’ve ever had).

So if you want a pie or dessert or even an awesome chicken pie – I’m sending you straight to Seattle Pie Company. If you want a cool creative dinner that will surprise and delight you – I’m sending you to VOLT. (They do an avacado mousse that is unbelievable). I have been to both several times and have never (not once) been disappointed.

Facebook wants a database of preferences to build up so they can market stuff to people more effectively. The problem is they’ve created an A / B test that makes sense to them (two restaurants Facebook knew I enjoyed) and actively encourages false distinctions from distinction bias by making me jointly evaluate two things that are actually dissimilar or even complimentary. Ranking Seattle Pie Company against VOLT is like ranking oxygen against drinking water. The results can only be misleading.

In business and in our personal lives, we want to optimize for something. Sometimes it is cost, other times it might be effort, still others it might be profitability, screen size, or capacity. When we are given a choice, we want to optimize the choice. That is natural and even a good thing. But sometimes we go a little overboard, getting stuck in analysis paralysis and taking way too long to make a decision – negotiating our way through only marginal distinctions.

Choice infographic by Will Lion.

Indignant Screenshot of Facebook by Me.

When people decide that the nine-to-five world isn’t for them any more and it’s time for them to enter the consulting world, I give them this piece of advice:

You need eight “sure things” to get one project.

There are a variety of reasons why this is the case. Today I’d like to talk about the one that squarely rests on our own shoulders: The Overconfidence Effect.

Let me describe this to you, and then give yourself a few minutes to think of all the ways this little bugger works its way into your daily life.

The overconfidence effect is where people take too much stock in their own opinions, judgments or decisions.  They are then either surprised or indignant in the future when things do not go as expected. The tendency then, rather than say, “Oh wow, I was wrong,” is to say, “Who messed up my obviously correct expectation?”

No one messed up your expectation, man. You were wrong!

We are wrong all the time. Probability works that way. It is simply improbable that we will be right all the time. But we fall into the trap of the overconfidence effect repeatedly, we feel confident in a potential outcome and act on that confidence, rather than evidence.

This is also closely linked to something called Optimism Bias. This, as it sounds, is the tendency to actually believe the positive outcome you are planning for will happen. Now, heaven help us if we don’t have at least SOME Optimism Bias or we’d never bother to do anything.

I worked with one person who seriously based his company on Optimism Bias. He once told me that the key to success was to be “relentlessly optimistic.” That didn’t turn out to be such a good business plan for him. After repeatedly making decisions based on optimism and having few of them come to pass, he closed his company and went to find options elsewhere.

Eight sure things to get one project.

We will not only fool ourselves from time to time – we stand the chance of fooling ourselves often.

The key here, for all projects, is to recognize that overconfidence and optimism bias plays a role in how we interpret plans, potential and outcomes. Be confident. Be optimistic. I certainly would not advocate pessimism. But never lie to yourself and look for those points where you might be doing just that.

Photo by Tonianne

The Gemba is where it all happens. It’s the factory floor, the crime scene, ground zero. It’s where the evidence is, the witnesses are, and the location to find clarity. In lean we are told to “Go to the Gemba” – to walk the floor, talk to the people, and make the change happen. The Gemba, in Lean, is where managers go to learn the real story from the ground level.

But we have a horrible (sometimes catastrophically so) history of doing this.

In 1847, Ignaz Semmelweis was the Gemba and was destroyed by the Gemba. The Gemba actively worked against itself. Semmelweis was a doctor who was dealing with a terrifying problem. Babies were dying of something called “childbed fever” in obstetric wards. All doctors shared a desire to rid the world of this calamity.

Semmelweis figured out that if medical staff simply washed their hands with a disinfectant of chlorinated lime after performing an autopsy, the rate of disease dropped dramatically. His peers (other doctors) found his theory laughable – even repugnant. His theories could not possibly explain all the cases of childbed fever. Discredited and, worse yet, unable to prove his theory correct and forced to know that babies were continuing to die, Semmelweis fell into a deep depression and was committed to an institution where he later died.

A few years later, Louis Pasteur greatly advanced the notion of germ theory and proved Semmelweis correct. While it wasn’t necessarily handling the cadavers that was causing childbed fever, it was pervasive germs that required more than soap to cleanse them.

The result from this is now known as the Semmelweis Reflex. This is a professional (and general psychological) reflex to reject new evidence that in some way threatens established norms or firmly held beliefs. Throughout my career, I’ve watched this play out while building freeways (what do we need ramp metering for!?), planning rail systems (why not just drive?!), contracting software projects (what do you mean you can't say exactly what the software will look like?!), and introducing new process ideas (creating tests first is a waste of time!). People require an extremely high level of proof to offset a strongly held belief. And yes, sometimes those people were me.

We are beginning to use visual controls like kanban to help see past our Semmelweis Reflexive tendencies, but these controls will not save us outright. Even if we visualize the problem and make these blind spots explicit, we will still find ways to explain them away.

So, remember this. When you conduct your retrospectives, when you examine your workflows, when you take a look at your own lives, question institutionalized biases that may be making your own Semmelweis Reflex fire.

Photo from the Library and Archives of Canada.

In short, why do people repeatedly and predictably fall into traps of poor logic, bad citizenship, and self destruction?

If we as managers, as workers, as leaders, as humans – can’t get a grasp on why we make uninformed decisions or ignore information … how will we ever be able to make decisions effectively?

So … Stay Tuned for more Biases.

Do you like people to tell you what to do? Do you like your freedoms taken away by others? Do you really enjoy someone limiting your choices?

My guess is probably not.

When you make rules for others, this is exactly what you are doing. Even if it is “for their own good,” the more rules you have, the more freedoms you have removed. For this reason, when we make rules or set process, we need to understand that no matter how well we explain these new rules – no matter how great the buy-in from others in the group – there will be those that resent or break those rules.

When you set a rule, people ask two questions:

(1) What is the minimum amount I need to do to not break this rule

(2) What is the easiest way for me to not follow this rule at all?

This is due to Reactance – which is a tendency in people to push back against reductions in perceived or real freedoms. The more the new rule is unexplained, unexpected, or disruptive, the more reactance you will encounter.

Most organizational change or processes come with outside rules that actively and immediately engage reactance behaviors. People don’t like being controlled. You don’t, I don’t … no one does.

What people do like is clarity. A law we willingly follow does not limit our freedoms by fiat. It merely becomes a cultural norm that supports our preferred way of life. If we have clarity over the work we are doing, what our team members are doing, and how we fit into the production of value – we’ll likely need less rules to control our behavior. Less rules mean less reactance.

This does not mean structure should be abandoned, it means that our approach to rule making needs to be examined. Collaborative creation of rules, of process, and of the rate of change is required for healthy rule creation and adoption.

--

To quickly turn that on its head … in the software world I have seen IT groups and development groups adopt much-needed and healthy agile methodologies and the rest of the organization engage in reactance behavior as the techies approached them and said, “Our new process means you have to follow these new rules.” Since they were not involved in the decision for agile migration, or see themselves as direct beneficiaries of the new rules, they push back.

Photo by Tonianne

“I shall not today attempt further to define the kinds of material I understand to be embraced within ["hard-core pornography"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.”

— Justice Potter Stewart, concurring opinion in Jacobellis v. Ohio 378 U.S. 184 (1964), regarding possible obscenity in The Lovers

I’ve used this quote a lot lately in talks about quality and completeness. There are some things that are entirely contextual and, therefore, lend themselves to ambiguity. This is the way language works. Some (few perhaps) words are very concretely defined like “five” … “five” means when something is one more than four of some state. Five years old, five batteries, five muppets singing five people in my family.

For everything else, we have different degrees of ambiguity. The current ambiguity of the week might be what “guilty” means for Casey Anthony.

A lot of that ambiguity is driven by our past experiences, which make up our “world view”. Our world view is basically a filter by which we take in information and rapidly process it. Often, this is very easy and painless. Our more-than-likely-shared-world-view says a vacuum cleaner shaped object is probably a vacuum cleaner. This lack of variability makes vacuum cleaners fairly safe for discussion.

But what other topics like religion, elected officials, education, leadership styles, international relations, HR policies, health care, road improvements, anti-trust law, … and so on have attached to them are a passel of biases. Regardless of which of many possible sides of these issues we may personally be on, the existence of bias is apparent.

We don’t shut off our biases at work either. So, today I’d like to discuss a key bias (anchor bias) and explore how it might make things easier or harder for us at the office.

Easier? Yes, easier. Many biases we set up are the result of actively training our brains to respond quickly to certain situations. If we are working with a particular system and that system has three states (A, B and C) and we know that A requires response 1, B requires response 2, and C requires response 3 – we will start to watch for those three states and quickly respond to them.

Further, if we notice over time that B happens 70% of the time, C happens 23% of the time and A only happens 2% of the time, we’ll start to assume that B is going to usually happen, C will happen sometimes, and A is rare. We will then tool ourselves and our environment to suit mostly condition B.

We develop a cognitive bias about the outcomes from the machine.

How strongly we hold onto that bias is key. We can use it as a rule of thumb: “B happens a lot, so I’m going to prep myself for B. But if it changes, I’ll just adapt.” Or we can use it as something to anchor our processes to: “We’ve seen that B happens 70% of the time, so we are going to train everyone to expect B 70% of the time and develop policies and procedures around this 70% number. It has always been 70% and always will be.”

Harder. As we get closer to that second one, we approach what is called “Anchoring Bias.” We begin to rely on that 70% number and institutionalize policies around it. If that number happens to change, neither we nor our systems can easily adjust. The 70% figure has become part of our world view. A change in that number is now no longer merely a fluxuation, it becomes a major upheaval.

Some may call anchoring bias “sacred cows” – these concepts are central to the operations of your group. We will always have core beliefs that make up the mission of our organization. Missions, by default, need to have some type of world view – and moreover a clear and well-defined world-view. But the more we add to it, the more we run risk of unhealthy anchoring bias.

Photo by Lo van den Berg

The agile manifesto said "Individuals and interactions over processes and tools".  For years, I did not question that principle.

Now, however, I would replace this with "Collaboration over process."  Here’s why:

What's happened with agile is that the rhetoric is so team empowering that it transforms teams into heroes. Like individual heroes, this divides them from the rest of the org. It turns them into inward focusing groups that are optimized for their own product and have a well constructed but ill-fitting interface into the rest of the organization. While it was team collaborative and was more collaborative with outside stakeholders, the rhetoric still focused on the teams.

But the teams are made up of individuals. And the team operates within an organization. And the team has outside resources. And the team has clients. There’s a lot going on with those outside interactions that need to be explicit.

I really took the Agile manifesto seriously. Like many, it was pinned on my office wall. I could bludgeon uncooperative employees or clients with it. I could wax eloquent about it. For me, finding its shortcomings was a painful and lengthy process. I slowly came to the realization that, as it had aged, Agile had codified, ossified, solidified into something you could easily do wrong and that was nearly impossible to do right. The words in the manifesto no longer represented what was happening in practice.

So, I began to strip away some of the trappings of over-loaded agile at my company. We replaced sprints with release cycles. We destroyed the product owner for a fully collaborative relationship with clients. When we started with kanban, it was game-on. In 2005, when we ran our first kanban driven project, we had a very different view of kanban - but even then visualization of flow almost immediately started to change how we worked.

Our process evolved rapidly during that project. At every standup people had a suggestion of how to make it better. There was a collaborative spirit not just for creating the software, but also for how the project was managed. We were no longer following a rule-book of best practices. We were building something that worked for that particular team building that particular software for that particular client.

In other words, the team had the freedom to truly optimize.

Don’t let anyone say you are doing a process “wrong" – find what your “right” is.

Image by @gavintech and shared by Venessa Miemis

 
--