Engineers like to solve problems. When presented with a problem, professionals are often tempted to propose solutions without validating the problem statement. This can be the right thing to do when the problem is well defined. Unfortunately, outside of academic exercises, such well-defined problems are rare. Sometimes the problem you need to solve is different—and sometimes simpler—than the stated one.
Consider the problem of waiting in line. In "What You Hate Most About Waiting in Line," Seth Stevenson explains that while shorter waits may be better, the underlying problem is often that people are bored, and it may be simpler and less expensive to address boredom than to provide for shorter waits. This is much like an example in one of my favorite books, Are Your Lights On, where dissatisfaction with a slow elevator (a very expensive issue to address directly) was addressed by installing mirrors on each floor so that people could distract themselves, making the wait less onerous.
Waiting at a train station presents similar issues. In "What Makes Train Station Waits Better Than Others," Eric Jaffe points out that queuing seems more fair, making the wait less boring as well as letting people know how long they should wait. Addressing issues like social justice, environment, and feedback might seem like dodging the obvious technical problems (long waits), but it can also be a way to efficiently address real needs and add value.
In some cases, the answer may be to address the stated concern. Sometimes helping people feel better about a slow system response isn’t enough and you need to address the underlying performance issues. In this case, it doesn’t hurt to evaluate whether what someone says he is concerned about is the core issue. Take a step back and try to understand the underlying problem before jumping to a solution. Don Gray provides some guidance on how to do this in "Why not Ask Why."
Once you have a handle on the real problem, a good habit is to try to evaluate at least three options before implementing a solution. Once you have what you think is the right solution use the Rule of Three—If you haven’t thought of three things wrong with your solution, you haven’t evaluated it thoroughly—to validate that the solution really fits the problem.
By stepping back to consider what the real problem is, you can develop a better solution for your customers, while avoiding working on “solutions” that aren’t valuable. Sometimes by doing less you can deliver more value and avoid wasted energy.
Steve Berczuk is an engineer and ScrumMaster at Humedica where he's helping to build next-generation SaaS-based clinical informatics applications. He is the author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, and has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT.