Engineering Manager Vocabulary

PIP (Performance Improvement Plan): a formal HR tool used when an employee's performance falls below acceptable standards. It documents specific measurable goals, a timeframe (typically 30-90 days), and the consequences of not meeting goals (usually termination). People management vocabulary for engineering managers: 1:1 (one-on-one) — regular private meeting between manager and direct report; for relationship building, feedback, career growth, and blockers. Skip-level 1:1 — a manager meets with someone two levels below them (skipping the intermediate manager); helps gauge team health independently. Feedback models: SBI (Situation-Behavior-Impact) — "In the sprint review [Situation], you interrupted the product owner three times [Behavior], which made them hesitant to share updates [Impact]." COIN (Context-Observation-Impact-Next) — adds the "Next" step (what to change). Headcount — the number of people on a team or in a budget. Attrition — employee turnover rate; voluntary (quit) vs involuntary (fired/laid off). Span of control — number of direct reports a manager has; typical optimal range is 5-10 for engineering managers. In conversation: "I try to catch performance issues early in 1:1s — by the time a PIP is needed, trust is already broken."

The staying technical challenge is a defining tension in engineering management. Engineering managers (EM) often move away from production code as their management work grows. Vocabulary for EM technical responsibilities: Technical credibility — the team's trust in the manager's ability to understand and evaluate technical work. Earned through past output, current engagement, asking good questions. Code review participation — reading and commenting on PRs; keeps the EM connected without blocking the team. Architecture review — participating in design decisions, RFCs, and system design discussions. Tech debt advocacy — the EM champions refactoring and infrastructure investment with product management and executives. EM vs IC (Individual Contributor) track — most engineering career ladders split at senior engineer: keep growing as an IC (Staff/Principal/Distinguished) or move into management. Staff Engineer — a senior IC with broad technical scope, often partnering with EM. Manager of managers (MoM) — an EM who manages other EMs. Technical vocabulary in management: Technical roadmap — a forward-looking plan for infrastructure, platform, and tooling investments. Tech vision — a multi-year architectural direction. In conversation: "The best EMs I know still do thorough code reviews — they're not writing features, but they spot design issues immediately."

Engineering ladder (also: career framework, levelling rubric, engineering levels): a defined progression system specifying what mastery looks like at each level. Used for hiring calibration, promotion decisions, and career development conversations. Levelling vocabulary: L3-L8 — common Google-derived level numbering; other companies use different scales (Faang tends to have more levels). IC levels: Junior → Mid → Senior → Staff → Principal → Distinguished/Fellow. Rubric dimensions: Technical Impact, Execution/Delivery, Collaboration/Communication, Scope of Influence. Scope of impact: task → feature → team → org → company/industry. A Staff engineer impacts the team/org; a Principal impacts across multiple teams; a Distinguished impacts the company or industry. Promotion calibration — cross-team meeting where managers compare promotion candidates to ensure consistent standards. Promotion packet/doc — a written case for promotion: evidence across rubric dimensions with concrete examples. Levelling in hiring — matching a candidate's demonstrated skills to the appropriate internal level during interviews. Common tension: people who are promoted for execution may struggle to show the broader cross-team impact required at higher levels. In conversation: "We aligned our levelling rubric across teams so 'senior' finally means the same thing in backend, mobile, and data."

Technical debt: the accumulated cost of shortcuts, outdated dependencies, poor design decisions, and deferred refactoring — it "accrues interest" in the form of slower development, more bugs, and higher incident rates. Ward Cunningham coined the metaphor. EM vocabulary for advocating tech debt investment: Frame in business terms: "This costs us 2 engineer-weeks per month in bug-fixing" or "This blocks Team X from shipping feature Y." Velocity loss — developers spend more time navigating complex, poorly designed code rather than delivering features. Mean Time to Repair (MTTR) — high tech debt areas often have longer MTTR due to unfamiliar/fragile code. Bus factor — how many people must be unavailable before a system becomes unmanageable; high tech debt + low bus factor = critical risk. Strangler fig pattern — incrementally replacing a legacy system by routing new functionality to new code, eventually replacing the old system. Big bang rewrite — the anti-pattern: scrapping everything at once; almost always fails to deliver on time. Tech radar — a technology assessment tool (e.g., ThoughtWorks) categorising technologies as Adopt, Trial, Assess, Hold. In conversation: "I stopped saying 'refactoring' in executive reviews — now I say 'reducing the 15% incident overhead from unstable services' and budget gets approved."

Structured interview: a rigorous hiring process where all candidates are asked the same predetermined questions, evaluated against the same scoring criteria, and decisions are made from documented evidence rather than gut feel. Reduces affinity bias, halo/horn effects, and inconsistent evaluation. Hiring vocabulary for engineering managers: Debrief — a post-interview meeting where interviewers share and discuss assessments before making a hiring decision. Calibration — aligning scoring standards across interviewers so that "Strong Hire" means the same thing to everyone. Behavioural interview — questions asking about past behaviour: "Tell me about a time you…" (uses STAR framework: Situation, Task, Action, Result). Technical interview types: coding/algorithms, system design, architecture, debugging. Culture fit (problematic): hiring people who are "like us" — perpetuates homogeneity. Culture add: hiring people who bring new perspectives while sharing core values. Hiring bar — the minimum standard for a hire; each new hire should raise or maintain the average. Bar raiser — a senior interviewer (common at Amazon) whose sole job is to maintain the hiring bar across the company. Headcount planning — forecasting how many hires are needed, when, and for what roles. In conversation: "After switching to structured interviews our offer-to-acceptance rate dropped but 12-month retention improved 30%."

This question tests understanding of proactive risk management. Sarah isn't criticizing the team; she's highlighting a systemic issue – underestimation of dependencies. The correct answer focuses on improving estimation processes to mitigate future risks during sprint planning. Option A is a common but ultimately inflexible approach, and options B & C are misinterpretations of her message.

This assesses the ability to provide constructive technical feedback. David's logging is functionally correct, but insufficient for production use. The key additions are robust error handling (try-catch) and detailed, informative log messages with contextual information like timestamps and severity levels – this will be crucial for debugging. Option A prioritizes performance over proper logging which is a bad practice.

This tests the ability to translate technical jargon into understandable explanations. Maria's response directly identifies the root cause (insufficient memory) and provides an actionable step – investigating resource constraints and potentially scaling infrastructure. Option A is vague, option B is still too technical for the team, and options C & D are dismissive or blame-shifting.

This question probes the importance of context and alignment in standups. John wants to know *why* David fixed the user profile bug and how that relates to larger goals – this fosters collaboration and ensures everyone is working towards shared objectives. Option A reflects a lack of engagement, options B & C misinterpret the purpose of a standup, and option D undervalues the importance of thoughtful updates.

This assesses understanding of risk-based prioritization. Emily's statement emphasizes the importance of user value – identifying risky features allows the team to proactively mitigate potential negative impacts on customer satisfaction. Options A & B misinterpret her focus on technical complexity and speed, while option D is a completely inappropriate approach.