Engineering management's foundational skills.

management (214)

This is a reference for the eight foundational engineering management skills introduced in “Good engineering management” is a fad. Each section includes practices, anti-patterns, and self-assessment questions.

These skills are grouped into core skills essential for all management roles (Execution, Team, Ownership, Alignment) and growth skills that determine how far you can go in your career (Taste, Clarity, Navigating ambiguity, Impact across timeframes). Notably, which skills are “core” shifts as industry fads evolve—execution was less emphasized in the hypergrowth era, and may be less emphasized again in the future.

Work from complex problem to opinionated, viable approach. If you’re given an extremely messy, open-ended problem, can you still find a way to make progress? (I’ve written previously about this topic.)

Examples: launching a new business line, improving developer experience, going from 1 to N cloud regions.

  • Decompose the unknown. Break ambiguous problems into smaller questions you can actually answer. Identify what you’d need to learn to reduce uncertainty, then go learn it.
  • Create structure where none exists. When there’s no playbook, write one—even if it’s wrong. A bad plan you can iterate on beats paralysis.
  • Timebox exploration. Set explicit checkpoints to decide whether to continue, pivot, or abandon. Ambiguity is not an excuse for infinite investigation.
  • Build coalitions in the fog. Ambiguous problems often span teams and functions. Identify who else is affected, align on the problem definition, and co-own the path forward.
  • Make reversible bets. When you can’t know the right answer, choose options that preserve optionality and are cheap to undo.
  • Anti-patterns: Analysis paralysis; waiting for someone else to define the problem; building consensus on a direction no one believes in; treating ambiguity as someone else’s job.

Self-assessment:

  • What problem have you worked on that was stuck before you assisted, and unstuck afterwards? How did you unstick it?
  • Do senior leaders bring ambiguous problems to you? Why or why not?

Impact Across Timeframes

Ensure your areas of responsibility make progress across both the short and long term. There are many ways to appear successful by cutting corners today that end in disaster tomorrow. Success requires understanding, and being accountable for, how different timescales interact.

Examples: have an explicit destination, ensure short-term work steers towards it, be long-term rigid and short-term flexible.

  • Work on multiple clocks. Deliver today’s commitments while shaping quarterly bets and multi-year architecture/org durability.
  • Make tradeoffs explicit. Write down rationale (speed vs. quality, centralization vs. autonomy, debt vs. optionality) and the review cadence to revisit them. (Useful tradeoffs are multi-dimensional)
  • Design for resilience. Right-size teams, set explicit leads, and evolve structures as context changes; prefer mechanisms (reviews, exception paths) over heroics. (Running an engineering reorg)
  • Institutionalize decisions. Capture strategy, policies, and exceptions in writing so progress survives leadership turnover. (Write five, then synthesize: good engineering strategy is boring)
  • Portfolio & fiscal stewardship. At scope, own money and time allocation. Fund value streams with explicit budget guardrails; make portfolio-level tradeoffs visible (not just team-level). Tie quarterly investments to measurable business outcomes. (How to plan as an engineering executive)
  • Security & privacy governance. Make “secure by default” an explicit, org-level responsibility. Adopt secure-SDLC practices (e.g., NIST SSDF), establish clear roles and policies, and ensure leadership review loops (e.g., ISO 27001 alignment) so security survives reorgs and audits.
  • Anti-patterns: Chasing only near-term wins; “someday” strategy with no delivery; hidden tradeoffs; org change without mechanisms; hero culture; security as an afterthought.

Self-assessment:

  • What’s a recent tradeoff you made between short and long-term priorities?
  • How do you inform these tradeoffs across timescales?
  • What long-term goals are you protecting at significant short-term cost?

Execution

Lead your team to deliver expected tangible and intangible work. Fundamentally, management is about getting things done, and you’ll neither get an opportunity to begin managing, nor stay long as a manager, if your teams don’t execute.

Examples: ship projects, manage on-call rotation, sprint planning, manage incidents.

  • Move through ambiguity. Be prescriptive about what when certain; provide decision frameworks when not; never stall. (Developing leadership styles)
  • Enforce fairly and close loops. Apply policies consistently, keep engineering processes owned by engineering, and explicitly resolve/delegate/park work. (Close out, solve or delegate)
  • Drive measurable improvement. Pair metrics with a written vision; run a weekly operating rhythm (strategic doc, team-health review, 1:1s, one leverage upgrade, status comms). Track DORA metrics (deployment frequency, lead time, MTTR, change failure rate) to avoid local-max vanity metrics. (Goals and baselines, Guiding broad change with metrics)
  • Reliability & operations ownership. Define SLOs, track error budgets, run incident response as DRI, and invest in post-incident learning. (Forecasting synthetic metrics)
  • Developer experience & platform leverage. Treat DevEx as a product. Remove friction in code review, CI/CD, and local environments. Invest in platform/enabling teams so stream-aligned teams move faster. Use SPACE/DevEx frameworks to measure beyond output (satisfaction, flow state, collaboration). (Maintaining platform-product fit)
  • Anti-patterns: Managing only up or only down; criticizing without building; “making it up as you go”; avoiding hard truths; letting work drift; ignoring reliability signals until incidents force action.

