Here’s what being “difficult” actually looks like in engineering.
It’s not what you think.
Imagine you’re asked to represent your team in a series of highly technical meetings.
The stakes are high: you’re there to protect critical workflows, safety protocols, and architectural integrity. You’re not just relaying updates—you’re drawing lines. You make it clear: unless there are strong reasons and strong safeguards, some decisions should not move forward.
Now imagine that—even after those conversations—people decide:
- They don’t need to keep their commitments.
- They don’t even need to understand what they committed to.
- They can move forward on something they agreed to wait on—then call you difficult when your team pushes back.
- They’ll claim you can’t enforce a boundary now because you didn’t explicitly forbid it before they tried it, even when it is a bad practice they never brought up.
- They’ll say you’re “discouraging” because you pointed out their “easy fix” was going to be complex, risky, or flat-out irresponsible.
You end up having to say: “We can’t approve this PR unless we understand the rationale—because you made decisions about our architecture without including us.” Or: “We have to be on the same page as to what you are trying to accomplish before we will move forward with this code change.”
And while all of that’s happening?
You will also have to correct the record:
- Reminding people of documented and verbal agreements.
- Taking screenshots of the docs you sent months ago when someone claims, “We never got any documentation.”
- Confirming teams never followed the tutorials, never spun up the stack, never even tried—before declaring the system “too hard.”
You will push for clarity, transparency, and follow-through—and somehow that makes you the obstacle.
So what does being difficult actually mean?
Being difficult means:
- Pushing back on bad decisions and broken agreements.
- Not allowing people to reframe conversations dishonestly.
- Correcting the record when someone tries to say you agreed to something you didn’t.
- Saying “I asked for a meeting, not a PR,” and meaning it.
- Holding the line when someone tries to bypass architectural boundaries.
- Standing firm when the safest and most responsible answer is “no, not like that.”
Because if you don’t hold that line?
Your team gets hurt.
Your product gets hurt.
Your platform gets risky.
And the person who let it happen was the one too afraid of being seen as “difficult.”
Now imagine getting dinged on a review—or several—because of that.
Even though everyone agreed, at the time, that your pushback was necessary.
Even though what the other team proposed was objectively unsafe.
You still get told you need to “keep an open mind” about architectural decisions.
Because protecting the system wasn’t the problem—having the audacity to say no was.
And here’s the part no one likes to say out loud:
The opposite of being difficult isn’t being nice.
It isn’t being friendly.
It isn’t collaboration.
The opposite of being difficult… is compliance.
So yes—I’m proud to be difficult.
It suits me.
It protects my team.
It defends the architecture.
And it makes sure no one ever mistakes silence for agreement.