Keyboard ALT + g to toggle grid overlay
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.” –Albert Einstein
Knowing which problems to solve is what makes us a better engineer. Abstraction laddering gives you structure on the path to understanding the task that has been put in front of you.
Problems present themselves constantly in our lives as engineers. We may be solving problems or simply trying to avoid them in the first place, but understanding these constraints is essential to performing our job well. An issue arises in the engineer’s problem-solving process, however, when problems are abstract. When we are faced with a task that hasn’t been clarified or can’t be clarified, this confusion hinders our abilities to work well. This unclear task can often come from management, or it can come from a brainstorming session. Regardless, we have to refine our understanding.
Great engineers understand how to solve problems, but they also know which problems to solve. When we are presented with a task, we have to understand the correct path forward to solving the key problems if we want to be as efficient as possible. While we may be faced with obvious problems, the only way to know which problems that genuinely need addressing is by properly framing out the problems at hand. This is where the technique of abstraction laddering comes into play.
This technique gives us, as engineers, a framework to solve problems and to solve them correctly at varying levels of focus. It gives us a framework to respectfully question our leadership. It gives us a path to understanding.
If you have ever been given a task by your boss and wondered what exactly he or she wants, it can be difficult to determine which questions to ask and perhaps even ask them in a respectful way. Abstraction laddering provides a framework to not only ask questions, but develop the right questions. The ladder allows us to move both up and down, framing problems as needed. By moving up we can expand our scope, and by moving down we can develop concrete solutions. It can and should become an instrumental tool to facilitate proper problem solving within the realm of engineering.
Abstraction laddering as a technique is simple once you understand the core principles. The implications of properly using the technique, however, are wide reaching into our design process.
When we are presented with a problem or an unknown, we start the process by placing this problem at the middle of a theoretical ladder. Above us sits the question of “Why?” and below us sits the question of “How?”. Above (why) is the more abstract and generalized idea of the problem and below us (how) sits the more concrete idea of what needs to be done.
Let’s put the technique into something a little more relatable for us - designing an electric car. This becomes our initial problem statement in the process, similar to how you might get tasked with a project. We can parallel this problem statement to the design goals faced by Tesla engineers.
Traditionally, we might approach this initial problem by developing a plan of action first and working from this plan in what is called the waterfall technique. While this strategy works, and many engineers use it, it isn’t the most optimized way of solving the initial problem. Utilizing waterfall techniques in your design process assumes that the initial problem of designing a better electric car is well understood. This misconception can be an ultimate hindrance to our ability to innovate designs. An initial problem statement of “design a better electric car” appears concrete, but the word “better”, upon inspection, is incredibly vague. Even “electric car” is a vague term when investigated closely. For these discrepancies, we turn to the abstraction ladder.
As engineers, we likely have an idea of what a better electric car might look like. It might be more efficient, able to operate at higher speeds, or able to last longer on a single charge, etc. – but we aren’t designing an electric car for just ourselves. Even if we were, we often have an unclear idea of what we ourselves actually desire. Taking this idea further, the actual intention of a task given by a client or management may be something less than obvious. With this in mind, we can begin the first step of abstraction laddering by asking the question, “Why?”.
Asking why moves us up the ladder into more abstract concepts and ideas. In terms of our initial problem statement, it may look something like this:
As you can see, we ask “Why do we need to design a better electric car?” Upon investigation, we find answers to this question: “To help people access a more efficient way to get around” and “To increase sales of our line of vehicles.” Investigation may consist of personal inflection or precise questioning of those further up a management chain. One answer to this question abstracts the function that makes the electric car better and the other abstracts our motivation for making the electric better. For any given problem, you can expand outward with questions until you properly frame the problem.
From these answers to the why question, we develop the most abstract problem statements possible (as seen below). For the respective answers, we develop the statements, “How might we help people access a more efficient way to get around?” and “How might we increase sales of our line of vehicles?” As a design engineer, we likely don’t deal with these abstract ideas on a daily basis. We tend to deal with much more concrete ideas, which can often limit our insight into how we should design. By understanding the abstract concepts, we can take each proposed improvement to a design and run it up or down the abstraction ladder, making sure it fits. After we have properly developed a frame for our problem, it becomes time to move down the ladder, closer to a solution.
Asking “How?” is the way to move down the ladder into something more concrete. Just like when moving up the ladder, we can ask as many how questions as we need to fully conceptualize concrete solutions. For our initial problem, we ask “How?” (as seen below) and are left with the following answers: “By making our batteries last longer,” and “By making our electric car the easiest to drive.”
These answers then move into formulating concrete problem statements in our pursuit to refine our process. This results in the statements: “How can we make the longest lasting batteries?” and “How can we own the statement, ‘our electric car is the easiest to drive?’” These problem statements further frame our task of making the best electric car, derived from making an electric car better, and our goal of making an electric that is the easiest to drive. All of these problems allow us to see how Tesla engineers likely formulated their end designs.
The ladder is complete and we are left with a perfectly framed and filled in problem. We understand the abstract picture of why we are designing a new electric car and we have solidified constraints that need to be addressed in the design process. With our ladder built and climbed, we now have to understand when to use it.
The method of abstraction laddering can be done on an individual level to help you as an engineer better understand your task or it can be done on a team level to encourage cohesion in the design process. There’s not a limit to where the ladder can be used in the design process either. If you reach an impasse at a certain location of a design, it might be useful to use abstraction laddering to frame why you are doing something and how to proceed with a given task. Many times, you may find that by framing a problem, you see that it really isn’t a problem at all and addressing it is only wasting time.
Diverging from the concept of allowing the ladder to define your understanding and workflow, we can apply it to proper questioning of management or clients. The abstraction ladder gives you a structure on the path to understanding. By formulating a ladder around a given problem, you can see the right questions to ask your boss or client without seeming to undermine their ideas. In essence, it allows everyone to refine exactly what is being requested and designed in a useful, structured manner.
This process doesn’t need to be fancy, it can be done alone in 5 minutes or quickly in a team meeting.
Another application of the ladder moves deeper into the understanding phase to prevent ourselves from becoming dismissive of management and design ideas. When we have an accurate abstract framework built for a certain task or even our job, we prevent ourselves from becoming upset with the direction things are moving. Even better yet, when things do get off track, the ladder allows us to bring our engineering back into frame, thus moving further along towards a design solution.
Ready to tackle your next engineering problem? Download the abstraction ladder template to get started.