On Exercising Engineering Judgment

Friday, November 8, 2019

Author: Donald Telian, SI Guys - Guest Blogger

Signal Integrity Engineering requires Engineering Judgment. The same thing that makes SI require Creativity causes it to also require above average Judgment; namely that “you will consistently be asked to craft clear answers from insufficient data based on ill-defined measures of success”. There’s no way around it, Engineering Judgment Required. So we’ll address this topic here in our mini-series on the soft skills required for Signal Integrity Engineering.

While you may have been born with a certain Intelligence Quotient (IQ), there are things you can do to improve your Judgment Quotient® (JQ®). As such, this article will provide both a process for exercising Judgment in your daily tasks as well as methods for improving your Judgment. No doubt your JQ® naturally increases over time, yet it’s worth our time to step back and think about how we can hone our Engineering Judgment and decision-making skills. 

I’ll start by detailing a process for exercising Engineering Judgment using the 3-steps shown in Figure 1: Gather Ye Data, Hit a Crescendo, and Find Your Way Out.


Figure 1: A 3-step Process for Exercising Engineering Judgment


Gather Ye Data

While it may seem self-evident that Engineering Judgment requires data, it is surprising how many times I watch engineers try to skip this step. Indeed, it is “data” that changes “Judgment” into “Engineering Judgment”. As Engineers, we need to gather data to exercise Judgment. SI data comes from a variety of sources such as simulators, measurements, field solvers, published works, and past projects. Well into my 4th decade of doing SI, I still catch myself deciding things without data. Becoming data-driven is an important discipline because intuition and data don’t always agree. And, particularly in SI, data has a way of surprising you; it often shows you things you did not expect. This is the value of the tools we use; they exist because the interconnects we work with are often unpredictable.

One reason some propose skipping this step is because it seems data cannot be obtained. Maybe “there isn’t a model” or “I can’t get a probe on that” or “there’s no time in the schedule”. As these are all real problems, we must become skilled at the concepts of “close” and/or “some data is better than none”. Not having a model or not getting one in time are everyday problems for SI Engineers, so many times we have to use something “close”. Judgment has now entered the process. Substitute a similar connector, use the generic “spec” model included with your simulator, or focus your analysis on refining only the passive connection. Learn how to remove (de-embed) whatever is not ideal in your measurement setup. SI Engineers do these things all the time.

Once the intellectual and logistical barriers are overcome and you’ve begun to “Gather Ye Data”, you may encounter the opposite problem: too much data. Compute farms, simulators that sweep variables, and measurement automation have the potential to quickly create Gigabytes of raw data. While some of this data may arrive pre-processed, the practice of SI typically involves spreadsheets, scripts, and graphing utilities that help us find what we’re looking for. Judgment helps us sort the data between relevant and irrelevant, enabling us to dive deeper into the things that matter.

There’s nothing like good solid data. I love it when simulators and measurements are working reliably, piling up data I sense can be trusted. This in itself is a substantial Engineering achievement, one that might trick us into thinking we have achieved our end result. Many an SI Engineer has arrived at review meetings with piles of credible data but little sense of what it all means. So learn how to connect the dots. Think about it, how would you feel if your Layout Engineer sent you a PCB with colorful traces on dozens of layers yet none of them connected to the devices? Data guides Judgment, but it does not make decisions. Engineers make decisions.

While good data is imperative, to help us keep in mind it is the means to an end and not an end in itself, we need to learn to Hit a Crescendo.

Hit a Crescendo

In music a “crescendo” is a gradual increase in volume, as well as the term for the peak volume at the end. A crescendo is stunning when done correctly. And so it is when gathering data; you need to sense when you now have enough data and are “there”. If you drag it out you have too much data and, just as in music, the result is nauseating and suffocating. Get there too fast and there’s no effect at all. So the skill is timing; enough, but not too much.

As I work through projects, I plan and allow time to gather data; this is an important and valid phase. The phase begins with assembling models or a measurement setup, and then the data starts to flow. Your Judgment helps you perceive when the data is looking relevant and believable, and this in itself may require time and iteration. Eric Bogatin’s Rule #9 is helpful here: “Never do a measurement or simulation without first anticipating the results.” Once the data is acceptable you continue to gather it as you journey towards your crescendo. The musical analogy works for me but you could also picture data collection like filling the gas tank in your car. At some point it becomes “full” and it’s fruitless to try to put more in. The purpose is to empower the car to go somewhere, and so it is with data and your project.

A few ways to know you have enough data are: (a) you are no longer learning anything new, (b) it all starts to look the same, (c) you cannot process it all, and (d) you have a headache. But note that different tasks require different amounts of data. For example, I’m working on a project now that has endless permutations and hence requires more data. Other tasks are more straightforward. On the current project more time, data, expense and engineering are required, yet I’m still watching for the crescendo. A crescendo is typically marked by a discovery and/or a sense the data set is robust and complete. And truth be told, sometimes the crescendo is provoked by schedule; either someone needs the answer or the work is no longer equitable. Those situations might require an additional dose of Judgment, but I’m getting ahead of myself.

Working in SI, where compute power can provide more data than you can absorb, sometimes you’re closer to a crescendo than you think; you just need to slice the data a different way. For example, plot variable xy against variable z and discover what is really happening. As we typically work with more dimensions than we can plot, try holding some variables constant while plotting the ones that seem most relevant. Some use 3D graphs, but I prefer scatter graphs overlaid with colored filters on subsets of the data (pages 7-10). When you discover the dependencies that dictate performance you have had your “aha” moment. Once there, it’s fun to test and confirm your theory a couple ways to ensure your conclusions are correct. Indeed, you have Hit a Crescendo and now it’s time to Find Your Way Out.

Find Your Way Out

