This award is humbling. Shingo awards are usually focused on manufacturing or applications of specific Lean principles with many direct nods to Toyota.

Personal Kanban is strongly rooted in Lean ideals, but it much more focused (as the name implies) on the individual – on us as people.

Tonianne and I are greatly energized by this award and look forward to seeing Personal Kanban continue to grow and thrive.

Read about it on CBS News and the Lean Systems Society sites.

I’m vowing to change that this year and this post is a start.

All my life, I’ve wanted to be a writer. In some ways, I always have been one. But, it’s strange. Commerce seems to often validate when we can call ourselves something.

Two years ago, with my collaborator Tonianne, I wrote the book Personal Kanban. This year, it won a Shingo - known by some as the academy award of Lean. And, despite the fact that I had written this book now two years ago, I feel I can finally call myself a writer.

Now, I can also call myself a publisher.

This is part of my analytics screen on Amazon. Modus Press has a catalog now. Small, but growing. Small, but greater than one or two. Small, but increasingly noticed. There are five authors represented in the list so far.

Today, as I write this post, I lie on my bed in Saigon. In a few days Toni and I will do what has become routine. Together with over 100 other people, we will be responsible for changing people’s lives for the better. Our field of process improvement may sound stolid and overly professional, but the ramifications are purely human.

By the end of our class, in this case together with our friends Mary and Tom Poppendieck, we will help people understand, control, and improve their work. Most of what we do is “work” and we tend to do too much of it. Unfortunately, like any addiction, we can’t get it under control unless we understand it and our relationship to it.

It is hard not to feel successful today, we just published Beyond Agile, we have a healthy portfolio of books, Toni and I were honored by the Shingo board of examiners, and our calendar for the year is filling up. I lie on a bed in one of my favorite places on earth, preparing to walk the streets and eat the food. Soon Tonianne will show up at my door and we will head out.

I strive to find the apparent balance Mary and Tom have found. They schedule a set number of trips a year and are scrupulous with their personal time. If you look at their website, see their calendar? There’s time set aside specifically to write.
What comes next in this space? I think Evolving Web will still focus on the social aspects of work, as it always has, but there will be more personal missives like this one, more images of these trips we are blessed to take, and more discussions of food. In short ... more Jim.

The last few weeks have been busy. We’ve launched Kaizen Camp which is bustling with activity. We have three Kaizen Camps scheduled for New York, Los Angeles, and Boulder – with more on the way in Tel Aviv, Sydney, Melbourne, and Ho Chi Minh City.

We started Kaizen Camp here in Seattle in 2011, now we’ve held three and the requests to host these worldwide are like a flood.

A Kaizen Camp discusses continuous improvement – at the office, at home, and anywhere else. No matter which way we approach our work (from process, from waste reduction, from psychology, from economics) the fact is that we create better product when we can improve our processes and enjoy our work.

Past Kaizen Camp topics can be found in this lengthy list. The low-down on Kaizen Camp is also interesting, but deep.

Right now, I’m just looking forward to some great conversations, deep problems to solve, and to meet people actively improving, creating, and innovating.

After working with and owning several startups, it is clear that startup owners regularly overload themselves with work. It’s part of the startup mythos. The problem is, overwork kills lots of startups. The pace set is unsustainable and the endeavor collapses.

A few very important things where Lean Startup can be informed by Lean Lean.

First - Limiting work in progress is key to finishing things. You can't do more work than you can handle.

Second - Visualize the work - get it out of your head. There are too many variables and too many changes in context. You can better manage what you can see.

Third - Manage the flow, not the tasks - you are a startup, you will always have tasks. Working yourself to death will only result in your death. The flow of work is what is important - what can you produce, at what rate, and of quality.

Fourth - Kill Lists - Lists lack context, they age-out within hours, they leave you with no reasonable record of work done. They are the index of a map - even if read the entire index, you'll never understand the terrain.

Fifth - Prioritize Last - Making a long list and prioritizing up front is un-Lean. Most of your listed items will change in substance and priority as you do your work. With a visualized system, you prioritize / select work on-the-fly.

Sixth - Learn Cynefin - Understand that you will never know which of your tasks are simple, complicated, or complex. Some of them will bite you in the ass. If you outsource a task and think it's simple, but it is complicated or complex, you will end up working harder to manage the contractor than you would have doing the work.

Startup work is inventive - it is creative. Spend your time inventing the product and not reacting to the workload. Again, as Adrian said, this may mean some long days, but don't overdo it. Your brain is the only thing you have to make money from here. If you overwork it, it will underperform for you.

So learn from Lean, set up a Personal Kanban or any other type of kanban, and start visualizing your work.
Steve Blank says "Get Out of the Building."

I say, "Get Out of Your Head."

We say that kanban is a visual control, but we also eschew external control (rules) being placed on us by others. So what does control really mean? We when we look at it, we have a lot of depth here.

(1) Like a dial – a controller

We can use our kanban as a controller for our work. We can adjust our WIP limits, the people doing the work, the throughput of various work-item-types, the granularity at which we track our work. We have a number of dials we can tweak to control our work.

  (2) Controlling action through constraints

