Why Your Questions Are Your Real Engineering Credential
The engine had eaten itself.
Why Your Questions Are Your Real Engineering Credential
The engine had eaten itself.
A compressor failure had sent metal parts downstream into a 3,000°F+ combustor. The resulting molten metal hit our composite components and blasted the coatings we had spent years developing. We were two thirds of the way to our long term durability goal. We needed to close the remaining third.
Three of the best advanced coatings scientists in the world were standing next to me. People who had spent careers developing these coatings. People who knew exactly what the gap was between what existed and what we needed.
I asked them: How do we develop an advanced coating repair chemistry in three months? (Note - Not can we? but, How do we?)
Three months, that was how long the compressor’s metal parts would take to repair before the engine was reassembled. Three months. Not three years. Not a full development program with budget and schedule and a program manager. Three months, field-applicable, no flame spray equipment available, liquid or slurry only, thermally processed in place.
Nobody laughed. Nobody said it couldn’t be done. They knew what I knew — if we didn’t try, the composite parts came out of the engine. The program lost its test platform. Years of data became a dead end. The next generation of engine efficiency that depended on this technology went back to square one.
The question wasn’t audacious. It was the only move.
We built a design of experiments. Three slurry chemistries. Three heating methods. Nine combinations mapped systematically so that every result — success or failure — meant something and built on the one before it.
Some worked. Some failed.
The ones that failed gave us something we hadn’t planned for. With the coating gone, we had bare composite substrate exposed to the full engine environment at known conditions — temperature, gas composition, flow rate, time. We could study the erosion rate of the composite itself. Was it linear? Was it logarithmic? Was it exponential? That answer determines inspection intervals, replacement schedules, remaining life prediction — the entire maintenance architecture of a technology that didn’t have one yet.
The design of experiments produced three research threads. Three chemistry patents. Two application patents.
We went to that teardown site with one question and came back with work that lasted a decade.
The repairs that worked kept the program alive. The repairs that failed built the foundation for everything that came after.
What a Weak Question Reveals
A weak question exposes the boundary of your mental model in real time. It tells everyone in the room exactly where your thinking stopped. The question that could have been answered by reading the abstract. The question that ignores a constraint everyone already knows. The question that asks for permission to think rather than presenting a thought.
Weak questions are not a crime. They are a signal. And in a technical room, people read that signal instantly, without discussion, without judgment — they just recalibrate who you are and what you’re worth in the conversation.
Strong questions do the opposite. They signal that you have already done the obvious work before opening your mouth. That you have pre-filtered the retrievable answers and are now pointing at the actual gap. That you belong in the conversation at the level the conversation is operating.
The diploma on the wall tells people what you were certified to know at 22. The question you ask at 45 tells them what you actually built since then.
A note before the break. Inventor's Mind is free, and subscribing stays free — no payment, no upsell, just an email. The reason the rest of this column sits behind a free subscription is simple: we are building this together. A sub tells me who is in the room.
Equally, it lets me shape the next column around what you came here for, instead of what I guessed you came here for. We get a better blog when the conversation is two-way. Please don't go — subscribe and stay with us. Thank you for being here.
The Question That Changed Every Room I Walked Into
My default question was never why did that happen.
It was why not this.
Those are not the same question wearing different clothes. They come from entirely different postures.
Why did that happen is diagnostic. It is backward-looking, reconstructive, forensic. It is the question of someone trying to understand the existing system on the existing system’s terms. Important work. Necessary work. But fundamentally conservative — it accepts the current solution as the reference point.
Why not this is generative. It is forward-looking. It assumes without apology that the current solution is not the final solution, and it applies immediate pressure to the boundary. It makes people who have been living inside a problem suddenly look at it from outside.
In a room full of analysts asking backward questions, one forward question lands like a change in air pressure. People stop retrieving and start thinking. That is a different gear. Most technical meetings never find it.
And then there is a third question — the one that precedes all the others. The one that started my career as a repair development engineer. Not why did that happen. Not why not this. But:
How do we make this — something that does not currently exist — happen?
That question does not navigate the solution space. It declares what is necessary and demands that the engineering catch up. It treats the gap between current capability and required capability as a problem to be solved rather than a boundary condition to be respected.
It is the question that built the Apollo program. It is the question that preceded every technology development program that eventually became a product. It is Question Zero — the one that makes all twelve questions below worth asking.
The Twelve Questions
What follows is not a list of clever phrases to memorize. It is a map of mental postures — twelve distinct ways of standing relative to a problem. The engineers who change rooms can move between them fluidly. The engineers who fill seats have one, maybe two, and use them on everything.
1. Why not this — The Inventor’s Question
Assumes the current solution is provisional. Applies pressure to the design boundary without asking permission. Signals that you have already processed the obvious paths and are now working the edge. This is the question that generates patents.
When to use it: Any time the room is converging on a solution through momentum rather than logic.
2. What is actually fixed here versus assumed fixed — The Constraint Hunter
Most constraints in engineering are not physical. They are organizational, historical, or political — and they have calcified into the problem definition without anyone noticing. This question separates the real walls from the drawn ones.
When to use it: When the solution space feels artificially small.
3. How does this die — The Failure Prospector
Not why did it fail. How will it fail — prospectively, specifically, before it happens. This question requires you to build a mental model of the failure before the failure exists. It is the difference between design review and failure mode engineering.
When to use it: Before any design is locked. After any design is locked.
4. What was the last moment this could have been caught — The Forensic Question
Every failure has a last moment of intervention — a test, an inspection, a review — where the outcome was still changeable. Identifying that moment backward teaches you where to put the gates forward.
When to use it: Post-failure analysis. Design of verification systems.
5. Does this still work at 10x — The Scaler
Lab results are not product results. A mechanism that functions beautifully at prototype scale can become a liability at production volume, at temperature extremes, at the edges of the use envelope. This question separates inventors from engineers and engineers from product builders.
When to use it: Any time someone presents a proof of concept as a solution.
6. Who gets hurt when this is wrong — The Humanist Question
Engineering decisions are not abstract. They land on people — operators, maintenance crews, end users, bystanders. This question forces the consequence back into the room before the design leaves it.
When to use it: Every design review. No exceptions.
7. What does the second-order failure look like — The Systems Thinker
The first-order failure is usually obvious and usually designed against. The second-order failure — the cascade that the first failure triggers — is where the actual damage happens. This question requires you to hold the whole system in your head simultaneously.
When to use it: Complex systems. Anything with interdependent subsystems.
8. What would we do if this constraint disappeared tomorrow — The Liberator
Sometimes the constraint is real. Sometimes it disappeared three years ago and nobody updated the design logic. This question tests the difference. It also generates the next generation of solutions before the current one is obsolete.
When to use it: Mature programs. Legacy designs. Anything that hasn’t been questioned in a decade.
9. Has anyone solved an adjacent version of this — The Pattern Matcher
Engineering problems rarely arrive without cousins. A thermal management problem in aerospace has relatives in electronics cooling, in HVAC, in materials processing. The pattern matcher looks across domains before inventing from scratch.
When to use it: Early in problem definition. Before the team commits to a direction.
10. What are we not measuring that matters — The Gap Finder
Every test program measures what the designers thought to measure. The failure modes that kill products are frequently the ones nobody thought to instrument. This question audits the measurement system against the actual risk landscape.
When to use it: Test planning. Certification programs. Any time results look cleaner than expected.
11. What does the customer never tell us but always means — The Translator
Customers describe symptoms. They rarely describe root causes and almost never describe the actual requirement underneath the stated requirement. The translator reads between the lines of the specification and finds the real problem.
When to use it: Requirements definition. Any customer-facing technical review.
12. What would I do if I had to ship this myself — The Accountant
This question eliminates abstraction. When the consequence of the decision lands on you personally — your name, your license, your business — the analysis sharpens immediately. It surfaces the things you know are wrong but haven’t said yet.
When to use it: Any time a decision is being made by people who won’t live with the outcome.
The Question Is the Visible Tip of Invisible Preparation
Here is the thing nobody tells you about strong questions: they are not spontaneous.
The reason why not this lands with authority is that the person asking it has already worked through the obvious alternatives and eliminated them before speaking. The question sounds like a flash of insight. It is actually the output of a filtering process that happened in the ten minutes before the meeting, or the night before, or across thirty years of pattern recognition.
Weak questions are unfiltered. Strong questions are pre-filtered. The filtering happens before you open your mouth — which means the quality of your question is a direct measure of the quality of your preparation, your mental models, and your domain depth.
That is your real credential. Not the degree. Not the title. Not the institution on the letterhead.
The question you ask when the room goes quiet is the truest thing about you as an engineer.
Make it count.
Herbert Roberts, PE | Licensed Professional Engineer | Six Sigma Black Belt
Forensic Engineering Consultant | 32 Years Aviation R&D | 62 Patents
inventorsmindblog.com