These 3 Rules Help Me Solved Several Problems, And It Could Help You Too.

I often share three important rules with my teams, repeating them multiple times a week to help solve problems. Each rule may sound simple at first, but when you delve deeper into what they entail, you’ll discover they often go against common intuition and require active effort. However, based on my experience, following these rules can make it possible to solve even the most challenging problems.

Here are the three rules, ranked by their level of importance:

1. Before you start, determine your destination and plan how to get there.
2. Embrace the problems you’re tackling rather than becoming attached to specific solutions you’ve created. The former lasts, while the latter is temporary.
3. If a technology seems indistinguishable from magic, it’s a sign that it’s advanced enough.

I’ll provide a brief explanation of each rule along with a story about fencing to illustrate why I chose these particular rules.

Also read: Why We Should Stop Worrying About What Others Think? How to Stop Caring About What Others Think?

The First Rule: Plan Your Way to Get to Your Destination

If there’s one thing you should remember from this essay, make it this: I’ve discovered that it’s absolutely crucial for effective problem-solving. While it might seem simple, following it can be surprisingly tough.

Here it is: First, figure out where you want to go, and then figure out how to get there.

Now, the key word here is “then.” There’s a specific order to these steps, and it’s vital not to mix them up.

When you’re trying to solve a problem, it’s very tempting to look at where you are now – your current situation, the choices you’ve made in the past, your strengths, and even what your customers have historically liked. You might ask, “How can I make things better by tweaking what I’m doing?” It sounds like the right thing to do.

The issue with this approach is that if you plan this way, you’re essentially planning around the problems you’re facing right now. You’re only considering small changes from your current position, and that might not lead you to where you actually want to be. It’s a bit like wandering in a maze: the turn that seems to take you closer to the exit might lead you down a series of better approximations, eventually reaching a dead-end.

In engineering projects, I’ve seen this happen repeatedly: teams make minor adjustments without realizing that the system they’ve built no longer serves their customers’ basic needs. The customers who stay only do so because they fear the cost of change, until one day, they leave. Then, you’re left with no way to bring them back because you haven’t invested in reaching your actual goal.

To avoid this, it’s essential to distinguish these two steps clearly. First, determine where you want to be: What problems need solving? Who cares about these problems, and do they agree with how you’ve defined them? What would an ideal solution look like, and do these stakeholders agree that it’s a good solution? Only once you have this clear picture should you start thinking about how to move from your current position to your destination. This becomes a more concrete and often quite different question from merely tweaking your current solution.

To break it down further, I typically expect teams to follow these steps in each phase:

1. Clean-sheet Design Phase: Ask three critical questions in this order: A. What problem are we trying to solve? B. Who are the people who care about solving it, and do they agree with our understanding of the problem? C. What would a good (but achievable) solution look like, and do these people agree it’s a good solution? Are there any aspects it misses? These questions should be documented in writing to ensure clarity and alignment. Failure to do so can lead to significant organizational mistakes.
2. Planning Phase: Once you have answers to these questions and know where you want to go, you move on to the planning phase. I’ll discuss this stage in more detail another time, but the key idea is to break the work into milestones.

A good milestone isn’t necessarily about launching a product but capturing real value. Each milestone should stand on its own, so if you had to stop the project after achieving it, you’d still feel that you’ve gained something valuable. This approach acknowledges that circumstances may change, priorities may shift, and the original problem may no longer be the primary focus. Having valuable milestones makes it easier to decide whether to continue or abandon the project.

The Second Rule: Do Not Rely On Only 1 Specific Solution or System

The second rule of design might sound simple, but it challenges some deep instincts we have. Here it is:

Your systems are tools for achieving goals; they’re temporary and will eventually become obstacles. Don’t get too attached to your systems; fall in love with the problems you’re trying to solve.

It’s easy to become emotionally invested in the systems we’ve spent years building. We might feel defensive when someone suggests replacing them. However, this attachment blurs our view of the past and the future. These systems were created because they improved things and made the world better. When they’re ready to retire, it doesn’t mean they failed; it means they succeeded and it’s time to give them a well-deserved retirement. Their successors are like their intellectual children, benefiting from all the lessons learned in their creation and use. We want the new systems to be even better, just as we want our own children to surpass us.

It’s quite amusing to think about, but one of the happiest moments in my career was when a system I had built, which served as the backbone for Google Search for over a decade, was retired. This system had done an incredible job and pushed the boundaries of our understanding of search. It drove changes in software and hardware architecture. Yet, it was replaced by a new system, built by the next generation of the original team. This new system incorporated all the knowledge and experience from the past decade, solving a new set of problems even more effectively. It was a beautiful transition. I’m confident that this new system is on its way to its own replacement, for the same reason. The day of retirement was not a sad occasion; it was a moment to celebrate achievements and look ahead to the future.

