Thorsteinn Siglaugsson has taken his writing and thinking about the “Logical Thinking Processes” from Theory of Constraints and compiled them into a booklet, From Symptoms to Causes: Applying the Logical Thinking Process to an Everyday Problem (published 2020 - I had only recently started following Siglaugsson’s writing). It took about an hour to read through the booklet and read through the diagrams. Siglaugsson takes the readers through a relatively common example of applying the main thinking tools and how they are sequenced from the Goal Tree, the Current Reality Tree, the Conflict Resolution Diagram (aka Evaporating Cloud), the Future Reality Tree, and the Prerequisite Tree.

For most people, these specific thinking tools are probably a jumble of words. For people into Theory of Constraints, these are familiar, if not always used, tools to help understand and design full solutions. But one of the main reasons for the book is to show how important thinking is in the world of systems thinking. As Siglaugsson describes, almost everyone when presented with “a problem” starts to describe solutions without fully understanding the situation - what are we striving for, what does this problem keep recurring? Even worse, when we’ve tried to “solve” these problems in the past, they’ve either generated new, unanticipated problems or the original problem didn’t really get resolved.

Thinking, whether in this form or others, is the key to Systems Thinking. Yes, understanding that things are connected is an important aspect of this. But doing something with that understanding requires thinking through the implications. Even if the system in question is particularly complicated - and what systems that we care about aren’t complicated to some degree?

The new book from Steven J. Spear and Gene Kim takes a look at what makes for winning organizations and develops what they call a new theory of performance management - why do some organizations really seem to fly year-over-year while others do not? Why is it that some organizations can really take advantage of the tricks and techniques of Lean or DevOps or Theory of Constraints or agile software development or <pick your approach>, while others never seem to find their footing? Wiring the Winning Organization attempts to answer these questions.

The short answer to these why questions is that winning organizations are designed to win, while the others are designed to trap people and ideas in chaos - what the authors call the danger zone. The Deming line about “every system is designed to get the results that it does” ran through my head over and over again as I read the book. And the design of the system is up to the leaders - at whatever level they might be.

I appreciate the clarification that the authors provide about how organizations create value - or more specifically the different layers at which value is created in any organization: the physical or mental labor that goes into creating goods and services (Layer 1); the tools and technologies required for Layer 1 to work (Layer 2); and then the “social circuitry” of how an organization brings everything together (Layer 3). It is the social circuitry of Layer 3 where the emphasis of this book resides - and the authors bring in many cases where the social circuitry enables organization, and several examples where it blocks organizations.

The answer to the questions about why some efforts succeed while others fail fall squarely in Layer 3 - the social circuitry of an organization. And this is where the book places its focus as well. It is in Layer 3 that organizations are either pushed into the danger zone or the winning zone. The danger zone is frustrating and chaotic, and the people in Layers 2 and 1 cannot seem to get anything done, whether they are highly skilled or not. The winning zone is where the work flows smoothly, challenges are handled, and the organization wins.

The core of the book is around three ways winning organizations work in Layer 3: Slowification, Simplification, and Amplification. Slowification, essentially, is acknowledgement that there are times to go fast and times to take it easy. Planning and experimentation are supposed to be times of learning, checking, testing - system 2 should dominate. And production and operations are the places where we want fast, system 1 thinking to be the primary mode. But when things go sideways or something unexpected happens, we want mechanisms to slow down and take us out of the routine to think, plan, experiment and prepare. Even in high-intensity settings like space flight, one can find mechanisms to shift out of the standard mode and into system 2. Another way to think about this is that there is a time for planning and a time for doing. Both should be happening, but they should not get confused with each other.

Simplification might sound obvious - make things simpler, break them down, improve everything. This is NOT where the authors take the discussion, as I was initially concerned. If systems thinking has taught us anything it’s that improving everywhere does not lead to better results. We have to improve at the few places in the few ways that will actually improve the system as a whole. Simplification, in the context of this book, has three elements: incrementalization, modularization, and linearization. Incrementalization: Make the smallest change or smallest build that makes the biggest difference, rather than changing everything at once and hoping you made the right choices. Build on what is known to work and make incremental changes from there. Iterate. The agile software development and Lean Startup have taken this concept to heart and spread the concepts far and wide. Modularization: work on elements that are relatively well contained (coherent) and don’t have strong ties to other modules. The authors suggest organizing around flow or value, as opposed to the common organizing principle of functional silos. Breaking things down by function often leads to local optima and a focus on “efficiency” that only serve the silo, rather than overall value delivery. And then linearization - within the modules, define the flow of operations and handoffs. Enable standardization. Enable flow. Make it simple for people to do the right thing, and know they are improving.

Amplification is all about a well-functioning feedback mechanism. There must be a way to trigger a signal, the signal must be received and acted upon by the right people and in the right timing, and the resulting corrective action must be implemented and studied to see if it had the desired effect. While this topic takes up the smallest footprint in the book, it’s because some form of feedback is required for slowification and simplification to work. How do we know that it’s time to shift from System 1 to System 2? How do we know whether those incremental changes/tests are working? Feedback. The examples discussed in this section primarily reference back to the cases already described, highlighting how the feedback loop enhances the story.

The book doesn’t directly recommend a course of action to build your own winning organization. Rather, it shows how the multitude of approaches out there fit into the framework they’ve created. Given who the authors are, it shouldn’t be too surprising to read that the Toyota Production System (not just the Lean tools) and DevOps (and a few others) are suggested as approaches which cover most of the ground of Slowification, Simplification and Amplification. Many familiar techniques and approaches do some of these three, but not all. Organizations combine approaches to get all three of Slower, Simpler and Louder. While there aren’t directions per se in the book, there are questions at the end of major sections that are designed to nudge the leader-reader in the right direction. One topic I’m curious about is how leaders might take these kinds of questions to do some diagnostics and improvements within their organization to move more and more towards being a winning organization.

In the end, the theory presented here makes a lot of sense to me. Success doesn’t come solely from having a great product or service or from having a raft of brilliant scientists and engineers. It’s in how we structure the organization and make the value flow.

The publisher’s page for the book includes more details, a reader’s guide, links to videos related to the content, etc. Note: I was given an advance copy of the book to review.

1. Lack of project management expertise

2. Little or no executive support

3. No business sponsor accountability

4. Lack of business sponsor engagement

5. Not involving all stakeholders

6. Not enough resources or not the right ones

7. Lack of in-person collaboration

8. Disjointed handoffs

I’m sure in the past, I have claimed that one or more of these items was the problem. The handy thing is that there is an obvious answer to all of them. Just do the opposite! We just need more…

1. Project management expertise

2. Executive support

3. Business sponsor accountability

4. Business sponsor engagement

5. All stakeholders involved

6. All the right resources

7. In-person collaboration

8. Smooth handoffs

Surely, if we just do all these things, our projects will be much more successful. Right?

The discussion in the article doesn’t delve further into why these situations arise in organizations. Even worse, I would wager similar articles have appeared in CIO.com and many other venues over the years. I’d even wager that organizations have tried these solutions but that the “problems” have come roaring back. (Why else would this kind of article come up over and over again? The word “still” is in the title!)

The fact that the same “problems” (solutions) keep coming up is a sure sign that there is a deeper problem that is creating the symptoms that we see. The deeper problem is likely creating all or most of the effects that are appearing in the system. It was Drucker, I believe, who said, “The system is perfectly designed to get the results it gets.” If we don’t resolve the core problem, we are sure to keep seeing the same problems over and over.

To my eye, it seems like a lot of these challenges are related to organizations trying to do everything - they believe they need to respond to every request or upset or demand from elsewhere in the system. There is a hesitation to say, “No” or “Not now.” Or they release more work to hedge their bets in case some initiatives fail. (Or to “use up” the budget.) As a result, you get everyone and everything spread way too thin. And what happens then? Sponsors and executives don’t have time for all the projects. Decisions get delayed. Project leaders (product leads; scrum masters) get stretched and don’t seem to be able to resolve local issues. And the inevitable effect of projects taking too long and not delivering the expected value.

What if you could focus on the critical few projects? What if the organization had confidence that the projects would deliver value to the organization (the customers!)? What would decision-making look like? What if people had time to focus on one thing at a time?

I don’t have all the answers, but the list in this article just bugged me. They aren’t the real problem - just representing symptoms that won’t go away without addressing the root cause of the system’s behavior.

We all make mistakes - big and small. But what do we do with them? How do we react? How do the people around us react?

Mark Graban’s latest book, The Mistakes that Make Us: Cultivating a Culture of Learning and Innovation is an interesting combination of anecdotes from his My Favorite Mistake podcast and his other experiences, along with guidance on developing the environment where making mistakes is an opportunity to learn and grow instead of something shameful. The tone of the book feels very much like a conversation - in some instances I could hear Graban’s voice. The writing is also broken into bite-sized chunks around the various themes associated with learning from action. [Note: I received a review copy of the book.]

There are always opportunities to learn in life - another way to say that there are many ways to screw up. The big question is whether one has the honesty to admit the mistake and the willingness to learn from it. Similarly, we can’t wallow in perfectionism - preventing us from doing anything until we are sure it will be “perfect” - as then nothing gets done, a mistake in its own right. I love the quote Graban has toward the end of the book from Kurt Wilkin, “If you don’t make mistakes, you’re not trying, and you’re not growing.” I like to make a similar joke about mountain biking - if I don’t come back scraped up and muddy, I wasn’t trying hard enough.

The theme that rang loud and clear was that even people who want to learn and grow will struggle in environments that punish or denigrate them for making (and admitting) errors. And those organizations will struggle to survive in the long term. Psychological Safety gets a lot of airplay in Mistakes that Make Us for good reason, as does systems thinking. The Deming line of “the system is perfectly designed to get the results it gets” applies here too. Blaming individuals for mistakes will ensure that you don’t hear about them - that doesn’t mean mistakes don’t happen. And if you don’t hear about the little ones, it is only the “big” ones that get attention and a whole new cycle of “naming, blaming and shaming”.

Alternatively, airing mistakes AND an honest desire to repair the system in which the mistakes happen is a key component. There is often something “simple” or “obvious” in the examples that are used here and other places, but there is often a hidden message. Mistakes happen - assuming that an individual is to blame will almost guarantee that mistake to happen again and again. Signs and exhortations to “do better” do not work. What is it about the system/situation that allowed for the mistake? And this is where the hidden magic of systems thinking really comes to life. Ask “why” and “how could that occur” - look for the assumptions underneath the operations. What was “obvious” to the designers that is no longer obvious to the people doing the work? What changed in the environment that allowed for the mistake?

The other thing that I saw in the book was a connection to the ideas of knowledge management - particularly in the arena of learning organizations and sharing knowledge. How else can an organization learn if the people within cannot admit they aren’t perfect - that there is always plenty of room to grow and learn. And how do you grow and learn but by challenging assumptions along the way? This is inherent to the ideas Graban describes in the book. And while he is focused on mistakes as the source of learning opportunities, it is the environment that enables those mistakes to become opportunities (or not).

Mistakes happen. It’s all in how we respond to them of whether we will keep bashing our heads against the same mistakes or get past those mistakes to find different ones. Living with a mindset of learning from these signposts is the way toward growth and more interesting signposts. “May you live in interesting times.”

Deming’s Journey to Profound Knowledge by John Willis and Derek Lewis is the story of how W. Edwards Deming’s background, education and experiences inspired him to develop his System of Profound Knowledge. The book is sort of a biography, but very focused on those elements that led him to be the important figure in many circles. The authors wrap up the book with some thoughts on how Deming’s thinking continues to influence our world of work, emphasizing their perspective in IT environments. [Note: I received a complimentary preview copy of the book from the publisher, IT Revolution. The book is expected to be published this month (Aug 2023).]

The book opens with an anecdote about the 1980 documentary from NBC, "If Japan Can ... Why Can't We" that features Deming. Then the authors go back into his history and how the situation came to be that Deming was practically anonymous in his home country, while Japan regarded him with great respect. As usual in these kinds of scenarios, he didn’t show up in Japan with that stature - he was one of many people sent to Japan to help rebuild after World War II. It was his expertise in statistics and analysis that initially drew the eye of the relief agencies. And it was that expertise that landed him in the right places to help rebuild and rethink management principles.

Throughout the book, Willis & Lewis attempt to unearth the influences on Deming's development of profound knowledge - from his experiences on a hardscrabble farm to his formal education to his early career and interactions with people who were core to the development of lasting concepts. It's a fascinating weave - some speculative and some pretty obvious. I like that the authors unearthed descriptions of the environments, like Hawthorne Works or post-war Japan, giving a nice picture of the environment and how Deming could have developed elements of his own thinking. They also delve into the history of concepts like standardization and statistics to provide additional context to how Deming likely came to his thinking. If you read slowly, some of these side stories might be a little confusing as to why they are relevant, but most of the tangents have a good connection to the train of thoughts about Deming.

While this is not formally a biography, I could have used a timeline of some sort to help remember when and where some of the important activities discussed in the book fell. And maybe even some of the non-Deming connections used to flesh out the story - like Deming was at Hawthorne Works for a couple summers; how long was Hawthorne in play? When was Shewhart there?

One of the key elements in Deming’s System of Profound Knowledge is the idea of systems - that people and organizations work inside of larger system. Without appreciating the full system, it is easy to make lazy mistakes. I often struggle with the stories used to describe systems thinking, as they seem almost moralistic (DDT kills mosquitos … and a lot of other things; Introducing rabbits to Australia caused vast defoliation; and other examples). The key is that people who are "good at systems thinking" are able to look beyond the immediate effects of a suggestion. They ask questions that may seem tangential. This is the same with the "Five Why's" analysis. It's easy to ask "why" a few times and get a seemingly pat answer, but asking a few more times, or thinking sideways might turn up deeper, more endemic causes.

I particularly liked Deming's focus on management within organization: they are the ones that create and reinforce the system, and it is the system that people operate within and create the results, good or bad. There are a number of anecdotes where he was kind to the front line workers and very tough with the top management. And many examples where he declined to engage when he saw that the top leadership weren’t interested in learning and changing their approach to enable the system to operate more effectively.

The final section of the book talks about Deming’s influence today and into the future. The authors talk about how the System of Profound Knowledge is obviously related to Lean, as that comes from Toyota and Deming’s influence there. In IT circles there came Agile, which is related to Lean and deeply depends on the these same principles (look at all the connections amongst the 14 points and the principles in agile software development). And then DevOps, which takes Deming and Goldratt and Agile and many other approaches to further improve upon delivering IT with business partners. I also enjoyed the “what if” thoughts in the discussion in chapter 17 on What Would Deming Do. How do these concepts work today and in real challenges that have arisen in the business world? There was even a discussion of how the positive principles could be applied for “evil” - hacking and general bad actors. This is where the authors take a shot at applying the 14 Points of Management to the situation to see if there is a direction forward - or how using the 14 Points could help organizations deal with the cybersecurity threat.

