Soft Skills Vocabulary for IT

Alignment in an IT context means ensuring that all stakeholders share the same understanding of goals, direction, or decisions. "Getting aligned" is a standard phrase in sprint planning, OKR setting, and cross-team meetings. Related phrases: "Let's align on the priorities for Q3." / "Are we aligned on the acceptance criteria?" / "We need cross-team alignment before the launch." Escalation (option A): raising an issue to a higher authority or management level because it cannot be resolved at the current level — e.g., "I need to escalate this blocker to the VP." Bandwidth (option C): available capacity to take on work — "I don't have bandwidth for that this sprint." Buy-in (option D): support or agreement from stakeholders, often before a decision is made — "We need buy-in from the security team before deploying." Buy-in is close to alignment but more specifically refers to obtaining approval or commitment, not just shared understanding.

Both bandwidth and capacity are widely used in IT teams to mean "available time and resources to take on work", and in everyday professional communication they are largely interchangeable. Bandwidth comes from networking (the maximum data transfer rate) but is used metaphorically for human/team workload capacity. You'll often hear it in agile/startup environments: "Do we have bandwidth to take on another initiative?" Capacity is the more formal term, used in capacity planning, sprint capacity calculations, and resourcing discussions: "Team capacity this sprint is 40 story points." Availability (option D) is not wrong but is less common in this context — it usually implies scheduling ("Are you available Tuesday at 2?") rather than workload. In daily standups you'll hear: "I don't have bandwidth/capacity for this because I'm blocked on..." ↔ "I have spare capacity if anyone needs help."

Escalation is the formal process of raising an issue, blocker, or decision to a higher level of authority when it cannot be resolved at the current level. It is a standard, expected practice in professional IT environments — not a sign of failure. When to escalate: security or compliance risk beyond your authority → when a blocker affects delivery timelines → when a decision requires resources you don't control → when a conflict can't be resolved between peers. How to escalate professionally: "I want to flag a security concern that's outside my authority to address — I'm escalating to you so we can decide on next steps." Escalation vocabulary: "escalate an issue", "escalation path", "escalation matrix" (who to contact for what type of issue), "escalate to management/stakeholders". What NOT to do: option C (parking) silently delays risk; option D (silent self-resolution) bypasses governance. Option A (ownership transfer / delegation) is different — it's choosing who does the work, not raising a risk.

A stakeholder is any individual, team, or organisation with an interest in or impact on the outcome of a project — regardless of whether they use the product directly or approved the budget. Stakeholders can be: Internal — engineering, product, design, legal, sales, compliance, senior management. External — customers, partners, regulators, investors. Stakeholders vs. end users: "end users" are the people who use the product daily; stakeholders is a broader category that includes users but also business and regulatory parties who have interests even if they don't touch the UI. Key phrases: "stakeholder management" (communicating with and balancing the needs of stakeholders), "stakeholder mapping" (identifying who has interest and influence), "key stakeholders", "stakeholder requirements", "stakeholder sign-off". In practice: "We'll hold a stakeholder review before the feature goes to production." Related: "RACI matrix" — Responsible, Accountable, Consulted, Informed — a common tool for mapping stakeholder roles.

Mentorship is an ongoing relationship where an experienced professional (the mentor) guides and supports the growth of a less experienced person (the mentee). It goes beyond code review — it includes career guidance, knowledge transfer, skill development, and professional confidence building. In IT contexts, mentorship includes: reviewing and explaining PR feedback in depth rather than just approving. Discussing engineering trade-offs and reasoning. Guiding career development. Providing safe space to make and learn from mistakes. Related terms: Code review (option A) — evaluating specific code changes for quality, correctness, style. Can be part of mentorship but is narrower. Pair programming (option C) — two developers working together on the same code simultaneously, real-time: driver (writes code) + navigator (reviews and guides). Onboarding buddy (option D) — someone assigned to help a new hire during their first weeks; often time-limited and role-specific, not a long-term growth relationship. Key phrases: "mentorship programme", "act as a mentor to", "mentor-mentee relationship", "give mentorship", "seek out a mentor".