The “Soft” Skills Are the Hard Part And They’re Learnable Like Anything Else
Let me make a case to the engineers, analysts, scientists, and developers in the room in language you’ll trust: the term “soft skills” is a naming error, and it’s quietly costing a lot of brilliant technical people the influence their work deserves.
Here’s the pattern I see constantly. Someone spends years becoming genuinely excellent at a hard technical craft. They can architect the system, prove the result, debug the thing no one else can. And then they hit a ceiling that has nothing to do with their technical ability. The promotion goes to someone whose code was arguably worse. The idea they raised in March gets adopted in June credited to the person who explained it well in the room. They start to suspect, quietly, that the game is rigged toward the “talkers.”
I’d offer a different diagnosis, and it’s more hopeful than it sounds.
The game isn’t rigged toward talkers. It’s rigged toward translation.
Your technical work only creates value when a decision-maker understands it well enough to act on it. Communication, persuasion, and stakeholder management aren’t a popularity contest bolted onto the real work they’re the interface layer between what you built and whether it ships. A brilliant solution no one adopts has, functionally, an impact of zero. That’s not a moral claim. It’s just the math of how organizations convert insight into outcomes.
So let me reframe “soft skills” in terms your discipline respects. These are learnable, debuggable, iterable skills. You did not emerge from the womb writing clean code; you practiced, got feedback, refactored, improved. Influence works identically. The only reason it feels innate in some people is that they got their reps earlier. You can get yours now. Nothing about a technical mind makes you bad at this; in fact, the same rigor you bring to a system makes you unusually good at it once you decide it’s a system worth learning.
A few places to start, framed as problems to solve rather than personality to change.
Optimize for the listener’s model, not your own. The most common failure mode I see in technical communication is completeness explaining the full derivation when the audience needed the headline and one reason. Your manager doesn’t want the whole dependency graph; they want to know what it means for the timeline, the risk, and the decision in front of them. Before you present, ask: what does this specific person need to know to act, and in what order? Lead with the conclusion. Offer the depth on request. You’re not dumbing it down you’re routing the right payload to the right endpoint.
Treat persuasion as requirements-gathering. Persuasion has a bad reputation among honest technical people because it sounds like manipulation. It isn’t. Effective influence starts by understanding the other person’s actual constraints and interests, their deadlines, their incentives, what they’re measured on. When you frame your idea in terms of the problem they’re trying to solve, you’re not spinning. You’re doing the same thing you’d do before designing any system: gathering the real requirements before proposing the solution.
Make your work visible without apology. Many technical professionals believe good work should speak for itself. It doesn’t, not because the world is unjust, but because decision-makers have limited attention and can’t act on what they can’t see. Saying “I built X, which reduced Y by Z” is not bragging; it’s a status report the organization needs in order to position you correctly.
Silent excellence is a logging failure. Turn the logs on.
This is, at its core, a leadership skill set, and leadership is learnable too. It runs on systems literacy: understanding how decisions get made around you, how influence flows, how positioning is designed rather than deserved. The good news for a technical mind is that these are systems, and systems are exactly the thing you were trained to read.
So here’s my challenge for the month. Pick one skill and treat it like a project with a definition of done. Maybe it’s leading every update with the conclusion. Maybe it’s asking one stakeholder about their constraints before you pitch. Maybe it’s stating your impact in one clean sentence in your next review. Ship it, watch what happens, iterate. Run the reps.
Your technical excellence got you in the room. Learning to translate it, to make people understand and act on what you know, is what will let you actually lead in it. And that’s not the soft part of your career. It might be the highest-leverage engineering problem you ever solve.
Ready to build the influence layer on top of your technical skill? Explore the WIN Leadership Lab and coaching at winwithkara.net.