John Willis has been writing and talking about this topic for some time. Most recently, he’s had a podcast called Profound where he interviews a variety of people, focusing on the influence Deming has had in their lives. Some of those conversations have found their way into the book.

Just in case: Deming’s System of Profound Knowledge

I suspect most people who pick up the book will be familiar with The System of Profound Knowledge and the connected Fourteen Points of Management. The Willis and Lewis do a nice job of describing Deming’s development and the importance of The System of Profound Knowledge:

• A theory of knowledge: How do we know what we believe we know?

• A theory of variation: How do we analyze and understand what we know?

• A theory of psychology: How do we account for human behavior?

• An appreciation of systems / System thinking: Are we seeing the bigger picture?

And toward the end of the book, they go through each of the Fourteen Points of Management and think about how they apply to today’s current IT environment, particularly emphasizing the concepts associated with cybersecurity. Here are the points, which were originally from Deming’s Out of the Crisis) though I have seen a number of variations in how they are articulated. Deming says that these points come out of the System of Profound Knowledge, and Willis & Lewis suggest that following these points might lead an organization into the System of Profound Knowledge.

1. Create a Constant Purpose Toward Improvement

2. Adopt the New Philosophy

3. Stop Depending on Inspections

4. Use a Single Supplier for Any One Item

5. Improve Constantly and Forever

6. Use Training on the Job

7. Implement Leadership

8. Eliminate Fear

9. Break Down Barriers Between Departments

10. Get Rid of Unclear Slogans

11. Eliminate Management by Objectives

12. Remove Barriers to Pride of Workmanship

13. Implement Education and Self-Improvement

14. Make "Transformation" Everyone's Job

I’ve been catching up on some blogs, and came across one from Leandro Herrero on 3 Ways to Get Approval from your CEO or Leadership Team that essentially described some decision modes:

1. My team has developed these three options, A, B and C. Which one do you want us to do?

2. I need you to approve A. We also have options B and C but would not recommend them.

3. Just to let you know that we are doing A. We explored B and C, but they did not rank as high as A.

These all have the team conversing with the leader, based on their current understanding. But of course there are other modes of decision making from full autonomy of the team to the leader doing everything. How a leader / manager might choose to use these modes of decision make obviously has a lot to do with context. Sometimes it is critical to simply make a decision and go, and sometimes it is important to get out of the way, and let a team move as quickly as they can.

• Leader decides:

  • Announce: “This is what we are going to do.”

  • Explain: “This is what we are going to do, and this is why.”

  • Discuss: “This is what we are going to do. What questions do you have? How might we best implement this decision?”

• Leader takes input (but still decides):

  • Discuss the decision: “I think I want to do A. What do you think?”

  • Discuss the problem: "Here is the problem, team. What options do we have to solve it?”

• Leader delegates the decision:

  • Delegate the decision within limits (time, money, options, etc). This looks a lot like #2 above, and maybe #1 if the limits are being challenged.

  • Delegate with full authority - the team is acting under the leader’s full authority, so there are still limits but those are the same as what the leader operates under.

One of the important elements of the discussion is that it helps to be clear on what type of decision mode we are in - I have seen a lot of conflict in organizations created simply because people had different assumptions about what their role was in the decision. (Similar examples would be the RACI Matrix or the PACE model or several other variants.)

I learned about this from a consultant many years ago (they retired a while ago) and refer to the concepts from time to time. It’s a useful way to check when people get wrapped around the axle on a decision: “what mode are we in?”

Ayelet Fishbach’s Get It Done: Surprising Lessons from the Science of Motivation was an informative read, offering exactly what the subtitle suggests: interesting (surprising?) lessons from a variety of angles on what creates motivation (or not) for people. Given the research, the book also provides some guidance on approaching oneself and others to improve motivation.

At first the book seemed to be going in the direction of a self-help book, suggesting how the contents would help the reader become better at staying motivated and reaching goals. But then it really shifted into the science and studies around motivation. The challenge I had was that there didn’t feel like a solid “story” through the book. The science contributes to this: one set of research results points left, and another set of research results points right - all depending on the context and setting of the individuals involved. Lots of head scratching, but I suppose that is some of the reality of being people in this world.

The book is broken into four sections. The first contains chapters on goal-setting, being clear about what one is reaching for in a goal, and how one might use (or abuse) incentives to help keep motivation rolling. I liked the first chapters emphasis that goals are not intended to be chores, but things we want to reach for or achieve. Chores are easily thrown to the wayside, or become … a chore. The second section discusses motivations - both strategies to boost motivation and those scenarios in which motivation changes. This was a section where it was easy to get lost in the research. Our motivations vary significantly depending on our content - even on the context around one goal (have you just started? are you near the end? are you stuck in the middle?) How do we use (negative) feedback to reinforce motivations? When does feedback kill motivation? I liked the idea that when we can lean on our expertise and experience that negative feedback can be fitted into a bigger picture and used as redirection and reinforcement, rather than discouragement.

In the third section the author branches out from individual goals to the reality of our lives - we have many goals, and some of those compete with each other for time and attention. Some even compete directly for the end results: exercise for health or eat for pleasure (and possibly lead to poor health). How do we juggle multiple meaningful goals? How do goals build together into a personal “goal system”? Can we be patient and or show some self-control in dealing with all these options - especially when the short-term excitement wants to trump the long-term value.

And then the final section of the book brings in the idea that not only do we have multiple personal goals, but there are other people around us with goals - some that we share in common as part of a family or organization. Interestingly, when we pursue goals around others - others aiming for the same goals as in a race or competition - we tend to have stronger motivation than we would if we were doing this alone. And in collaboration, we can find motivation stronger to win together (so long as we don’t fall prey to the “someone else will do it” problem of group work). And how to have happier relationships? Support their goals, instead of demanding that they support your.

Of course, reading a book about motivation research needed a little motivation itself. I amused myself by having to create motivations to finish the book: Finish a chapter - get a snack. Or maybe convince myself that there might be something interesting around the corner. And the closer I was to the end, the more I was motivated to finish.

I’ve heard Adam Lawrence on Lean-oriented podcasts (mostly Marc Graban’s Lean Blog) a number of times, talking about his “wheel of sustainability.” He has written a book on the topic, The Wheel of Sustainability: Engaging and Empowering Teams to Produce Lasting Results, that goes through the approach he has devised.

The book and the examples draw from Lawrence’s experiences over the years both inside companies and as an external consultant, bringing changes to life. I liked how each of the sections featured examples from the shop floor that worked and some that might not have worked so well. He even brings in examples from home or office that connect to the topic in question. For each of the “spokes” of the wheel, he also provides a couple paragraphs of how leadership commitment (the hub of the wheel) relate to that spoke, as well as the full chapter on the topic.

While I didn’t see the work I do in the examples, I kept thinking about how the eight spokes plus the hub of the Wheel of Sustainability might apply - what I could take away from these ideas. All the concepts make a lot of sense in just about any environment - it is the details where there might be differences in approach. The book reads quickly with the basics in each chapter rounded out by those examples. In the meantime, here are my brief thoughts on the spokes:

• Notification: Not just telling people what is coming, but really talking with them about the proposed changes and how it might impact their work. We might actually learn something that will make the change even better. This spoke seems important in any change initiative, and it is often missed in favor of bulk announcements - giving a flavor-of-the-month perception.

