Engineering Communication and Professional Judgment

Communicating Design Rationale

The engineer put a lot of work into the fixture design. After a solid analysis and creative design, a lot of work went into optimizing the fixture cost. The project was just getting started, and we were in the design review meeting. The project manager stopped me on the 3rd slide and asked "What's the point of all of this. We can just buy this fixture off the shelf." He never asked me the cost to build it. He never asked me the lead time to build it. In fact he never asked me a single question about the challenges that the fixture design team would face trying to maintain it.

Simple design, horrible communication. The project got delayed because no one understood the need for this or how it would be used. If you can't explain and defend the need for your design, it won't be built.

Engineering plans do not exist in a vacuum. Someone has to pay for them (managers), someone has to understand what they will get (clients), and someone has to build and maintain the design (technicians) or verify the engineering assumptions (engineers). Also, someone has to procure the parts (procurement). All of these people require different views of the information, presented in different ways.

What you need to communicate:

This is the thing I've come up with. In brief, I explain what I've designed, and then I go on to justify why it's the best solution to the problem at hand, discussing its benefits, rationale, and details. I then go on to list all the requirements that need to be met and provide evidence of why this solution meets more of them than anything else I've seen proposed.

Describe the underlying assumptions made in the design. Clearly articulate these assumptions at the beginning of the design document. Describe the loads, material properties, boundary conditions, and patterns of use that are incorporated into the design. Later, when a requirement is modified, the individual will know what assumptions are no longer valid and will need to re-examine those sections of the design.

The trade-offs involved and reasoning behind your decision. I get to see all of the different options that were considered, and your selection is clearly the best of the three options balancing cost and weight for me at 2× cost over Option A (the lightest), but less than half the cost of Option B requiring custom tooling.

What risks and limitations exist. Be honest about what could go wrong, what you didn't analyze, what requires testing. Don't oversell the certainty you don't have.

What do you need from others to move forward? Be very specific about what you need, i.e. "I need the material specs by Friday so that I can complete the design", rather than "we need more information over the next few months/years so that we can move this project forward".

On, writing clear documentation is important so that others know you are capable. If you don't, then no one will trust your work. And while they are discussing it in meeting, the project will come to a halt.

Audience-Specific Communication

We continue to give our best misunderstanding of what our clients and stakeholders need. We present the shaft design to our manager in detail complete with von Mises stress distributions to validate our finite element analysis (FEA). He questions us about mesh convergence but all he really cares about is will it work, when will it be completed and what will it cost. Later we give the machinist instructions on how to make the shaft. We emphasis the cost and schedule but he interprets our silence on tolerances and surface finish incorrectly and as a result he builds the part wrong.

This is a standard product representation (same graphics) that has been poorly communicated to the audience. Information needs are highly dependent on the role of the user and the decisions that they are trying to make. For example, the manager may be interested in knowing the project cost and delivery time, the technician just needs to know the overall size of the part and some specific tolerance information, and the engineer would benefit from knowing all of the assumptions made in the design, as well as detailed calculations for critical parameters.

Keep the post at the right depth for the audience. If you're writing for managers, make sure you don't get too bogged down in details they won't be able to act on. Conversely, for people who will verify your work (e.g., your manager or peer reviews your work), you do want to make sure you don't gloss over key details that will demonstrate that you actually did the work described.

Everyone has just the right responsibilities to fulfill their role.

Documentation as Design Control

It is now 2 years since we launched our product into space, and one of the components has failed. We have begun to pour over the design files, looking at the CAD geometry to try to understand why things went so terribly wrong. Many of the single page calculations have circles around the results, but with no mention of loads, boundaries, or safety factors. Unfortunately, our primary designer of this component left the company 6 months ago, and no one else remembers the assumptions that went into the design or the level of validation that was performed. We are now embarked on an effort to reverse-engineer our own product in order to figure out what went wrong.

