“What metric are you using to incentivize your people to perform?”

“Every day we compile who processed the most orders, the winners are broadcast every day – as are the losers.”

“Hmm, and how is that working.”

“People love it, they are all working as hard as they can to process orders.”

It didn’t take long to verify that, rather than creating an environment to process orders, it instead had fostered an environment where everyone was angry. High performers thought low performers were lazy. Low performers knew that high performers were cherry picking. People in the middle just felt lost in the shuffle.

This can be attributed to something called “The Tiger Woods Effect”.

As we are put into competitive systems with clear winners, the actual performance of other players actually decreases. When we set up competitive games in our organizations, we unleash all sorts of cognitive biases – this being one. The goal becomes winning (or losing) the game (satisfying the metric) and not providing value for the company or the customer.

The team processed less orders because they were playing the game to individually process the most orders. Golfers shoot worse when under direct pressure to perform better.

Note: The Modus Press ebook Why Plans Fail, examines how cognitive bias impacts our decision making at the office.

(And Bloomberg needs to have better video embedding.) For the video click here.

Okay..  Herbert Hoover and Ayn Rand tell us of the rugged individualist. More or less, its a western ideal. We question convention - even conventions WE helped create. We have free will. We make decisions and act accordingly. In our rational hearts, we make only appropriate, moral, and ethical decisions.

We want to control our environment and, in order to do that we must control ourselves - and perhaps even those “less intelligent than us”.

But we've learned a lot recently about the human brain and the psycho soup we call a mind.  We now have significant data that leads us to scientifically understand that humans are more like highly suggestive, moody, erratic meatbags. And I understand that I, Jim Benson, fit that bill as much as anyone.

We also understand that we fall into some definable types. Some of us are introverts, some of us are gregarious, some of us are creative, some of us are INTJ, some of us are ADHD, some of us get depressed in the Winter. etc. etc.

And maybe all these deterministic blanket statements describe no one in particular - but rather describe common human states we all find ourselves in from time to time. We do know one thing, that whatever evidence we may find that our will isn’t as free as we’d like it to be - the opposite is also untrue - we are not some B.F. Skinner robots of behavioralism. We are neither John Galt nor walking computers.

We’re something very different. We are neither pre-programmed nor truly rational, we are influenced. We are complex emotional beings striving for clarity. And we go to work in the morning.

Why this matters to people and business...

Recently, I had the unique opportunity to see some beauty worked. Simon Marcus and Jabe Bloom at The Library Corporation decided that their staff needed a dose of entrepeneurialism. Why they felt this is not really important right now. What is important was that a large group of computer programmers who had worked their entire careers on legacy systems suddenly found themselves in a situation where they had to invent new products and then discuss those products with potential users.

And by potential users I mean strangers walking the streets of Washington DC.

TLC’s staff is as varied as anyone’s, and they have their share of introverts. These introverts had to talk to strangers on the street about products they just made up.

Jabe Bloom, TLC's CTO, knew that the coders would literally freak out if asked to do this - so he had to ease them into it. For a week leading up to the DC day, he gave his teams exercises that slowly helped them understand who their clients were, the sensibilities and needs of other people, what problems these people might be having, and then license to invent products that might solve those problems. From this, product ideas would be generated, refined, and then vetted (validated) with these on-the-street interviews.

What was important was that these programmers were ... programmers. They just wanted to code. This was a huge and frustrating distraction from their regular work - which really needed to get done. So they started the first exercises annoyed and angry. Jabe gathered comments along the way - after the first few days of this process he received some extremely negative feedback.

As the exercises progressed, they began to generate products for the participants. They created personas of their system users, affinity maps of attributes, and most important - real individual and team learning.  Feedback became more positive.

By the time the group started generating real, tangible ideas - they had unprecedented clarity, not only into the exercise, but into their own clients and products. Perhaps for the first time ever, they had a deeper understanding of who would use their products and that those people were real. That clarity felt good, it was empowering. I don't mean “empowering” in the harmonically convergent woo-woo babble sense - I mean that in the actual "I now know how to really do my job" sense. They had more real power to write good code.