Why? Because the old system had achieved its goal: how to search an internet a hundred times larger than what “classical” search engines could handle. It had tackled all the challenges of its time, and the new system would address the next set of challenges. Our mission was to solve the problem of finding information and synthesizing knowledge. The tool we built was a crucial step in achieving that, but the problem itself endures.

To be completely honest, most problems, not just in engineering, persist indefinitely. Rabbi Tarfon used to say, “It is not yours to finish the work; but neither are you free to set it aside.” The most significant problems in life often have no end in sight, and they won’t be solved in our lifetimes or even our children’s lifetimes. This means our role is to build stepping stones toward their solution, addressing the aspects that surface during our time, and moving closer to an ultimate goal that may, with hope, be reached by future generations.

The Third Rule: If a Technology Seems Indistinguishable From Magic, It’s a Sign That It’s Advanced Enough.

Arthur C. Clarke famously said that “any technology so advanced appears as if it were magic.” This statement has a counterpart worth considering:

Any technology that doesn’t resemble magic is not advanced enough.

At first, this may sound like a clever phrase, urging us to aim for better technology. But it carries a deeper meaning when we think about what “magic” means in this context and why we find it desirable. Magic, in this sense, isn’t necessarily supernatural; it’s about the power to make your inner vision shape reality directly.

To illustrate, the famous magic word “abracadabra” isn’t gibberish; it’s Aramaic, meaning “let it come to pass as I have spoken.” Magic, from this perspective, is the ability to transform your mental image of how things should be into physical reality effortlessly.

This concept is crucial. Technology becomes “indistinguishable from magic” when it doesn’t require users to go through complex steps to manifest their ideas. For example, I can vividly imagine images that I lack the skill to draw. I could potentially learn these skills over many years and create a painting, but that’s far from magic.

For technology to be truly “magical,” it should:

1. Let you describe your vision in the same language you conceive it.
2. Allow you to perceive the current state of the world in the same language as your desired state.
3. Enable you to manipulate the world in that same language, saying, “Make it like this.”

Now, why does this matter in my three rules of design, even though it’s more specific than the other two? It influences how we approach problem-solving. When we follow the first rule’s third step – describing the ideal solution – this rule becomes crucial in defining what “ideal” means. It also makes it easier to communicate with stakeholders and determine if the solution truly addresses their needs. A system that requires abstract thinking may not align with your mental picture during these discussions.

The separation of these three properties is intentional. Describing, perceiving, and manipulating reality should all share a common language. Achieving any one of these in problem-solving is a significant advancement. In my experience, a system that can simply describe reality in an easily understandable language is a massive improvement, and if it can also change that reality, it’s even better.

Precision matters. “Seeing the current state” isn’t the same as “seeing the state the system is supposed to be in.” The Three Mile Island incident illustrates this point. Operators had gauges showing the system’s set state, which was useful until a valve got stuck, and the system’s actual state differed from its intended state. This emphasizes the importance of staying true to these properties when designing advanced technology.

Also read: 5 Morning Mistakes to Avoid for a More Productive Day

In Conclusion

These three rules may sound simple when you first hear them, but putting them into practice is much more challenging than it appears. To illustrate this challenge, I’d like to share a story from my friend and colleague, Nelia Mann, who was a skilled fencer. She explained to me that every fencing student goes through three stages in their fencing journey:

1. First, they are taught strict rules and try diligently to follow them.
2. Then, they reach a point where they realize that by bending these rules, they can achieve wins. They become adept at finding ways to bend the rules.
3. Finally, as they approach mastery, they return to following the same rules they were taught as beginners. However, this time, they follow them correctly.

The key difference between the first and third stages is a deep understanding of why the rules exist and the ability to sense when they are being followed correctly or incorrectly. Fencers learn that some rules are more like guidelines, things they typically follow but may deviate from in specific situations. They can explain when and why these rules apply or don’t apply. On the other hand, there are iron-clad rules that they would never consider breaking in their practice.

My experience over the years since hearing this story is that these three stages apply not only to fencing but to every skill. In my profession, software engineering, I’ve observed the same pattern, and it’s often not obvious which rules fall into which category. For instance, there’s a rule about the partial ordering of mutexes, which is occasionally violated but always extensively documented to justify the deviation. Yet, rules about code commenting, documenting resource ownership transfer, or adhering to code style guidelines become as fundamental as not typing your code backwards. The rules that may seem basic to beginners turn out to be the most crucial to consistently follow.

The three rules I’ve presented here belong to that second category. These aren’t rules you casually follow; they require a dedicated effort to perfect your technique until they become second nature. The way I’ve framed them here is the result of years spent refining my understanding of these rules, their significance, and how to apply them effectively. I fully anticipate that these framings will continue to evolve and improve over time, and, in accordance with the second rule, they might even be replaced by better ones eventually.

I eagerly anticipate such improvement and hope that, in the meantime, these rules prove valuable to you.