• Training & Review: “See one, do one, teach one” is the version I’ve used of this. In the context of the book, these are training sessions around a piece of equipment or on how to conduct physical operations. But the idea applies to anywhere a new behavior is expected. The more safe practice people get with the new behavior, the better. And once again, this becomes an opportunity for both improving the implementation (feedback from the trainees) as well as gaining deeper commitment to the change by showing both the how and the why.

• Visible Evidence: This one and all tools available initially seem to be the most specific to shop floor kinds of environments. This is about having easily-seen evidence of the system’s health: something close to the action that lets the people doing the work see and respond to the situation. This is often harder in office environments where people are moving around and stuck to their devices all the time. I liked the note that leaders should come to the information, not making it come to them - who is this in service to?

• All Tools Available: Do people have what they need to successfully start AND complete the work they are doing? In a shop floor, this one looks like wrenches and hammers available and in good working order - often in very specific places with outlines. For knowledge-work, we need documents and people and approvals - clear inputs and outputs. In either case, when these are missing, we create lots of chaos. I have a harder time imagining what this looks like physically.

• Clear Benefits: “Because I said so” is something my mother used to say when I questioned her rules. It didn’t work terribly well then, and it hardly ever works in organizations. When a change is introduced, it has to make sense to the people who have to absorb that change. I’m not exactly clear on the difference between this spoke and Notification - possibly it’s needed to emphasize the point.

• Layered Audits: This is an interesting one - setup mechanisms to ensure the change is happening, and check at multiple levels from the daily checks at the coal face to the random walks and other reviews that check we are getting the desired results. More than simply monitoring OKRs (objectives and key results), this looks for the new desired behaviors. “If the audit looks like help, people will welcome you and share ideas to improve the system.”

• Accountability: While everyone is accountable for the change, this spoke emphasizes that the leaders (at all levels) are responsible for ensuring the new behaviors and the new ways of working keep working, even when no one is looking. Reinforce the importance and value of the change. You know why the change is happening, right?

• Recognition: While the changes might by physical changes or new ways of working, the way they become the regular mode of operation is in the stories we tell. Give people credit when they are doing the right things - even if they still have some way to go. They’ll remember and begin to joke about the things people have done to make the initiative work.

And finally, there is the hub of Leadership Commitment. This one almost goes without saying - except that there are so many examples of change projects which were made much more successful and sustained when people could see their leaders (both the official leaders, as well as the people to whom people look for direction) wanted these changes to work. And that those leaders are “walking the talk” as described in the various spokes of the wheel.

One of the elements Lawrence discusses is the idea of having a clear charter for a change event (or project for that matter) that defines the problem, objectives, team members, and owner of the results. From the comments Lawrence makes, it sounds like he’s seen many charters that don’t do these things well. A charter should answer the question of why? Why is this initiative important? What will be better if the “problem” is solved or removed? Will we create problems elsewhere? Are we solving a symptom and missing out on the root cause? I like the phrase “what does good look like” in relation to this - what are we aiming to create? What will we see?

Neil Rackham’s SPIN Selling was written back in 1988. Does it still make sense? A group of people I work with decided to re-read it together and see if it still makes sense. The basics of the overall selling model and the SPIN approach to the “investigation phase” as discussed in the book are a helpful review, but that isn’t where I want to focus today (my review from 2010).

The obvious thing for me in re-reading and discussing the book is that the concepts apply more broadly, which is why some of that other work might strike a chord for other people. “Selling” is not only about getting people to buy your latest offering, but more so about understanding what they are up against and whether you can help them through changes. In any large change project, the change agents are always selling - working to make the change happen and make that change become an embedded way of operating.

The core SPIN Selling (Situation, Problem, Implications, Needs-Payoff) process is all about developing understanding of the customer through conversation - likely many conversations over the course of an engagement. Even when I think I “know” the customer, there are always new people and situations that need to be checked against that pre-existing knowledge. This reminds me of the classic aphorism, “Seek first to understand, then to be understood.”

And while an academic understanding of this method is important, it is even more important to actually DO this. The book gives some guidance along these lines as well. As with any new capability, one does not become an expert overnight by reading a book or attending a few lectures. It is the practice of those skills that is critical. Practice often. Practice with a partner. Practice in safe situations - don’t try it the first time in front of your most important customer. And practice some more.

Guess what I’m going to be doing? And guess how comfortable it is!

The home company of Neil Rackham, Huthwaite International, has a Complete Guide to Spin Selling with courses and videos about SPIN. One video from Neil Rackham about “is SPIN still relevant” that provides some additional context. In that, he clarifies that selling is still about creating value for customers. That hasn’t changed. But he does suggest that the way people approach the questions inside the SPIN model has changed. Critically, the implication questions are even more important - possibly because the kinds of implementations today are getting more and more complicated.

A new book from the Goldratt family! Efrat Goldratt-Ashlag has taken on the mantle of writing a business novel in the style of her father, Eli Goldratt. Goldratt’s Rules of Flow expands upon The Four Concepts of Flow as originally articulated in the 2009 article Standing on the Shoulders of Giants (my post on the topic). The story focuses on project management environments, though the general concepts apply to many environments. I wonder if other books are forthcoming that follow a similar treatment for manufacturing environments or supply chain or sales or maybe specific business types.

The setup is pretty familiar for a business novel: The main character finds himself in a desperate situation - the family business is floundering and might be sold out from under him. Can he make significant changes in the way projects are delivered to prove that he can run the business? Or will the business be sold to a competitor with the inevitable loss of jobs?

There is another familiar element in this story, much of the knowledge is transmitted in the form of an MBA course on project management, being taught by one Eric Silver - I assume this is the same character that taught the project management course in Eli Goldratt’s 1997 book Critical Chain (my review from 2014). There’s even a familiar class curmudgeon. In that book he was just learning the concepts that became known as Critical Chain, and in this book his thinking about projects has evolved in some interesting ways. In particular, the focus is on flow instead of directly on managing projects.

There is an assumption that in most project environments, people know how to do the work of the project. They have their technical expertise or sales acumen or PMI certifications. “Working harder” in these areas only make people tired and angry. And these skills and capabilities aren’t what cause projects to be late, over budget and/or not deliver the full scope (the “golden triangle” or “triple constraint” of project).

As articulated in this book, and I deeply believe, it is the flow of work where things go off the rails. And to do a better job in project environments, we need to find ways to improve the flow of the work. The bulk of the book uses the story to identify the kinds of things that get in the way of flow, and it will be a familiar list for anyone interested in this topic: bad multitasking, missing information, assumptions about the work, everything is a priority, a focus on efficiency everywhere, mis-synchronization, along with variants of these.

Of course, the book presents rules of flow that address these blockers that create such frustration in project environments. The rules are geared around enabling individual projects to finish faster as well as enabling an entire portfolio of projects to flow through the system quickly. As is the case with many of business novels, the characters try the various techniques to surprising success - and some concern that “that won’t work here.” I would have enjoyed expanding the story with more diversions into the challenges of implementing some of the ideas - and how to resolve them.

I particularly liked the way the rules of flow were introduced via the MBA course in the story. Along with the discussion style of the book, the instructor suggests that, depending on your specifics, some of the concepts will make more sense than others. The underlying drive is to improve the flow of work - to enable people to get their activities done with high quality as quickly as possible. The specific techniques depend on what you find in the environment in question. Granted, many of the elements of the discussion are going to be familiar, so it is likely worthwhile to check and implement many of these rules.