By the time these people did their exercise in DC, they were so into the game and their ideas, that the previously terrifying prospect of going out on the streets of Washington and talking to strangers was now merely .... terrifying.

Yes, it was still terrifying.

But they did it.  Introverts and non-people-persons stormed the nation’s capital and got some real work done.

Because they had clarity and because there was a system that made those actions logical. That made those terrifying actions easier.

Punch line

Our individual programming obviously runs deep, and circumventing it is not trivial. But we are not hopeless. No one is a trapped.

We can step outside our comfort zones, we can grow. And we can enjoy the experience.

Our brains have tendencies, some stronger than others, and many extremely rewritable. When we encounter stimuli, our brains record it and we are changed by it. The more that stimuli is repeated, the more our brains physically and operationally adapt to the new patterns.

We, as individuals, team members, and managers, all would do well to appreciate that thoughtfully created collaborative systems like TLC's can have radical impacts on the system participants. (Habits take longer to develop, of course).

After all was said and done, at about 10 pm on a Wednesday night we were gathered in TLC’s offices back in Inwood, West Virginia. I ran a retrospective with everyone in attendance. These people were exhausted and euphoric. The most successful applications will be further refined and likely built. People stepped way outside their normal comfort zones to make that happen. It was draining and beautiful to watch.

Simon Marcus, the COO at TLC, who started this whole process rolling, listened to everyone talk about what they enjoyed about the process and what they did not. He made it clear that innovation was everyone's job. And, by and large, everyone knew he was serious. The next morning they were at work, building a new process to harness this new power.

Simon and Jabe could have written off their programmers as stereotypical introvert meatbags and left the innovation to product development experts - but that's the normal way of doing things. Silo'ing innovation where it’s appropriate and turning everything else into a factory.

In the middle of all this, Jabe said to me, "you know, I thought I would get a ton of stupid ideas and maybe two good ones, but I've been overwhelmed by the number of really good - not just good but really good - ideas these guys came up with."

If Jabe and Simon  would have silo'ed their innovation, they would have destroyed not only value, but people as well.

Photo of Jim Benson by Jim Benson

Photos of TLC staff by Jabe Bloom

“Wine is to enjoy, not to judge.”
~ Hwi Woong Jeong (웅가) Wine Enthusiast

The gentleman next to me took out his laptop and began typing, he had a large pile of wine labels and a notebook filled with wine notes. He began systematically copying them into his laptop. I figured he was a wine critic.

Other work he went on to do involved software development and airplanes so my curiosity overtook me and we began to talk. It turned out that he was a software developer that worked with airplanes. But … he was also a noted wine critic enthusiast. He had been to the Pacific Northwest of the US on a wine excursion as a guest of the major wineries. He had been all over Washington and Oregon tasting.

When I was in my 20s, I decided I wanted to be a wine snob. So I went and took courses on wines, read books, and started a collection. I became rather good at it. So good, in fact, that I found I wasn’t actually enjoying wine any more. I was always critiquing it. I could always find something not quite right.

I told him this and he smiled and said, “wine is to enjoy, not to judge.”

We will always suffer from snobbery – to this day, I cannot listen to music from laptop speakers. And I know more than my share of agile adherents who actively hate every team they come into contact with because of their flaws.

We tend to fall in love with our ideas and nothing kills romance like familiarity. Richard Dawkins once said, “There is an anaesthetic of familiarity, a sedative of ordinariness which dulls the senses and hides the wonder of existence.”

We do this all the time with our work. We get excited about a task or an idea and we go deep. Too deep. Beneath the layer of effort that separates excitement from boredom. From energizing to draining. From inspiration to drudgery.

We might call this “depth in progress”. Just like we can have too much work in progress, we can also have too much depth. It’s simply doing too much of something. We go beyond what would be an acceptable level of completion and strive for “perfection.”

“The fact of storytelling hints at a fundamental human unease, hints at human imperfection. Where there is perfection there is no story to tell.” ~Ben Okri

