Starting With The Actual Method Before Anything Else
John Adair's approach to decision making and problem solving is built around a sequence of steps that most leaders skip over in practice because they're too busy putting out fires. The method itself is fairly mechanical, which is both its strength and its weakness. You define the problem. You identify the boundary conditions. You break the problem into parts. You generate alternatives. You choose. You act. You review. That's the skeleton. What makes it useful is how Adair ties it to his broader Action-Centred Leadership model, where every decision has to account for three simultaneous needs: the task at hand, the team that executes it, and the individual people involved. Here's what the seven steps actually look like when you apply them, not just read about them. Step one: Define the problem. This is where nearly everyone fails. Adair insists you write the problem as clearly as possible before you do anything else. Not a vague complaint about something being wrong. A precise statement. "Production line B is running at 60% capacity" is better than "we have efficiency issues." The difference matters because it determines every step that follows. I once spent three weeks trying to solve a staffing shortage on a shift that turned out not to be a staffing problem at all. The real issue was a calibration tool that had drifted out of spec six months prior, causing defective output that workers kept reworking. We were hiring people to fix a machine problem. Writing the problem statement first would have saved us three weeks and four temp-hire contracts.
Step two: Identify the boundary conditions. These are the constraints that any solution must satisfy. Budget. Timeline. Regulatory requirements. Available personnel. Adair treats these as non-negotiable filters. A solution that works beautifully but costs twice your budget isn't a solution, it's a fantasy. Most people skip this step because they want to explore options freely. They shouldn't. Getting the boundary conditions wrong means you'll evaluate the wrong solutions against each other. Step three: Break the problem into manageable parts. This is decomposition. Take the defined problem and split it into components. In Adair's framework, you specifically look at how each part affects the task, the team, and the individual. A breakdown that only addresses the technical side of a problem will usually fail because it ignores the human side. I learned this the hard way on a project where we optimized a workflow for speed but made it so rigid that three people quit within six weeks. The task was solved. The team and individual circles were neglected. The solution collapsed. Step four: Generate possible solutions. Brainstorming, but with a filter. Adair doesn't recommend wild creative sessions. He recommends generating alternatives that actually satisfy your boundary conditions from step two. Quantity matters less than relevance. You're looking for three to five viable options, not twenty ideas that sound good but can't work within your constraints.
Step five: Choose the best solution. Evaluate each option against the boundary conditions and the three-circle model. Which one best serves the task without breaking the team or burning out individuals? There's rarely a perfect answer. You're usually choosing between options that each have a different set of trade-offs. Adair is clear about this: good leadership decisions are almost never optimal decisions. They're acceptable decisions made with clear awareness of what you're sacrificing. Step six: Act on the decision. This is where Adair's action-centred philosophy becomes most visible. A decision without action is just an opinion. He emphasizes that the leader must ensure the decision is communicated clearly to everyone affected, that responsibilities are assigned, and that the timing is right. Rushing implementation because you're impatient with deliberation is a common mistake. So is delaying action because you're waiting for perfect information, which never arrives. Step seven: Review the outcome. Did it work? What changed? What didn't? Adair builds feedback loops into the process deliberately. The review step isn't an afterthought, it feeds back into step one for whatever problem emerges next. This is also where most organizations drop the ball. They implement and move on without closing the loop.
Get the Full Details
How It Actually Feels In Practice
The model sounds clean on paper. In reality, it's messy because people and problems don't respect step boundaries. You'll often find yourself jumping between steps, going back to redefine the problem after you've already generated solutions, or realizing your boundary conditions were wrong mid-implementation. That's normal. Adair's framework isn't a rigid procedure, it's a checklist for a process that's inherently iterative. One thing beginners miss: Adair's model assumes the leader has enough authority and information to actually make decisions. In matrix organizations, startup environments, or any situation where decision rights are unclear, the framework breaks down. You can follow all seven steps perfectly and still be unable to act because someone else controls the budget, the timeline, or the headcount. I encountered this on a cross-functional initiative where my team owned the work but a separate department controlled the tools we needed. We did the analysis, identified the constraints, chose the best option, and then hit a wall. The workaround was straightforward but annoying: I mapped out which boundary conditions were hard constraints versus soft ones, identified which department held each hard constraint, and went directly to their decision-makers with a focused ask rather than waiting for permission through layers of management. It took two meetings instead of eight. Adair would probably approve of that as pragmatic leadership, though he'd also say the real problem was poor role clarity upstream.
Common Pitfalls That Have Nothing To Do With The Model Itself
The biggest failure point isn't the seven steps, it's the problem definition. Adair himself noted that a problem well stated is half solved. The other half is still hard. People tend to define problems at the symptom level rather than the cause level. "Customer complaints are up" is a symptom. "Our onboarding process creates confusion that leads to incorrect product configuration, which generates support tickets" is a problem statement. The first one sends you down a customer service training path. The second one sends you to the onboarding workflow. Different solutions, different results. Another pitfall: treating the three circles as equally weighted at all times. They're not. During a crisis, the task circle dominates. During a restructuring, the team circle matters more. Adair doesn't explicitly rank them, but his examples make it clear that effective leaders shift emphasis depending on the situation. Rigidly applying equal weight to all three in every scenario leads to paralysis. You end up trying to please everyone and satisfying no one. There's also the delegation trap. Adair is a strong advocate for delegating authority, not just tasks. But he recognizes that many leaders say they delegate while actually micro-managing the execution. If you follow the seven steps yourself and then don't trust anyone else to carry out the chosen solution, you've undermined the whole process. The review step becomes meaningless because you've created a dependency on your own involvement rather than building team capability.
Where The Model Falls Short
Adair's framework works best in structured environments with clear authority lines and stable enough conditions that you can reasonably define problems and test solutions. It struggles in highly ambiguous situations where the problem keeps shifting, where boundary conditions are unknown, or where you're dealing with complex adaptive systems rather than straightforward causal problems. In those cases, the seven-step approach can give a false sense of control. You'll go through the motions and feel productive while the actual situation evolves past your analysis. For those scenarios, a more exploratory approach like agile decision-making or Cynefin-based sense-making tends to work better. You iterate faster, test smaller, and adjust continuously rather than trying to get the definition right before acting. Adair's model isn't wrong, it's just optimized for a different kind of problem. Using it for everything is like using a wrench for every fastener, it'll get the job done but you'll break some things along the way. The practical takeaway is straightforward: learn the seven steps, internalize the three-circle model, apply them rigorously when the situation calls for it, and recognize honestly when you're in territory where the framework doesn't fit well enough to be useful.
