One Pager Cheat Sheet

• As a software engineering manager, you move from great individual contributor to trusted engineering leader, adopting the skills and day-to-day systems to deliver outcomes through others, increasing your leverage while you balance people, product, and platform to create an environment where engineers do their best work and users get dependable value.
• The manager's job is to build and sustain a team that reliably delivers business impact at a healthy, predictable pace without burning out, using clarity, prioritization, and coaching.
• A manager’s primary job is to create the conditions so the team reliably delivers impact sustainably, using clarity, prioritization, and coaching, aligning work to OKRs/KPIs and roadmaps, removing blockers, and establishing predictable cadences like sprints.
• Shifting from IC to EM is a move from depth and speed of personal output to team clarity, coordination, and growth, typically via roles like tech lead → tech lead manager → manager or directly on small teams, where you may keep some technical work early but gradually reduce it to make room for people and process.
• Measuring an engineering manager (EM) by their own commits and tickets is false — an EM’s role is to amplify team effectiveness and enable others (not act as an individual contributor IC), and counting commits/tickets is a poor proxy for management impact because it incentivizes the wrong behaviors and overlooks outcomes like delivery of OKRs, system reliability (MTTR), hiring, coaching, and psychological safety.
• Focus on three pillars — people leadership, delivery management, and technical stewardship — avoid being the hero IC, and instead create clarity by defining goals, what done means, who owns what, and when risks must be surfaced.
• The missing word is technical, completing the three pillars — people leadership, delivery management, and technical stewardship — where technical stewardship means owning standards, architecture, quality, tech debt, CI/CD, and tooling to define definition of done and acceptance criteria, set clear ownership and risk gates (e.g., release readiness), and thus protect long‑term technical health and productivity.
• Establish a predictable operating rhythm with regular rituals—weekly 1:1s, sprint rituals, monthly roadmap syncs, and quarterly OKRs—and use lightweight artifacts (a living roadmap, an owner-mapped backlog, and a risk register) that are reviewed on schedule, not only when things break.
• Define audiences — team, cross-functional partners, and execs — and change the altitude for each: team gets details and next steps, partners get dependencies and dates, execs get impact, risks, asks; prefer written clarity first (brief specs, short updates, clear owners) and then use meetings to resolve decisions, not to discover the problem.
• Start meetings by leading with impact, risks, and decisions — this sets the right altitude, surfaces blockers and uncertainties early, and makes meetings decision-focused (e.g., approve an MVP scope cut or accept a delivery slip) with clear owners and ticket references.
• Use RACI — Responsible, Accountable, Consulted, Informed — to ensure role clarity and avoid decision fog, document RACI for recurring work (incidents, releases, hiring), and revisit it when the team changes.
• In RACI, the Accountable role is the person with final decision authority, who owns the outcome, approves the deliverable, and serves as the single point of accountability for the decision.
• Run a 1:1 as the employee’s meeting where you bring prompts, they bring topics, cover growth, feedback, blockers, and energy, end with clear actions, and follow the coaching model ask → mirror → suggest — ask to uncover thinking, mirror what you heard, and suggest options, not orders.
• Use SBI (Situation-Behavior-Impact) to keep feedback specific and fair, follow with a Next Step and offer help, praise in public, improve in private, and make feedback normal by doing it often and early.
• The statement is false — SBI (Situation-Behavior-Impact) avoids labeling by anchoring feedback in observable facts and effects, focusing on behaviors, not labels, which reduces defensiveness, makes feedback actionable, and supports constructive next steps (Next Step).
• Use lightweight planning — define outcomes, slice into vertical increments and timebox work — track progress with a visible board and weekly risk check-ins, and if slip risk rises adjust scope first, then dates, while communicating early and offering options, not surprises.
• Start by defining outcomes to set what success looks like; next establish constraints with a timebox to force prioritization and create trade-off rules; then slice work into vertical increments sized to the timebox so each increment delivers usable value; and finally track progress with a visible board and weekly check-ins on risks so you can adapt early and trade scope before dates, producing focused, predictable delivery that advances the outcomes.
• Technical stewardship without becoming a bottleneck means applying guardrails (not gates) by defining engineering standards and architectural principles, joining early for clear problem framing, reviewing at integration points, and measuring quality with SLIs/SLOs.
• A manager should define the guardrails—clear standards like testing, code review, observability, CI/CD, and SLIs/SLOs—and empower reviewers (engineers and tech leads) to make day-to-day technical decisions within those boundaries, escalating only cross-cutting trade-offs so stewardship scales quality and speed instead of becoming a bottleneck.
• The process follows the Idea → Shaping → Plan → Build → Review → Release → Measure → Iterate flow, with stage owners and exit criteria, treating inputs as outcomes and constraints and outputs as running software and learning, and keeping the loop short to reduce risk.
• Track a few key signals like DORA metrics (deployment frequency, change failure rate), people signals (retention, hiring velocity), and user impact (activation, reliability); beware vanity metrics and tie each metric to a decision you’ll make if it moves.
• Tying metrics to decisions and owners makes metrics actionable, creates clear accountability, prevents vanity metrics, and improves data quality and cross-team coordination by ensuring concrete triggers (e.g., deployment frequency, change failure rate, time-to-first-value) have owners empowered to act.
• When incidents occur, leaders should make it safe (fix the system, not blame people), then stabilize and communicate with timeboxed updates and clear roles—Incident Commander, Ops, Comms, Scribe—and follow with a blameless postmortem that records actions with owners and due dates.
• A blameless culture does not mean no accountability; rather it emphasizes learning over punishment and psychological safety, treats human error as a symptom of system gaps, and ensures clear ownership and verified follow‑through through postmortems that produce action items with owners and due dates tracked in tools like JIRA/GitHub Issues and validated by monitoring, alerts, automated tests, and updated runbooks, assigns incident roles (incident commander, Ops, Comms, Scribe) to ensure tasks are done, holds leaders responsible for resourcing and escalation, and still permits consequences for deliberate misconduct or repeated negligence.
• Build partner trust by sharing trade-offs early, bringing options with pros/cons and clarifying the ask (people, time, scope), and make Executive updates short and decision-ready by leading with goal, status, risks, and help needed.
• Focus on achieving outcomes through others, keep a regular cadence with 1:1s, planning, demos, retros and OKRs, rely on practical tools like RACI, SBI, SLIs/SLOs, and DORA, prefer an iterative flow (Idea → Iterate) with guardrails over gates, and adopt habits of clear writing, frequent coaching, and measuring what matters.