Most soft skills lists aimed at IT professionals read like they were written by someone who has never sat in a sprint retrospective. “Be a good communicator.” “Show empathy.” Useful in theory. Useless when you’re staring at a Slack thread where two senior engineers are publicly disagreeing about an API contract, and you need to ship by Friday.
The soft skills that actually matter for IT professionals aren’t abstract personality traits. They’re specific behaviors that show up in specific moments: the code review that turns hostile, the stakeholder meeting where you need to explain why the migration will take three months instead of three weeks, the incident postmortem where blame is easier than learning.
This list covers 10 soft skills that matter in IT work. Each one is anchored to a real scenario you’ll recognize.
1. Written Communication
The scenario: Your team works across three time zones. A critical decision about database schema changes needs to happen, but the people who need to weigh in won’t be online for another eight hours. You write a Slack message. If it’s unclear, you lose a full day to follow-up questions. If it’s too long, nobody reads it. If it lacks context, people make assumptions and you end up with conflicting implementations.
Written communication is the most undervalued soft skill in IT. Engineers spend more time writing (Slack messages, pull request descriptions, design docs, Jira tickets, incident reports) than they spend in meetings. Yet most engineering programs teach zero writing.
The gap shows up fast. A vague PR description forces reviewers to read every line of code to understand intent. A design doc without clear problem framing gets derailed by tangential objections. An incident report that buries the root cause behind three paragraphs of timeline guarantees the same failure will happen again.
One technique to try: Before sending any written communication longer than two sentences, lead with the decision or action needed. “I need a decision on X by Thursday” or “This PR changes the auth flow to support Y” gives readers a frame before they hit the details. Context follows the ask, not the other way around.
Want to see where your communication skills stand today? Risely’s free assessment gives you a starting point.
2. Active Listening
The scenario: A product manager describes a feature request. You hear “we need real-time notifications” and immediately start architecting a WebSocket solution. Twenty minutes into your technical deep-dive, the PM says, “Actually, we just need an email when the status changes.” You weren’t listening for the underlying need. You were listening for a technical problem to solve.
Active listening in IT contexts is not about nodding and making eye contact. It’s about resisting the pull to jump to solutions before you’ve fully understood the problem. Engineers are trained to solve things. That instinct becomes a liability when the problem hasn’t been fully stated yet.
This shows up constantly in requirements gathering, user interviews, and bug reports. A user says “the app is slow.” An engineer who listens actively asks: slow compared to what? Slow on which actions? Slow since when? The one who doesn’t starts optimizing database queries when the actual problem is a third-party API timeout.
One technique to try: After someone finishes explaining a requirement or problem, restate it in your own words before proposing any solution. “So what you need is X, because of Y. Is that right?” This single habit catches misunderstandings before they become wasted sprints.
Take a closer look at your active listening skills with a free assessment.
3. Constructive Feedback
The scenario: You’re reviewing a pull request from a mid-level engineer. The implementation works, but the approach will create maintenance problems in six months. You could write “This is the wrong approach” and suggest your preferred pattern. Technically accurate. But the engineer will feel criticized rather than coached, and the next three PRs they submit will be defensive and over-documented.
Code review is where constructive feedback either builds team capability or destroys psychological safety. The difference between “Why didn’t you use the factory pattern here?” and “Have you considered the factory pattern here? It would help us when we need to add new providers later” is enormous. The first questions the person’s competence. The second shares reasoning and invites discussion.
Design critiques carry the same weight. Saying “this won’t scale” without explaining the specific scaling constraint gives the other engineer nothing to work with. Saying “this approach handles our current 10K daily requests well, but we’re projecting 100K by Q3, and this pattern would need X changes” turns feedback into shared problem-solving.
One technique to try: Frame feedback as questions or future-oriented observations rather than verdicts. Replace “This is wrong” with “What happens when…” or “I’m wondering about the case where…” You preserve your technical judgment while giving the other person room to think through the implication themselves.
Assess your constructive feedback approach with Risely’s free skill assessment.
4. Stakeholder Translation
The scenario: The VP of Sales asks when the CRM integration will be done. The honest engineering answer is “it depends on whether we refactor the event bus first, which depends on whether we prioritize the tech debt sprint, which depends on Q3 roadmap decisions that haven’t been made yet.” The honest answer is also completely useless to the VP, who needs to tell a customer something concrete by end of day.
Stakeholder translation is the ability to convey technical realities in terms that map to business outcomes. Not dumbing things down. Translating them. The VP doesn’t need to understand the event bus. They need to understand: “If we prioritize the integration now, it ships in 6 weeks but it’ll be fragile. If we do the foundation work first, it ships in 10 weeks but it’ll be reliable and extensible. Which outcome matters more for this customer?”
This skill is the single biggest differentiator between engineers who stay individual contributors and engineers who move into staff, principal, or leadership roles. Technical depth gets you respected by your peers. Translation ability gets you trusted by the business.
One technique to try: When explaining technical concepts to non-technical stakeholders, translate every technical constraint into a business trade-off. “We need to refactor the database” becomes “We can add this feature in 2 weeks with workarounds, or 5 weeks with a foundation that lets us add the next 3 features in days instead of weeks. Which timeline fits our priorities?“
5. Conflict Resolution
The scenario: Your team depends on an API maintained by another team. Your launch date is in three weeks. Their API has a breaking change scheduled for two weeks from now, and they won’t delay it. Your team lead says they should wait. Their team lead says your team should have planned for it. Both are right. Both are also wrong. And the Slack thread is getting longer and more passive-aggressive by the hour.
Cross-team dependency conflicts are some of the hardest interpersonal challenges in IT. They involve competing priorities, limited resources, and organizational structures that incentivize local optimization over collective outcomes. No amount of process fixes this if the people involved can’t have a productive conversation about trade-offs.
Conflict resolution in engineering contexts isn’t about compromise. Splitting the difference between two technical approaches usually produces the worst of both. It’s about getting both sides to articulate their actual constraints (not positions) and then finding a path that respects the constraints that are genuinely immovable.
One technique to try: When a cross-team conflict escalates, shift the conversation from positions (“We need them to delay their release”) to constraints (“We need 72 hours to update our integration tests before their new endpoint goes live”). Constraints are negotiable in ways that positions are not. Maybe they can release to staging first. Maybe you can get a preview branch. The constraint opens doors that the position closes.
6. Presentation Skills
The scenario: Sprint demo day. You’ve spent two weeks building a caching layer that reduced p95 latency from 800ms to 120ms. You show a terminal with some benchmark numbers. The product team looks politely bored. The engineering manager nods. Nobody asks questions. You sit down feeling like the work didn’t land, and you’re right. Not because the work wasn’t valuable, but because you presented a solution without presenting the problem it solved or the impact it created.
Presentation skills in IT are not about slide design or public speaking confidence. They’re about structuring technical information so that your audience understands why it matters to them. An architecture review for engineers needs different framing than the same architecture presented to a product steering committee. Same technical content, completely different narrative structure.
Sprint demos are where this skill has the most daily impact. The difference between “I implemented Redis caching for the user profile endpoint” and “Users were waiting 800ms every time they opened their profile. Now it loads in 120ms. That affects 40,000 daily active users” is the difference between being seen as someone who writes code and someone who solves problems.
One technique to try: Structure every technical presentation as Problem, Approach, Result, What’s Next. Start with the pain point. Explain why you chose this approach over alternatives (briefly). Show the measurable outcome. End with what comes next. This structure works for sprint demos, architecture reviews, and conference talks equally.
7. Negotiation
The scenario: The product team wants five features in the next sprint. Your team has capacity for three, and one of the five has unclear requirements that will likely balloon in scope. You could say “we can’t do all five” and let the product team pick three. But that’s not negotiation. That’s abdication. The features they pick might not be the three that create the most value, and the one with unclear requirements will keep showing up until someone addresses the ambiguity.
Negotiation in IT usually isn’t about money. It’s about scope, timelines, quality trade-offs, and resource allocation. Every sprint planning session is a negotiation. Every technical debt conversation is a negotiation. Every “can we get this done faster?” question from leadership is the opening of a negotiation.
Engineers who negotiate well don’t just push back. They offer structured alternatives. “We can do features A, B, and C this sprint and deliver them production-ready. Or we can do A, B, C, and D but D ships behind a feature flag and needs another sprint for edge cases. Which of those outcomes do you prefer?” This frames the conversation around choices rather than limitations.
One technique to try: When facing scope pressure, always present two or three concrete options with clear trade-offs rather than a single “we can’t.” Options give stakeholders agency. A flat “no” gives them a reason to go around you.
8. Collaboration
The scenario: You’re pair programming with a colleague on a complex migration. You see an approach that you’re confident is better. You could just take over the keyboard and implement it. You’d be faster alone. The code would probably be cleaner. And you’d also miss the edge case your colleague was about to mention, the one they noticed because they’ve maintained this system for two years and know about the legacy integration that isn’t documented anywhere.
Collaboration in IT is complicated because individual technical contribution is highly visible and rewarded. The engineer who ships the feature gets credit. The engineer who spent three hours helping a teammate debug a concurrency issue before they could ship their own feature often doesn’t. This creates incentives that work against genuine collaboration.
Real collaboration isn’t just working in the same repository. It’s sharing context, asking for input when you don’t strictly need it (because someone else’s perspective often catches what yours misses), and building shared understanding of systems rather than creating knowledge silos. Cross-functional collaboration with design, product, and QA teams adds another layer. The engineer who builds a strong working relationship with their QA counterpart catches bugs in design, not in production.
One technique to try: Before starting any task that touches a system you didn’t build, spend 15 minutes talking to someone who knows it well. Not reading the docs (do that too). Talking to the person. You’ll learn things that never made it into documentation: why a particular approach was chosen, what was tried and abandoned, where the known fragility lives.
9. Adaptability
The scenario: Your team has spent four months building a microservices architecture. New leadership arrives and decides to consolidate back to a modular monolith. Your technical investment feels wasted. The new direction contradicts everything you argued for in the architecture review. You can resist, comply, or adapt. Resisting burns political capital without changing the outcome. Complying means executing without ownership. Adapting means finding the genuine merits in the new approach, bringing your architectural knowledge to bear on doing it well, and moving forward productively.
Adaptability in IT isn’t about being passive or agreeable. It’s about separating your identity from your technical decisions. The ability to say “I advocated strongly for approach A, the decision went to approach B, and now I’m going to make approach B succeed” is rare and valuable. Engineers who can do this get trusted with bigger decisions because leadership knows they won’t sabotage outcomes they didn’t choose.
Technology changes constantly. Frameworks, languages, cloud providers, architectural patterns, deployment strategies. The engineer who built their identity around being a React expert has a harder time adapting than the engineer who built their identity around solving frontend problems well, regardless of the tool. The skill isn’t learning new things quickly (most engineers can do that). The skill is letting go of the old thing without resentment.
One technique to try: When facing a significant technical direction change, give yourself 24 hours before forming a public opinion. Use that time to genuinely explore the merits of the new direction. Write down three things it makes easier, not just three things it makes harder. You might still disagree. But you’ll disagree from an informed position rather than a reactive one.
10. Mentoring
The scenario: A junior engineer joins your team. They’re technically capable but make the same kinds of mistakes you made three years ago: over-engineering simple problems, not writing tests for edge cases, treating code review feedback as personal criticism. You can let them figure it out the way you did (slowly, painfully, through accumulated scar tissue). Or you can accelerate their growth by sharing what you learned, when they’re ready to hear it.
Mentoring in IT is not lecturing. The engineer who explains the SOLID principles to a junior who just wants to know why their PR was rejected is teaching, not mentoring. Mentoring is contextual. It meets the person where they are, with what they need right now. Sometimes that’s a technical explanation. Often it’s helping them see a pattern in their own behavior that they can’t see yet.
Knowledge transfer is the organizational version of mentoring. The engineer who is the only person who understands the billing system is a liability, not an asset. Effective mentoring creates redundancy in knowledge. It distributes understanding so that the team’s capability isn’t dependent on any single person’s availability. Onboarding documentation, architecture decision records, and pair programming rotations are all forms of structural mentoring.
One technique to try: When a junior engineer asks for help, resist solving the problem for them. Instead, walk them through your diagnostic process out loud. “First I’d check the logs for X. Then I’d look at whether Y changed recently. Then I’d try to reproduce it with Z.” Teaching the process is more valuable than providing the answer, because the process transfers to problems you won’t be around to solve.
The Skill That Ties Them All Together
If you read through these 10 skills, you’ll notice a pattern. Almost every one of them depends on one underlying ability: seeing a situation from someone else’s perspective. The code reviewer who considers how feedback will land. The engineer who translates technical constraints into business trade-offs. The mentor who meets a junior where they are rather than where the mentor thinks they should be.
That perspective-taking ability isn’t something you’re born with or without. It’s a practice. And like any practice, it improves with repetition and feedback.
Risely’s AI coach Merlin helps IT professionals build these skills through simulated conversations grounded in real workplace scenarios. Instead of reading about how to give better code review feedback, you practice the actual conversation with an AI that responds the way a real colleague would. Over 4,000 professionals have used Risely, with an average 26% improvement in targeted skills within 12 weeks.
The soft skills that matter aren’t on a poster in the conference room. They’re in the pull request comment you almost sent, the meeting where you almost stayed quiet, and the conflict you almost avoided. Start with the one that costs you the most right now.
Try Merlin free and practice the conversations that matter most in your work.