This is a common problem. As an engineer, you dream up designs in your head, do back-of-the-envelope calculations, and then move on to the next problem without documenting anything. Then, when you need to make a slight modification or try to diagnose why something is failing, you have nothing to fall back on. This is why documentation is not some arbitrary red-tape, it is your proof that you put some thought into solving a particular problem.

Documentation serves two important roles, to justify your decisions to others, and to excuse you to others, in case things have gone poorly. It's far easier to abuse documentation than to use it well.

Documentation is the act of recording important decisions, assumptions and calculations so that Future-you and/or someone else can understand the logic behind the work and even be able to recreate it.

What needs documenting:

Problem statement and requirements: What were you solving? What were the constraints? Document what you were optimizing for.

Assumptions and inputs: We systematically analyze assumptions and inputs for geometry, material properties, loads, and boundary conditions, including the so-called safety factors. If design requirements change, we easily know what parameters need to be re-analyzed.

Methods and calculations: Formulas, FEA setup, hand calculations. Enough that someone competent could reproduce your result.

Results and conclusions: We present findings and interpretations from our experience with a student-generated tutorial project. Conclusions are drawn from our observations. Recommendations for teaching and learning are made explicitly.

Limitations and what you didn't analyze: Be honest about what's not covered.

Defending Decisions with Evidence

My designs are constantly being questioned, challenged, and torn apart. Someone will say "Why didn't you design it out of Aluminum?" or "We can use a reduced safety factor" or "This supplier makes a similar part that's half the cost." My job is to defend my design and rationale with clear logic, facts and real world data. I can be wrong, and I have been. I need to have the character to admit when I made a mistake.

I'll keep using the term "defending" for now, but I don't mean to suggest that explaining the reasoning behind your choices has to come across as defensive. Instead, I'm going for full exposure, where I clearly lay out my thought process, and – ideally at least – show that I did consider alternative approaches and chose the best one given what I know.

How to defend engineering decisions:

Design to requirements. The requirements were for a linear actuator with 5000 N capacity and FoS of 2.5 minimum. It had to fit within a certain envelope of 250 mm diameter and 450 mm length. The cost was to be no more than $50. The steel tubelinear actuator met all three requirements. The aluminium tube actuator would have required an impractically thick wall for stiffness reasons.

Show alternatives you considered. Be honest if you didn't do a full analysis. "I looked at using steel as alternative, however based off my research it would be significantly cheaper and stiffer than aluminum, making steel appropriate for fixed part designs where weight is not a concern."

Understanding the tradeoffs is important too. Saying Aluminum is lighter is too weak. Aluminum saves 1.2 kg, but it costs $35, and requires a 50% larger cross-section that doesn't fit in the wall.

Ref document if applicable. "ASME B31.3 requires minimum Factor of Safety (FoS) of 1.5. However, we are using a FoS of 2.5 to account for both variability of loads and intervals between inspections." - following established practices here, not pulling numbers out of thin air.

Be honest about uncertainty - don't make unrealistic claims of confidence. I assumed uniform load distribution - if loads are concentrated then re-analyse and test under realistic loading.

Building Judgment Through Failure Patterns

Judgment is probably the hardest skill to teach. It's something that comes from real world experience. Learning when to trust a calculation and when to perform physical testing. Learning to spot when a design just "feels wrong", even when the math checks out. Learning when to tell someone that their requirements for a feature are not realistic and that it can't be done within the planned timeframe. Having the skill to guide a design in the right direction instead of trying to make something work against your better judgment. Judgment comes with time and is slowly built by making decisions and learning from their effects.

Good judgment, therefore, is nothing more than pattern recognition. You have seen these patterns before; you understand how existing situations have worked out; you apply those experiences to new situations in order to reach a predictable conclusion for the best outcome. A junior engineer performs the calculations and determines a 10 mm bolt to be suitable. An experienced engineer looks at the 10 mm bolt in a high-vibration environment and says "that'll loosen and fail." Both reach a conclusion, but for different reasons; the junior engineer arrives at his answer based solely on mathematical calculation while the experienced engineer bases his answer upon past similar exposure and the patterns he has observed in practice that ultimately led to a good judgment.

