Do You Think Like a Lawyer, a Scientist, or an Engineer?

Do you think like a lawyer, a scientist, or an engineer? These professions all emphasize logical reasoning, and all require deep study, practice, and understanding. Yet, they take different approaches to building knowledge and implementing that knowledge in their field.

There’s a lot we can take from all three disciplines. Being effective requires us to apply the right mode of thinking in the right situation, and switch between them as needed. Let’s look at each mode of thinking and how to choose between them.

Law: Issue, Rule, Analysis, Conclusion

In law, rules are the primary foundation for decision making. Years of study enable lawyers to understand rules and how they should be applied. Much of law regards analyzing an issue and concluding whether something complies or does not comply with these rules. These conclusions can then drive behavior. Conclusions guide people to act appropriately and legally, and guide the state in punishing those who violate laws.

Training to be a lawyer requires repeatedly evaluating scenarios and coming to correct conclusions. The Bar exam, the final qualification for becoming a lawyer, includes hundreds of such scenarios.

A classic legal decision-making framework is IRAC: Issue, Rule, Analysis, Conclusion. The first step is precisely identifying the issue. Many aspiring lawyers fail their Bar exam by failing to understand the real issue in a scenario. Correctly identifying the issue can be challenging.

The second point is to understand which rules apply to this scenario. Skilled lawyers remember thousands of points of law, but finding relevant laws can also require extensive research. There is an interplay between determining the relevant rules and identifying the issue. Different rules require attention to different aspects of a situation, so the issue may appear very different depending on the rule.

For example, if someone injures themselves on an icy sidewalk in front of a building, you need to know what rules apply so you can identify the issue. If the law states that a property owner is responsible for clearing walkways, then the issue becomes whether the owner was negligent. If the law states that the tenant of the property must not put snow or ice on public walkways, then the issue becomes whether a tenant piled up snow where they shouldn’t have. The issue and the rule are interwoven.

Once you understand the relevant rules, you analyze to determine whether the rule was violated. That analysis leads you to the conclusion.

Implicit in this way of thinking is that the rules are known, stable, and reliable. As we’ll see, in science, the challenge is to learn what the rules (of nature) are. In engineering, the challenge is to create the rules (or structures) that define a system.

While much of law is about following or interpreting existing rules, lawyers are also involved in designing contracts, which creates rules. Government legislatures design the overarching rules for that territory. This aspect of law is similar to engineering. These laws are social constructs, unlike the law of gravity. Crafting rules guide behaviors, ideally, to promote a stable and fair society.

As our organizations mature, processes crystalize, and we accumulate a wide range of rules. How do we get budget approved for a project? How do we report issues with the software we’re using? How do we systematically onboard new employees?

If we get an irate email from a customer, how do we respond? First we need to determine what’s the issue. Are they facing a bug in the systems we produce? Are they disappointed we’re lacking a feature? Do they have concerns about the services we’re providing? Are they just having a bad day?

Customer support teams master this kind of triage, following the rules and processes established for the team. Analyzing the issue against internal rules, they conclude with an appropriate response. From there they tap into processes for reporting bugs, adding feature requests, etc. You never knew customer support thought like lawyers, did you?

Science: Building to Learn

Scientific thinking is an entirely different form of logical analysis. The challenge in science is not to follow the rules or define the rules; the challenge is to discover them. In any truly scientific investigation, we do not know the rules in advance. To discover the rules, we use observation and inference. This contrasts strongly with the IRAC method of logical analysis.

The scientific method emphasizes intellectual humility, treating knowledge as layers of hypotheses. Accumulating new knowledge requires designing and running experiments to test new hypotheses. A hypothesis is an idea about what rules may govern a certain situation. Designing an experiment means imagining how a system would behave if a certain rule holds true. Running an experiment means carrying out a scenario to see if the results matched your expectations.

In the scientific method, you validate your mental model against observed results. If results match your expectations, it gives confidence that the hidden rules match your hypothesis.

The defining characteristic of the scientific method is building systems that enable us to learn. Learning underlying rules (while holding our knowledge of them as tentative) is the product of this exercise.

The 20th and 21st centuries have seen a dramatic increase in business and technology striving to adopt scientific thinking. The idea of data-driven organizations is to ensure that businesses are not driven by opinions, but that data is used to discover which approaches are most effective.

This may come as a surprise to IT leaders, but the most scientific department in many organizations is the marketing department.

In a world of billions of competing messages, marketing organizations are under enormous pressure to be effective. Necessity being the mother of invention, marketing teams adopt sophisticated measurement techniques, website analytics, click through rates, conversion rates and more.

Many marketing teams never launch a campaign without employing A/B testing to measure message effectiveness. Applying such techniques to software projects is still a novel concept for most teams.

Engineering: Learning to Build

