Natural Problems vs. Self-Induced Problems
I frequently work for companies as an engineering and product development consultant. I particularly enjoy working with tech startups who are experiencing challenges for the first time and are still flexible and eager to improve. In recent years, while working with these companies, I have observed an interesting pattern that I now observe in myself, my research lab, and in larger established companies. The observation is about dealing with natural problems versus self-induced problems. The goal of this article is to help us be more aware of self-induced problems and systematically work to eliminate them.
It is important to know that companies generally interact with consultants when something is not going so well. The consultant’s job is to listen, observe, and then try to discover the root cause of a problem and eliminate it. It’s common to simultaneously discover various problems all with different root causes. After observing such problems, I like to produce a list and discuss each one with the person who hired me. The findings often fit roughly into one of two categories: Natural problems and Self-induced problems.
Natural Problems:
Natural problems are the ones that occur in your work simply because the work is hard. It is, for example, just plain difficult to land an aircraft when there are strong crosswinds, or to know a precise aquifer depth before drilling a water well, or to model heat flux across an amorphous structure, or to write a computer code that seamlessly integrates multiple software packages. These tasks are naturally hard.
Natural problems are the reason why our specialities exist – they require deep knowledge and skill to overcome. We should expect natural problems, and we should also expect them to be challenging to solve. If natural problems don’t exist, or they are easy to solve, you – the expert – are not needed.
Workers: be happy that natural problems are present and that your knowledge and skill enable you to solve them.
Managers: natural problems are naturally occurring; they are no one’s fault; they happen because what you are working on is difficult; be glad you have capable people who are willing to work on their solution. Natural problems are why companies have engineering departments continuously employed.
A business model worth pursuing won’t exist without natural problems. If there are no natural problems there are no barriers to implementing your design. No barriers means a saturated market and most likely a race to the bottom [1]. For this reason, workers and managers should embrace natural problems as a challenge worth working through together.
Finally, a company that is not facing natural problems is likely not pushing the technological boundaries enough, and can expect to be surrounded by competitors in short order.
Self-Induced Problems:
Self-induced problems, on the other hand, are destructive and every effort should be made to systematically eliminate them. Self-induced problems are those that occur because of something we did (or did not do) to cause them. For example, it is not hard to be on time to a meeting but being late erodes team trust, wastes time to repeat information, and complicates decision making. Likewise, it’s not hard to read instructions, but failing to do so causes the worker to make multiple assumptions that may or may not be good. It’s not hard to build a fully defined CAD model that can be easily updated, but failing to do so causes all kinds of problems that need to be resolved when non-robust CAD models crash. It’s not hard to add comments to computer code, but failing to do so causes significant problems in the future. Checking engineering drawings is not hard, but failing to be careful about it easily leads to costly compromises and/or fixes on the assembly line. All of these problems are self-induced – they are all problems we did to ourselves and have nothing to do with the natural problems of the project.
Workers: At least weekly, make an honest assessment about what went well for you in your workflow. Continue doing things that went well and create a specific and simple plan for what to improve on. I recommend a thoughtful use of the start-stop-continue framework [2]. Also, be thoughtful about over committing. If committing to something new increases the risk of successfully completing another commitment, reconsider or at least be sure to communicate this with your manager.
Managers: Some self-induced problems will occur. Be particularly concerned when they continue without correction. Give your workers honest and helpful feedback about needed improvement. Be sure to avoid the common problem of overloading your workers and then punishing them for self-induced problems. This common problem is actually a self-induced problem caused by poor managerial decisions. If you need to, speak with experts about how long to expect worker tasks to take given their skill level.
Four Ways to Reduce Self-Induced Problems
I can summarize what seems to have helped multiple companies to reduce self-induced problems as follows:
Be careful, and pay attention to details
Prioritize then validate assumptions
Have a revision control process
Know when to expand capacity/expertise
Be Careful
It seems like it shouldn't have to be said, but it does; we need to be careful in our work. Engineering, product development, and design are all very detail-intense endeavors. If you’re not careful, precise and detail oriented, your design will not turn out the way you want it to. I experienced a simple and somewhat unexpected example of this when I worked in the consumer electronics industry: Sitting in a Chinese taxi with an Apple engineer, I learned that Apple had a set of 27 unacceptable white plastic colors. These samples were essential for suppliers to ensure that what they produced did not violate the Apple cosmetic specs. Without a detailed definition like this, Apple white would not be nearly as consistent as we observe it to be.
It takes effort to pay attention to the details. Simply stated, you can choose to be careful with the details or you can choose to put out the fires that are ignited by lack of care.
When I was an engineering manager, I was required to approve all engineering drawings. After checking many drawings, I found something interesting; if I assumed the drawing was correct, I rarely found problems. On the other hand, if I assumed there was a problem somewhere in the drawing and it was my job to find it, I frequently found problems and fixed them before they became expense fires.
Validate Assumptions
To get going on any endeavor, assumptions need to be made. Make assumptions and develop plans to validate those assumptions without delay. Unvalidated assumptions are seeds for failure [3]. I think of them as seeds because when you make the assumption it is benign – it hasn't yet sprouted into a problem. Not all assumptions will sprout into self-induced problems but some will. I recommend that we all use Clayton Christensen’s approach: Ask yourself what assumptions have I made that if proven wrong would cause us to change course? [4] He further suggests that a list of assumptions be made and then organized on a plot of risk of being proven wrong vs. cost of being wrong. Then work on the high risk, high cost assumptions first.
Revision Control Process
For engineering projects many self-induced problems can be eliminated by having a good process for decision archiving. If the team doesn’t know what decisions have been made, then the work of different team members can become incompatible. I had this experience as a young engineer. I was designing a connector system that had a male and female side. I changed one of the dimensions on the male side and made sure to propagate that change through to the female side. We made the tool change and when I got the parts from the factory, the male and female sides mated as designed. But I had not realized another company was also building an accessory to mate into the same interface that I changed without communicating it to the team. This was a self-induced problem caused by a poor information management process.
Revision control and information management is often a root cause for self-induced problems. When consulting with start-up companies about specific engineering challenges, I will almost always need to see the latest technical specs, engineering drawings, or the bill of materials, so I’ll say: “Let’s see the latest drawing for part X”. So often there is a sheepish look that comes over the engineer: “We don’t yet have good revision control… I think it’s in my email.” This is a self-induced problem, if the engineer doesn’t know what the latest version is and where it is located for all people to access, then no one knows what the latest version is or where it can be found. It is essential to note that at a minimum the engineer can simply finish the day by moving a copy of the latest revision out of a working folder into a latest revision folder. This is not hard. Yes, it takes some time, but it is not hard. Failing to do this, or something similar, produces a situation where information management is ignored and team members are left in the dark relative to the latest version of a design. This is a self-induced problem that is often costly.
None of us is perfect, so some amount of self-induced problems will occur, especially for novices and start-ups. When they are encountered, they should be recognized for what they are and individual and company workflow should be updated to reduce the chance of self-induced problems.
Expanding capacity and/or expertise
My experience describing natural vs self-induced problems to companies generally leads to an important question: Is our own ignorance a natural or self-induced problem? This is a good and complicated question, but I suggest treating it as a self-induced problem.
You can do something about self-induced problems, and you can do something about what expertise and capacity your company has. Be careful and thoughtful about what you expect of yourself, and what you ask your workers to do. It is good to consider the triple constraint of project management: If you expect your workers to do more, you will either need to give them more time or more resources to accomplish it. If it is expected to come from the worker’s personal time, recognize that this is not sustainable.
Conclusions
Ultimately, the message of this article may seem obvious, and even simple, which it probably is. However, there is something unusually hard about putting this simple message to work. In short, embrace the natural problems associated with your work, and put processes in place to systematically eliminate all self-induced problems associated with your work. Be deliberate about improving in this way. Doing so will make you and/or your company more capable of solving technical problems in an effective and efficient way.
References:
[1] Wikipedia. "Race to the bottom." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 10 May. 2025. Web. 12 May. 2025.
[2] Mattson, Chris. “Start Stop Continue.” The BYU Design Review, 29 Jan. 2021, https://www.designreview.byu.edu/collections/start-stop-continue.
[3] Mattson, Chris. “Seeds of Failure.” The BYU Design Review, 3 Dec. 2019, https://www.designreview.byu.edu/collections/seeds-of-failure.
[4] Christensen, C. M. (2010). How will you measure your life? Harvard Business Review, 88(7/8).
To cite this article:
Mattson, Chris. “Natural Problems vs. Self-Induced Problems.” The BYU Design Review, 12 May 2025, https://www.designreview.byu.edu/collections/natural-problems-vs-self-induced-problems.
