Engineers, in general, are thought to possess a very keen attention to detail. It is their nature, almost to a fault, to delve into the minutiae of a problem to uncover the best, most optimal solution. Their reputation is that they get so immersed into what they’re doing they become almost oblivious to what is going on around them. In the engineering world, the need to immerse oneself into the depths of the design is critical to success. But engineers are also human. They lose focus to things such as pressure, complacency, accelerated schedule demands, making false assumptions, fatigue and a host of others issues. Just like anyone else, these can affect their work product and the need to drive as deep into the details as required. In engineering, however, that risk tends to be magnified, because to be successful, the myriad details contained in their work product all must work together almost perfectly. If any one doesn’t perform as expected, it could lead to product failure. And in numerous instances, the “details” that need to be fully defined will be at the micro level. Failure to fully vet those details could result in a problem that may not surface right away. But the engineers that were the high achievers learned that through self-awareness and discipline they could combat those things competing for their attention in a way that allowed them to still focus on their tasks in the most thorough way possible.
One of the most common issues I have observed among my fellow engineers is complacency. This is typically brought about by being assigned a task that, on its surface, seems simple or straight-forward. The task is perceived as “easy,” especially compared to others you may have had or been exposed to. In this instance, the inclination is to almost rush through it. The danger here is that details get glossed over and in general the task is approached superficially, with a lack of adequate depth. The attention to the minutiae just doesn’t seem to be warranted in this situation you say to yourself, the margin for error is so big. This is a recipe for failure. Yes, the task may not be difficult but if you approach it cavalierly, it is quite likely your design will have flaws, probably due to the silliest of mistakes. Then your reputation may suffer because people will come to believe that you have trouble with the “easy” stuff, never mind the hard things. It is human nature to give all of your attention to an extremely hard task and to pursue that task’s issues with an engaging level of depth. To engineers, that’s the fun stuff. “Easy” tasks aren’t necessarily fun, they’re mundane. But set that aside and perform the task with the same degree of rigor and depth as you would a difficult design.
In general, be your own harshest critic. Question your solution especially if it’s been derived quickly or without much thought. Maybe you’ve simply copied a design or design subset that someone else has successfully implemented with the belief that since it worked for them it’ll work for you. Maybe. Maybe not. There are myriad reasons why it might not. Do your due diligence to make sure that is suitable for your application. Don’t just insert something you don’t understand into your design because your boss said to. Take the time to understand it. You’ll expand your knowledge base, of course, but maybe your boss overlooked something. Remember it is your design. Take note if someone completely detached from your design asks a question about it and your answer is “I don’t know.” That may be an indicator that you have approached the task too superficially. You should know your design, its details and nuances better than anyone. And being thorough can extend beyond the design stage. For example, in a troubleshooting scenario, it may mean implementing a fix to a problem that you have analytically derived, and as a consequence have a good understanding of why it worked versus implementing a fix to a problem you guessed might work and don’t have a full grasp of why. The latter approach usually comes back to bite you.
In the pursuit of depth and a thorough understanding of your design, it is possible to suffer from that dreaded affliction: paralysis by analysis. It is certainly possible you might not need to drive down to the molecular level to adequately define an issue. There will always be a need to strike the right balance between doing a thorough job and overdoing it. You probably won’t have to wonder too long whether you’ve tipped the scales too far, though. Someone, likely your boss, will tap you on the shoulder one day and ask why your upcoming deadline is at risk. That will be your clue. You will no doubt be torn between doing what you feel is a thorough job and, in this case, satisfying the schedule demands. What you do in that situation is dependent on several factors, but remember that in the end it is your design, you are responsible for it and you should claim ownership of it. A compromise plan of some sort is likely in that scenario, but insist that it provides you the time you need to yield a final product that you feel confident in.
Executing a design with thoroughness and the appropriate level of depth should be an essential element of design. If it isn’t done, mistakes can be made or — even worse — defects might go initially undetected despite rigorous in-house examinations and test regimens. The last thing you want is for your design to fail after it has been delivered to the customer or end user. And only then discover that the problem could have been detected much sooner, if you had only dug a little deeper during the design phase. The best way to avoid that scenario is to be as thorough as you can when you control the design. But, as mentioned, several different distracting factors can come into play during that phase that have the potential to keep that from happening. Mistakes can never be completely avoided, of course, but with some self-discipline and strategic thought, the appropriate level of depth can be attained. Then the chance of design mistakes or issues are minimized, and the chances of first-pass success and producing a highly reliable product are increased.
William S. (Bill) Bunch is a recently retired electrical engineer, having spent the bulk of his professional career working for a global aerospace and defense company in the design, test, integration, fabrication and delivery of systems used by the U.S. military. Bill enjoys sharing his knowledge and experience particularly to early career and aspiring engineers. He is currently a volunteer mentor in the Horizon Scholar Program which strives to increase college access and professional opportunities to low income students in grades 9-12.
