Engineering management's foundational skills.

management (209)

Draft

Impact Across Timeframes

Ensure your areas of responsibility make progress across both the short and long term:

  • 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.

Execution

Navigate reality to make consistent progress, even when reality is difficult:

  • 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.

Ownership

TBD

Alignment

Build shared understanding across leadership, stakeholders, your team, and the problem space—and surface misalignment before it becomes costly:

  • 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.

Clarity

Your team, stakeholders, and leadership know what you’re doing and why:

  • 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.”

Team

Creating the environment for strong teams to succeed:

  • 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.

Taste

Exercise discerning judgment about what “good” looks like—technically, in business terms, and in process/strategy:

  • 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.