What the Engineer in the Room Knows
I used to be the quiet engineer at the end of the table, the one the vendor never looked at. One sentence from me after the meeting could kill a deal.
In every buying meeting there is one person who will operate whatever you’re selling, and they are usually the quietest person at the table. Vendors pitch past them, toward the title. Then the meeting ends, the boss turns to that engineer and asks “is it real?”, and the answer — often one sentence — outweighs the whole deck. The engineer isn’t scoring your features; they’re pricing what it costs to live with your product after you leave. Treat them as the real audience and the deal gets honest fast.
For almost two years at Infosys, I was the engineer they brought into vendor meetings. Not to speak — to listen. I sat at the end of the table with a notebook, and the vendors, almost without exception, pitched at the people with budget titles and their backs to me.
I understood why. I couldn’t sign anything. I couldn’t approve anything. On the org chart I was nobody in that room. But the meeting after the meeting belonged to me. My manager would close the door and ask some version of the same question every time: “So. Is it real?”
“It’ll work. We’ll spend a year making it work.”
That’s a sentence I actually said, about a product whose demo had gone beautifully. Nothing in it was a lie, and nothing in it was in the deck. The vendor never found out why the tone of the account changed. They’d spent ninety minutes selling to the wrong person.1
The engineer is pricing a different product
The confusion is that everyone in the room appears to be evaluating the same product. They aren’t. The executives are buying the outcome on the slide. The engineer is buying the 2 a.m. version: the migration weekend, the API that’s “documented” the way a rumor is documented, the support ticket that gets answered by someone reading the same manual they are.
So the engineer’s questions sound hostile when they’re actually the most serious buying signals in the room. “What happens when the connector fails mid-sync?” is not an attack. It’s someone imagining owning your product — which is further along than anyone else at the table has gotten. A vendor who hears it as an objection deflects it, and in that moment tells the one person who matters that living with this product will mean being deflected.
What the engineer knows, and mostly doesn’t say, is the institution’s real history: what the last vendor promised, which integration quietly runs on one person’s goodwill, where the bodies are buried in the current stack. Your product will be judged against that private map, not against your competitor’s feature grid.
What actually works
Ask who will run the thing day to day, and ask for thirty minutes with that person — no slides, no managers. It signals respect, and everything they tell you is more useful than anything you planned to say.
Before anyone asks: here’s what breaks, here’s how you’d know, here’s who picks up the phone. Said plainly, this one paragraph buys more trust than the entire demo.
Offer the sandbox, the real docs, the ugly changelog. An engineer who has tried to break your product and failed becomes your advocate in the meeting you’ll never attend. There is no substitute for this.
If the engineer says something wrong about your product in the meeting, correcting them in front of their boss costs you the account. Take it offline, give them the fix, let them deliver it as their own discovery.
The org chart tells you who signs. It doesn’t tell you who decides. In technical purchases those are almost never the same person, and the gap between them is usually one quiet engineer whose verdict travels in a single sentence.
I don’t have to guess what that engineer is thinking. I was that engineer. Mostly I was thinking: look at me once, and I’ll tell you what’s actually going to go wrong.