The phrase "soft skills" does the category a disservice. There is nothing soft about writing a design document that changes a team's direction, or telling a stakeholder that the date is not achievable in a way they can act on. These are learnable, high-leverage skills, and past the mid-level they are the main thing separating engineers whose work lands from engineers whose work is technically excellent and quietly ignored.
Writing is the highest-leverage one
Most decisions in a distributed, asynchronous organization are made from a document by people who were not in the room. Writing clearly is therefore how you scale your judgment past the meetings you can attend. The craft is simple to state: lead with the conclusion, then the reasoning, then the detail. Say what you decided and what you rejected and why. Use short sentences. Cut every sentence that survives only because it was hard to write.
- 01Context — what is true today and why it is a problem, in one paragraph.
- 02The decision or recommendation, stated plainly and early.
- 03Options considered, with the trade-off that decided it — this is the part reviewers actually engage with.
- 04Risks and what would make you change your mind.
- 05What happens next, who does it, and by when.
Disagreeing without becoming the difficult one
Strong opinions are useful only if people can hear them. The reliable move is to separate the observation from the interpretation: "this endpoint has no timeout, so one slow dependency will take the checkout flow down" travels much further than "this design is wrong". Argue about consequences, not about taste. Ask a genuine question before delivering a verdict — half the time the constraint you did not know about is the answer. And when the decision goes against you, disagree and commit visibly; the engineer who relitigates a settled decision for three sprints loses influence permanently.
Estimating honestly
Estimates are not promises, but treating them as pure guesses is a cop-out. Give a range with the assumptions attached, break anything longer than a week into pieces small enough to reason about, and update the moment reality diverges — a surprise on Monday is a schedule change, the same surprise on Friday is a crisis. "I don't know yet; give me two days to spike it and I will give you a number" is a professional answer, and saying it early is what makes it one.
Bad news does not improve with age. The cost of a delayed disclosure is always paid by someone with less time to react than you had.
The rest of the list
- Code review as teaching, not gatekeeping — distinguish blocking concerns from preferences, and say which is which.
- Listening for the problem behind the request. Most feature requests are a proposed solution wearing a costume.
- Managing up: your manager cannot help with a risk they have not heard about. Short, regular, unprompted status beats a perfect quarterly summary.
- Saying no with an alternative attached — "not this sprint, but here is what we can do now" is a no that keeps the relationship.
- Giving credit specifically and publicly. It costs nothing and compounds faster than almost anything else you can do.
- Knowing when to stop polishing. Shipping something good on Thursday usually beats something excellent three weeks later.
These improve the same way technical skills do: deliberately, with feedback, one at a time. Pick the one that is currently costing you the most, work on it for a quarter, and ask someone whose judgment you trust whether they noticed a difference.