The kanban itself places constraints on our work. It enforces policies we have set. The WIP limits, the value stream, what is allowed and when, and so forth are controlled using the board.

(3) Controlled experiments

When we hypothesize something can be done to alleviate a bottleneck or some other item inhibiting flow, we can run controlled experiments using sour board as the laboratory. We can make small changes and measure their impacts directly.

(4) Communications Control

The board, in real-time, is a control center – communicating status, activity, bottlenecks, completion rates, issues, staff availability, and more. It is the switchboard of your team.

It’s important for us to grasp that “control” means many things. This helps us envision more creative and robust controls.

This year, Kaizen Camp is the July 24-25. Again we are at the beautiful Center for Urban Horticulture. We also have award-winning food trucks (with vegetarian options) catering the event. So, no boring food! The event is nearly half full already, with attendees from software, government, health care, manufacturing, education, and more.

The diversity of ideas and voices are unparalleled – which is exactly what we were searching for. Lean ideals and principles will be discussed. People share success stories as well as challenges. Different disciplines work together to create new ideas. Continuous Improvement is explored.

Last year we were blessed with great conversation, learning, food, and near gender parity. This year looks even better.

What to expect

1. Great sessions
2. Conversations with other smart people
3. Learning about what is working
4. Strategizing about sticky problems
5. Learning ways to create better working environments, systems, processes, and policies

What you will be spared

1. Boring speakers
2. Bad boxed lunches
3. The inability to speak
4. Canned presentations
5. Sales pitches from consultants pretending to be speakers

See you there!

This song was recorded in 1985, it was likely the 20th version of the song. It’s not our best song, but it is my favorite. Corey Smith, David Fisher, and myself in Corey’s living room. We all played just about everything on it. Yes, those are my vocals, with Dave doing rap and backup.

In those days, I could walk into a room of my friends and start making crazy strings of noises. Corey, I want you to take the guitar and go ba ba tssst tssst tssst babababa wham. And Corey would do it, except a lot better and with an actual guitar. Dave, I want you to pound on those things over there like this tap tap bam taptaptap bamBAM. And he’d do it.

And soon we’d have a song, or something like a song. Doing overdubs on it until we’d either reached perfection or total audio breakdown.

You have no idea how much I want to go back to that time, if only for a few hours.

Now when I listen to this song, I am struck by how I am the only one left alive. I’m not quite old enough to say this, I think.

Corey left us in 1990 in a car accident. Sudden, extreme, painful – like a shotgun blast. I was still in Michigan and flew back to Nebraska for his funeral. At that time, Dave was getting his law degree from the University of Nebraska.

Corey’s funeral was more than likely the most painful day of my life.

While I was there, I had a conversation with Dave’s then girlfriend Melissa. She was taking me to task for writing zines that described Dave’s and my misadventures in Colorado. Most of these stories involved me hauling Dave’s overly drunk body out of one situation or another.

She yelled at me across a table at an Italian restaurant: “I would kill you if you wrote things like that about me, but you know what Dave says?”

“I’m just glad I make good copy.” Dave said, taking a sip of beer.

But those stories were prescient. Corey died suddenly, unexpectedly, shockingly. Dave died very slowly, painfully, and perhaps worst of all, boringly. The initially funny stories of Dave’s antics led ultimately to annoyance. Dave stopped making good copy.

In 1985 in Denver, on the Denver University campus, Simon Bone yelled at Dave, “Goddammit, you’re an alcoholic at 20 years old!” (Back then, the drinking age in Colorado was 18 for ‘3.2 beer’.)

Dave’s heroes were Neal Cassady, Jack Kerouac, and Charles Bukowski. In Denver, we’d stay up late talking about literature, music, and thought. Dave saw the prolific writing of 2 of his heros (Jack and Bukowski), and the stories generated by the third (Neal). Those guys drank heavily, why couldn’t Dave?

Simon was right, of course. Dave was already an alcoholic. While in Denver, I became more and more annoyed with Dave’s drinking. After Denver, each time I saw him, we connected less and less. His sharp mind would latch on to manic tangents and he would rant just on the border of nonsense.

Dave was dying slowly.

One day, in what I believe was 2003, Dave called me at 5 in the morning. This was not unusual and we had a policy not to answer the phone at that time. Something told me I should answer the phone. So I did.

Dave was in the process of drinking himself to death, with the strategic aid of sleeping pills, in a Presidential Suite of a hotel in Hartford, Connecticut. I managed to figure out where he was and get police and paramedics to him. He died in his hotel room, then again in the ambulance, then again in the ER.

His wife was the strange mix of sad, infuriated, and unsurprised that I am today.

Of course, Dave did not die in 2003. He managed to come back even after three charges at the pearly gates.

I hoped that this would be the ‘rock bottom’ that Dave needed to get better.

So, Dave and his wife really liked status-type things. So they checked Dave into a rehab clinic loaded with music and film stars. Net effect: they spent some money and met some stars.

Years pass and Dave ends up with an ultimatum from a judge in Nebraska, where Dave has moved to do … nothing at all but drink. “Get sober or get time,” the judge says. So Dave went to a rehab clinic in Colorado.

