The Shift
The classic engineering manager was measured by how well the machine ran: sprint burndown, story-point velocity, standup hygiene, capacity plans, and a steady stream of “unblocked” tickets. The job was process and execution tracking—keeping eight engineers pointed in the same direction and proving progress to stakeholders with charts.
That model collapses when agents multiply individual throughput by three to ten times. Velocity stops being a signal; it becomes noise. Story points lose meaning when an agent can close a backlog’s worth of tickets overnight. You are no longer managing eight engineers—you are managing eight engineers and their agents, each pair capable of output that legacy metrics cannot interpret. The EM who optimizes for volume optimizes for the wrong era.
The work moves to what HELM encodes across the organization: Shift 2 (Leadership)—from directing execution to defining constraints so teams and agents operate inside clear boundaries; Shift 6 (People systems)—measuring impact, not output volume; and Principle 6 (Team-Wide Adoption Over Individual Mastery)—the team’s effective capability is bounded by its least-adopted critical-path member, not its star performer. The engineering manager is the role that executes those shifts every day: building capability, balancing adoption, and insisting the team measures what actually matters.
What the Traditional Job Description Looked Like
Traditional postings stacked familiar bullets: five or more years managing engineering teams, deep comfort with Agile and Scrum ceremonies, proven ability to track velocity and run capacity planning, strong stakeholder communication, and often a narrative about scaling headcount from X to Y. Interviews rewarded fluency in backlog grooming, sprint planning, and escalation paths. The emphasis was process management and execution tracking—keeping the train on the tracks and the metrics green.
The Transformed Role
Core Mission
Build and lead an AI-augmented engineering team where every member operates effectively with agents, the team measures impact over output, and adoption levels are balanced across the pod.
Key Responsibilities
- Assess and advance the team's maturity level using the HELM Maturity Model (Levels 1–5)
- Ensure adoption equity: treat the team's effective level as the least-adopted member in a critical-path role, and close that gap deliberately
- Define and enforce the team's operating rhythm around the Plan-Execute-Verify-Ship-Learn loop
- Restructure workflows from horizontal silos to vertical, outcome-oriented cross-functional pods
- Establish and track KPIs that measure product impact, not output volume—lead time, change failure rate, escaped defects—not story points or pull requests merged
- Coach engineers on judgment, review quality, and context engineering, not only on narrow technical skills
- Own execution of the adoption roadmap (Phases 1–4) for the team, with clear exit criteria per phase
- Manage the human side of AI adoption: resistance, anxiety, identity shifts, and the honest question—what is my job now?
Required Competencies
- Adoption management — Assessing where each person sits on the maturity model and building individual development plans that raise the team floor, not only the ceiling.
- Outcome-based measurement — Designing KPI frameworks that reward impact over activity, aligned with the HELM KPI Dashboard.
- Organizational design — Moving teams from functional silos to pods organized around outcomes and customer value.
- Change leadership — Holding space for emotional and identity challenges as roles transform, without letting avoidance stall the whole organization.
- Coaching for judgment — Developing engineers who can evaluate and review at volume with consistent standards.
- Agentic workflow fluency — Knowing the Plan-Execute-Verify-Ship-Learn loop well enough to see where it breaks in practice and fix the system, not blame individuals.
What We No Longer Screen For
- Ability to "run a good standup" or optimize Scrum ceremonies as the core proof of management skill
- Deep expertise in a specific project-management toolchain (e.g., Jira wizardry) as a proxy for leadership quality
- Velocity tracking and capacity planning anchored in story points
- Team growth framed primarily as headcount scaling
- Performance management driven mainly by code output or merge volume
How We Interview
- Adoption equity scenario — "Your team has one Level 4 engineer and two Level 1 engineers. The Level 4 engineer is frustrated that their pull requests wait for review. What do you do?" Tests whether you protect stars or lift the floor and rebalance how work flows.
- Measurement design — "Design a KPI framework for a team adopting agents. What do you measure, what do you stop measuring, and why?"
- Change management — "An experienced senior engineer says 'AI is going to replace us all' and resists adoption. How do you handle it?"
- Team design — "You are restructuring from a frontend team and a backend team into vertical pods. Walk through your approach—stakeholders, sequencing, and risk."
- Maturity assessment — Given a concise description of current practices, place the team on the maturity model and propose a 90-day advancement plan with milestones and exit criteria.
Day in the Life
You open the day on team-level signals: lead time, change failure rate, escaped defects, and adoption KPIs—not a burndown chart. The question is whether the system is getting safer and faster in ways users and the business can feel, and whether adoption is spreading or concentrating in a few individuals.
A one-on-one might be entirely about review judgment: an engineer drowning in agent-generated diffs, unsure what "good enough" looks like at this pace. You coach on heuristics, sampling, and escalation—building skill, not assigning more tickets. Midday, the pod meets briefly on blockers and adoption progress—where the loop is stuck, who needs pairing, what rule or template should change—not on point totals.
The afternoon goes to the 90-day adoption roadmap: which phase the team is in, what evidence satisfies exit criteria, and what you will do this week to move the lowest-adopted critical path forward. Before you close, you refresh shared rules files and templates so this week's lessons compound. The through-line is capability building and team-system design, not execution tracking dressed up as leadership.
Connection to HELM
The engineering manager is where HELM's Six Organizational Shifts meet the calendar: you translate the Leadership Guide into weekly choices about constraints, measurement, structure, and people systems. The Maturity Model (Leadership and Practitioners guides) is your shared language for where the team is and what "better" means next. You own execution of the Adoption Roadmap—phases, gates, and honest assessment of whether the team is ready to deepen autonomy. The KPI Dashboard is how you keep the team and leadership aligned on impact instead of vanity metrics. Principle 6: Team-Wide Adoption Over Individual Mastery is your mandate in one line: the pod wins when everyone who must ship in the critical path can ship with agents at the required bar, not when one hero carries the load.