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

As good left brained analytics trained by Western “education systems,” many of us technical folks believe that there is one right answer to every question or every decision that is in front of us. We tend to argue endlessly about which is the right feature to implement or which way to implement a given feature or which tool to use. We’d rather argue than try and do an experiment to find evidence as to what is the right path.

Recently, a great deal of attention is paid to A/B testing to quickly gather evidence as to which way to implement a new feature. What gets missed in A/B testing is that you actually implement both options rather than argue about which option to implement.

I first captured this thought in Walter’s Laws:

7. If you are agonizing over picking the optimum choice from a list, implement all of them (move from either/or to BOTH/AND).  Time after time I see software engineers spend days to weeks trying to figure out by themselves (without involving real users) what is the best choice.  By implementing all of the possible ways (usually takes far less time building than trying to decide), choice is preserved until you do get the product in front of real users.

I was reminded of the need for this “law” when working with an early stage start-up that is evaluating technologies to incorporate into their product. I brought up the importance of backward chaining (from the AI world) in doing their customer research versus the forward chaining thinking that most developers start with in the “If you build it, they will come” mode.

They were about to pivot and were asking me what I thought of their new product direction versus their old product direction. I loved the new product direction because it nicely fits the “backward chaining” model. That is, there is a clear goal or decision that the users of the product would have and thus you could do the user research to figure out what steps are necessary to reach the goal.

Their first product had no clear goal or decision to aim at. It was a “forward chaining” kind of product that leads to a development process of continuing to develop new features in hopes that somebody would find some subset of the features useful for some as yet unidentified activity.

As we discussed the concepts, I realized that I was going into the Either/Or mode of thinking and not the Both/And. I shared that “of course, good developers realize that no problem is either completely a backward chaining or a forward chaining type of problem, so a good solution usually involves both approaches.”  This kind of approach is often associated with the AI technique of a “blackboard system” where you have multiple types of processes working against the same knowledge base and updating the “blackboard” as they complete the iterating with their world view. From Wikipedia, a metaphor for a blackboard system is:

“A group of specialists are seated in a room with a large blackboard. They work as a team to brainstorm a solution to a problem, using the blackboard as the workplace for cooperatively developing the solution. The session begins when the problem specifications are written onto the blackboard. The specialists all watch the blackboard, looking for an opportunity to apply their expertise to the developing solution. When someone writes something on the blackboard that allows another specialist to apply their expertise, the second specialist records their contribution on the blackboard, hopefully enabling other specialists to then apply their expertise. This process of adding contributions to the blackboard continues until the problem has been solved.”

Over the years, this combination of backward and forward chaining shows up in interesting places beyond the AI world. While in a working session with several long time DuPont manufacturing managers, one of the managers responsible for building DuPont plants in remote sections of the world shared his process for planning the logistics of plant construction.

“When I started in this business, I would begin my planning in Wilmington, DE, with all the things I needed to get from here to some remote place in China or India. What I quickly found myself doing is contingency planning and before long I was trying to ship everything we had in Wilmington to the remote location.

“After several very expensive and over-budget construction projects, I realized that a much better way was to stand in the remote location and then figure out what I needed to pull from Wilmington, DE. This backward chaining process cut 50% off the logistics costs. I no longer had to do any contingency planning and the path to get everything to the site was a whole lot clearer.

“I later realized this was a different form of the ‘Begin with the End in Mind‘ habit of Stephen Covey. In this case, the end is the physical location.”

As we explored his experiences further, he allowed as how he was really using both backward chaining and forward chaining. The flipped perspective was to realize that I needed to ADD backward chaining to my previous unsuccessful use of forward chaining. Both/And thinking emerges again in the context of remote plant construction.

Calm from Fl!p shares his insights on flipping your perspective:

This backward chaining also shows up in Russ Ackoff‘s development of his Idealized Design methodology. Russ and his clients were frustrated with the lack of results from trying to plan for the future by only looking at the past. Russ described other planning methods as being a variant of either standing in the present and looking backward at what an organization did in the past or standing in the present and trying to predict the future. His Idealized Design method recommended standing in the future and looking backward at the present through the lens of what you want your world to be like in the future. Backward chaining by any other name.

However, in order to prepare for an idealized design session you need to understand where the organization has come from – Both/And at work.

From today’s social media stream and an article from Geekwire “Three book recommendations for executives from Amazon CEO Jeff Bezos,” I was reminded of another example of the perspective shift of Both/And thinking and backward chaining from Eli Goldratt. Goldratt was an Israeli physicist who got involved with transforming manufacturing with his Theory of Constraints. There are two key lessons I carry with me always from Goldratt – the Theory of Constraints and his use of the Socratic Method of story telling. Both lessons reinforce the Both/And concepts.

Goldratt’s book, The Goal, was one of the three books that Bezos employs for his book club discussions. The Goal is a novel that tells the story of a manufacturing manager who learns the Theory of Constraints from the Socratic guru Jonas to save his factory from being shut down. Goldratt had tried for years to get his concepts across to manufacturing managers through hours of lectures that he captured in his first book, The Race. None of his “students” got the concepts or acted upon them. So in desperation he linked up with a novelist (in the loosest sense of the term) Jeff Cox to write the story. The Goal sold millions of copies very quickly and Goldratt was in high demand to help companies implement the Theory of Constraints.

The Goal provided the context and the motivation for manufacturing managers to then really dig into the Theory of Constraints through The Race and through Goldratt’s classes. Neither of the books could work without the other to generate action and great results. Both forms of “knowledge” are required.

The Theory of Constraints is a Both/And and backwards chaining example as well. Most of us when confronted with a complex workflow that needs improvement believe that in order to improve overall performance you need to optimize every single step. Drawing on his work in physics with analysis versus statistical methods, Goldratt realized that optimizing every single step doesn’t optimize the whole system. Rather, there are only two to three “constraining” steps in any given complex workflow. To improve overall performance you only need to focus on optimizing these bottleneck or constraining steps.

Goldratt realized that through backward chaining at the right level (the whole system versus individual workflow steps) you could achieve high performance results with significantly less effort. You still need to optimize, but only for a couple of steps.

So the next time you are sitting in what could turn out to be an interminable argument around an either/or discussion, change it to a Both/And that will allow you to more quickly both implement a solution and gather the evidence. As I found in the past, it generally takes less time and you end up with a better architecture and design if you implement both approaches rather than just a single approach.

Both/And thinking and backward chaining – where could you be using these techniques today?

For a humorous look at the wonderful world of innovation and new ventures, checkout Fl!p and the gang at Fl!p Comics.