Let’s borrow a famous quote from a man who understood corporate negotiation better than any MBA graduate:
“If you’re good at something, never do it for free.”
— The Joker, The Dark Knight
Now, before you judge the source — yes, this is advice from a man who set fire to a pile of money just to prove a point. But if you have spent more than two years in the IT industry, you will realize this line contains more corporate wisdom than every keynote speech at every tech conference combined.
Because the moment you prove you can fix something, you will be expected to fix everything. Forever. For free. With a smile.
Otherwise you will be asked: Why so serious?
“If It’s So Simple, Why Didn’t You Just Fix It?”
This is the most dangerous sentence in the entire IT industry. It is disguised as a question, but it is actually a trap — a weaponized piece of corporate rhetoric that does three things at once:
It implies the work is trivial.
It shifts responsibility to you.
It erases the years of knowledge required to even understand the problem.
Here is how this typically unfolds.
A production bug appears at 4:47 PM on a Thursday. The business is screaming. Three managers are in a group chat typing variations of “URGENT” in all caps. The QA team is saying it “works in their environment.” The Product Owner is spinning up a group chat with every engineer in the org—because nothing says “incident” like 14 people typing at once. Everyone’s rushing to orchestrate the chaos, because in this company, incident management is a competitive sport. If they’re not running the show, it might never get fixed (or worse, someone else gets the credit).
You look at the logs. You identify the root cause in twelve minutes. You push a fix in eight more. Total resolution time: twenty minutes.
And then someone — usually the person who contributed nothing to the resolution — says:
“Oh. That was it? If it was that simple, why didn’t we catch it earlier?”
That sentence should be framed and hung in every engineering office as a warning. Because it reveals the deepest misunderstanding in our industry:
They don’t see the years. They only see the minutes.
The Iceberg of Competence
Let’s do the math on that “simple” twenty-minute fix.
What the business saw:
Engineer opened laptop
Engineer typed some things
Bug disappeared
Total effort: “basically nothing”
What actually happened:
3 years of learning how the platform works
2 years of fighting the same architectural patterns across different projects
400 hours of reading Stack Overflow threads at 2 AM
An instinctive understanding of where to look in the logs because you’ve personally caused similar bugs before and lived through the consequences
12 minutes of pattern recognition that only works because of all of the above
8 minutes of typing the fix with the confidence that it won’t break five other things
That twenty-minute fix is the visible tip of a ten-year iceberg. But icebergs don’t show up on Jira timesheets.
The business sees the 20 minutes. They don’t see the decade underneath. And because they don’t see it, they don’t value it.
This is exactly what the Joker was talking about.
The Competence Tax
Here is what happens when you are the person who fixes things fast.
Phase 1: The Discovery.
You fix something quickly. Someone notices. “Wow, that was fast.” You feel good. You are useful. The dopamine hits.
Phase 2: The Expectation.
Next time something breaks, they come straight to you. Not because it’s your job. Not because it’s in your sprint. Because you were fast last time.
Phase 3: The Normalization.
Your speed becomes the baseline. Twenty minutes isn’t impressive anymore — it’s expected. If it takes you an hour, they ask what went wrong. If it takes a day, they escalate.
Phase 4: The Entitlement.
Now you are the unofficial on-call for every problem that isn’t even in your domain. Salesforce Flow broke? Call The Engineer. Data migration failed? Call The Engineer. Someone accidentally deleted a Production dashboard? Call The Engineer.
You are no longer an engineer. You are a free emergency service with a Jira login.
Phase 5: The Invisible Ceiling.
Here’s the cruelest part. In annual reviews, nobody says: “This person saved us 47 times this year from production disasters.” They say: “Solid performer. Reliable.” Maybe a 3% raise. Because firefighting doesn’t show up on a roadmap. Heroism doesn’t have a story point estimate.
You were good at something, and you did it for free. Now it’s your unpaid second job.
The Picasso Napkin Problem
There’s a famous story — probably apocryphal, but the lesson is real.
A woman sees Picasso in a café and asks him to draw something on a napkin. He sketches something in 30 seconds and says, “That will be $10,000.”
She says: “But it only took you 30 seconds!”
Picasso says: “No. It took me 40 years and 30 seconds.”
Every engineer has this napkin moment at least once a week. You walk into a meeting. Someone describes a problem that has been plaguing the team for a sprint. You listen for 90 seconds and say: “It’s the trigger order. The before-update fires after the Flow, not before. Swap the execution order and it’s fixed.”
Silence. Then: “Oh. That’s it?”
That’s it. That’s $10,000 on a napkin. But because it sounded simple when it came out of your mouth, the entire room just unconsciously devalued ten years of your career.
Why the Joker Was Right (About This One Thing)
The Joker wasn’t making a career coaching point. He was describing a power dynamic.
When you give away your expertise for free — without boundaries, without recognition, without scope control — you teach the organization that your knowledge has no cost. And anything with no cost gets consumed without limit.
This is basic economics applied to engineering skill:
If the fix is free, there is no incentive to prevent the bug.
If your time has no boundary, meetings will consume all of it.
If heroism is expected, it stops being rewarded.
The organization doesn’t do this maliciously. It is a system. Systems optimize for whatever is cheapest. If your expertise is free, the system will drain it until you burn out, quit, or become the bitter senior engineer who says “not my problem” to everything — which, by the way, is just a burned-out version of the person who once said yes to everything.
The Playbook: How to Stop Working for Free
You don’t have to become the Joker. You don’t have to set fire to anything. But you do need to stop subsidizing broken processes with your unpaid labor.
1. Make the invisible visible.
When you fix something in 20 minutes, follow up with a short message:
“Root cause: execution order conflict between Process Builder and Record-Triggered Flow. Resolution: reordered automation sequence. Underlying issue: no automation inventory exists for this object. Recommend we build one to prevent recurrence.”
This does two things. It shows the actual complexity. And it shifts the conversation from “that was easy” to “we have a structural problem.”
2. Scope your help.
When someone asks you to fix something outside your sprint: “I can look at this, but it’s not in my current scope. If this is a priority, let’s talk to PO about reprioritizing.”
You are not saying no. You are saying: this has a cost, and someone needs to decide if it’s worth paying.
3. Stop being the single point of failure.
If you are the only person who can fix something, that is not a compliment. That is a bus factor of one. Document it. Train someone. Refuse to be the only one. The organization’s inability to build redundancy is not your personal burden to carry.
4. Price your time in trade-offs.
Every time you spend 20 minutes on an unplanned firefight, that is 20 minutes stolen from the actual roadmap. Make that trade-off explicit:
“I can fix this now, but that means Feature X slips by a day. Which one do we want?”
Now the cost is visible. Now someone has to make a decision instead of getting free labor disguised as teamwork.
5. Let it burn (a little).
This is the hardest one. Sometimes the most valuable thing you can do is not fix the problem. Let the broken process produce its natural consequence. Let the missing test coverage cause the regression. Let the skipped code review result in the rollback.
Pain is the only currency that buys organizational change. If you absorb all the pain, nothing changes.
The Economics of “Simple”
Next time someone says “if it’s so simple, why didn’t you just fix it?” — remember:
The diagnosis was simple because you are experienced. Not because the problem was easy.
The fix was fast because you have failed at this exact thing before and learned from it.
The calm was possible because you have panicked through enough production incidents to know what panic buys you: nothing.
Simple is what expertise looks like from the outside.
From the inside, it is a decade of compound interest on every mistake, every late night, every “why is this not working” spiral.
Bonus: Copy/Paste Responses
For when they say “that was quick, must have been easy”:
“It was quick because I’ve seen this exact failure pattern before. The experience was not quick.”
“The fix is 3 lines. The knowledge of which 3 lines took 10 years.”
“If we want to prevent this, the real fix is structural change. The quick fix just buys us time.”
“Happy to help. Let’s make sure this is tracked so the effort is visible.”
“Simple fix, complex root cause. I’ll document both.”
For when they ask you to fix something outside your scope:
“I can advise, but ownership should stay with correct team. I’ll pair with them.”
“This needs a ticket and a priority call. My sprint is full.”
“I know how to fix it. Let’s make sure someone else also knows, so we’re not single-threaded on this.”
If you’re good at something, never do it for free.
Not because you’re greedy. Because if you do, no one will never understand what it actually costs. And what no one understands, how can then anyone properly value it?
Be an engineer.