Before I was a software engineer, I was a salesperson. It has shaped me into who I am today. I want to share some reflections on how my previous sales career helped me become a better software engineer.
When I tell people about my background in sales, I often get raised eyebrows 😲. There’s a perception that sales and engineering are completely different worlds. One is about relationships and persuasion, maybe even the occasional white lie 🙊. The other is cold logic, cranking out code, taming large systems.
The truth is, the skills I learned in sales have been absolutely crucial to my success as a developer. In fact, I’d argue that many of the soft skills that make engineers truly exceptional aren’t technical at all.
Lesson 1 – Problem Solving 🧠
This one is pretty universal and can be learned in any career path if you have the gumption. But the specific problem-solving I’m referring to is interpersonal problem-solving.
“How can I get Dave in Accounts Receivable to work closely with Linda in the warehouse to ensure the delivery goes smoothly?”
Or, “How can I position our company so that client abc chooses us over a competitor?”
Sales is mostly this: interpersonal problem solving. Getting people to work together. Winning new business or increasing existing business by solving problems for clients. You’re constantly solving problems that involve multiple stakeholders with competing interests and different communication styles. It can get messy, but if you take the time to learn from it, it can teach invaluable lessons.
When we take our problem-solving sales glasses, put them on, and take a closer look at the problems we solve as software engineers, it’s like instant wall hacks. For my non-gamer readers: a cheat code.
You immediately level up by seeing all the gaps in your org structure and n your team, and you see problems you can solve for your client. Simply identifying the problem can lead you to great success. It allows you to identify a solution, which may not even need code. Wouldn’t that be nice 😉.
One time, I had a client ask me to build a small new feature. They wanted me to add authentication to their website. All the software devs reading this are nodding, saying, “Yes, small.” Joking aside, that would have wrecked the timeline and sent the project into a tailspin. Instead of focusing on how I could shoehorn auth into this project, I asked questions to better understand what problem the client was trying to solve. We uncovered that they were trying to capture analytics and track users. I suggested a lightweight analytics integration that would completely sidestep a whole lot of chaos. Most importantly, the project stayed on track, and the client was happy, even though I didn’t build what they asked for.
This sales solutioning perspective helps you see upstream and downstream effects of your work. You start asking questions like: who else is affected by this change? What problems might this create for other teams? How can I make this transition smoother for everyone involved? These aren’t technical questions, but they’re often the difference between a successful implementation and one that creates more problems than it solves.
Lesson 2 – Tenacity 🗿
It’s easy to get down from rejection. Honestly, most of the sales motivational speaking is trying to get salespeople to get out of their heads. Because management knows eventually they’ll win if the team sticks with it. I’ve even got my own stories of wins where if I hadn’t stuck with it, if I had listened to the prospective customer when they said “I’m happy with my current vendor,” then I would have missed out on the biggest sale of my life. But I didn’t turn around. I was respectful, of course, and courteous for sure. But I was also present and tenacious, and I ended up being in the right place at the right time.
The thing about tenacity in sales is that it teaches you to separate the “no” from the “not yet.” When someone rejects your proposal, you learn to ask better questions: What would need to change for this to work? What are the real blockers here? Is this a timing issue or a fundamental mismatch? This mindset shift transfers to software. Imagine you’re debugging a particularly stubborn piece of code or trying to get buy-in for a new architecture. Tenacity definitely will come in handy 💪🏽.
Working through project roadblocks becomes second nature when you’ve spent years hearing “that won’t work” and turning it into “here’s what needs to happen for this to work.” The persistence you develop in sales isn’t about being pushy – it’s about being resourceful and creative in the face of obstacles.
Lesson 3 – Persuasion and Influence 💭
This one is contentious. A lot of people feel this is why salespeople are all bad. People are afraid they are being manipulated. Now, I’m not here to say that salespeople don’t lie or misrepresent their products. Some do. But, I’d like to think the vast majority of salespeople are just helping their prospective customers see a different perspective that’s favorable to them, the seller. And to do that, the salesperson has to believe that what they’re selling is good for the buyer and generally adhere to an acceptable level of ethics.
If we look at it from that angle, it’s easy to see how helpful it can be when you have an opinion you’re “selling” and wish to gather support. Persuasion is a tough skill. It can be difficult to learn because you need a certain degree of emotional intelligence to understand your audience and an even better understanding of yourself. Then you need to know how you are perceived by that audience. I know it’s a lot.
Ethical persuasion is really about helping people see possibilities they hadn’t considered. In engineering, this might mean helping your team understand why investing time in refactoring will pay dividends later, or explaining to stakeholders why a more complex technical approach will actually save time and money in the long run. You’re not manipulating anyone. You’re just providing perspective and information that helps them make an informed decision.
The influence skills from sales also help you navigate organizational dynamics more effectively. When you want to advocate for better tooling, or push back against unrealistic deadlines, or propose a new approach to solving a problem, you need to understand how to frame your argument in terms that resonate with your audience. It’s not manipulative. It’s about being strategic in how you communicate value and manage change.
The reality is that software engineering is ultimately a human activity. We build products for humans, we work in teams with humans, and we solve problems that humans care about. The interpersonal skills I learned in sales haven’t just made me a better engineer – they’ve made me a more effective problem solver and a better colleague. And in a field where technical skills become obsolete every few years, those human skills have been the most durable investment in my career.