Self-assessment:

  • When did your team last have friction delivering work? Is that a recurring issue?
  • What’s something hard you shipped that went really, really well?
  • When were you last pulled onto solving a time-sensitive, executive-visible project?

Ownership

Navigate reality to make consistent progress, even when reality is difficult. Finding a way to get things done, rather than finding a way that it not getting done is someone else’s fault.

Examples: doing hard things, showing up when it’s uncomfortable, being accountable despite systemic issues.

  • Solve the problem first. Address what’s in front of you before escalating cross-team gaps. Accountability means owning outcomes, not just activities.
  • Show up when it’s uncomfortable. Be present for difficult conversations, failed launches, and messy incidents. Visibility during hard times builds trust.
  • Own failures publicly, share credit broadly. When things go wrong, don’t hide behind process or blame others. When things go right, highlight the team.
  • Make problems stay solved. Don’t just patch issues—understand root causes and prevent recurrence. A problem that keeps coming back isn’t solved.
  • Be accountable despite systemic issues. Yes, there are org-wide problems, tooling gaps, and upstream failures. Own your scope anyway.
  • Anti-patterns: Blame-shifting; disappearing during crises; solving problems performatively without follow-through; treating accountability as “someone else’s job”; learned helplessness about systemic issues.

Self-assessment:

  • When did you or your team overcome the odds to deliver something important? Would your stakeholders agree?
  • What’s the last difficult problem you solved that stayed solved (rather than reoccurring)?
  • When did you last solve the problem first before addressing cross-team gaps?

Alignment

Build shared understanding across leadership, stakeholders, your team, and the problem space. Find a realistic plan that meets the moment, without surprising or being surprised by those around you.

Examples: document and share top problems, provide updates during crises.

  • Understand the landscape. Map what leadership cares about (their goals, constraints, risk tolerance), what stakeholders need (dependencies, timelines, success criteria), what your team believes (technical intuition, capacity concerns), and what the problem actually requires. Write these down and identify gaps.
  • Make misalignment visible early. When priorities conflict, constraints bind, or worldviews diverge, raise it explicitly—in writing, with options and tradeoffs. Don’t let friction hide in vague language or optimistic timelines. (Setting policy for strategy)
  • Negotiate tradeoffs transparently. Present competing concerns directly: “Leadership wants speed, the team flags quality risk, and stakeholders need reliability—here are three approaches with clear consequences.” Let stakeholders choose with full information rather than absorbing tension silently. (Make timeline tradeoffs using iterative elimination tournaments)
  • Align on problem definition first. Before solutioning, confirm everyone agrees on what problem you’re solving and why it matters. Misalignment here multiplies downstream waste.
  • Create explicit agreements and reconcile regularly. Document what you’re committing to (and what you’re not), decision ownership, escalation paths, and review cadences. Make promises precise enough to know when they’re broken. Use recurring touchpoints (steering meetings, written updates, retrospectives) to re-verify alignment as context shifts. Treat divergence as information, not failure. (Mailbag: Building alignment around a new strategy)
  • Product & customer partnership. Practice EM↔PM “one team, one roadmap”: maintain a single backlog balancing user value, tech health, and risk. Shorten customer-feedback loops so engineering hears user signal directly, not just filtered through PM.
  • Anti-patterns: Saying “yes” to everything and choosing privately; absorbing irreconcilable tensions without escalation; alignment theater (nodding in meetings, diverging in execution); assuming agreement means understanding; letting “we’ll figure it out” substitute for explicit tradeoffs; EM-PM power struggles over backlog ownership.

Self-assessment:

  • When was the last time you were surprised by a stakeholder? What could you do to prevent that reoccurring?
  • How does a new stakeholder understand your prioritization tradeoffs (including rationale)?
  • When did you last disappoint a stakeholder without damaging your relationship?
  • What stakeholders would join your company because they trust you?

Clarity

Your team, stakeholders, and leadership know what you’re doing and why, and agree that it makes sense. In particular, they understand how you are overcoming your biggest problems. So clarity is not “Struggling with scalability issues” but instead “Sharding the user logins database in a new cluster to reduce load.”