A crescendo doesn’t work unless you “find your way out”, or, in musical terms, finish up the song. Songs don’t end on the crescendo; instead they resolve the excitement created with settling and easily absorbed harmonies. Similarly, your crescendo doesn’t do any good unless you package it up and make it useful for the rest of the design team. You have shopped for the gift and selected it, but it’s not wrapped or given yet.

It should seem self-evident we need to find our way out. But engineers love to engineer, and hence managers have discovered that at some point they need to “shoot the engineer and ship the product.” Can we become skilled enough to find our way out before we get shot? I think so, but this may require improving our Engineering Judgment. We need to acquire the ability to sense either that we are “done”, or should be done. Judgment is the thing that stands between dawdling and finishing up. You’ve gathered your data, hit your crescendo, and now you need to decide what it means in terms of the Project. Do we need to constrain that length? …swap that dielectric? …use a different connector? …none at all? Or maybe the system is acceptable as is and we don’t need to (get to?) change anything, hence our value-add was verification and sign-off. Sleep on it, if you must, but it’s time to make a decision. And decisions require Engineering Judgment; the moment has arrived.

“Finding Your Way Out” forces another problem with many engineers – particularly we techy SI Engineers. How will you communicate what you have learned? How will you make it simple and digestible? You resolved the correct length to be 1.2894 inches, but perhaps you can communicate it to be 1.3”? What’s the best way to show that graph? …enlarge the fonts? …leave out that variable? …not show it at all? Finding your way out and finishing well requires you to hand-off your work, and simplification and clarity are essential. Don’t be content just to know you have finished your task; provide ways for others to know that too.

Engineering is an endless stream of projects and revisions of projects. Sometimes you might need to delay that thing you want to do until the next revision. And at times I’ve clung onto projects because it was a good one and/or I didn’t want to do the next one. Engineering offers a non-compelling reward for finishing up: more work. So we have to train ourselves to move forward; that project you just finished will soon be out of date technology. That’s the nature of engineering. You have to learn to enjoy the process because completion can be underwhelming. Find Your Way Out and everyone wins. Done.

Improving Your Engineering Judgment

While your Engineering Judgment will naturally improve over time, Figure 2 illustrates four things you can do to accelerate the process: Find a Mentor, Invest in Learning, Use It, and Close the Loop.


4 Methods for Increasing Engineering Judgment

Figure 2: 4 Methods for Increasing Engineering Judgment


1. Find a Mentor. I’ve been privileged to work with many excellent engineers, yet three guys standout among them: John, Bob, and Mike. These guys were natural engineers, loved engineering, and seemed to be born to engineer. They engineered at work and at home - typically with their ham radio gear or some other project. They taught me poise, pace, and new ways of looking at problem solving and the practice of engineering itself. Find someone like this and spend time with them. It’s not intuitive or even scientific, but skill rubs off.

2. Invest in Learning. I know, you don’t have time to read books, blogs or go to conferences. Neither do I. But viewed from another angle, you don’t have time to be stuck viewing things through the lens of only what you know. What we know needs to be expanded and honed over time or it becomes a limitation. It’s difficult to cut with a dull ax, so learn to Sharpen the Saw®. SI Engineers should go to DesignCon at least every other year. Find out what other SI Engineers are learning and leverage their work. Think critically about what they’re saying and if they have substantiated and communicated it well. Get in the mix, and you will discover those you connect with and appreciate learning from. This step is the less organic and broader-based version of step 1, but is still extremely helpful.

3. Use It. Just as a muscle doesn’t get stronger unless you exercise it, likely the best way to grow your Engineering Judgment is to use it. But using it involves risk, and many SI Engineers hate risk. If your best data suggests something should work, take the risk and go with it. While I am naturally nervous and conservative, I’ve been pleasantly surprised by the things I feared might not work yet did. Taking those risks grew my Engineering Judgment in ways that wouldn’t have happened otherwise. It’s exhilarating to figure something out and see it work across millions or billions of units. Taking data-driven risks builds your judgment, confidence and courage. And when you muster up the courage to believe your own data, you’ll find others will too and your credibility will increase.

4. Close the Loop. In SI this term is typically used to refer to Measurement Correlation, but that’s not how I’m applying it here. Because we’ve been successful at migrating SI to the front of the design cycle, we’re often 3 projects down the road before our current work gets built, debugged and shipped. Perhaps if there is an SI problem you will be the first to hear about it, but it’s a rare day when someone finds you to let you know there isn’t an SI problem. So I’ve learned to ask the question: “Did the xyz work OK?” I just asked it of a customer I worked with 2 years ago who replied that “both projects are working well and in production now. No SI problems.” Nice. Signal Integrity Engineering forced you to make decisions about the line between function and failure, and Closing the Loop provides necessary feedback to your Engineering Judgment. It’s helpful to discover that your Judgment calls were good ones and that, indeed, your Engineering Judgment is increasing. So learn to follow-up and Close the Loop. 

In Conclusion

Signal Integrity, In Practice requires Engineering Judgment; there’s no way around it. As it’s possibly the skill no one taught you in college or on the job, we’ve endeavored to examine it here. While Engineering Judgment is intertwined in the process of gathering data, it is forced by the events I have labeled “Hit a Crescendo” and “Find Your Way Out”. I trust these concepts – which are unavoidable moments in the engineering process – will help you identify when the next step is not more models, measurements or data but rather Engineering Judgment. Exercise it effectively.


Judgment Quotient® and JQ® are registered trademarks of Choiceladder LLC, and are used here with permission.

Sharpen the Saw® is a registered trademark of FranklinCovey®, is one of The 7 Habits by Stephen R. Covey, and is used here with permission.

Donald Telian, SiGuys - Guest Blogger 11/8/2019

Did you like this post?

Sign up for our mailing list and we'll let you when we post a new one.