One of the surprises for me and others who might equate Goldratt and Theory of Constraints with buffers is that the concept of buffers and the original Critical Chain solution are hardly discussed. It shows up in a later chapter as something some project environments might find useful. The clear message is that the other ideas discussed throughout the book are going to make a significant impact on the flow of project work in any environment. More importantly, without some of the other concepts implemented, buffer management cannot work. The chaos caused by the way we do things must be significantly reduced before a buffer management solution can further help.

Improving flow might also be articulated as reducing chaos. Jumping from task to task to task to task; re-hashing decisions or reworking completed activities; endless debates about priorities … these and more are signs that there is chaos on the environment. Use the rules of flow to reduce the chaos. Be pleasantly surprised at how much better the environment becomes.

I picked up David McRaney’s How Minds Change: The Surprising Science of Belief, Opinion, and Persuasion on recommendation from a colleague who somewhat-jokingly told us that he couldn’t convince us to buy the book other than his recommendation. The book has a lot to do with how we think about convincing others to do something - particularly when they hold beliefs and opinions that run in the opposite direction.

I think the simplest summary of the book is that “changing minds” is much more about opening people to new thoughts and experiences than it is berating them with new procedures or facts. In some cases, these openings happen naturally with the people in question and in others, the openings come upon them through care-filled conversation.

A familiar situation in the world of “changing opinions” is the idea of throwing more information and facts at people - surely they will change their mind if they only could see what I see. The problem is that I am only thinking from my perspective - my experiences, my community, my worldview. In the midst of an argument, it is never the right time to throw more facts on the fire. We can look at the same information and draw different conclusions. Even better, we only look for information that supports our cause - we actively seek it out and actively ignore contra-indicating information. A simple example might be we only weigh ourselves once when the scale reports good news, but try several times when it tells us the “wrong weight.” But why? And what about “bigger” changes to the way we think? Of course, that is the real meat of the book.

McRaney is a science writer, so he dove into a lot of the science about how we think and how people change their perspective, particularly for deeply held beliefs. He also brings in some nice personal perspectives with people who have had rather large changes-of-mind and with people who are actively out working to change minds of others. The emphasis of the book is around hot-topic issues like conspiracy theory, extreme religious views, and social-political views - all with examples where people have changed and where people haven’t. What is it about their situations that caused a change or not?

A key element that comes across early in the book is that our experience colors how we see the world. That statement seems obvious, but it is relevant to the topic. If I want someone to do (or think) something different, but that change goes against their previous experiences, the change is rather unlikely. Even more, not only do our experiences define what we see, but it also tends to define the communities we join. Or more accurately, the communities we join tend to cause us to see things in concert with the community. If the community has particularly strong beliefs or opinions, suggesting alternate views is a great way to get kicked out / excommunicated / laughed at / harassed. Presumably, this has a deep connection to our human need to survive and our days as hunter-gatherers.

This deep connection to one’s identity is also where the core nugget of this book resides on how minds change. In order to make changes to those deeply held beliefs, something has to open up that identity. There are many ways this could happen, and McRaney gives a number of examples in the book. We tend to be in many communities and join and leave them as we go through life. Maybe one of those communities loses prominence to another, and those core beliefs shift to be consistent with the new community. Or in the example of deep canvassing, people actively seek out conversations with people who hold opposing views. But rather than trying to convince them, it is all about seeking to understand and then opening the conversation with “what if?” or “have you ever?” or “do you know anyone like?”… Or in another situation, maybe an individual begins to experience things that deeply shake their core views.

All of these have the effect of enabling the individual to start thinking about their thinking. Maybe it isn’t explicit, but it is there. And that ends up causing discomfort. Either it gets justified and the beliefs hold. Or it becomes harder and harder to hold that belief, and the opportunity for change is there. McRaney outlines the way several approaches work, and they all seem to have this as an essential element - a new perspective opens. The various approaches get there and make use of it in slightly different ways.

As I was in the middle of the book, someone referenced James Clear’s Atomic Habits where he talks about our Identity leads to Behaviors which produce Outcomes. This is right in line with what McRaney describes concludes in his book - that one’s identity is really tied up in some of those deep beliefs. McRaney delves into more of the science behind how this all works. And in a nice surprise, I just noticed on James Clear’s website an article about Why Facts Don't Change Minds.

A funny note: I read the book on a tablet and found it funny that McRaney included a number of QR codes to follow a link somewhere. Might have been nice to convert those to URLs for e-readers. (It would be even stranger in an audio book.) His website for the book includes a bunch of links and interviews related to the book, including those images from chapter 3.

Dentistry with a Vision: Building a Rewarding Practice and a Balanced Life by Gerald I. Kendall and Gary S. Wadhwa is a Theory of Constraints business novel, this time focused on dentistry practice. Kendall is a long-time TOC practitioner, and Wadhwa is a dentist who has had great success implementing these ideas. As with many of these books, putting the story into novel form allows the ideas to develop and a “guru” to provide guidance in a more visceral form than one might get from a textbook or workbook. And in this case, it felt like the guidance from the guru provided good starting points for further investigation to someone who might want to try the ideas in practice.

Theory of Constraints applies to many situations, though it is usually larger organizations that get the notice of consultants and books. But a business like this - physicians, lawyers, architects, furniture repair, etc - makes perfect sense. And the key constraint or limiting factor inside the business should (always) be the doctor / lawyer / expert repair person. The book also talks about having the right mix of work - work that brings the most profit per hour for the dentist (in this case) as well as work that enables long term stability and growth for the business. And, as with other types of business, it could be that the dentist isn’t currently the limiting factor in growing the business. It could be other specialists or available space as the current bottlenecks. Once you’ve decided where you WANT the constraint to be, there are decisions to be made on how to make that happen and then on how to continue exploiting the constraint (getting the most value from it).

Of course, it is not just Theory of Constraints that applies in making any improvements, though this book (and a lot of my work) uses TOC as an organizing principle. Where is the best place to make improvements? Start with the constraint. Improvements elsewhere only benefit if they help the constraint (step 3 of the five focusing steps); improvements without this knowledge can actually do damage, which the book gives a few examples of. The authors bring in several TOC concepts along with Lean, Six Sigma and others. It was interesting that the “human side” of change management was the topic that came last. The authors acknowledged that while change doesn’t happen without the people involved, sometimes it is difficult to get people motivated to consider those aspects until they see some of the potential effects on personnel and their colleagues.

I could have used more in the telling of the story in this book about how they implemented a shift from the dental assistant as the constraint to the dentist as the constraint. There was a lot of conversation about the impact of “cost cutting” or “cost control” measures that end up causing damage to the business: the dental practice couldn’t take on as much work and keep the dentist active on dental work when there is no protective capacity in the other roles in the business.

Dentistry with a Vision has a lot of similarities with Graham Scott’s more recent Practice Makes Profit (my review) - TOC applied in a medical practice (dermatology instead of dentistry). Scott’s book was much shorter and focused on the first three elements of the Five Focusing Steps: identify the constraint, decide how to exploit the constraint, and subordinate everything else to the above decisions. Kendall and Wadhwa’s take expands the story to include more thinking around how to implement a larger solution.

A recent examples is Do DevOps and the Theory of Constraints still relate by Will Kelly. The popular origins of DevOps came with The Phoenix Project (my review from 2013), a book that was heavily influenced by Goldratt’s The Goal, the starting point of TOC. Kelly focuses on the TOC five focusing steps and talks about how DevOps relates.

