Ever had someone ask you a question, then do the opposite of what you advised—or even tell you that they might just do the thing you advised them against anyway?
It happens to engineers all the time.
And I don’t mean the “what’s the right function name for this?” kind of question. I mean the “should we do this at all?” kind.
Spoiler: It’s not always a real question. Sometimes it’s just a polite way of saying, “I want your blessing on this kinda-bad idea.”
Of course, asking an engineer for quick information is usually fine.
“What’s the right API call here?”
“Have you seen this issue before?”
“Where does this data live?”
You’re not asking them to consult on your project. You’re just tossing them a puzzle piece and asking for some information. They may say, “Yep, lives over there with the Z-data.” Sometimes they’ll point you to a better piece.
But then there’s the other kind of ask.
The one where someone says, “We want to do X.”
And the engineer replies, “Oh, don’t do X. X is a bad idea. It’ll break in production, it’ll violate how our system works, and it’ll cause long-term pain.”
And after some back and forth, the reply is, “Yeah, we’re still going to do X.”
At that point… why’d you ask?
You’re not looking for engineering judgment. You’re just hoping someone will co-sign a shortcut. That’s not collaboration. It’s rubber-stamp theatre.
Not all objections are equal
If one engineer raises a professional concern—“this will break under load,” “this violates our architecture,” “this introduces risk”—and another engineer says, “Eh, I just don’t want to learn the new thing,” those are not the same.
You can’t treat a technical warning and a personal preference like they weigh the same on the scale. You have to know which is which.
Engineers are not reference manuals
You don’t bring in a structural engineer to ask how wide your bridge can be. You bring them in to tell you whether the bridge will stay standing when the hurricane hits.
The real value of engineering isn’t just in the bits and bytes. It’s in the judgment.
When you reduce someone to a question-and-answer station and then ignore the hard advice—the kind that comes from experience, context, and pattern recognition—you’re not just disrespecting the role. You’re setting yourself up to build something fragile. That means expensive and possibly even embarrassing over the long term.
If you want engineering input, treat it like input. Not optional seasoning you sprinkle on after the dish is cooked.
The point isn’t just to answer your question. The point is to help you avoid mistakes you might not even see yet.
If you already know what you’re going to do, regardless of the answer, then you need to own the risk.
That engineer isn’t a reference manual. They’re the person trying to keep the wheels on the bus while it’s going 70 down a gravel road. You’d do well to listen when they say, “Your wheels are going to fall off long before you arrive at your destination.”