Imagine this...
You’ve spent weeks — maybe months — crafting a solution.
You’ve carefully considered each step, each line of code, and each corner case.
It’s solid, it’s sound, and you know it’s the right choice.
Now comes the hardest part — explaining it to people who have no clue about the tech world you live in, but they must approve your solution before you can proceed.
And not just explaining it but defending it, selling it, and proving why it’s the way to go.
Over and over.
It’s like you’re stuck in a loop where every “yes” you earn has an expiration date.
Next week, you’re back in the same room, justifying the same choice, maybe to the same or different set of people.
Sounds familiar?
If you’re a developer, tech lead, or an architect, you know this frustration.
There’s an exhaustion that comes from constantly selling your technical solutions to non-technical stakeholders. It’s a mental drain that’s hard to shake and can leave you feeling undervalued or even resentful.
In the two decades of my software career, I’ve been in such situations more than I would like. Through my experience, I’ve found there is a skill to it that can help you sell your solution efficiently.
Here’s the reality — justifying your technical choices is part of the job. But that doesn’t make it any easier or less frustrating. So, let’s talk about how you can handle it most efficiently without losing your sanity.
1. Break It Down Like You’re Explaining to an Eight-Year-Old
As software engineers, it is tempting to use technical jargon. It makes us feel proud of our knowledge.
But that’s the first misstep.
Think about it this way — if you’re explaining it like you’re talking to another developer, your stakeholders probably won’t understand. You have to come to their level while sharing your solution.
So break it down. If an eight-year-old can understand the gist, so can your stakeholder.
I am not asking you to feel like you’re dumbing it down. The suggestion is to simplify.
Focus on “why” rather than “how.” Instead of getting into the weeds, say something like, “This will make the system faster, which means your team spends less time waiting.” The simpler you can make it, the better.
2. Shift the Story from Tech to Business
Non-technical stakeholders don’t care about code. It’s harsh but true. What they do care about are results, efficiency, and cost savings. So make your decisions relevant to them.
Frame your solutions in business terms.
For example, if you’re pushing for a new software integration, don’t just talk about how seamless it will make your workflow. Explain how it’ll save the company time and money in the long run.
Or, share metrics on how your solution can make things more reliable, which means fewer outages and less downtime. Everyone loves to be as close to zero downtime as possible.
Suddenly, for your stakeholders, it’s not just a “tech upgrade” — it’s a business investment.
3. Use Analogies to Build Bridges
Analogies are like little shortcuts for understanding. They connect something new with something people already know. If you’re trying to explain why certain technical changes are important, compare it to something in the physical world.
Make the outcome of your solution relatable to the stakeholder and their needs.
Let me give an example from our team.
We prefer to keep the frameworks and libraries we use up-to-date. This means periodic upgrades to the code base.
But then these upgrades also bring in a few defects along with them due to developer oversight or changes in the way of doing certain things.
These changes or issues are unnecessary overhead from a business point of view. They don’t care how the application is running as long as it is meeting their needs.
So, to help them understand, we tried a different approach — “Think of our server or application like your vehicle. Just like a car or motorcycle needs oil changes and tune-ups, our servers and applications need maintenance to run smoothly and avoid breakdowns.”
Since then, we have hardly had to explain our subsequent upgrades to them.
4. Don’t Justify — Educate
Educating gives you authority, while justifying makes you sound unsure — even if you’re not.
When you’re on the back foot, you try hard to justify your actions. The same happens when you share your solution to gain the buy-in of your stakeholders.
And your audience can sense it.
There’s a subtle difference between “justifying” and “educating.” When you justify, you’re on the defensive. When you educate, you’re sharing knowledge.
This shift can make a world of difference.
Imagine this scenario — you’re being questioned for using a specific framework. By default, most engineers will try to enumerate all the technical perks because that is their comfort zone — the technical details. They feel they can justify their solution through all the technical benefits.
Instead, educate your stakeholders on how the framework is a standard in the industry, how it’s well-supported, and how using it can future-proof your application for meeting business needs.
Educating gives you authority, while justifying makes you sound unsure — even if you’re not. Combine the education along with sharing the business benefit derived from your solution and you have a winner.
5. Know When to Push Back (and When to Let Go)
Just remember — Not every fight is yours to win.
I like the phrase one of our Enterprise Architects frequently uses in such situations — ‘Ask yourself — Is this the hill you want to die on?’.
Sometimes, the battle just isn’t worth it. If you’ve explained your solution and given it everything you’ve got, it might be time to let go. Not every hill is worth dying on, and sometimes, you must choose which battle you want to fight.
I remember a project where the stakeholders didn’t sign off on an upgrade to be done in a specific quarter, and we wanted it to happen. I pushed, I reasoned, and I even showed them numbers.
But in the end, I just could not break through their defence. At a certain point, I chose to let it go for the time being and focus my energy on something more fruitful.
Just remember — Not every fight is yours to win.
The Takeaway: How to Sell Your Technical Solution
As a software engineer, your expertise is in the technology. You know what works and what does not for your application.
But to succeed in your career, your expertise must also consist of how to communicate effectively with your non-technical stakeholders. For that, you must shift your focus from “selling” to “connecting” by taking control of the conversation.
So, next time you’re trying to gain approval for your solution — go in with confidence and an open mind.
Instead of viewing the discussions as a drain, see it as an opportunity to build bridges and trust.
So go in, make your point, and then let your work speak for itself.
Subscribe to my free newsletter to get stories delivered directly to your mailbox.