The Five Focusing Steps are

1. Identify the system’s constraint.

2. Decide how to exploit the system’s constraint.

3. Subordinate everything else to the above decision.

4. Elevate the system’s constraint.

5. If in any of the above the constraint has been removed, go back to Step 1. Do not let inertia become the constraint.

What does constraint mean in this context? It is the limiting factor - the thing that prevents you from getting more of the desired goal out of the system. (Often the goal here is money - what is the thing that limits us from getting more money from this system.) In this context, there is always a constraint in the system, otherwise we’d be able to get infinite amounts of our goal. These steps are a loop for system improvement.

Back to the article about DevOps and TOC, Will Kelly emphasizes “identify the constraint” and talks about some of the more challenging barriers to adoption of DevOps, like company politics and change management. But then he talks about “fixing the constraint”, rather than the TOC perspective of deciding how to exploit the constraint. This is not unusual. Many people see the constraint as something to remove or fix. It’s something bad. (The original language in The Goal used the term “bottleneck” which had even more connotations around “bottleneck busting.”) Notice step 5, however. In some cases, there is a current constraint in the system that really should not be the controlling constraint and can be easily removed. In that case, there is a new constraint, go back to step 1. Where is the constraint now? Is it in a place that makes sense for the whole system - is the constraint where we want it to be? As Will Kelly notes, iteration is key in going through this loop of the Five Focusing Steps.

Then go to step 2. Once we know where the system’s constraint is, how do we take advantage of that? How do we want to make the best use of that constraint to get more and more value out of the entire system. Usually this implies changing policies and practices, rather than spending a lot of money (which is typically step 4 - Elevate). Sometimes these steps can cause the constraint to shift. Go back to Step 1 again.

What about step 3, subordinating everything else to the decisions about how to exploit the constraint? Will Kelly seems to think this no longer applies in a DevOps environment - and it seems he’s shifted from adoption to application of DevOps. He talks about iteration being the key - ever improving. That said, I think this is exactly what the focusing steps are about. What is limiting our ability to grow now? How can we adjust our practices and policies now that we see that?

And step 4, Elevate? Many organizations discover that going through the five focusing steps they don’t need to “Elevate the constraint” right away - this often involves spending significant amount of money on people or equipment. Looping through the first steps often uncovers capacity that has been hidden by the ways of working in the system. When that elevate is required, the whole system has to be ready for it - increasing the capability / capacity at the constraint with a significant investment can easily shift the constraint to another part of the overall system. Are we ready for that?

My take is that with successful DevOps implementations the immediate “problem” that DevOps was meant to solve has been successful. That part of the business system is no longer slowing down the business. Looking at the larger business, something else is now the limiting factor - the constraint has shifted. This happens in The Goal where Alex Rogo realizes his plant is now operating faster than the demand from the market. So now the question is how to find ways to get more demand - decide how to exploit the new constraint and operate the plant according to this new way of working.

I’m happy to have a conversation on this one, as there are always many threads of discussion that I didn’t include here. And of course, there are many aspects of what Will Kelly described that may not have been included in the article that inspired this one.

I picked up The Myth of Multitasking: How “Doing It All” Gets Nothing Done by Dave Crenshaw on a recommendation from a colleague. It’s a nice quick read, and covers some familiar ground for people who talk about multitasking and the sorry effects of high work-in-process (WIP) for people and their businesses.

The book is setup as a business novel, where the main character is an “efficiency and time management” expert, working with an executive who has tried a number of times to get herself together and keeps sliding back to the old ways of working. The expert goes through the familiar process of defining multitasking (“switchtasking”) and expanding on just how much damage it can do to one’s ability to get things done. This should sound familiar to anyone who works in this arena: switching from one thing to another to another without getting anything done makes everything take longer due to the need to re-engage with the work when you come back to it. And there is a higher likelihood of mistakes and rework when operating this way. Replicate that around a company, and you have lots of very busy people who get very little done.

I liked how Crenshaw is working with an executive - not only might the executive benefit from less multitasking, but her entire team - the entire company even - will gain from her setting an example and expectation of a way of working that is different. And finding ways to eliminate or reduce multitasking for her was going to have knock-on effects throughout the organization.

One of the common frustrations that I have with discussions of multitasking is that they often make it sound like a simple solution is to “stop multitasking.” But that isn’t something to do - what should people do, so that they are less likely to multitask? This book came with some specific recommendations for this executive, given the way that multitasking arises in her life. If the book were working in a different context, the specific suggestions might be different.

I particularly liked the example of frequent interruptions by her staff and employees, who have “a quick question” any time they find her free. These quick questions always derailed the manager, and it wasn’t obvious how to eliminate this big source of multitasking. The story asked the question of why they operate this way (and why the executive allows it): they never know when the boss is going to be available, so they hover and pounce when it looks like she has a free second. The solution is to create reliable space and time for people to resolve questions and issues that need her attention. For staff, this is likely regular 1-on-1 time. For others in the organization, it is focused “office hours” where she could pay attention to them and their challenges. (I missed the other aspect of this conversation: why do they need to come to the executive at all; what prevents them from being able to resolve these questions themselves?)

Another example of a solution applies to just about everyone. When you are doing something, focus on that one thing until it is finished. If you are meeting with a colleague, leave the phone (and computer) off to the side; if you are enjoying family time, enjoy that. Focus. Pay attention. It seemed like this element in the book - that of fractured attention - was just as important as the traditional discussion of multitasking around fractured work. It certainly does similar amount of damage.

One thing that this book didn’t touch upon was the damage that multitasking (and high work-in-process in general) does to the flow of work around an organization. When everything is piled up everywhere, people feel like they have no choice but to multitask. This is relevant in organizations that do a lot of project work. The suggestions in the book will help with this aspect as well - it is just coming at multitasking from a different perspective.

The book wraps with a “several months later” chapter that suggests how well things have gone, now that the executive has implemented the ideas outlined in the book for herself and introduced them to her organization. Along with the personal benefits, there are hints that these efforts have positive impacts on interpersonal relationships as well as business relationships with customers and suppliers. I can confirm results on all of these fronts as well.

Find ways to reduce the need to multitask. In some cases it’s obvious why it is happening. In other cases it may take some digging to understand what causes the situation to arise. Eliminate that underlying cause, and you will go a long way to improving the situation: less distraction - less multitasking - higher quality - shorter turnaround time - better relationships.

And really, getting more of the right things done.

A Radical Enterprise: Pioneering the Future of High-Performing Organizations by Matt K. Parker is a curious book. It describes a vastly different way of working in organizations that enables significantly better outcomes - an exciting scenario. At the same time some of the stories and prescriptions made me either disappointed in my own ways of working or think that there is a deep canyon between my current ways of working and this radical new enterprise. Am I ready to try to reach across? And in some cases, Is this for real? To put off some of the skepticism (“this will never work”), Parker brings in examples of companies that have started down the path to becoming high-performing organizations with a very different working model. And these examples come from a variety of industries - IT, manufacturing, consulting, innovation and others - which bolsters the argument that this isn’t something that applies only in one type of firm.

What is a radical enterprise? My take is that is a new choice of how to operate that creates much better collaboration (radical collaboration?) and interpersonal connection within the organization. And that then creates significantly better outcomes for the customers of the organization. The other part of the discussion is “what is NOT a radical enterprise?” And that is essentially what we have now in the familiar description of organizations: strict hierarchy, employees locked into roles/teams, low psychological safety. Parker talks a lot about the dominator hierarchy model in this context.

