MENU

Chapter 15

What to Fix First (And What to Ignore)

If you looked honestly at where work gets stuck, where information gets lost, and where decisions pile up, you probably identified more issues than you can address at once. This is normal. Not everything that could be fixed needs to be fixed. Not everything that needs fixing needs to be fixed now. The skill is knowing where to focus limited time and energy for the greatest effect.

The Instinct to Fix Everything

When problems become visible, the natural response is to want to fix them all. Each issue, now that you can see it, feels urgent. The accumulated weight of unaddressed problems creates pressure to act comprehensively.

This instinct is counterproductive. Trying to fix everything at once typically results in fixing nothing well. Energy is scattered. Projects compete for attention. Half-finished improvements create their own problems. You, likely already the constraint, become even more overloaded trying to manage multiple change initiatives simultaneously.

Restraint is a skill. It requires accepting that some problems will persist while others are addressed, tolerating imperfection in areas that are not the current priority, and resisting the urge to start new improvements before existing ones are complete. This is difficult, but it is necessary for making actual progress.

High-Leverage Interventions

Some improvements have more impact than others. A high-leverage intervention is one where a relatively small change produces a disproportionately large benefit. These are the improvements to prioritize.

High-leverage interventions typically share certain characteristics. They address constraints that limit overall capacity, not just individual inefficiencies. They reduce dependency on specific people, especially the owner. They eliminate recurring problems rather than addressing symptoms. They make future improvements easier rather than harder.

The diagnostic questions from the previous chapter can help identify high-leverage opportunities. Where does work get stuck? The constraint that limits flow is often a high-leverage target. What depends on one person? Reducing that dependency frees capacity and reduces risk. Where does information get lost? Fixing this often resolves multiple downstream problems at once.

Not every problem that seems urgent is high-leverage. A frustrating daily annoyance may consume attention without actually limiting what the business can accomplish. A dramatic failure may be less important than a quiet inefficiency that affects everything. The question is not “what bothers me most?” but “what is actually limiting the business?”

What Does Not Matter Yet

Some problems are not worth solving at your current stage. This is difficult to accept, but resources are finite, and problems that do not significantly affect the business today should not consume resources that could address problems that do.

Problems that often do not matter yet include: edge cases that occur rarely, inefficiencies in processes that are not currently limiting output, features that would be nice but are not necessary, and improvements that would matter at a larger scale but provide little benefit at your current size.

The test is impact. If solving this problem would not meaningfully change how the business operates, it can wait. If the business could grow significantly without solving this problem, it can wait. If the time spent solving this problem would be better spent elsewhere, it can wait.

This is not the same as ignoring problems permanently. It is sequencing. Some problems become worth solving as the business grows or as other issues are resolved. The goal is to focus current effort where it will have the most effect.

Avoiding Over-Engineering

A related trap is building solutions that exceed the actual need. Over-engineering happens when the solution is designed for problems that do not yet exist, for scale that has not yet been reached, or for sophistication that the situation does not require.

Over-engineering is appealing because it feels like good planning. Building for the future seems responsible. Creating a comprehensive solution seems thorough. But over-engineering has costs: more time to build, more complexity to maintain, and more difficulty to change when circumstances evolve differently than anticipated.

The principle that constraints should shape design applies here. Over-engineering violates that principle by designing for constraints that are not present. A system that is perfect for a business twice your size may be unnecessarily complex for the business you actually have. A process that handles every possible exception may be harder to use than one that handles the common cases well and relies on human judgment for the rest.

The right solution is the simplest one that addresses the actual problem. If the problem grows, the solution can be extended. If circumstances change, a simple solution is easier to adapt than a complex one. Good enough today, with room to evolve, beats perfect for a future that may never arrive.

Starting Points

Given these principles, where should you start? The answer depends on your specific situation, but some general guidance applies.

Start with the constraint. If one bottleneck limits what the business can accomplish, addressing that bottleneck will have more impact than improving anything else. Effort at non-constraints does not improve overall flow. Find the constraint and focus there.

Start with your own dependency. If you are the person through whom everything flows, reducing that dependency creates capacity for everything else. It also reduces risk and improves quality of life. The first three diagnostic questions often lead back to the fourth: what depends on one person?

Start with something completable. A small improvement that gets finished is more valuable than a large improvement that stalls. Success builds momentum. Completing one project creates confidence and capacity for the next. If the highest-leverage opportunity is too large to complete in a reasonable timeframe, find a smaller piece of it that can be finished.

Start with what is already painful. Motivation matters. An improvement that relieves daily frustration will be pursued more vigorously than one that addresses an abstract inefficiency. When choosing among roughly equal priorities, pick the one that people will be glad to see fixed.

Prioritization Is Ongoing

Prioritization is a practice, not a one-time decision. As problems are resolved, new ones become visible. As the business grows, what matters changes. The diagnostic framework and the prioritization principles in this chapter can be applied repeatedly as circumstances evolve.

At some point, you may need help. The problems you have identified may exceed what you can address alone, or they may require expertise you do not have. The next chapter addresses how to work with outside help effectively—and how to avoid the common pitfalls that make outside help more costly than it should be.

About the Author

Alison Stoughton

Alison Stoughton

Founder & Lead Software Engineer, Stratelios

Alison is a software engineer and small business advocate who has spent over a decade building operational systems for growing companies across Kansas and Missouri. She founded Stratelios to give small businesses access to enterprise-quality technology through a direct, long-term partnership model.

Learn more about Alison →

Ready to Transform Your Business?

There are a number of ways to get in touch with us. Feel free to connect in whatever way you find most convenient.

Get in Touch

Contact Form

Call or Text

Slack

Slack

Slack Connect DM: alison@stratelios.com Open Slack

Google Chat

Google Chat DM: alison@stratelios.com Open Google Chat