The final approach to learning is through engineering. Unlike science, where you build systems to help you learn, in engineering you learn underlying rules so you can build new systems. Engineering is the practice of using science or technology to create new systems. You learn basic rules of nature, software, etc, and on that basis build systems that accomplish the results you want. Software engineering is a form of engineering where you create your own rules (programs). You craft logic for manipulating information to accomplish the output you desire. Software engineering has parallels to legal systems. Legislation is a type of engineering whereby you design laws or rules with a desired output on social behavior.

Laws define boundaries on acceptable human interactions, just as software defines rules for processing information. Courts and lawyers help ensure that human behavior follows those legal patterns, just as CPUs reference programming instructions to guide the correct retrieval, processing, storage, and display of data. One key difference is that programming is mostly about defining the rules rather than adjudicating them. Computers are more reliable than people in following rules if they’re well defined.

Another thing that sets programming apart from the legal profession (and from many other forms of engineering) is that software systems change frequently and fluidly. These changes occur in response to the changing business needs, changes in adjacent systems, and improvements to logic. It’s the role of programmers to constantly tune and perfect the logic as business processes evolve.

IT teams typically take great pride in the systems they build, seeing engineering as their core activity. But our strengths can conceal blind spots. It’s empowering, if not addictive, to feel that we have sole power to define the rules of a system. In a world where we usually feel powerless, to have the power to create provides incredible reassurance.

That opens engineers to the hubris that users should simply use the systems they build. But engineers can be so focused on creating that they neglect to explore how users actually use their system. At the same time, we are usually oblivious to our own assumptions about how a system should be used.

The User Experience (UX) movement seeks to remedy these blind spots by ensuring that we couple the design process with the exploration of user experience, something that requires a scientific mindset.

Different Situations Demand Different Approaches

Each of the three logical approaches applies in different situations. When trying to discover the underlying rules of a system, we need scientific thinking, an open-minded, iterative, and experimental approach to understand these hidden rules. Once basic rules are understood, we can use engineering to build higher-level systems. Once those systems are defined, legalistic thinking becomes most appropriate.

The Cynefin Framework

We can make sense of a situation using an approach known as the Cynefin framework. If we cannot understand a situation, it appears disordered. As our understanding grows, we can discern four types of situation: clear, complicated, complex, and chaotic. A clear system (also called "simple" or "obvious") is one in which simple rules can be applied, and there is a well-understood best practice we can employ. If you understand those best practices and follow them, you will achieve reliable results. For a simple situation, all you need to do is know the rule and follow the rule reliably to get good results.

The Cynefin Framework

A complicated system is one that may have many parts, many applicable rules, and many possible right answers. It requires careful analysis to understand the issue, applicable rules, and possible outcomes. There may not be one single best practice; rather there may be many good practices. We usually have a strong tendency to assert a known and trusted practice as a "best practice". But if a situation is complicated, it’s rare to try every alternative. It’s ignorant to project certainty where there is none. And oversimplifying a situation will often lead to poor results. It is safe to say that in a complicated situation there are never best practices: there are only good practices that might work effectively when employed in the right way.

Engineering is typically based on complicated systems. You can build systems that are highly complicated but can also be well understood. A car engine is a good example of a complicated system. Good system architecture results in relatively predictable results.
    
The third level in the Cynefin framework is complex scenarios. A complex scenario is one where you act on the situation and that, in turn, changes the situation. Interpersonal relations are an example of complex scenarios. Companies operating in a market face a complex scenario. Our bodies are complex. You cannot expect to always get the same result from performing the same action. This means that within a complex scenario we are operating in conditions of extreme uncertainty and as such, we need to take a scientific approach. We observe, then we act, then we study the results and go from there, analyzing the data to build better results. In a complex system you can identify the causes of something in retrospect, but you cannot guarantee a result in advance. Traffic in a city is a good example of a complex system.

The fourth category in the Cynefin framework is a "chaotic" situation. Chaotic situations are ones in which there are no discernible patterns to explain what caused something. This blocks us from acting in reliable ways. Many situations may appear to be chaotic initially, until we understand the rules that govern them. But even in a clear situation, if we misjudge the problem and apply the wrong rules, that situation can devolve into chaos.

Observe, Orient, Decide, Act

The OODA Framework helps knit these approaches together into a framework for action. OODA stands for Observe, Orient, Decide, Act. The framework was developed by Colonel John Boyd of the US Air Force. He was a legendary fighter pilot and developed this framework to describe how to outmaneuver opponents by understanding their biases and acting more quickly than they can respond to. His principles of energy and maneuverability guided the design of the F-16 fighter jet. This framework has been adopted across many branches of the military, and is widely influential in the business and technology world.

The OODA framework depicts how individuals and organizations constantly move from observation to action. Observation (the intake of information) feeds into orientation (a mental model of the world) to enable decisions and finally actions. Orientation is particularly complex, since it combines our cultural heritage, our genetic heritage, our understanding of rules and past experiences, and our ability to analyze and synthesize information.