Parker describes four imperatives of the radical enterprise: Team Autonomy, Managerial Devolution, Deficiency Gratification, and Candid Vulnerability. Each of these get their own discussion, though Parker makes clear that they are not stand-alone factors that one can create without at least some elements from the other imperatives.

Teams operate with autonomy - teams and team members decide for themselves how they work, when and where they work, with whom they work, on what they work, and what role they play in that work. In conjunction with that, you have a devolution of management from the directives-from-on-high mode of the dominator hierarchy to more and more self-management of decision-making, personnel decisions, performance evaluation and even compensation. This was the area where I had the most “is this possible?” reactions while I read. And then there were several examples to back it up.

And to support these new ways of working and organizing, the other two imperatives come along. Deficiency Gratification is an idea from Maslow’s hierarchy of needs that I hadn’t heard before, but when the human physiological, safety, belonging, love and esteem aren’t met, people lose motivation and performance suffers. Organizations that are better able to meet these needs with one another tend to have higher-functioning people. And this almost rolls right into the idea of Candid Vulnerability: people need to be honest about when they don’t know. They need to feel safe to bring the “hidden” conversations out into the open.

One thing that was missing for me was a “roadmap” or maybe some guidance on how to get to this new way of operating. Yes, there were examples how how some companies made the shift - or how they started with this new way of working. But then, I think some of the point of the book and stories is that there are many ways to get there and they are very dependent on where your company is today. Many of the example companies relied on small tests and trials to get where they are now. And Parker warned a number of times that just applying one of the concepts without being prepared to bring in the others could be a recipe for danger.

Another addition that I would like - maybe this is a conversation or discussion, rather than additional book content - is how other exemplar companies might fit into the framework of A Radical Enterprise. In particular, I kept thinking about the software design company, Menlo Innovations, with the work practices and love of each other as articulated in Joy, Inc. It seems that they cover many of the imperatives described in this book.

As I said at the top, A Radical Enterprise is an inspiring description of a new way of working that is good for the people inside the company AND good for the customers and other stakeholders around the company. But, boy oh boy, there are a lot of questions for people who are in traditional organizations about how to get there (or even if it is possible).

Note: I received a review copy of the book from the publisher.

Conflicts arise in many scenarios every day - work, home, social situations, politics, … pretty much anywhere you have humans interacting with one another. Often people talk about compromise as the best way to “solve” a conflict. The challenge with many compromises is that they end up being lose-lose. Neither party really gets what they want - they’ve just made sure the other party doesn’t “win.”

The Theory of Constraints approach to conflict resolution is a way of thinking that says conflicts can be removed. Removed, not resolved or ameliorated. The specific tool is the “evaporating cloud” or “conflict cloud.” I also like Clarke Ching’s variant on this of Corkscrew Solutions or his earlier analogy to a stick figure. The general idea is to dig under the conflict to figure out what is going on - the conflict is happening because of the action or position: hold more inventory / hold less inventory; respond immediately / response later; spend money on X / spend money on Y. But also why do we want to take these actions? What is the underlying need behind what you want to do? Even deeper, is there a common goal that ties those needs together? Is there truly a conflict - can we really NOT do both of those things? And if there isn’t a common goal, then this discussion won’t apply either - if we don’t share something in common, why would we want a resolution?

Here is a classic case from business - hold more / hold less inventory. We want to have a profitable business (now and into the future). In order to do that, we need to control costs and we need to protect sales. In order to control costs we must hold less inventory. In order to protect sales we must hold more inventory. And we can’t both hold more and hold less at the same time. A conflict. And when there is a conflict there meetings and meetings and meetings, sometimes a compromise is obtained but then something happens and the conflict rears its head again: the organization misses a sales target, so push out more inventory. Or the finances aren’t looking to good, so cut inventory across the board. A classic sign of an unresolved conflict is this kind of pendulum swing between actions.

Articulating the conflict is just the start, but often a very good one. Now we can start checking the assumptions - the because under the statement “In order to meet need A, I must do X because ___.” And it is in the assumptions where the cloud can be evaporated: we can take one action (or a set of coordinated actions) that will enable us to meet both needs. A win-win.

* The podcast in question was a recent Hidden Brain episode Changing Behaviors, Not Beliefs with Prof. Phillip Atiba Goff.

Jamie Flinchbaugh has a new book out about problem-solving, People Solve Problems: The Power of Every Person, Every Day, Every Problem. The basic setup is reasonable - we all solve problems all the time, how should we think about it? I like how this isn’t a set of specific directions for problem solving, but rather what any approach to problem solving should have from the individual contributors through to the leaders. The book is primarily centered around problem solving in a Lean environment, and there are frequent references to Flinchbaugh’s books (along with other Lean-related books). But it is clear from the tone and examples that the concepts here apply well beyond formal Lean implementations.

Flinchbaugh goes through a basic structure of problem solving - even starting with a discussion of the problem that the book is addressing: that many “problem solving” implementations are heavily focused on the tools and artifacts, rather than on the underlying mindset and behaviors. The tools support the mindset, they don’t create it. This applies to almost any change effort - if we think that Lean or Theory of Constraints or Agile are the artifacts people see, we have lost the boat. It’s the cargo cult mentality or wearing black turtlenecks because your hero wears them. Flinchbaugh attempts to discuss throughout the book the underlying principles / mindset that create positive problem-solving behaviors, which then create the desired results of learning at the individual and organizational levels. Tools that are out there - those that work for people using them - have been developed by organizations over time and through practice, iteration. Without the inherent practice and internal learning, picking up someone else’s tools of any discipline inherently means you will be starting in a different place and get different results than the original developers. This thought may be deeper than it seems.

For people in many disciplines, the problem-solving general framework should look familiar. It might be the scientific method or your favorite learning loop or something more formally applied to problem solving.

• Identify the problem. This may happen through observation or analysis, but it includes not only noticing something (“that’s interesting”) - it also implies that we see a difference between what we expect and what we got. And to be a problem, this difference in expectation has to be meaningful to the organization. It has to be worth pursuing. My wife likes to separate this into two statements, “Does it exist?” and “Is it a problem?” Flinchbaugh also comes to the idea that “lack of a solution” is not a problem. Not only does the problem need to make sense, but those who are affected by it - and by the potential solutions - should agree that it is a problem. There is also the idea here of being careful about playing Whac-a-Mole with symptoms, instead of finding an underlying core problem.

• Coming up with ideas and selecting a solution. Is there really only one way to solve the problem? Do you already have a selected solution before investigating? Another sign that the problem-solving mindset is missing. The basic idea here is that once we have an idea of the underlying causes and conditions, there are likely many options to try. Thinking about the options might even change how we frame the problem. Are there aspects of the options which might require us to expand or narrow the scope of the problem? Might they create unintended side effects or raise other challenges?

• Test and reloop. This is where many Change efforts stop. Pick a solution and go - damn the torpedoes. But in a learning organization - and problem-solving is definitely a learning process - we test out the changes. Sometimes that can be done in the lab or with a small group of people, or tested for a short period. What do we expect to happen? What actually does happen? Does this change our understanding of the situation? (Don’t be lulled into confidence if the results are better than expected, this suggests we don’t understand the situation fully too.) Do we drop the suggested solution or modify it?