How to build judgment faster:

Study failures. Reading case histories, post-mortems, recalls and tracing the decision making steps will also give you insight on how the failure happened. The infamous collapse of the Tacoma Narrows Bridge span teaches one lesson about aeroelastic flutter while the Challenger disaster teaches a second lesson about how strong organizational pressures can override good engineering judgment. The failed roof structure of the Hyatt Regency hotel in Atlanta teaches a third lesson – that every design change requires re-analysis. More can be learned from design failures than from successful designs.

Always seek feedback on your work, and not just to have redlines fixed. Ask engineers experienced in design to explain their reasoning behind specific design decisions, to learn the pattern recognition that went into their work.

Reflect on your decisions and their outcomes. Do a personal post-mortem on projects you've done in the past. What would you have done differently had you known then what you know now? What assumptions were faulty? What were unexpected? Write down all the lessons you can and look at them as you would a case study.

Develop a deep understanding of the context in which the weight optimization decision will be applied. Decisions made with rigorous weight optimization techniques in the aerospace industry may not be optimal for a consumer product. In the latter case, weight is one of many considerations and the marginal return for effort and investment is far less than in the aerospace environment. The effective judgment maker makes decisions based on the factors that matter most for their specific application.

Know your limits. Confidence is essential for good judgment. Overconfidence, on the other hand, can kill a project and even maim an employee. If in doubt, say so. Asking for help when uncertain is good judgment, not evidence of weakness.

Developing judgment takes time. You hit some bumps along the way and, hopefully, learn from those mistakes sooner than learning from your mistakes the hard way. Learn from others' mistakes. Seek feedback. Reflect. Over time, you'll begin to see the patterns and anticipate a problem before it becomes a failure.

From Solving Problems to Owning Decisions

As I got further into school, I started to realize that problems in textbooks are so different from the real life work of engineers. In school, problems are closed system with complete information and typically have a single solution to a well-defined problem. You are given the knowns and unknowns and can easily set up an equation to find the answer. Real engineering is rarely like that.

Specs are never perfect, loads get estimated from similar applications, only stocked materials can be selected, competing demands from manufacturing and procurement and customers all have to be balanced. This is a real-world engineering design problem. There is no single perfect answer. There are many acceptable solutions. The solution is choosing one of them, arguing that it is good enough, and clearly communicating risks.

This series gave you the mindset to approach problems like an experienced engineer. We took things one step at a time. It was basic, yet very important to understand how software design fits into the larger scheme.

Level 1 - Problem Framing - Define your problem before you solve it. Make sure you know what you're optimising for. Avoid wasting weeks solving the wrong problem.

Level 2 - Estimation & Intuition Estimate first. Build your intuition so you can recognize that your final answer is wrong. Quick order-of-magnitude checks can uncover errors that would otherwise be multiplied and confirmed by a more detailed analysis.

Level 3 - Tradeoffs & Constraints: Everything you do to improve something else will degrade something else. Systematically search the design space. Separate between what is actually constraining you from what are your preferences.

Level 4 - Risk & Safety Anticipate potential failure modes (not just parts, but system-level failure). Design for safe degradation when prevention is not possible. Build enough safety margins to absorb worst-case loads, equal to or greater than the consequences of failure. Hold oneself and others professionally responsible for safety.

Level 5 - Communication & Judgment with others: Explain decisions clearly to diverse audiences; Document and share reasoning behind decisions; Defend difficult decisions made with logic and data to build trust and understanding, while acknowledging potential mistakes; Build judgment (intelligent thinking) through patterns and learning from failures.

Five critical skills separate a great professional engineer from someone who can simply crank out calculations to get by. These are skills that you can develop over time, and the more you practice the more natural and instinctive they will become. Eventually you'll be able to frame a problem, come up with a rough solution, weigh the trade-offs, think about the risks, and effectively explain your decision to someone else -- all without much conscious thought.

You have built a strong foundation; now it's time to apply it to "real world" problems. Make mistakes - learn from them - gain the experience necessary to transform your knowledge into judgment.