Imagine playing a game, a jigsaw puzzle, with a toddler. One of their favorite pastimes. How does the game work? You begin with a clear picture of what you are building, like say a majestic mountain. The pieces are numbered and have distinct edges, making the process enjoyable. You assemble them, piece by piece. The task involves limited variables, a reasonably well-defined process and an expected outcome. To adults, this may seem simple, but many tasks in the real world fall into this category, simple tasks. Making a Cocktail, baking banana bread, or crafting a Caesar salad are among them. With some practice and determination, one can get highly skilled in these tasks.
Now, let’s take that same puzzle and play it with a ten-year-old. The jigsaw puzzle lacks a final picture, with similar-looking pieces numbering over a hundred. Completing this puzzle demands thinking skills, time, and experimentation. It requires trying different approaches and iterating until the pieces fit together, gradually revealing a cohesive image. Patience and effort are necessary. Eventually, the child realizes that a large jigsaw puzzle is merely a collection of interconnected smaller puzzles. This type of task falls into the category of complicated tasks. Assembling a computer or a car is a prime example. It necessitates the expertise of domain specialists who refine individual components, and integration experts who ensure everything fits together, seamlessly. Although complicated tasks often have predictable outcomes, they demand analysis, planning, and coordination for effective execution. In the software realm, where outcomes are partially defined, terms like “agile development” or “six-sigma quality bar” are thrown around as attempts to handle complicated tasks with a semi-defined playbook.
Now, let’s delve into a game with a teenager, perhaps a real-time strategy game like StarCraft. It’s an unpredictable game with a steep learning curve, where cause and effect relationships are not readily apparent. The game is characterized by dynamic, ever-changing environments, and your choices create feedback loops that influence the intended outcomes. Unlike complicated situations, this puzzle cannot be easily decomposed into separate pieces because the variables are interconnected. Such systems demand adaptability, experimentation, and the ability to iterate based on feedback. Raising a child serves as a real-life example. Each child is unique, and there is no playbook; you invent it as you go along. Research and development in most areas, such as genetics, deep learning, and pure mathematics, fall into this task category. There is no playbook because there is hardly a process. For instance, developing a marketing strategy for a new product category in a market where competitors have a significant advantage in similar categories is one such complex task.
The first key factor that distinguishes a complicated task from a complex one is the definition of the outcome. In a complicated task, the outcome is either well defined or reasonably well-defined. However, in a complex task, the outcome is veiled in uncertainty. You don’t know the magnitude of the dragon you’re about to face. Yet, when you’ve reached a point where progress aligns with your ideals, the proof is in the pudding. For instance, a child who grows up to be healthy, happy, and reasonably literate is a testament to the success of dedicated parents and teachers, unlike a child who ends up emotionally scarred. In the realm of software, when you hear terms like rapid experimentation, employee autonomy, growth mindset being mentioned, chances are you’re dealing with something complex.
The second crucial factor that sets them apart is the kind of thinking required to navigate these environments. In complicated scenarios, reductive thinking serves as a key differentiator. However, in complex environments, holistic thinking becomes essential for survival. Here, the sum of the parts can be exponentially greater than each individual component.
Allow me to share a personal story to further illustrate the distinction between reductive and holistic thinking. Years ago, I had the chance to attend a workshop on user experience. On the second day, a case study comparing Google Docs to Quip was conducted. Seated among a group of engineers hailing from diverse backgrounds, we conducted on the task of creating a pros and cons list, weighing the merits of Google Docs against those of Quip. In our evaluation, Google Docs emerged as a feature-rich tool seamlessly integrated within the Google ecosystem. On the other hand, Quip showcased a visually appealing design but suffered from minor technical flaws. At nearby tables, where product designers were stationed, a different assessment unfolded, leading to spirited debates.
Then, the moderator posed a question that resonated deeply within me: “When your thoughts are scattered and you simply seek to write something down, which product makes you want to scribble?” Without hesitation, the majority, around 70% of those present, expressed their preference for Quip. The engineers had used reductive thinking, focusing on the individual aspects and features of each product. In contrast, the moderator and designers had employed holistic thinking by considering the overall experience and the emotional response evoked by the products.
Parting words, understanding the context of a problem makes it psychologically easier to deal with.
Amogh Mahapatra's Writings 