At some point on the path to perfection, we pass the point of diminishing returns. After that point, our efforts do not return profit, only waste. In our pursuit of perfection, we identify all the things that cannot be perfect and then strive to perfect them. Yet, the imperfect is always with us. It is where growth resides.

Yet the need for growth, and the imperfection, will always be there. We end up in a doom loop of reductio-ab-absurdum – we manage our products as if the end product were a fine diamond that would last centuries. Well, it took the planet millions of years to make that diamond, and we don’t have that kind of time.

Therefore we need to approach our work by asking, “What is the least amount I can do to make this task successful?” In doing this, we want to move our ticket to DONE and have it stay there. No re-work, no additional tasks created because it was incomplete.

Can that task be improved in the future? Absolutely. But for now, it is complete. We launch it, watch it work, and come back to improve upon it later if necessary.

We want to know what the minimal completed task looks like and then do that. Anything beyond is too much work. Our previous goal of “perfect” is still valid, but now it has an upper boundary. Overly polishing the task does no one any good. Because of this, perfection is no longer gilding the lily - we now recognize the lily is perfect. We want to enjoy our wine, not judge it.

"To gild refined gold, to paint the lily ... is wasteful and ridiculous excess." ~ Shakespeare

Policies and processes we adopt over time are corporate inventory. We have to maintain them, administer them, and be annoyed by them. All these actions are waste.

The tricky thing here is that all policies can be defended by “what if” arguments. “We can’t get rid of that policy … what if someone does something bad?”

Well, what if someone does something bad? How likely is that to occur?

We know for certain that the waste is making the group less effective when subjected to the policy. What is the likelihood of your What If?

A gross example of this is airport delay post 9-11. The 9-11 hijackings had nothing to do with airport screening points. They were a systemic breakdown (and a highly improbable one) of the global intelligence network. Yet, the 631,939,829 people who flew in 2010 all were delayed at least one hour by needing to get to the airport early, stand in line, and subject themselves to security policies. At about 40,000 as an average income, this quickly pencils out to about 12.5 billion dollars worth of delay every year. That delay can be easily compounded by the lost time of collaboration that people have endure by leaving the office early.

The What Ifs here are obvious. But so are the costs. Are there better ways of dealing with terrorist threats than incurring billions of dollars in passenger delay?

Other examples are regular reports that show the progress of various business metrics. One company we visited generated a weekly report of dozens of pages and nearly 100 metrics every week. Not only did report generation take more than a combined 40 hours to produce (an obvious cost), it delayed the very projects it was trying to measure. In the end, the overwhelming number of charts, graphs, and numbers created a culture of managing by the numbers while totally ignoring what was really happening. Managers would comb through the document until they found the metric or two that went in the wrong direction, then they’d come to find out why.

More often than not, the why was a normal fluctuation in the number. The conversation was waste, the “analysis” was waste, and the generation was waste. But those receiving the report had become so fixated on it that they couldn’t see beyond it. “What if we didn’t have this report? We’d never know what was going on!”

Examine your policies regularly. Make sure that you don’t have policies to create waste.

Photo by Anders V

Dear Jabe

It strikes me that we humans often like to think.

Yet we are still territorial creatures.

Therefore when we invent anything, we wish to guard that thing. We are protectors of our territory.

Even when there clearly is neither threat nor territory.

• My friends Chris Matts and Olav Massen had the idea that we can apply the economic theory of real options to your daily life.
• My friend Dave Snowden is posits that there is a rather fluid landscape of existential states that all things (people, policies, relationships, goals, etc) live in that has varying degrees of simplicity, complication, complexity, and chaos and that understanding that state greatly informs responsible action.
• My third friend, Jurgen Appelo has constructed a management aesthetic that transforms the roles of the worker and management to create a simultaneously profitable and humane working environment.
• My friend David Anderson has spent a great deal of time creating a new way of managing software development and IT teams with greater clarity and significantly less process overhead.
• And my friends Bob Marshall and the regrettably late Grant Rule have a concept that companies are in a state of evolution or devolution from zero-sum game authoritarian weak states to more resilient collaborative states.

I, for one, count myself lucky to have such friends. No, doubt they will all disagree with my summaries. :-)