By this time, I had come to the conclusion that I was an enabler for Dave and had stopped taking his calls altogether. In a way, failing to come back from the three deaths and make something of himself offended me. It made me resent that Corey had left this earth long before his time and now Dave was just pissing away his talents and intellect.

But, one day, the phone rings and something tells me to pick it up.

Dave is at a Buddhist rehab clinic in Colorado. And, holy crap, the guy on the phone is my old friend Dave.

He’s lucid, creative, smart, optimistic.

And I got very excited.

It was like someone I cared about had died … and come back. ... because it was that exactly. You just don't get gifts like this. 

Over the next few weeks, Dave and I had great conversations. We talked almost every day. The monks had asked Dave to stay on and work at the facility. This was too good to be true. I made plans to go to Colorado and visit him.

“I just have to go back to Grand Island to clear up some stuff with the family,” Dave said.

“No!” I said, “Don’t under any circumstances go back to Nebraska.” I knew if he did, he’d slide right back to the bottle.

And that’s what happened. My next calls from Dave were rambling incoherence and him telling me he was sober. After several calls of me asking, suggesting, pleading, or cajoling him to go back to the facility, I Finally told him, “The only call I’ll take from you is when you’re back in Colorado.”

And I never spoke to him again. We "talked" on the phone a few times, but it was always me listening and nothing really being said.

During Dave’s last decade, he managed to get himself in all sorts of trouble that would have made good copy. Dave had more talent than necessary to quit drinking, tell those stories, and tell them with a purpose.

As it is, Dave, who ironically inherited a bunch of money that did not let him “have a real life” but did enable him to drink his life away, died a few weeks ago in a lonely hospital room in Grand Island, Nebraska. What he specifically died of is unknown to me and it doesn’t really matter. It was a long slow downhill slide.

Like both Jack and Neal, Dave died in his 40s.

Today, part of me feels guilty for not helping Dave more. Part of me wonders if it wouldn’t have been better for everyone if I didn’t answer the phone in 2003. Part of me will feel forever pissed off that Dave didn’t write his own Dharma Bums or Subterraneans. Dave leaves us a legacy of unrealized potential.

He could have written some awesome books.

The Lean Software and Systems Consortium (LSSC) has evolved to the Lean Systems Society (LSS).  I was never a member of LSSC, but I am a founding fellow of LSS. Why?

LSSC was a very necessary institution to begin talking about Lean in software development. With LSSC, we had several awesome conferences that rapidly increased the level of thought, range of adoption, and inclusion of new groups.

However, LSSC’s mission was very open-ended. Talks with LSSC ranged from setting up free communities to instituting scrum.org style certification for Capital K Kanban. I want to be clear here that I really love the LSSC people – it’s just that my voice was better used from the outside of the organization, always discussing new ideas and ways to expand the community beyond Software.

LSS is an entirely different animal. It is only focused on discussing new ideas and ways to expand the community beyond software. So … it seems to fit me better!

Along with this transition comes two things that I want to talk about:

Thing 1: LSSC 2012

This year’s conference felt different. I think we did a few things that gave this year’s LSSC a bit of slack.

Calmer Content

This is the part where I get to talk about how wrong I was. So, I’m  all big into setting up unconferences and putting the people in charge of the content. This year, at LSSC we had a few track chairs (mercifully few!) who were responsible for populating the content in their tracks. The speakers this year were awesome, the quality of the presentations was stellar, and the smaller number of tracks meant that people could focus.

I was initially unhappy with the decision to go this way – but in the end it made for a fantastic conference.

Start Loud

This year we started with a one-day unconference, a community meeting, a special event (Lean Action Kitchen), and a reception. This year just started fun and thoughtful. We built up a great momentum on the first day.

In addition, each day started with a Lean Coffee that went from last year’s one table to three to five tables a day.

Centralized Vendors in a Fun Location

Rather than having the vendors off in some removed part of the building, this year they were right at the center of everything. The vendors helped this by becoming “snack central” as well – it seemed like everyone had food. The space was also light and airy – which is something I noticed about the entire conference – the whole thing seemed less cramped and dark.

Thing 2: The LSS Mission Statement

Here’s the LSS Credo:

The Lean Systems Society believes that excellence in managing complexity requires accepting that complexity and uncertainty are natural to social systems and knowledge work. Effective systems must produce both better economic and sociological outcomes. Their development requires a holistic approach that incorporates the human condition. The Society is committed to exploring valuable ideas from all disciplines, and fostering a community that derives solutions from a common set of values and principles, while embracing specific context and avoiding dogma.

There’s nothing I can’t get behind here. This is an outward facing, humanistic, respectful approach to business, learning, and people.

This year I was lucky enough to win a Brickell Key award, which is given every year to two people in recognition of their work in this community. This meant a lot to me, because my focus has been often beyond software and my style of presentation is sometimes, shall we say, nonchalant.

This award was especially rewarding for me, given that this year I really feel like the community has really come into its own. This has been an exciting movement to be a part of and I look forward to what comes next.

“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