Ty Stephens
7 min readJul 23, 2022

Army Lessons Learned 4: Define the Problem. Understand the Situation.

“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it,” Albert Einstein

“Seek first to understand, and then to be understood” -Stephen Covey, 7 Habits of Highly Effective People

Photo by Towfiqu barbhuiya on Unsplash

Lesson 4 falls into the category of things that sound intuitive and common sense in theory, but are surprisingly rare to see in practice. In practice, most organizations I have worked in, even the good ones, burn a lot or organizational inertia and resources solving the wrong problems. I have seen this happen at all levels, across many teams, projects — to the point I think a lot of it is human nature. We need to “feel” busy. And often, we equate “efficiency” to “effectiveness”.

I often use the analogy of a car driving from point A to point B to illustrate this idea. Efficiency for a car would involves things like speed, horsepower, traction, having gas, having a good set of tires. These are all great things to have. But effectiveness is your direction. It’s entirely possible to by incredibly efficient at going in the wrong direction (effectiveness). It’s entirely possible to be really really good at solving the wrong problems.

To be clear, efficiency is completely irrelevant without effectiveness.

This should be intuitive to many, we’ve often heard the idiom that “sometimes less is more”. But how do we define the problem? How do we ensure we’re being effective? How do we understand the situation, and ensure we’re solving the right problem? Allow me to weigh in on those questions from a few perspectives: in general, in business, and in military operations.

In general, identifying the right problems to solve requires understanding logic. Specifically inductive vs deductive reasoning.

Source: deduction-vs-induction.png (2000×1600) (themuslimtheist.com)

The infographic above lays out the differences on a basic level. Deductive is kind of a top-down, general to specific, approach and induction is more of a bottom up, specific premise to a general conclusion, approach. But in general both require making some assumptions and testing whether those assumptions are true or not. Making good assumptions is really a cornerstone of defining problems well. Rarely do we have the luxury of knowing anything for certain. So we rely on assumptions to bridge the uncertainty. Those assumptions must be clearly identified, because assumptions have a tendency to change based on new information, and when those assumptions change, they have the ability to derail your whole theory or proposed solution. That is something you very much want to know and have clarity on. How do you make good assumptions? There are a few ways. Most simply, ask good questions: what has to be true? what has to be false? if A then B type thinking. On the complex side, you can apply statistical inference or conduct sensitivity analysis ( which is basically a fancy term for testing how much changes in your assumptions effect your outcome. In other words, we would say a sensitive model is weak compared to a model that is less sensitive — robust. A robust model would say, if we’re wrong about this, it effects the outcome very little.)

In business, it is very important to carve out some time to think about solving the right problems. “Are you Solving the Right Problem” by Dwayne Spradlin touches on how companies can improve their problem definitions. In that article Dwayne outlined some simple steps:

Establish the need for a solution. What is the basic need? Who will benefit from a solution?

Justify the need. Why should your organization attempt to solve this problem? Is it aligned with your strategy? If a solution is found, who will implement it?

Contextualize the problem. What have you and others already tried? Are there internal and external constraints to implementing a solution?

Write the problem statement. What requirements must a solution meet? What language should you use to describe the problem? How will you evaluate solutions and measure success?

In the Military, Troop Leading Procedures (TLPs), Military Decision Making Process (MDMP) assume the problem has already been largely identified by your higher headquarters. Still, part of receiving the mission is understanding how your problem helps your higher headquarters problem. But you can’t just assume everything is right and skip to mission and key tasks and get to work. When you receive a mission, you need to devote some time early on to understanding what problem you’re trying to solve — what is your higher headquarters mission and intent ( 2 levels up), what are the adjacent units doing? how does your mission fit into the larger operation? You have to build contextual understanding of your mission, and by doing that, you’re going to take your planning, recommendations, and execution to the next level.

In other words, don’t skip paragraph 1 of the OPORD. And don’t just read it, you need to map it, so you can visualize what is happening spatially and across time. What assumptions are your higher headquarters making? Are they good assumptions? What is the enemy doing? How might their actions change your assumptions? A good question to ask yourself over and over in this process is “So what?”

For tactical leaders, NCOs and Junior Officers, you need to look past fact and begin to deduce insight. “It’s going to rain during the operation”. No one cares. That’s not insightful. Ask yourself So what? “visibility is going to be reduced, and our rate of march is going to take 50% longer, and Aeromedevac is going to be a no go, so we’re going to have to ground evac if we take casualties” That is insight. See how it differs from merely stating fact? You are combining fact (“it’s going to rain”) with assumptions about how that fact might effect your operation. To do that, you need to understand the situation, and that doesn’t mean just memorizing facts — it means applying your brain to deduce how those facts might influence, positively or negatively, your mission.

At more senior levels, you don’t always have the luxury of getting an OPORD with all the answers in it. You might be trying to solve problems that haven’t been solved before, trying to define problems is more important for you. Army Design Methodology can be a great tool for this, because it provides a framework to think deeply about problems by trying to understand your current situation and think through your desired end state.

You can also pull a lot of wisdom from cross-domain applications — data science, A/B testing in Marketing, how pharmaceutical R&D conducts clinical trials, statistics, game theory, legal litigation strategy (specifically cross-examination strategy),all provide some relevant techniques that can be adapted to better help define problems and understand a situation. The frameworks are very similar.

At more senior levels, and when complexity and uncertainty about problems is inevitably higher, it is more important to test your assumptions. You can accomplish this through war gaming, red teaming, statistically, or through various forms of intelligence to confirm or deny your most important assumptions. Increasingly, artificial intelligence and machine learning make this level of analysis more attainable and computationally cheaper than ever before. You intelligence folks should be helping leverage some of those tools to help decision makers craft, test, and revise important assumptions about their problem.

But to truly craft good problems requires a team effort, across various staffs, a varying levels of subject matter expertise, and occupational specialties. It is important that problems can be viewed from as many perspectives as possible. But also important you don’t get “sucked in” to confirmation bias — in other words, becoming a solution in search of a problem. Red teaming can be an important part of avoiding this trap. And when you think you have a problem, ask the group to punch holes in it, as best they can. Avoid becoming emotionally invested in a certain problem or solution.

An example of Army Design Methodology Source: Why Non-U.S. Militaries Should Adopt the U.S. Army Design Methodology by Jean Dagher

You could write a book on this topic, and admittedly, I am hitting wave tops here. But my most important take away is this: avoid the tendency to jump right in and start building solutions. Slow down. Take a step back. And devote some capacity to ensuring you are solving the right problem first. You WILL be more effective and it will save you from wasting needless time and resources pursuing dead ends.

Deeper Dive Recommended Reading:

Red Team: How to Succeed by Thinking Like the Enemy by Micah Zenko

Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts- Annie Duke

Anti-fragile: Things that Gain from Disorder- Nassim Nicholas Taleb

Are You Solving the Right Problem by Dwayne Spradlin (Harvard Business Review)

Thinking Fast and Slow — Daniel Kahneman

Being Logical: A Guide to Good Thinking- Dennis Q McInerny

The Battle Staff SMARTbook, 6th ed. — Norman M. Wade

The 7 Habits of Highly Effective People — Stephen R. Covey

Thinking in Systems: A Primer — Donella H. Meadows

How to Do Strategic Planning Like a Futurist by Amy Webb

The Most Powerful Idea in Data Science — Cassie Kozyrkov