Being Strategic - How to Analyze Problems
Learn how to problem-solve strategically.
“You need to be more strategic”.
It’s a phrase a lot of people hear as they aim to grow from middle management into the executive realm.
Not many people can really define it, though. Even the people giving this feedback have a difficult time.
Is it some magic “X” factor? Some “you either have it or you don’t” talent?
The truth is, being strategic can be taught and learned. It requires learning new ways of approaching problems, changing your mindset, and a bit of unlearning of the things that got us to where we are now. It requires picking up a few hard-skills and learning some very hard soft-skills.
Whether it’s analyzing problems, speaking the language of the business, or improving your bearing - the skills of being strategic can be taught.
From tactical to strategic problem solving
When many non-strategic people encounter a problem, they dive head first into solutions. While this might solve the particular problem, it isn’t necessarily the strategic choice.
Being strategic means resisting the impulse to act immediately and instead stepping back to analyze the problem more deeply. It requires applying first-principles and frameworks to analyze problems, not just in isolation, but also in terms of its broader ripple effects - both positive and negative.
If you don’t, you’re prone to make localized decisions that fail to improve the system overall. Local decision making that only targets “first-order effects” is one of the reasons why people gain the reputation of needing to be “more strategic”. These short-term solutions create downstream consequences that worsen problems or introduce new issues entirely.
Being strategic requires shifting from reactionary fixes to holistic, systems-level thinking—a skill that can be learned and refined - beginning with structured problem analysis.
How to Analyze Problems
Analyzing a problem effectively ensures you have answers to these questions at the end of the thinking process:
Do you know what the problem is? Sometimes, you hear about symptoms rather than the actual problem. You have to dig in to identify the problem itself.
Is the problem actually a problem? Sometimes you’re not presented with a problem, but a perceived problem. It’s important to validate whether it’s actually a problem, or whether taking action would result in over-indexing on what’s ultimately a non-issue.
Is the problem worth keeping? Sometimes, you keep a problem with negative effects because it has some positive effects.
Is the problem worth solving? Not all problems are worth solving. Some will cost too much relative to the benefit. A process that wastes 5 minutes a month that would take 2 dev-days to solve would take hundreds of months to show a return. Remember that an irritation isn’t necessarily a problem - don’t conflate the two.
Is the problem worth solving right now? Sometimes, a problem is a problem, but the timing isn’t right. There’s a temptation to solve all problems as soon as they are discovered, but one has to keep track of appropriate timing, ensuring capacity, cognitive load, and operational sequencing all have due consideration applied.
What’s contributing to the problem? You need to identify factors that contribute to the problem explicitly in order to find possible solutions that impact those factors. It’s tempting to try to attribute everything to a singular “root cause”, but problems you encounter may have dozens or hundreds of factors - your frame may lead to blind spots that cause you to gloss over impactful options.
What levers can you pull to solve the problem? Once you’ve answered the above, it’s really a matter of “what should you do to solve the problem”. In order to actually decide, you first need to understand what levers are available to you.
Deciding on and implementing the solutions. Once you understand your problem, have your options - the rest is just execution.
Do you know what the problem is?
Oftentimes, when you hear about a problem, what you’re hearing about is a symptom: the pain that is being felt.
Reporters often report issues from the perspective of the pain they are feeling - an issue is wasting time, or demoralizing the team, or harming productivity.
Tactical people jump in immediately - they jump to solutions to increase efficiency, or motivate the team, or improve productivity.
Strategic people do not confuse the effect of a problem from the problem itself.
You need to understand the problem, not the effect. Ask questions:
Why does the person telling you about the problem care?
What other effects have they experienced?
What did they experience?
What did they perceive?
Dig until you have a good understanding of the boundaries of the problem and some of the contributors, at least from the perspective of the person reporting it.
An engineering manager once brought me an urgent problem - there were too many unreviewed PRs. She started rattling off a list of interventions she wanted to make to resolve the problem, from being more stringent about closing PRs to recommending a freeze on new work to implementation of automations and reminders for stale PRs.
I had her pause and take a step back.
It turned out the unreviewed PR count was about average, and there wasn’t a bottleneck in our delivery pipeline. These weren’t the real reasons why this was a problem.
After some digging, it turns out the manager had an upcoming deadline she had made public commitments towards and that she had scheduled vacations inefficiently, resulting in multiple team members being out of office.
Her problem wasn’t that PRs were unreviewed - this was just an effect. Her problem was ultimately poor planning, and her fear that she was going to be responsible for harm to her reputation drove her decision-making.
I had her go back and instead talk with her stakeholders to negotiate a new timeline. It turns out the stakeholders were more than happy to shift the deadline a couple of weeks and it actually worked more favorably for their go-to-market announcement timeline.
Her reputation was preserved and a lot of ultimately unnecessary process change avoided.
Is the problem actually a problem?
When someone presents a problem, there’s an implicit assumption that the problem is indeed an issue and thus needs to be addressed and remediated.
That’s not entirely true. Validate this assumption, and ask yourself:
Why is this issue bad?
To what extent is it bad?
Does it apply to all instances of the problem, or are there specific characteristics?
Wasting time in trying to solve a problem that’s not actually a real problem can distract from solving the real problems.
Why is this bad?
If you ask the question “why is it bad” and all you get is an amorphous trueism of “because it’s bad”, then that means you may be dealing with a perception issue rather than actual problem.
Real problems have negative effects attached to it. Perceived problems can be solved with just a mindset change.
To what extent is it bad?
This is where you can start pulling in data to validate your assumptions. If someone claims a negative effect, you should quantify it by examining the length of time the negative effect remains, frequency of occurrence, and even the dollar cost of remediation. This will ultimately give you a quantifiable impact you can us to make decisions.
It’s much easier to discuss about a problem that “costs the company $100,000 a year” vs. a problem that “takes a while to solve every year”.
Does it apply to all instances of the problem, or are there specific characteristics?
Once you have data, you can start seeing if there are patterns in characteristics of the problem or how the problem presents itself.
Find out if there’s any commonality or segmentation in the problem. Perhaps you’ll find the problems are coming for a particular source, for a particular time period, is only being experienced for a particular group, or some other factor.
Make sure you have a list of the characteristics. You may end up over-scoping your problem-solving, applying solutions to groups that aren’t even experiencing the problem, or making a mountain out of what ends up being a molehill.
Some of the engineers came to me, frustrated about configuration management.
They proposed purchasing and implementing a configuration management system to automatically notify and update the configuration when it changed. It would’ve taken several weeks and cost over $10,000 to implement.
I dug in deeper. What configurations were changing and getting out of sync? Why wasn’t the current process effectively catching it? What was the negative impact when it didn’t catch it?
It turned out that there was only one configuration in particular that one engineer was experiencing issues with. Our platform connected to a particular third-party system with a manual configuration that failed to automatically update when regular rotations would occur, and it just wasn’t compatible with the rest of the configuration management, which was reliable and automated. The engineer had rallied some other engineers into support a wholesale change of the entirety of configuration management all over this one issue.
I looked into the data further for that particular case. The issue they were concerned about occurred just 4 times in a year, and each time it took about 5 minutes for the engineer to resolve.
They were attempting to solve a $100 problem by spending $10,000. Instead, I had them document the solution steps and share it out so that it was not entirely dependent on them to know how to do - this alleviated their frustration as they were not the only individual who was able to resolve the issue.
The problem just wasn’t worth fixing.
Is the problem worth keeping?
Counter-intuitively, you don’t actually want to solve all problems, even if you can. Sometimes you intentionally take a negative effect to realize a positive benefit elsewhere.
Yes, negative things can have positive effects.
For example, if a team complains about the time it takes to test their features themselves, you may think that problem needs to be solved, possibly by hiring people dedicated to QA. However, having the team member testing features they wrote themselves may have benefits like promoting increased ownership or improving knowledge share in the team. There’s benefits to the problem being complained about, and you don’t want to throw the baby out with the bathwater.
That’s not to say benefits can’t be realized in alternate ways. The important part is to recognize that a non-obvious benefit may exist so that when you evaluate problems and solutions you can ensure that the potential benefit of the problem itself are considered.
Chesterton’s Fence
There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
Is the problem worth solving?
Even if you identify a problem and validate it’s actually a problem, with real data - you still need to figure out if it’s worth solving.
People have a hard time recognizing this, but there’s an acceptable level of “badness” for most problems. There’s probably a threshold or frequency at which it becomes not worth it to solve the problem because its occurrence is so rare, or the frequency not representative of most cases.
If it turns out a problem only occurs once a year an causes a large negative effect, it may not be worth fixing if averaged across a year. A problem that causes tiny negative effects that occurs daily may still be worthwhile to resolve immediately just because of the frequency at which it occurs. This depends ultimately on the frequency of the problem and the negative effects it causes.
The value of reaching “zero badness” is often exponentially higher than reaching “low badness” and not worth the cost.
A classic example of “low badness” is that of Uptime.
Most companies would love to have 100% annual uptime, but the cost of achieving uptime increases exponentially with every 9 you add.
99% uptime is 5,256 minutes of downtime a year (3.65 days)
99.9% annual uptime is 526 minutes of downtime a year (8.77 hours)
99.99% annual uptime is 52.6 minutes of downtime a year
99.999% annual uptime is 5.26 minutes of downtime a year.
Going from 99.9% to 99.99% uptime could mean a couple hundred thousand dollars invested into improved testing and a slight slowdown in delivery to reinforce quality.
However, going from 99.99% to 99.999% uptime could mean tens of millions of dollars on operations head-count, infrastructure tooling, redundancy, personnel retraining, and process changes.
Whether avoiding that extra 48 minutes of downtime is worth it or not depends on a lot of factors, such as contractual SLAs, reputational damage, mission-criticality. If a minute of downtime costs 10 million dollars in SLA penalties, it might be worth it. However, if your SLAs are only 99%, you may be completely fine with a few hours of downtime a year.
It all depends.
Is the problem worth solving right now?
You don’t have unlimited resources. Part of thinking strategically is deciding how much to invest in solving specific problems.
Prioritization frameworks like the Eisenhower matrix (Urgent/Important) can help identify which ones are truly worth solving now.
Even if you do identify a problem worth solving now, you have to then put it in the context of your resourcing and capacity. You need people to implement the solution, and if they are already working on ten other things, you may end up creating another problem through attempting to solve that problem at the wrong time.
Even if you have people who can be dedicated to implementing the solution, you still have to look at the history of how your organization has changed. The truth is, organizations only have a limited rate at which they can absorb change. Over-activity creates an environment of churn and instability, which affects performance, morale, and retention. When you solve a problem by making a change, factor in the rate at which the organization can absorb all changes in the timing of solving the problem.
Many problems can wait and be delayed. You don’t need to do everything or solve every problem you know about immediately - otherwise it distracts from other, more important efforts. Even exploring potential solutions can be a waste of time for problems that might be minimal.
After all - if you try to chase two rabbits, you won’t catch either one.
What’s contributing to the problem?
There’s rarely a particular singular “root cause” to a problem. New leaders often attempt to boil everything down to a singular “root” cause. If only that cause could be resolved, then the whole issue would be fixed.
This is dangerous for many reasons - silver bullets are rare, especially at decisions made at the strategic level. While some problems luckily do have one or two dominant contributors, most issues executives face are systemic in nature with a complex web of contributing factors. Otherwise, why would you be wasting time on a straightforward problem with such a obvious solution?
Additionally, what you define as the “root cause” is going to depend entirely on how you frame things, which is prone to significant amounts of mental biases that lead you off track or hide the true solutions.
You frame is your particular perspective you are adopting when you are examining a problem. The frame dictates what factors or causes you identify, what causes you attribute effects to, what benefits or costs you recognize are important or not, and ultimately what solutions you reach for to solve the problem.
For example, if your framing is people, you’ll naturally reach for rationale where the root cause and solutions are people-oriented. A problem exists because people aren’t doing their job, or they aren’t competent, or they have bad mindsets or poor habits.
Maybe you view problems from the frame of culture. Now, issues are caused because of the environment - maybe people are fearful to make mistakes, or afraid to step on toes, or have too much to do.
If your framing is technical, you’ll naturally reach for causes that involve technical controls - there’s not enough automation, or the validation is incorrect, or the tests weren’t comprehensive enough.
There’s many possible frames, all borne from experience, education, mindset that lead to a person’s unique perspective. People, culture, process, technology, systems, environment, market - the frame you use has a massive impact on what problems factors you are able to identify.
If you only analyze a problem with one or two frames, then you’re very limited in your ability to ultimately solve that problem. You may not even think to address the most impactful causes of an issue. This is where including people with other frames can be useful, and educating yourself on how to think about the same problem through multiple lens. The more frames you have, the larger your palette of options for addressing a problem.
What lever should you pull to solve the problem?
Your solution levers are also dictated by your framing.
If your framing is people, then your solutions tend target people as the lever, and will aim towards things like improving training, punishing non-compliance, increasing hiring standards, etc.
If it’s cultural, your solutions might be to ensure people feel safe to learn, giving avenues to communicate, or better clarifying priorities.
Technical? You’ll implement automation, technical controls, notifications, code-quality improvements, etc.
The fact is - whatever lever you do reach for needs to also be viewed from multiple frames.
Using multiple frames requires intentionality to adjust, especially frames that are outside your “default mode”. It’s a superpower if you can do it, but most people don’t even think about it. They usually go with their default frame, whether it’s people, process, culture, systems, market, environment, etc.
Our revenue growth was off track.
The new CRO had pulled me aside while I was walking past his office. We weren’t meeting board expectations of growth, and he could feel the guillotine hanging above his head.
Coming from a sales frame, he proposed investing significant amounts in outbound sales and wanted a product initiative around optimizing for and supporting rapid, at-scale onboarding.
I knew from the data that wouldn’t work. We already had saturated many of our markets, and adding additional sales resources to an already crowded environment wouldn’t lead to increased acquisition at the levels he needed.
Our acquisition rate and onboarding speeds were also already quite good. Even a 10% improvement would have only nominal effects on the growth rate.
Coming from an enterprise frame, I saw our challenge was actually churn - we were losing customers year-over-year at about the same rate we were acquiring them, thanks to a product that wasn’t built with any capabilities that kept people coming back year-over-year nor did it give them any long-term capabilities. It was a leaky bucket that was already full, and no amount of adding to the top would solve our problem.
I instead proposed and later spearheaded product capabilities to support year-over-year needs alongside improved customer success and account management. It worked effectively in restoring revenue growth to desired levels.
Deciding on and implementing the solution(s)
Once you’ve identified a problem and its solutions - the rest is actually quite simple.
At this stage, it’s no longer about identifying the right solution, but about selecting the best solution set given your constraints.
This is classic tactical execution.
Apply your most applicable prioritization and evaluation frameworks - RICE, MoSCoW, Kano. Decide on a set of solutions that fit within your constraints and prioritize the tradeoffs that matter to you, whether that’s cost, effort, time horizon, or impact.
At this point, the conversation shifts from strategy to execution - logistical, operational, and tactical. While the “how” is still important, it an article entirely of its own.
Problems cannot be viewed in isolation.
One important note - when you’re thinking strategically, you need to think not just about the particular problem in isolation, but also thinking about the landscape of problems you have or face.
Problems (and their solutions) are all part of a system of cause and effect. You don’t just have one problem to solve or a single solution to implement, you have an entire portfolio that ultimately has an effect on each other. It’s all a part of a system.
Some of these systems are virtuous - by solving a particular problem or implementing a solution, it makes everything better in a repeating manner. Compounding interest is an example. A small amount can balloon over time as the amount that’s considered passively gets larger and larger.
Some of these systems are death-spirals - every time a problem occurs, it makes going through the cycle more difficult. An example would be bank overdraft fees, taking even more money from people who already don’t have enough.
Thinking through these requires deeply analyzing the problem using techniques like those listed here and understanding their effects - not just the first-order effects, but second-order, third-order as well.
What are the effects of the effects of the effects?
Some parting advice
Your environment is also going to dictate what solutions are feasible, even if they are impactful.
The speed and scope of adjustments you make depends on how much time you have to solve the problem and the number of attempts you have.
If you have a high-trust, adaptable team, you may be able to try hundreds of minor adjustments. If you have a low-trust team, you may only get one or two shots before the team refuses to implement new changes. If you’re in a crisis mode, you may only have mere hours or days to implement a change before the opportunity goes away.
The time horizon really matters. Ensure you’re applying the right solution to the right time horizon. Many leaders I’ve see apply a long-term lens to a short-term problem, or a short-term problem to a long-term issue.
Some people have done the thinking for you - you’ll quickly realize who brings up problems off the cuff and who brings up problems only after they’ve thought more about it than you ever will. Trust the ones that have done more thinking than you have.
Being strategic means improving the system, and that means being willing to take the personal negative hits if it makes the system better.