What a Businessman Is Really Asking When He Questions Your Engineering
12 business questions engineers consistently misread — and what to say instead
What a Businessman Is Really Asking When He Questions Your Engineering
12 business questions engineers consistently misread — and what to say instead
Herbert Roberts, P.E. | inventorsmindblog.com
He Is Not Attacking Your Engineering. He Is Speaking a Different Language.
Last week we covered what to do before you walk into a businessman's office. This week is what happens after you open your mouth — specifically, what happens when he pushes back.
Because he will push back. Not because the engineering is wrong. Because the questions a businessman asks during a technical conversation are not the questions they sound like. An engineer hears a challenge to the methodology. A businessman is asking about his exposure. An engineer hears skepticism about the timeline. A businessman is asking whether he is going to be surprised. An engineer hears a request for cheaper options. A businessman is asking whether you have optimized the solution or just priced the obvious one.
The engineer who answers the question that was asked — rather than the question that was meant — loses the room one misread at a time. What follows are the 12 business questions that derail the most technical conversations, what each one actually means, and what to say instead.
The 12 Translations — What He Said, What He Meant, What to Say
Budget and Numbers — When He Questions the Cost
1. He says: "Can you just give me a ballpark?"
What the engineer hears: He wants a rough estimate. I should caveat it heavily so I am not held to it.
What he actually means: He is testing whether you are in control of your own numbers. A heavily caveated range signals that you have not thought this through. He will use whatever number you give him — caveat or not — so give him one you can defend.
What to say: My working number is X. That assumes standard lead times and no scope changes. I can sharpen it to plus or minus ten percent with one more week of analysis if you need to take it to the board.
2. He says: "What's the worst case?"
What the engineer hears: He is worried. I should walk him through every failure scenario in detail.
What he actually means: He wants to know his maximum exposure so he can decide whether the downside is survivable. He is not asking for a fault tree. He is asking for one number with one condition attached.
What to say: Worst case is X dollars and Y additional weeks, which happens if the supplier qualification fails and we have to go to a secondary source. I have a mitigation path for that scenario already mapped.
3. He says: "Do we really need all of this?"
What the engineer hears: He wants me to cut scope. I need to defend every line item.
What he actually means: He is asking you to prioritize — to tell him which parts of the work are load-bearing and which are nice to have. He is not attacking the engineering. He is asking you to act like a partner who understands that budgets have limits.
A short 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.
What to say: The non-negotiable items are A, B, and C — those are what give us the certification path. D and E can be deferred to Phase 2 without affecting the primary deliverable. That gets you to X dollars instead of Y.
Schedule and Confidence — When He Questions the Timeline
4. He says: "How confident are you in that timeline?"
What the engineer hears: He doubts the schedule. I should add buffer and explain the dependencies.
What he actually means: He has been burned by engineering schedules before. He is not asking for a schedule defense. He is asking whether you personally stand behind the date — or whether you are about to hand him a number built on optimistic assumptions that will slip the moment the program starts.
What to say: I am confident in the date assuming the two external dependencies we discussed hold. If supplier X slips, we have a two-week float built in. I will flag it the moment I see risk — you will not be surprised.
5. He says: "What are the other options?"
What the engineer hears: He wants alternatives. I should present a full option analysis with pros and cons.
What he actually means: He is checking whether you have done the full problem space or anchored on the first solution that worked. He wants to know you considered alternatives — not that you are about to hand him a decision matrix he has to work through himself.
What to say: I looked at three approaches. Option A is what I am recommending — it is the fastest path to certification and carries the lowest integration risk. Options B and C trade cost for schedule in ways that do not serve this program's timeline. I can walk you through the comparison if it is useful, but my recommendation is A.
6. He says: "Is this really an engineering problem or an operations problem?"
What the engineer hears: He is questioning my jurisdiction. I need to defend why this is an engineering issue.
What he actually means: He is trying to route the problem to the right budget and the right owner. This is not a challenge to your expertise. It is an organizational question about who writes the check and who carries accountability. Answer it directly.
What to say: The root cause is an engineering specification gap — the fix requires a design change, which sits with my team. The operational workaround that exists today is masking the failure mode. I can show you the data that makes that case in about ten minutes.
Scope and Options — When He Questions the Approach
7. He says: "Can we do this cheaper?"
What the engineer hears: He wants me to cut the budget. I need to defend every cost.
What he actually means: He is asking whether you have optimized the approach or simply priced the obvious solution. The answer is never 'no' — it is always 'yes, if we accept this tradeoff.' Give him the tradeoff explicitly. Let him decide.
What to say: Yes — we can get to X dollars by deferring the third validation cycle to post-launch. The risk that introduces is Y. If that risk is acceptable given the program timeline, that is a reasonable tradeoff. Your call.
8. He says: "What does the competition do?"
What the engineer hears: He wants a competitive benchmarking analysis. I should gather industry data.
What he actually means: He is checking whether your solution is calibrated to the market or engineered in a vacuum. He is also testing whether you know your industry context or whether you only know your own program. Answer it in one sentence if you can.
What to say: The industry standard approach is X. What we are proposing differs in one key way — Y — which gives us a specific advantage on Z. I can document that comparison if it is useful for the board.
9. He says: "Have you done this before?"
What the engineer hears: He is questioning my experience. I need to establish my credentials.
What he actually means: He is assessing execution risk. He wants a reference point that tells him this is not a science experiment. Direct experience is the best answer. Transferable experience from an analogous program is the second-best answer. Either is credible. Neither requires a CV recitation.
What to say: Not this exact configuration, but we used the same analytical approach on Program X and hit the deliverable within three percent of budget. The failure modes we are managing here are the same family.
Progress and Fallback — When He Questions Your Control
10. He says: "Why is this taking so long?"
What the engineer hears: He is frustrated with the schedule. I need to explain the technical complexity.
What he actually means: He is not asking for a technical explanation. He is telling you he does not have visibility into progress and it is making him uncomfortable. The fix is not more explanation — it is more communication earlier in the program before the question gets asked at all.
What to say: We are at X percent complete against the plan. The current rate-limiter is Y, which I flagged in last week's update. I expect to clear it by Z date. Going forward I will send you a one-line status every Friday so you always know where we stand without having to ask.
11. He says: "What happens if this doesn't work?"
What the engineer hears: He is preparing for failure. I should reassure him with our contingency plan.
What he actually means: He is doing risk management. He needs to know that you have a Plan B — not because he expects failure, but because the existence of a fallback tells him you have thought past the optimistic scenario. Contingency planning is a signal of professional maturity, not a concession of doubt.
What to say: If the primary approach does not achieve the performance target, the fallback is X. It costs Y more and adds Z weeks. I do not expect to need it, but I have it scoped and ready to execute.
12. He says: "Can you just send me a one-pager?"
What the engineer hears: He wants a summary document. I should condense the full analysis into a shorter format.
What he actually means: He is telling you that everything you have given him so far is too much. The one-pager is not a summary of your analysis. It is the only version of your analysis that will be read, forwarded to his board, and used to make the decision. Treat it accordingly — and send it before he has to ask twice.
What to say: I will have it to you by end of day Thursday. Three sections: what we are proposing, what it costs, and what we need from you. Everything else is available as backup if questions come up.
The Question That Stopped Me Cold
Midway through a program review early in my career, a VP leaned back in his chair and said: 'Have you done this before?' I had thirty-two patents at that point. I had run programs from concept to certification. I had more relevant experience in that room than anyone else at the table.
I proceeded to tell him all of it. In detail. For about four minutes.
He was not asking about my credentials. He was asking about his risk. The question he actually needed answered was: is this a science experiment or an execution problem? I had the answer he needed in one sentence — 'same failure mode family as Program X, we hit that deliverable within three percent of budget' — and instead I gave him a resume recitation that consumed his remaining attention and left him less confident, not more.
The businessman who asks 'have you done this before' is not interviewing you. He is stress-testing the program. Answer the program question, not the credential question. It is a faster path to yes, every time.
The Pattern Underneath All 12
Read the 12 translations again and the structure becomes visible. Every business question is one of three things: a request for a number, a request for a commitment, or a request for a fallback. That is the complete vocabulary of business risk management.
The engineer who hears a technical challenge where a businessman is asking for a number wastes time defending methodology when a single dollar figure would have closed the conversation. The engineer who hears skepticism where a businessman is asking for a commitment loses trust by hedging when a clear yes-or-no was all that was needed. The engineer who hears pessimism where a businessman is asking for a fallback misses the opportunity to demonstrate exactly the kind of professional maturity that gets engineers retained, promoted, and called back.
The translation is not difficult once you know what you are listening for. Number, commitment, or fallback. Answer the right question. The technical depth that makes you credible is always available as backup. Lead with what he actually asked.
Download the Businessman Communication Checklist — the single-page field tool covering both The Ask and The Answer, formatted for boardroom prep and leave-behind use.
Herbert Roberts, P.E. is a licensed Professional Engineer with 32 years in aviation research and development, a Six Sigma Black Belt, and 62 U.S. patents.
He publishes thrice weekly at inventorsmindblog.com.