I lost my job for being right. Not for being wrong — for being right, but saying it the wrong way, to the wrong people, at the wrong time. That experience taught me something no bootcamp or MBA ever will: how you communicate matters as much as what you know.
Let me tell you what happened.
The Setup
By 2005, I was a senior developer at HP. A few years earlier, my team had built a content management system called ActiveAnswers that became so successful it was adopted company-wide after the Compaq merger.
I was the one who had convinced the team to take on the “impossible” project in the first place. I was feeling pretty confident about my judgment.
We’d rewritten the entire system into a WYSIWYG editor. It was working well, but our Visual Basic codebase was starting to feel overweight. So, with support of our manager, a few of us experimented with .NET — Microsoft’s new framework, which was about three years old at the time.
Though we struggled a bit at first, we thought things were going well. Leadership wasn’t convinced, however. After a few weeks, word came down: the experiment was over. We were to go back to Visual Basic for all new code.
The Decision
A few weeks later, we hit a particularly difficult problem. Visual Basic simply didn’t have the language facilities to solve it without massive brute-force coding. C# and .NET had a straightforward solution.
So I made a decision.
I implemented the component in C# — without permission.
My plan was to show management that .NET was still the right choice. The solution was everything I’d hoped: short, elegant, easy to understand.
I knew better than everyone else. No one understood the problem as I did.
At least, that’s what I told myself.
The Phone Call
We had a tradition: each new feature would be revealed on a team-wide conference call. The developer would demo the feature, show passing tests, and answer questions.
This was my time to shine — or so I imagined.
About 25 people were on the call, including my manager and the enterprise architect. Everyone agreed the functionality was correct. During Q&A, my peers wanted to see the code. I was happy to oblige.
Then the architect interrupted: “I thought we weren’t using .NET anymore. Why did you use .NET?”
I explained my reasoning. I walked through the elegant code. I pointed out where C# offered capabilities that VB simply didn’t have. I suggested that, as the senior developer, I felt it was within my purview to take calculated risks.
That explanation was not good enough.
The architect berated me in front of my colleagues for the next few minutes. He stripped my architectural authority on the spot. Someone else would rewrite my code in Visual Basic.
Dead silence.
The Moment I Sealed My Fate
Then I did something that probably sealed my fate.
I apologized: “I’m sorry. I honestly felt this was the best solution for the project and the team. Given the choices I had, I did what I thought was best. I won’t make that mistake again.”
And I hung up.
Here’s the thing: I had initiated the call. When the initiator left, the meeting ended for everyone. I’d inadvertently killed the entire meeting — and hung up on the architect in front of the whole team.
The Aftermath
A week later, my manager called. First, she assured me I wouldn’t be fired. However, I’d be on probation for 12 months. No promotions. No raises. No internal transfers.
Instead, I tendered my two-week’s notice and resigned on the spot. She “negotiated” to four-weeks, and I agreed.
I walked out a month later. I wouldn’t work as a software developer again for three years.
What I’d Do Differently
Looking back, I was right about the technology. I was wrong about everything else.
Here’s what I wish I’d done:
Build Your Case First
Before going rogue, I should have gathered evidence. A side-by-side comparison of both solutions would have given me ammunition for a proper conversation — not a fait accompli that put management on the defensive.
Choose the Right Venue
A team-wide demo was the wrong place to reveal my decision. A private conversation with my manager first would have given her the chance to support me or redirect me — without public embarrassment.
Offer Options, Not Ultimatums
Instead of presenting my C# solution as the only answer, I could have said: “Here’s the Visual Basic approach, and here’s an alternative in C#. I recommend the latter because…”
This frames you as a problem-solver, not a maverick.
Separate the Idea from Your Ego
I was convinced I was right — and technically, I was. But being right about the technology didn’t make me right about how I handled it.
Learn to advocate for your ideas without making them inseparable from your identity.
Know When to Fold
Sometimes the answer is still no. If leadership rejects your approach after a fair hearing, you have a choice: accept it and move on, or decide the disagreement is fundamental enough to leave.
What you shouldn’t do is what I did — ignore the decision and force the issue.
Accept the Consequences
If you do push back anyway, own what happens next. I don’t regret standing up for what I believed was the right technical choice. I do regret not handling the aftermath with more grace.
The Bottom Line
Disagreement is inevitable. In any career worth having, you’ll find yourself at odds with someone who has power over your future.
The question isn’t whether you’ll disagree. It’s whether you’ll handle it in a way that preserves your reputation, your relationships, and your options.
I learned that lesson the hard way. Three years away from software development is a long time to think about what you could have done differently.
This article is adapted from my book Don’t Say That at Work — 26 communication lessons from 30 years in tech, plus a free bonus book on giving presentations. Available DRM-free on Gumroad or on Amazon.