Soft Skills in Tech

Any person or group with an interest in a project's outcome: sponsors (funding), users (affected), managers (responsible), other teams (dependent). Managing stakeholders means communicating progress, managing expectations, and getting the right people involved at the right time.

"Before starting the migration, we mapped our stakeholders: the CTO (sponsor), the customer success team (affected by downtime), the mobile team (API dependency), and compliance (data residency requirements). Each group needed different communication."

Raising an issue to a higher level of authority or urgency when it cannot be resolved at the current level. Escalating appropriately is a professional skill — both under-escalating (sitting on a blocking problem) and over-escalating (bothering the CEO about a minor issue) are problematic.

"I escalated the procurement delay to my manager — the vendor hadn't responded in 10 business days and we're blocking the Q2 launch. This needed visibility above my level to get moving."

Agreement on goals, approach, or direction among all relevant parties. "Getting alignment" means ensuring everyone understands and agrees with a plan before execution begins. Lack of alignment is a common cause of wasted work — two teams building toward different goals.

"Before we start building, I want to make sure we have alignment on the technical approach — can we schedule 30 minutes with the product and backend teams to review the API spec together?"

A situation where improving one thing makes another thing worse. Technical professionals communicate trade-offs constantly: speed vs. quality, cost vs. performance, simplicity vs. flexibility. A key communication skill is explaining trade-offs clearly to non-technical stakeholders.

"There's a trade-off here: we can ship by the deadline by cutting the automated testing, but that increases the risk of post-launch bugs. Or we push the deadline by one week and ship with confidence. Which risk is the business more comfortable with?"

Information about a person's performance given to help them improve. Effective feedback: specific (what exactly), behavioural (what was done, not the person), impact-focused (what effect did it have), timely (close to the event). Receiving feedback professionally means listening without defensiveness and asking clarifying questions.

"I wanted to give you some feedback about the meeting. When you cut off Sarah during the design review, the team seemed less willing to contribute after that. Would it be okay to discuss how we can make sure everyone's voice is heard next time?"

A structured team meeting at the end of a sprint or project to reflect on what went well, what didn't, and what to change. A blameless retrospective focuses on processes and systems, not individuals. Common formats: Start/Stop/Continue; Mad/Sad/Glad; 4Ls (Liked, Learned, Lacked, Longed for).

"In the retrospective, the team identified three things to start doing: writing acceptance criteria before starting tickets, running smoke tests in staging before releasing, and blocking Slack notifications during deep work hours."

In a professional context, "bandwidth" refers to a person's available capacity or time, not network throughput. "I don't have bandwidth" means "I don't have time for this right now." Common in tech teams but worth knowing as jargon that non-English speakers sometimes interpret literally.

"I don't have bandwidth to take on the documentation task this sprint — I'm already at capacity with the migration. Can we schedule it for next sprint or reassign it?"

Formal approval or confirmation. "Getting sign-off" means getting an authorised person's approval to proceed. Important in technical contexts: sign-off on a design means you have approval to build it. Sign-off on a release means the approver confirms it's ready to ship.

"We need sign-off from the security team before we can push this to production — it's a new third-party integration and they need to review the data flow. I've sent the request and they'll aim to review by Friday."

Resistance or objection to a proposal or plan. "Getting pushback" means someone is questioning or opposing your idea. Responding to pushback professionally means listening to the concern rather than defending the original position immediately, then either updating the plan or explaining your reasoning clearly.

"There was some pushback from the product team on the two-week estimate — they wanted to launch next Thursday. I walked them through the complexity of the database migration and they agreed to extend the deadline once they understood the risk."

Issues that prevent progress on a task. Communicating blockers clearly and promptly is a key professional skill — sitting on a blocker without escalating is one of the most common causes of delayed delivery. Format: what the blocker is, why it's blocking, what you need to unblock, from whom.

"I'm blocked on the API integration — I need the authentication token for the staging environment. I've asked the backend team twice this week but haven't received it. Can you help escalate this to Alex?"

Acceptance and support of a plan or idea from key stakeholders or team members. "Getting buy-in" is the process of convincing people to support your proposal. It is different from getting sign-off (formal approval) — buy-in is about genuine support, especially from people whose cooperation you need.

"The migration will only work if the platform team buys in — they need to own the Kubernetes transition in parallel with our application changes. I'm presenting the plan to them on Tuesday to get their buy-in before we announce to the broader organisation."

Deadline: a final, non-negotiable cutoff — missing it has serious consequences (contract penalty, product launch, legal requirement). Due date: a target date — important but more negotiable. Understanding the distinction before committing to a date is important in professional communication.

"The audit submission is a hard deadline — we must submit by April 30 or face regulatory penalties. The internal documentation review has a due date of April 15 — it's important but we can request a one-week extension if needed."

The gradual expansion of a project's scope beyond its original boundaries, typically through informal additions that each seem small but collectively delay and overload the project. Prevented by: clear acceptance criteria up front, formal change control for scope additions, and saying "that's a great idea for v2" to well-intentioned feature requests.

"The team agreed to build a simple user profile page. Two weeks in, scope creep had added a profile photo uploader, a privacy settings panel, a linked accounts feature, and email notifications. None of these were in the original spec."

Proactively communicating what will and won't be delivered, and when — preventing disappointment by setting realistic expectations rather than over-promising then under-delivering. Done at project start and updated continuously. "Under-promise and over-deliver" is the common guidance.

"I want to manage expectations up front: the first version will handle the main user flow but will not include bulk export or API access — those are deliberately out of scope for the initial launch. I'd rather ship a solid v1 on time than a fragile v1 with three half-built features."

The process of passing knowledge from one person or team to another — during onboarding, offboarding, team reorganisations, or handoffs. Good knowledge transfer combines documentation (written, asynchronous) with sessions (spoken, synchronous). Prevents knowledge silos where critical information lives in only one person's head.

"The team lead is leaving next month — we've planned a two-week knowledge transfer. She's recording Loom walkthroughs of the most complex systems, writing a system overview document, and doing three live pairing sessions with the engineer taking over."