Performance Management and Standards Questions

Situation overview (brief)
I’d treat this as a signal that delivery and quality are decoupled: velocity up, but quality and customer satisfaction down. My goal is to diagnose root causes, align stakeholders, and implement short/long-term fixes.

Diagnostics I would run

• Data triage: correlate commits/releases to bug spikes (time-series), examine issue origin (regression vs new), and map bugs to teams/components.
• Process audit: review CI/CD logs, test pass rates, flaky tests, code review turnaround times, and sprint scope changes (more shortcuts?).
• Qualitative input: review customer tickets, severity, and reproduction steps; conduct lightweight RCA on representative incidents.
• Developer signals: survey devs about pressure, tech debt, or skipped QA.

Stakeholders to involve

• Product manager (scope/priority changes)
• QA leads/SRE (test coverage, monitoring)
• Customer support/CS (complaint themes)
• Tech leads and individual contributors (implementation details)
• VP Eng/PMO for cross-team impacts

How to reconcile metrics

• Stop treating velocity as a lone success metric; present a balanced scorecard (velocity, escaped defects, cycle time, customer NPS).
• Weight outcomes: prioritize production defects and customer impact over raw story points when evaluating team performance.
• Short-term: pause new feature pressure for a stabilization sprint if needed.

Process and incentive changes

• Introduce quality gates: merge blocked without tests, automated regression checks in CI, definition of done includes e2e or contract tests for risky areas.
• Release controls: feature flags, canary releases, and stricter rollback/playbook requirements.
• Team incentives: shift performance reviews and bonuses to include quality and customer metrics (reduced escaped defects, post-release MTTR).
• Operationalize learning: mandatory postmortems with action items, track tech debt tickets in backlog and allocate sprint capacity (e.g., 10–20%) to them.

Expected outcomes and follow-up

• Short-term reduction in escaped defects and complaints; medium-term improved maintainability and realistic velocity.
• Track balanced metrics over next 2–3 quarters and iterate on incentives/processes based on outcomes.

Clarify the problem (Situation)
I’d explain that yearly calibration shows promotion outcomes correlate with manager leniency, not performance — a systemic bias threatening fairness and retention.

Short-term remediation (30–90 days)

• Pause automatic promotions until investigation completes; communicate transparently.
• Run an audit: anonymize promotion packets and have a cross-functional calibration panel (senior EMs, HR, IC reps) re-score against rubric. Owner: People Ops + Chief Eng. Timeline: 4 weeks.
• Re-run decisions where bias materially affected outcome; offer remediation (e.g., adjusted title, compensation, career plans) and communicate to impacted employees.
• Quick manager retraining: mandatory 2-hour bias + calibration workshop and standardized promotion rubric walkthrough.

Long-term checks & balances (3–18 months)

• Implement a clear promotion rubric with behavioral anchors per level and example evidence; embed in promotion packet template.
• Require multi-rater input: manager, skip-level, peer, and panel review. Panel must include at least one neutral senior leader.
• Make calibration iterative (quarterly mini-calibrations) to detect drift sooner.
• Track metrics monthly: promotion rates by manager, department, gender, race, tenure; manager leniency score (avg deviation from panel). Set alerts and quarterly review.
• Tie manager review/compensation partly to calibration quality (e.g., consistency with panel).
• Ongoing training: annual calibration certification for managers, plus mentoring for borderline candidates.

Why this works
Combines immediate correction with structural fixes: objective rubric, multi-rater evidence, recurring audits and metrics create accountability and reduce single-manager variance while preserving developmental pathways for engineers.

Approach overview
I separate diagnostics into team-level signals (systemic) vs individual problems. I look for patterns across metrics, artifacts and conversations before acting on people.

Quantitative data to gather

• Velocity trends (sprint-by-sprint story points, scope changes) to spot sustained drop vs one-off
• Cycle time / lead time distribution (PR to merge, ticket open→done) for bottlenecks
• Bug counts & severity over time, escape rate to production
• Rework rate, blocked days, CI flakiness/failure rates
• Throughput per engineer (normalized), pull-request size/frequency

Qualitative data