Examples: identify levers to progress, create plan to exit a crisis, show progress on implementing that plan.

  • Legibility of priorities. Use plain language, labeled priorities, and visible decision criteria; avoid lore.
  • Documentation as leverage. Write for scale and continuity: decision logs, policies, expectations, strategy memos with exceptions, team-health dashboards, M↔M 1:1 agendas, durable process docs, runbooks, SLO dashboards, incident post-mortems, security policies, compliance documentation, OSS license inventory. (Model, document and share, Engineering strategy every org should write)
  • Communication as a multiplier. Right-size detail by audience, preflight narratives, maintain a steady cadence, ensure people feel heard. (How I write group emails at work, How to present to executives, Internal comms for executives)
  • Explicit strategy. Reconcile competing worldviews and choose decision altitude (centralize vs. delegate) deliberately. (Engineering strategy, Write five, then synthesize)
  • Anti-patterns: Ambiguity tolerated at the top; over-theorizing without artifacts; opaque priorities; irregular or audience-misfit comms; treating operational artifacts as “someone else’s job.”

Self-assessment:

  • What’s a difficult tradeoff you recently helped your team make?
  • How could you enable them to make that same tradeoff without your direct participation?
  • What’s a recent decision you made that was undone? How?

Team

Shape the team and the environment such that they succeed. This is not working for the team, nor is it working for your leadership—it is finding the balance between the two that works for both.

Examples: hiring, coaching, performance management, advocating with your management.

  • Hiring & bar. Define competencies; hire for current needs and future option value; run structured, consistent evaluation. (Your hiring funnel, Bar raisers, hiring committees, and other complex ways to improve hiring quality, The Engineering executive’s role in hiring)
  • Enabling conditions. Clear goals and boundaries, resourcing, blocker removal; uphold standards (including firing when necessary). (Staying on the path to high performing teams)
  • Retention & development. Align growth paths with business needs; give candid feedback; use stretch work and documented expectations. (Path to engineering manager of managers)
  • Constructive dynamics. Psychological safety with candor; visible decision-making; resolve conflicts via principles and mechanisms. (Gelling your Engineering leadership team)
  • Culture by design. Explicit norms and rituals (design reviews, incident retros) reinforced through policy and recognition.
  • External posture & talent brand. At senior scope, contribute to recruiting and retention through speaking, open-source contributions, thoughtful interviewing, and protecting team brand. Employer-branding investments show measurable impact on pipeline quality and offer acceptance.
  • Open-source & vendor governance. Own the basics: license/compliance guardrails, vulnerability response timelines, contribution policies, and third-party risk assessment—especially as OSS usage scales.
  • Anti-patterns: Tolerating persistent low performance; vague roles; favoritism; managing only individuals not interfaces; deferring hard staffing calls; treating external presence as “extra credit”; ignoring OSS/vendor risk until audit or breach.

Self-assessment:

  • Who was the last strong performer you hired?
  • Have you retained your strongest performers?
  • What strong performers want to join your team?
  • Which peers consider your team highly effective?
  • When did an executive describe your team as exceptional?

Taste

Exercise discerning judgment about what “good” looks like—technically, in business terms, and in process/strategy. Taste is a broad church, and my experience is that broad taste is a somewhat universal criteria for truly senior roles. In some ways, taste is a prerequisite to Amazon’s Are Right, A Lot.

Examples: refine proposed product concept, avoid high-risk rewrite, find usability issues in team’s work.

  • Technical taste (without IC hoarding). Maintain enough depth to hire well, review major decisions, and set technical direction—while partnering with leads instead of doing the work yourself. (Adding Value as an Engineering Manager)
  • Business taste. Understand the model, costs, constraints, and customer value; choose work that moves business outcomes, not just technical elegance. (Manage your priorities and energy)
  • Process/strategy/industry context. Develop taste by studying mechanisms that scale, strategy patterns, and industry benchmarks; translate them to your org’s constraints. (My rails for engineering leadership)
  • Reliability & security taste. Know what “good” looks like for SLOs (error budgets that balance innovation and stability), threat modeling (proportional to actual risk), secure defaults (developer-friendly guardrails), and incident response (blameless post-mortems that drive systemic fixes). (Metrics for the unmeasurable)
  • Mode selection. Know when to lead by policy, consensus, or conviction—and switch deliberately. (Developing leadership styles)
  • Anti-patterns: Hero mentality; hoarding technical work; optimizing tech detached from outcomes; cargo-culting processes or industry tropes; treating reliability/security as “compliance theater” rather than technical craft.

Self-assessment:

  • What’s a recent decision that is meaningfully better because you were present?
  • If your product counterpart left, what decisions would you struggle to make?
  • Where’s a subtle clarification that significantly changed a design or launch?
  • How have you inflected your team’s outcomes by seeing around corners?