Recently I was reading about the Navy Seals, their exploits and successes in special operations warfare. Awesome guys. And I got to thinking that some of the rules, guidelines, and commandments they follow can be applied to electronic engineering. Some of them certainly fit my own engineering experience. You may find the same.
The guidelines of Seal Team 6 founder Richard Marcinko are particularly applicable. Marcinko had a successful consulting company after leaving the Navy. A few years back, he wrote a series of novels about the not-so-mythical Rogue Warrior. I probably read most of them—very entertaining. Anyway, I couldn’t help but mentally translate some of his guidelines into rules reflecting on my own life in engineering. Here’s my interpretation based upon personal experience. I am paraphrasing these rules from several sources:
Keep it simple, stupid. A classic and so true. There’s a tendency to over-engineer everything, just because we can. As a result, your product gets more complex and therefore more expensive, more difficult to test, and harder to set up and use and repair. With everything microcontroller-based these days, it’s so easy to add features for little or no cost. The added value may be questionable. Why not keep things simple by making it faster and easier to design, test, build and use?
You don’t have to like it; you just have to do it. I love this one. It’s something we all learn eventually as adults. There are many things we do not want or like to do but must: making up a final BOM, wiring lists, PCB layout, etc. Or think about future maintenance on software. Some poor devil is going to have to do this. How about creating some helpful documentation? We put these things off and try not to think about them or even try to delegate them if we can.
But at some point, you just have to buckle down and get them done. Matching the specs of your design to a desired set of complex standards is an example. Brutal. You just have grind it out. Doing EMI testing and working through the certification process for a wireless product is like that. No fun. But it has to be done.
Never assume. We all assume. Sometimes we’re right, other times not. When working on a big or complex project or design, how many times have you assumed wrong? Did you get all of the specs from marketing, or interface details from another engineer on the project, or details on required testing? Maybe you’re part of a design team where your hardware has to match up and be fully compatible with one or more other hardware segments.
In one of my projects, another engineer made the power supply with insufficient current capacity. He didn’t get the memo, so he assumed. In another job, the physical dimensions of a module didn’t match the housing. There are usually many unknowns, so don’t assume. Pin down the details.
Don’t be afraid to fail. The path to success and achievement is almost always filled with screw-ups. Hopefully they’re not major. Failures are just opportunities to learn. How many times have you had to redesign something to get it right? Edison once commented “I have not failed. I've just found 10,000 ways that won't work.” This is called empirical design. Edison may not have been a genius, but he was a really a hard worker.
Take risks. It has been said that you never make any significant progress unless you stick your neck out. This is true. My greatest career successes came with some radical job-changing risks. But they did work out. Doing something radical and different could pay off big time or get you fired. Not all risk-taking ventures work, but I bet they work out to average better than 50/50. Try it if you have not.
Never be satisfied. This one is a bit difficult to translate. In one way, it says you’re trying for perfection. Of course, that can never be achieved. But you can try to get close. At some point in design, you have to stop engineering and produce the final product. It will never be perfect. Additional time and money spent in development brings only diminishing returns. Seeking the balance between being obsessive and reasonable is the challenge.
Most of Marcinko’s other rules are related to warfare and don’t translate well to engineering. For example, kill your enemy before he kills you, win at all cost, break the rules, lead from the front, serve a greater cause than you own ego, and never give up. Hey, maybe those rules do apply.