Importantly, deciding is set apart from orientation and action. Whereas observation and orientation deal with gathering and organizing information, decision-making is a fundamentally emotional process. From within all the available information, we need to choose one option, based on our subjective feelings about the different possibilities.
It’s that feeling-based decision that prompts action. The strength of our actions is in proportion to the strength of our feelings, and the strength of our conviction in our logic.

As shown in the diagram below, besides the simple four-step forward progression through this loop, there is a rich set of interactions between the elements. Our orientation provides implicit guidance over what we pay attention to, and what we observe. It also implicitly guides our emotional responses (decisions) and actions.

There are also feedback loops, where our decisions and actions give us new information and provoke changes to the environment that we need to respond to. This OODA loop process is not happening in a strictly linear way. It’s a dynamic and ever changing flow from information to action, and individuals and organizations are engaged in every part of the loop.

Logic in the OODA loop  

The OODA loop provides insight into the three approaches to the logic described above.
How does legalistic thinking operate through an OODA loop? You observe to understand the issue. Moving on to the orient phase, you recall or research the appropriate rules and analyze how they apply to this specific situation. Again, the rules identified will inform your understanding of the issue and vice versa. Analyzing how the rules apply to the issue allows you to draw a conclusion: this is the decision phase. That decision is the basis for taking action.

Scientific thinking progresses in a different way. An initial observation may prompt curiosity, a wish to understand the principles that underlie a situation. Again, with science, our goal is to learn the rules that govern a system; they’re not known in advance. The orientation phase in scientific thinking combines our observations with prior knowledge, research, and reasoning (along with our own biases and assumptions). The conclusion of this reasoning process is developing a hypothesis. This hypothesis is the decision phase in the loop. From among various possible explanations, one will feel most likely. The challenge then is to design and run an experiment, which is the action phase of the loop.

A careful experiment invalidates wrong assumptions. Conducting the test or experiment changes the environment and allows us to observe what happened. If the observation confirms our hypothesis, we increase our confidence in the theory. But if the observation conflicts with our hypothesis we return to the orientation stage and adjust our hypothesis.

The main point of scientific thinking is to learn based on observation. Whereas the result of legalistic thinking is a decision, that is the starting-off point for scientific thinking. The main result of experimentation is to increase our experience and improve our ability to orient to the world.

Scientific thinking directly challenges the rules we think apply. Our goal is to constantly refine our understanding of underlying rules and adjust our mental models.
Engineering focuses on building new systems to achieve a particular goal. Observing a particular problem, we orient to imagine how we might address it. Our decision is to create something that addresses that problem, and our action is to build a solution.

Having built a (preliminary) solution, we then observe whether this has solved the problem. The new systems we build abide by new rules, and so each creative iteration requires that we re-orient to the evolving system and decide the next best step towards a solution. Engineering is a highly iterative process, with layers of adjustments being made to address shortcomings in the initial design. Each iteration of the process is a pass-through of an OODA loop.

Engineering changes the world that others live in. For example, an engineer might build a bridge, and in building that bridge, create an opportunity for people to reach the other side of a river. Creating a new structure creates a new set of rules or options for how people can move. Laws do the same.

Conclusion

Law, science, and engineering offer three distinct approaches to logical thinking. Each is important in different circumstances, and in practice, we all use all three. In well-understood domains, we address issues by recalling relevant rules, analyzing their application, and coming to a conclusion. But when we’re striving to understand a mysterious domain we need a different approach: one of probing and investigating to understand what rules govern that situation. And often we can build and create, redefining the rules of our world.

The Cynefin framework helps us to appreciate that different situations demand different approaches, and that we are often operating in poorly understood domains. In our personal relationships, our business activities, and in human social movements, we are breaking new ground. Taking an experimental approach is important in the complex world we find ourselves in.

The OODA loop provides a unifying framework for understanding how information translates to action, and action brings new information. Our challenge collectively is to always improve our understanding and ability to act for the benefit of ourselves and others. We can keep the intellectual humility of a scientist, the ethical sensibilities of a lawyer, and the creativity of an engineer to solve the most challenging problems our clients and communities face.

About the Author

Andrew Davis is a Salesforce DevOps specialist who's passionate about helping teams deliver innovation, build trust, and improve their performance. After studying engineering at Virginia Tech and Johns Hopkins he became a Buddhist monk, teaching and building meditation communities for almost 15 years. Since 2014, he's focused on the Salesforce platform as a developer, consultant, and architect. He launched Appirio's DevOps practice, and focuses on promoting modern development practices for Salesforce. He currently works as Senior Director of Product Marketing for Copado, helping people understand the importance of DevOps for scaling Salesforce implementations. He lives in San Diego with his amazing wife and very cuddly dog.