Career Development, Soft Skills, Leadership People Skills Are Technical Skills (And I Can Prove It)
13 min read
9 views
Introduction
Let me start with a story you’ve definitely lived inside of, even if you haven’t told it out loud.
Sprint planning, Monday morning. You message the team: “The auth service is broken because the token refresh logic doesn’t handle edge cases in the OAuth flow.”
Your PM asks the group: “Is anything blocked?”
Nobody answers. The PM assumes things are fine. The auth service stays broken for three more days before anyone escalates. You technically communicated — you sent accurate information to the right channel at the right time. But nothing changed. Nothing got resolved. And by Thursday, you’re wondering why your PM “never listens.”
That’s not a technical failure. That’s a communication failure. And here’s what gets me: we’ve been calling communication a “soft skill” this whole time, as if that distinction explains why we don’t study it, practice it, or put it on our personal development roadmaps.
This article is my attempt to fix that — and to give you a framework for the 7 people skills that I believe are most critical to your career as a developer.
The Problem With “Soft Skills”
I’ve read a lot of job descriptions in my time. Frontend developer, mid-level, senior, staff — they all have a section at the bottom. You know the one. “Strong communication skills.” “Collaborative team player.” “Demonstrated leadership potential.”
We read that section and we skip it. We spend our prep time on the technical requirements — the TypeScript, the framework, the system design. And then we get to the interview, nail the coding challenge, and get dinged in the debrief for being “hard to work with” or having “communication concerns.”
Here’s what I’ve come to believe after years of building, shipping, speaking, and learning in public: we’ve been mislabeling these skills. Calling them “soft” implies they’re somehow less real, less learnable, less measurable than the skills we call “technical.” That’s not true. And it’s actively costing us.
67% of failed software projects trace back to interpersonal breakdowns — not technical failures. I’ll say that again for the folks in the back: two-thirds of the things that blow up in your career are people problems, not code problems.
What Actually Makes a Skill “Technical”?
Here’s a working definition: a technical skill is specialized knowledge and expertise required to perform a specific task in real-world situations.
Four criteria:
- Specialized knowledge — you have to actually learn it
- Expertise via practice — it gets better with deliberate repetition and feedback
- Measurable outcomes — it produces something real and observable
- Real-world application — it gets tested outside of the tutorial
Now apply that same test to communication. Do you have to learn it? Yes — nobody comes out of the womb knowing how to calibrate a message for a technical versus non-technical audience. Does it improve with practice? Yes. Does it produce measurable outcomes? Absolutely — blockers get resolved, trust gets built, features ship. Does it get tested in the real world? Every single day.
Communication clears every bar. So does interpersonal skills. So does time management. So does every skill on the list I’m about to walk through.
The “soft/hard” distinction isn’t describing the nature of the skill. It’s describing how uncomfortable we are with the idea that we need to study it.
The 7 Tenets of Peopling Well
I built this framework through trial, error, a lot of failed Slack messages, and one particularly memorable PR comment war that I am not proud of. Each tenet follows the same structure: what it is, what it looks like when you’re doing it wrong, what right looks like, and — most importantly — what better looks like.
01 · Communication
The hook: The most technically correct message, delivered badly, is still a failed message.
What it is: Sending and receiving information clearly — across technical and non-technical audiences, written and verbal, synchronous and async.
Doing it wrong looks like optimizing for precision over clarity. Writing Slack messages like commit messages. Ghosting threads. Over-documenting while under-communicating. Sending a wall of technical context to a PM who just needs a status.
Doing it right means adjusting your register for your audience. How you explain a bug in a code review is not how you explain it to a product manager — and both versions can be technically accurate. The question is: which one gets acted on?
Doing it better: Treat your written communication like code. It can be refactored. Ask for feedback on your Slack messages and your documentation the same way you ask for feedback on a pull request. That framing changed everything for me.
The auth service scenario from the opening? That’s this tenet. You communicated correctly. You failed to communicate effectively.
📣 Pick your tenet: Is communication the one you actively avoid? Write it down. Right now. We’ll come back to this at the end.
02 · Interpersonal Skills
The hook: You can be the best engineer on the team and still be the reason good people leave.
What it is: The ability to build and maintain working relationships — trust, respect, and conflict navigation with the people who share your codebase.
Doing it wrong looks like optimizing to be right in meetings instead of effective. Confusing directness with aggression. Making someone feel dumb for asking a question you’ve answered three times before. Treating collaboration as an obstacle to shipping.
Doing it right means assuming good intent before jumping to conclusions. That person who made the bad architectural decision you’re now cleaning up? They made it under pressure, with limited information, on a deadline — exactly the way you’ve made decisions before.
Doing it better: Know your teammates as people. What they’re working on outside of work, what they’re stressed about, what they care about. It sounds obvious. It’s rarely practiced. And it makes the hard conversations significantly easier when you actually have to have them.
The PR comment scenario: “This is the wrong approach entirely.” No explanation, no suggestion, just a rejection after two days of work. That’s not directness — that’s a skill gap. “Here’s why this might cause problems and here’s what I’d try instead” is a conversation. “This is wrong” is an opinion. Learn the difference.
03 · Problem Solving
The hook: Jumping to solutions is not problem solving. It’s solution cosplay.
What it is: A structured, collaborative approach to identifying root causes, evaluating tradeoffs, and making decisions under uncertainty — with and alongside other people.
Doing it wrong looks like jumping straight to implementation. Picking the first valid-looking solution. Solving problems alone when the problem lives in a system that involves multiple people. Calling a solution a problem.
Doing it right means defining the problem before defining the solution. “We need a new framework” is already a proposed solution — the problem it’s trying to solve might have three better answers. Ask “what problem are we actually solving?” before anyone opens a new branch.
Doing it better: Bring other people in earlier. The person closest to the user almost always knows something nobody in sprint planning does. Ask them first. The cost of that conversation is measured in minutes. The cost of solving the wrong problem is measured in sprints.
The 500 error scenario: Staging is throwing errors, half the team jumps into the codebase, fixes appear in multiple branches simultaneously. An hour later someone realizes the deployment pipeline ran the wrong migration. None of the code fixes were needed. All that engineering effort — wasted. Diagnose together before you split into solutions.
04 · Time Management
The hook: You can’t manage time. You can only manage decisions about what you do with it.
What it is: Protecting your capacity for deep work — not just task completion. Context switching and recovery are real costs that don’t show up in sprint estimates.
Doing it wrong looks like saying yes to everything. Treating your calendar like a public park. Context-switching fifteen-plus times a day and then wondering why your estimates are always wrong. Estimating in ideal hours and living in actual ones.
Doing it right means time-boxing your work, batching similar tasks, and treating focus time as a non-negotiable resource — not a luxury you get to when the meeting schedule slows down.
Doing it better: Communicate your constraints before they become emergencies. “I’m blocked until Thursday” said on Tuesday is a very different conversation than “I’m blocked and the deadline is tomorrow.” Your calendar is your architecture. If you wouldn’t ship code with no structure, don’t ship your week with no structure either.
05 · Adaptability
The hook: The sprint doesn’t care about your plan. Ship anyway.
What it is: Recognizing when conditions have changed, updating your approach accordingly, and bringing your team along — without making it a crisis for yourself or them.
Doing it wrong looks like treating the original plan like a contract. Letting sunk cost trap you on a bad path. Resisting pivots because you’ve already invested. Taking requirement changes personally, as if the client changing their mind is a personal attack.
Doing it right means decoupling your identity from your decisions. The call to use a specific technology was right with the information available at the time. New information changes the calculus — that’s engineering, not failure.
Doing it better: Build reflection into your process. Retros aren’t ritual — they’re a feedback loop. If you leave every retro with the same action items and nothing changes, the retro itself is broken. The engineers who advance fastest aren’t the ones with the best original solutions. They’re the ones who recover from changes the fastest.
06 · Attention to Detail
The hook: The bug that costs you the most is always the one you were “pretty sure” about.
What it is: The ability to catch what others miss — in code, requirements, communication, and decisions — and to build systems that reduce the likelihood of missing things in the first place.
Doing it wrong looks like mistaking speed for efficiency. Shipping fast and fixing “later” — where later quietly becomes never. Not having a checklist because “you’ll remember.”
Doing it right means externalizing your attention. Checklists. PR templates. Linting rules not just for code but for your own process. Systems are more reliable than memory — in engineering and in people.
Doing it better: Apply that detective energy to people too. When a conversation feels off, treat it like a bug. Reproduce it — what was actually said? Isolate it — where did things go sideways? Find the root cause before moving on. The date format production incident, the timezone bug, the missed edge case in the spec — all preventable. The system you don’t build is the one that fails.
07 · Leadership
The hook: Leadership is not a title. It starts the moment you have context that someone else doesn’t.
What it is: The ability to influence outcomes and people — whether or not your title says “Lead” — by sharing knowledge, creating clarity, and making the people around you more effective.
Doing it wrong looks like waiting to be promoted before acting like a leader. Hoarding context because knowledge is power. Staying quiet in meetings because “it’s not your place.” Thinking leadership only flows downward through org charts.
Doing it right means mentoring without being asked. Documenting decisions. Speaking up when you see a problem, even if you didn’t cause it. Being the person who makes the room better for having been there.
Doing it better: Seek out the small-stage reps. Run the retro. Write the post-mortem. Present at the team sync. The reps at small scale prepare you for the moments that matter. And remember: if you see the problem and you stay quiet, you own the outcome too.
As Homer Gaines — Staff UI Engineer and accessibility professional — put it: “Leadership is not about having all the answers. It’s about asking better questions than the people who came before you — and creating enough safety that the people who come after you feel comfortable asking better questions than you.”
That’s the whole game.
The Myths We Need to Retire
Myth: Soft skills are personality traits — you either have them or you don’t. Reality: Every tenet on this list is learnable, trainable, and measurable. You’re not born knowing how to give effective feedback any more than you’re born knowing how to debug a race condition.
Myth: Technical skills are hard. People skills are easy. Reality: Conflict resolution under deadline pressure is one of the hardest things you will ever do in an engineering career. Communication across a power differential is hard. Leading without authority is hard. The difficulty isn’t the argument — it’s that we’ve been treating these as optional.
Myth: This stuff isn’t relevant until you’re senior. Reality: Junior developers who communicate well get promoted faster and get better mentorship. The path from junior to mid to senior is not just technical. It’s almost never just technical. The people who figured that out early are the ones you look at and wonder why they keep advancing.
What You Can Do This Week
Three steps. No vague inspiration.
Step 1: Pick one. Not the skill you wish you were better at. The one you actively avoid. The one that shows up in your last few performance reviews but never makes it onto your personal roadmap. Write it down. Right now.
Step 2: Treat it like a skill. There are books, talks, and frameworks for every tenet on this list. You’ve spent hundreds of hours learning TypeScript. Invest 30 minutes in communication. Block it on your calendar. Label it “People Skill Practice.” No meetings in that block.
Step 3: Get a data point. Find one trusted teammate and ask them: “How am I doing at [the skill you picked]?” Specify a real situation. Ask for one concrete thing you could do differently. The answer will be uncomfortable. That discomfort is the data you need.
Further Reading
- Crucial Conversations by Patterson & Grenny — the definitive guide to high-stakes communication under pressure.
- The Culture Map by Erin Meyer — cross-cultural communication frameworks that apply even on single-timezone teams.
- Staff Engineer by Will Larson — the most honest map of the leadership skills that actually determine your trajectory past senior.
- “Scheming Is Always Good: A Developer’s Guide to Networking” → developingdvlpr.com — the companion piece on building and maintaining the relationships that make these skills matter.
- “How !To Be Mentored V2”** → *developingdvlpr.com — structured mentorship as a forcing function for people skill growth.
- ADPList — free platform to find mentors who’ve developed these skills and can help you develop them too.
Summary
People skills require specialized knowledge. They improve with deliberate practice. They produce measurable outcomes. They get tested in real-world conditions every single day.
They clear every bar we use to define a technical skill.
Hard to certify ≠ easy to master. Hard to measure ≠ not worth studying. Optional on your personal roadmap ≠ optional in your career.
Treat them accordingly.
📣 Your turn. If this resonated, I’d love to know which of the 7 tenets you’re working on. Send me a message via my contact page or find me on X at @Nerajno. I talk about this stuff constantly, and the community that shows up to those conversations is one of the best parts of building in public.
Nerando Johnson is a currently a junior frontend developer based in Atlanta specializing in Vue 3, TypeScript, and Nuxt. He creates content, speaks at conferences, and used to organizes Atlanta freeCodeCamp. Find him at developingdvlpr.com and @Nerajno everywhere.