Loading articles…
Field notes for building a business that can move without you.
We write from the intersection of operating systems, software, sales, marketing, and leadership—for owners building a more capable company.
Article
The Best Improvement Is Sometimes the One You Don’t Build
More complexity isn’t always more progress. Before adding a safeguard, measure the problem, understand the trade-off, and make the simplest decision that protects the work.
- Author
Everett Bellingham- Published
- Reading time
- 6 min read
Contents
A business needs its systems to keep the work moving, even when something goes wrong. But protecting the work does not mean eliminating every possible delay at any cost.
This week, our team faced a decision about a process we use when moving a business’s information into a new system. We could build a more elaborate safeguard to reduce how much work might need to be repeated after an interruption. The design was thoughtful. It addressed a real concern.
After looking at the numbers, I decided we should not build it.
That might sound like an odd way to improve a system. But sometimes the best decision is to understand what a problem actually costs before adding more machinery to solve it.
The problem we were trying to solve
When we move a business’s information, we want the work to survive interruptions. A long-running process should not have to begin again simply because a worker stops or a system is updated.
We are working on making the different stages of that process more resilient. Some stages involve substantial amounts of work, so it makes sense to save progress along the way. If one of those stages is interrupted, the aim is to pick up from a useful point instead of repeating everything.
One part of the process checks the information we captured and reconciles what we found. The original plan was to break that check into smaller pieces too. On paper, that would reduce the amount of checking we might repeat after an interruption.
That is a reasonable goal. But the proposed design became complicated because the check needs to consider how information relates across the whole account. It was not simply a matter of slicing a list into smaller lists. The pieces would need to be brought back together correctly, and the new approach would introduce more work of its own.
Before we committed to building it, we looked at the cost.
A few minutes, or a much bigger system
In one large ClickUp capture, the existing verification took five minutes and 45 seconds. If that stage were interrupted, repeating it would cost roughly six minutes for that capture.
The proposed alternative was designed to make the check recover in smaller pieces. But it would also add substantial complexity, and the team forecast that the redesigned check could take three to twelve hours on an account ten times larger. For comparison, a simple linear projection of the existing check at that larger size was roughly an hour.
Those numbers are not a promise of how either approach will perform for every account, but they were enough to show us the trade-off we needed to examine: we could introduce a more complicated process, potentially making the check itself much slower, to avoid repeating a relatively short stage if an interruption happened.
So we kept that check as one stage. We recorded the decision, the measured cost, and the reason for accepting it. If a future run shows that the repeat time has become material, we can revisit it with better evidence.
We did not decide that interruptions no longer matter. We decided that this particular safeguard did not yet earn its cost.
Not every risk deserves the same solution
The key distinction is that we are still investing in recovery where the repeated work is substantial. The decision to leave one short check whole is an exception to the broader work, not a reason to skip that work altogether.
A six-minute repeat is not the same thing as losing hours of progress. It is also not the same as losing or corrupting a customer’s information. The right response depends on the consequence, not just on whether a failure is technically possible.
That distinction matters outside software too.
A team might notice that preparing a report takes ten minutes each week and consider building an automated workflow. Automation may be worthwhile, especially if the task is frequent, error-prone, or holds up other people. But before changing the process, it is worth measuring how often the problem occurs, what it costs, and what the new workflow will need to maintain. Ten minutes may be worth removing—or the team may have a more important bottleneck to address first.
The same applies to business tools. A new platform, integration, or dashboard can be the right investment. It can also add another place to configure, another connection to maintain, and another process for the team to learn. If we do not know which outcome we are trying to improve, those additions can feel like progress while making the work harder to carry forward.
Measure the cost on both sides
It is easy to ask what a solution will save. It is just as important to ask what it will introduce.
Before making a change, I find these questions useful:
- What outcome are we protecting or improving? Name the work that needs to happen and who depends on it.
- What happens today when the problem occurs? Measure the delay, repeated work, errors, or impact on the people involved. Be clear about what is measured and what is estimated.
- What would the proposed change cost? Consider not only the work to build it, but also whether it makes normal operation slower, adds new failure points, or creates an ongoing maintenance burden.
- Is there a simpler acceptable option? A short repeat, a manual review, or keeping an existing tool may be reasonable for now. That does not make it the right answer forever.
- What would make us revisit the decision? Write down the trade-off and look again if the real cost changes or a new requirement emerges.
This does not mean waiting for perfect data. Sometimes the consequence is serious enough that action cannot wait for a complete measurement. But even then, being explicit about what we know and what we are assuming helps us choose—and gives us something to check later.
Simpler does not mean careless
I like building things. When there is a difficult problem in front of us, a more capable design can be satisfying. But the business relying on the system does not benefit from complexity simply because the design is impressive.
It benefits when the work is dependable, the people responsible for it understand the trade-offs, and the system can change when the evidence says it needs to.
That is the standard I want us to apply as we build and implement Accelerator OS. Start with what the business needs to accomplish. Measure the part that is getting in the way. Then make the smallest change that protects the outcome—and keep the decision visible enough to revisit.
Sometimes that means building a better safeguard. Sometimes it means leaving a six-minute check alone and spending that effort where it will make a greater difference.