For my part, I had the idea that if individuals better understood the work they were doing, they would make better decisions, feel better about those decisions, and could better deal with difficult challenges when they arose.

What I appreciate most about this nascent group is that there is no appreciable territorial overlap.  A team using David's Kanban can be employing Jurgen's Management 3.0 techniques to solve a wicked problem elucidated in Dave's Cynefin framework and act at the right time with Chris and Olav's Real Options by individuals who are informed and ready to act using my Personal Kanban - as they do all this, they are consciously engaged in Bob and Grant's Rightshifting.

I, for one, get a hell of a kick out of that.  Individually, we have managed to create an incredibly deep potential system.

So... territory.

Lucky for us all, we are not the only ones interested in our ideas. Globally, each of us has audiences for our ideas. Because all eight of us are quite excited by our ideas, we like to talk about them. So, we gather with those who can discuss and extend our thinking.

That is also awesome.

Over the last year, David hosted a Kanban gathering in Iceland, Jurgen had his Stoos meeting in Switzerland, and Dave et al hosted an event called CALM in England. All three meetings were simply gatherings of people to talk about the ideas. Yet all three were strangely attacked in blogs, Twitter, and through social media for no reason I can surmise other than territoriality.

If any of these three were attacked solely for the ideas being discussed, that would be one thing - but these attacks were most often from fear.  What are they doing in there? Why aren't they tweeting? They must have some hidden agenda! As if Stoos were the Illuminati or CALM were some kind of Skull and Bones society.

While all of us have egos, we're all too busy and too invested in social media to build secret process cabals.

We and our supporters apparently see some finite landscape that needs to be conquered and protected. This is regrettable, because without my seven counterparts I know I would have learned a lot less over the last several years. It is also regrettable because when we as standard bearers of ideas shut out the ideas of others, we make intellectual intolerance that much more permissible. This ultimately drives dismissal for our own good ideas.

And, for whatever trappings we may put around them, we are in the idea business.

So, Jabe, go fix that. Thanks.

All the best,

Jim Benson

The Lean Startup movement has focused considerable energy in the message that we learn from failures. Small, easily recoverable, failures can be invaluable in the success of a company. However, many ignore failure and focus on success.

Since success is a rarity and failure much more common, we limit our learning opportunities by that success focus.

However, many also do not understand how the scientific process actually works. We therefore tend to build experiments that are invalid.

In Episode 4 of Collaberwocky, Corey Ladas, Jabe Bloom, and I discuss thoughtful failure.

Are you a manager trying to get by in a flat or agile company?

Do you find the role of manager repeatedly maligned?

This is more than just “It’s lonely in the middle.” There are significant positive shifts in making the workplace more productive, efficient and effective. However, each of these shifts has been accompanied by changes in roles – and these changes are rarely clearly spelled out.

In Episode 3 of Collaberwocky, Jabe Bloom, Corey Ladas, and I discuss how to speak from power in this new uncertain world.

In this episode of Collaberwocky, Jabe Bloom, Corey Ladas and I discuss “The Language of Management.”

It seems that different rungs of the corporate ladder come with different perspectives. None are complete and all have their own biases and areas of focus.

Further, many management theories give rise to a sort of class warfare between the different rungs. “My manager doesn’t understand me.” “The C-Level suite are out of touch.” “The people who work for me are idiots.”

Far too often, this causes the rungs to appear so far apart that people cannot even fathom having productive conversations. Corey, Jabe and I mull over these issues.

For years I have been trying to get myself to do an interview show. There was one problem – interviews are not very collaborative.

After doing Lean Coffees for a few years and hosting Lean Camp Seattle last year, it became clear to me that conversation creates information – and that was compelling.

So we launched Collaberwocky, a series of conversations about collaboration.

This runs exactly like a Lean Coffee. We get together with a few participants, we build a kanban, vote on what we’d like to discuss, then we discuss.

The first five episodes are with Corey Ladas, author of Scrumban, and Jabe Bloom, CTO of the Library Corporation.

This first Episode is “Intentional Cooperation” in which we discuss creating teams and processes that intentionally foster collaboration.

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.