• 1:1s for context (burnout, blockers, clarity)
• Skip-level interviews for cross-team impressions and psychological safety
• Retrospective notes, action-item follow-ups, stakeholder complaints
• On-call incident postmortems and feedback from product/QA

Code-quality artifacts

• Static analysis trends, tech-debt backlog, PR review comments, code churn hotspots, test coverage changes, architecture docs

Diagnosis pattern

• Systemic: many engineers show slower cycle time, rising bugs, recurring blockers, repeated retro action failures.
• Individual: one person’s throughput drops while peers stable; 1:1 reveals personal issues or skill gaps.

Prioritization heuristic for remediation
Rank by impact × urgency × scope:

• Impact (customer/user risk)
• Urgency (production incidents, release deadlines)
• Scope (team-wide vs individual)
  Actions: 1) Fix critical production/blockers (high impact/urgency), 2) Remove systemic process/tooling bottlenecks (high scope), 3) Coach or reassign individuals (targeted, medium scope), 4) Address long-term tech debt and training (lower urgency).
  I pair metrics-driven interventions with short feedback loops (2–4 weeks) and re-measure.

Situation & goal
I would protect team safety and delivery while trying to correct destructive behavior from a high-performing staff engineer whose work is critical to the roadmap.

Short-term mitigation (30–90 days)

• Immediately remove public exposure that enables shaming: route code reviews and design critiques to private channels, require mediated design reviews with a neutral facilitator.
• Reassign mentoring and cross-team gatekeeping responsibilities temporarily.
• Communicate to team: leadership is taking steps to ensure respectful collaboration and uninterrupted delivery.

Coaching and discipline

• One-on-one fact-based conversation: share specific examples, impact on people and delivery, and expected behavioral changes with measurable goals and timeline.
• Create a written Performance Improvement Plan (PIP) focused on behaviors (e.g., no public shaming; use constructive feedback templates; attend conflict-resolution coaching).
• Pair with an executive sponsor and an external coach/HR partner; document progress with weekly checkpoints.
• Escalate to formal disciplinary steps if violations recur (written warnings → role restriction → last warning), aligned with HR policy.

Stakeholder management

• Inform product and engineering leadership about risks, mitigation steps, and contingency plans.
• Reprioritize roadmap items or redistribute technical ownership to reduce single-point dependency.
• Provide transparent but confidential status updates to affected teams to rebuild trust.

Decision framework for termination

• Criteria: failure to meet documented behavioral goals within agreed timeline; repeated violations after progressive discipline; measurable harm (high attrition, blocked delivery).
• Weigh technical value vs. cultural cost: quantify impact (replaced hires, delays, morale surveys).
• If termination chosen: ensure knowledge transfer plan, maintain delivery continuity, communicate rationale to teams focusing on values and safety.

This balances urgent team protection, fair opportunity for improvement, and clear exit criteria if behavior persists.

Overview — essential PIP elements

• Clear performance gap statement (specific behaviours/outcomes)
• Measurable success criteria (quantitative + qualitative)
• Realistic timeline and milestone dates
• Regular check-in cadence and format
• Owner responsibilities (manager vs employee)
• Support/resources (training, pair-programming, mentoring)
• Consequences and next steps if criteria unmet

Measurable success criteria (best practice)

• Specific metric, target, and measurement method (e.g., reduce bug rate to X per KLOC as measured in issue tracker)
• Observable behaviours and artifacts (code reviews with <N critical comments, documented designs)

Timelines & cadence

• Typical duration: 60–90 days for engineers
• Check-ins: weekly 30-min coaching sessions + biweekly written progress update
• Midpoint formal review at 30–45 days; final review at plan end

Owner responsibilities

• Manager: define criteria, provide coaching/training, unblock work, document progress, give candid feedback
• Employee: follow action plan, deliver artifacts/metrics, proactively raise blockers, update progress before check-ins

Two backend engineer example criteria

1. API reliability: Reduce 95th-percentile response latency from 600ms to <250ms for /orders endpoint, measured over 2-week window, with monitoring dashboard and regression tests passing.
2. Code quality & velocity: Merge at least 4 feature PRs with <2 critical review comments each and maintain 80% unit-test coverage on modified modules; tracked via PR and CI reports.