I particularly liked Flinchbaugh’s early comment about these elements of problem solving - it is a process of learning and investigation. If your problem statement never changes while going through the process, it’s an indicator that you are following rote steps, rather than diving in and trying to learn something. We always see a situation differently after exploring it - in this case, the understanding of a problem will change as we explore it.

Flinchbaugh discussed the high-level process in the first third of the book, the rest was focused on the elements of a problem solving culture in organizations. To summarize, it is all about the learning organization - individuals shifting from being knowers to learners, relentless pursuit of the ideal, collaboration, trust, coaching, and leadership. Much of the discussion in these sections reflects back to the high-level process above and deepens it. I found the several chapters on coaching rather insightful, as that is a lot of what I find myself doing in my own work. But the coach isn’t only a formal role - how do we set an organization to create coaches at many levels (both formal levels and levels of capability)?

I picked up the book after hearing about it on Mark Graban’s Leanblog podcast with Jamie Flinchbaugh.

Graham Scott has written a nice, short book that feels like a conversation, incorporating the ideas of Theory of Constraints - focus and leverage: Practice Makes Profit: The small business owner’s guide to making more money by NOT working harder.

In fact, this is more of a booklet - it comes in less than 100 pages, though with a little extra bonus content on his website. This makes it a fast read and really lets the book focus on the key content - how to focus on things that matter most. It’s also interesting that this story focuses on small business, where most of this type of book talk about larger companies with hundreds or thousands of employees.

Graham Scott frames the book around a medical practice - that of a dermatologist running a solo practice. He also brings in a number of other stories and anecdotes from other small businesses, including his own accounting practice. I like how he uses these as specific examples of the focussing process, as well as turning them back into the main story.

The main book ends with a summary of the impact that the high level steps had on business for the dermatologist - going from modest profits and frustration to significant profits. And as I’ve seen in many of these types of efforts, the initial improvements do not require significant investment. (They also don’t start with “cost cutting” efforts that many people assume are required.)

The focussing process in question is the Five Focusing Steps from Theory of Constraints, originally articulated in Eli Goldratt’s The Goal. He also uses the language that Clarke Ching’s The Bottleneck Rules (my review) with the acronym FOCCCUS. Graham Scott brings in many of the familiar terms associated with Theory of Constraints in a fairly natural way - constraint/bottleneck, efficiency/effectiveness, buffers (time, money, resource), protective capacity, what NOT to do, and more.

The Five Focusing Steps from The Goal:

1. Identify the system’s constraint(s)

2. Decide how to exploit the constraint(s)

3. Subordinate everything else to the above decision

4. Elevate the system’s constraint(s)

5. If, in a previous step, the constraint has been broken go back to step 1

And the FOCCCUS acronym from The Bottleneck Rules

• Find the bottleneck

• Optimize it

• Coordinate, Collaborate, Curate everywhere else

• Upgrade the bottleneck

• Start over (Strategically)

Both of these articulate a processes of ongoing improvement. Even within these cycles, there will be ongoing improvements. I’ve seen the constraint / bottleneck shift even when doing the first few steps. (The language about “bottleneck” and “constraint” varies over time and by author - bottlenecks tend to be temporary; constraints tend to be longer-lived or even strategic.)

I picked up Cynefin - Weaving Sense-Making into the Fabric of Our World just recently, though it came out last fall as a celebration of (at least) 21 years of the evolution of the Cynefin model. While I was hoping for some more insight into how people have applied the model, I appreciated most of the stories and the connections people made to using the Cynefin concepts in a wide variety of applications.

One nice element of this book is that it gives the reader a sense of how the Cynefin idea and framework has evolved - primarily from the perspective given by Dave Snowden in his chapter, but you also get a sense of the development from the other contributors.

Otherwise, I am having a difficult time in writing a review. This isn’t a “how to” book, nor is it one story. It is a collection of small stories, all centered around the many people and ideas wrapped up in Cynefin. If you have been following the concepts for a while, there are some nice examples and stories. If you are looking for an implementation guide, this is not the place. That said, it was a good trip both down memory lane as well as looking forward - what might come next from this community?

Update 27 Sep 2021.

Thinking further about the book, one of the highlights of the book is the wide range of application areas that are described - specific ways that Cynefin has been used, and adjacent areas of thinking which can be enhanced with the Cynefin concepts. Here are some of those.

• An early chapter by Sonja Blignaut describes the organizing principles of Cynefin that I hadn’t seen articulated before. Embrace of messy coherence; Self-discovery (enable descriptive self-awareness and self-discovery); Attune to timing and flow. There is a lot of explanation under each of these that would point to many of Dave’s videos over the years, but overall this is a way of seeing the world that reminds me strongly of the “four pillars” of Theory of Constraints. Most of the other how-cynefin-applies have a lot to do with this new way of thinking that Cynefin opens.

• Of course, there has to be a connection between Cynefin and knowledge management, as that was where Dave had a lot of attention in the early developments of Cynefin. (Or I should say KM is the domain from which I first learned of Dave Snowden.) His thinking got me to realize that what KM practitioners were trying to do had a lot to do with boundary-spanning - taking ideas from multiple disciplines about how people work together and how we can facilitate “knowledge” sharing. It’s has been a central point of this blog for many years.

• The other big topic on this blog has been Theory of Constraints, and there is a chapter here by Steve Holt that does a little compare-and-contrast between ToC and Cynefin. The approaches share some terminology, which sometimes confuses people, but looking under the woreds to the concepts shows a lot more harmony. Steve also happens to be the first person I hheard talking about Cynefin in the context of Theory of Constraints.

• Zhen Goh talks about shared connections between Cynefin and daoism. Knowing by not knowing. Yin - Yang.

• Several chapters talk about applying Cynefin in the public sector, and in my mind this seems to be the kind of application that Dave talks about the most. Of course “public sector” is many things given what governments do. There are examples from Wales to Singapore to Columbia or more specific to applications with policing or the US Navy.

• The other big area of application that Dave discusses - at least where he shows up to give presentations - is in IT / Agile conferences. This has transitioned into many people in that world talking about and applying Cynefin in their environments. And several of those are reflected in the chapters.

• I enjoyed Greg Brougham’s chapter on Cynefin and Delivery, where he mentioned the assumption many people make that the environment is fixed and known. In reality, “It is important that [we] acknowledge the context, and if the context changes, policies may need to be reviewed.”

• Ecology and the environment seems like an “obvious” fit for Cynefin, as that realm is loaded with complicated and complex relationships. Similarly the world of healthcare and disease (pandemic?) response is a great fit for this way of thinking.

• A chapter by Robert Koch describes how Cynefin helps with risk management - assuredly an area where differentiating between Clear, Complicated, Complex and Chaotic becomes quite relevant. There’s a great quote that Cynefin helps us to appreciate that ‘complexity is not simply greater order complicatedness’. Complex systems / situations are different creatures than complicated ones. And another chapter discusses Cynefin in application to safety culture - another domain where context changes, taking people through the Cynefin domains.

Other areas described include Training and development; Teaching with the body - using the physical experience; Workplace and employee well-being; Strategy development; Leadership development; Complex facilitation; live theater rehearsals and productions; … There are many arenas - probably infinite arenas. Human systems inherently show any of these domains, depending on what’s happening.

It’s always entertaining listening to yourself, but I enjoyed the conversation a second time. There were a couple conversation threads that had me very excited about the topic. Hopefully I wasn’t too over the top. I think I could have chatted with Jay Hrcsko for another podcast worth of material.