There’s a special kind of humiliation you only feel when you’re on a call with engineers and you realize, mid-sentence, that you’re confidently explaining something you barely understand. It’s not anger they give you in return — it’s the calm, quiet disappointment of someone watching a person drown slowly in a shallow pool.
I’ve lived that moment enough times to develop something like PTSD around certain technical phrases. You hear acronyms. They hear architecture. You hear “feature”. They hear “failure mode”. You hear “integration”. They hear three weeks of someone’s life disappearing into badly documented APIs.
Early in my career, I didn’t know this difference existed. I walked into technical calls with the arrogance of someone who thinks being articulate is the same as being competent. I memorized buzzwords the way kids memorize cheat codes, assuming the more I said, the more respect I’d earn.
One time I even tried to explain “data consistency guarantees” to an engineer. I don’t know why. Heat of the moment. Temporary insanity. Some demonic force possessing me.
He listened politely — painfully politely — until I finished. Then he said, “Yeah, that’s… not how any of this works.” And the rest of the call died like a candle in the wind.
I spent the rest of that week replaying the moment in my head like a car crash you can’t stop re-watching.
Years later, I realized something obvious: Engineers don’t expect you to understand the system. They expect you to understand the cost of being wrong.
The turning point for me came during a call with a CTO who looked like he hadn’t slept in three days. The kind of guy whose brain is juggling six incidents while he’s pretending to care about your product demo. Right before we started, he said, “Look, I don’t need another salesperson trying to impress me. I need someone who won’t create more work for my team.”
For whatever reason, that line cracked me open.
I admitted — bluntly — that I wasn’t technical. Not “a bit technical but not deep”. Not “used to code years ago”. Not “comfortable with the basics”.
Just: “I’m not technical and I won’t pretend. Tell me how you think, what you fear, what you don’t want me to screw up, and I’ll work around you.”
The whole call shifted. The CTO relaxed, shoulders unclenched, voice slowed down. He walked me through their architecture not because I understood it but because I understood him — a man who would get the blame when things broke, even if they weren’t his fault. He talked about tribal scars: outages at 2 a.m., phantom CPU spikes, a vendor whose SDK destroyed their weekend deployment, a junior dev who rage-quit after a rollback disaster.
This wasn’t a technology conversation. It was a therapy session disguised as a demo.
And that’s when I realized what selling to engineers actually is: It’s not about features. It’s about empathy for consequences.
After that, I changed how I walked into technical calls.
Instead of trying to look smart, I tried to look safe.
I’d say things like: “Tell me the one thing I absolutely cannot mess up for you.” or “If this project goes sideways, who gets yelled at first?” or “What’s the stupidest thing a salesperson has promised you this year so I know where the bar is?”
They always laughed — the bitter laugh of someone who’s seen things.
Once, an engineer told me about a vendor who promised “frictionless migration”. Three months later their staging environment was a war crime. When I said, “We’re not frictionless — but here’s exactly where the friction is,” he literally leaned closer to the webcam, as if honesty was a signal he hadn’t heard in a while.
There’s something else too: Engineers have this sixth sense. Call it bullshit radar, call it pattern recognition, call it years of debugging lies told by logs. Whatever it is — they pick up on your intent faster than any other buyer.
If you walk in trying to impress them, you lose. If you walk in trying to understand their world, they’ll give you the blueprint.
But here’s the twist: understanding their world doesn’t mean being technical. It means being able to say, “I don’t know, but I’ll get you the truth.” And then actually doing it.
The fastest way to earn credibility with an engineer is to say “I don’t know” without flinching.
The second fastest is to bring the right technical person from your side not as a prop but as a translator. Not the SE who delivers monologues from the documentation, but the one who knows how to talk about failure states like they’re telling a story around a campfire.
There was one deal I’ll never forget — a big one, high pressure, high visibility. We were deep in evaluation and everything depended on the engineering team trusting us. At some point, one of their leads asked me a question I didn’t understand at all. Not even the topic. Not even the vocabulary.
Five years earlier I would have tried to dodge. Or improvise. Or mutter something vague like “Let me circle back on that.” This time I just said, “Explain it like I’m an idiot.”
He paused for a second — probably shocked at the honesty — then laughed and said, “Sure.” And he did. And the simplicity of his explanation showed me something no sales book ever taught: Engineers don’t judge you for being ignorant. They judge you for pretending you aren’t.
We won that deal. Not because our tech was perfect — it wasn’t. Not because our pitch was sharp — it wasn’t every day. We won because they trusted that when something eventually broke (and something always breaks), we’d show up without lies.
So here’s the part that younger reps never believe until they live it:
Selling to engineers is the easiest kind of selling.
But only after you stop performing.
If you’re honest, thoughtful, and unafraid to expose what you don’t know, they’ll open the door. If you fake competence, they will close it so gently you won’t even realize they locked it.
And in enterprises, engineers are the ones who whisper to the actual decision makers, “Yeah, this vendor seems legit,” or “we’re not touching this with a ten-foot pole.”
It’s rarely the deck, the pricing, the trial, or the workflow diagrams. It’s the feeling of whether you’re someone who adds risk or removes it.
Everything else is noise.