Leading your engineers towards an AI-assisted future

Pete Hodgson · article · 2025-06-26 source ↗ Reader 🖥️

Craft Community DORA & Engineering Metrics Enterprise AI Adoption & Readiness Human-in-the-Loop Jevons Paradox Measuring AI Impact Team Autonomy Vibe Coding

An engineering leader should drive AI-coding adoption the same way they'd drive any major capability shift — by setting a clear, phased goal (Experimentation, then Adoption, then Impact) measured with lightweight KPIs, giving teams real autonomy over how they get there, and backing that autonomy with concrete organizational support (training, budget, protected time, a community of practice, empathetic communication) — rather than mandating a usage percentage from day one.

practical · argumentative — A how-to for engineering leaders, structured as an argument for a specific change-management strategy (phased goals + autonomy + support) against the implicit alternative (mandate a usage target and measure compliance).

Structure

Part	Role
Opening dialogue with a pressuring CEO	motivating narrative — establishes the organizational pressure the rest of the post answers
Overall approach: Aligned Autonomy and the three-phase roadmap (Experimentation -> Adoption -> Impact)	central claim / framework
Finding the Middle Path (vibe-coding overreach vs. defensive skepticism)	justification for why Experimentation must come before mandated Adoption
Driving Experimentation and Adoption (concrete KPIs per phase)	operationalization
Supporting AI adoption (structure, training, removing impediments, time, Community of Practice)	operationalization of the 'organizational support' leg
Leading with Empathy	addresses the emotional/identity dimension the metrics-and-process framework doesn't cover on its own
Communicating progress	closes the loop back to the opening dialogue — gives the leader something concrete to tell the CEO

Key terms

Aligned Autonomy
A change-management pattern (the author's own, from a 2019 post on Mission Command): leadership sets a clear goal and objective measures of progress toward it, then gives teams full autonomy over how they get there, backed by organizational support.
Mission Command
The military-derived leadership style underlying Aligned Autonomy: communicate current state, target state, and the comparison between them, then ask the team for their plan and what support they need — rather than issuing a direct order.
Experimentation / Adoption / Impact (the three phases)
A deliberate sequence of organizational goals: first get teams meaningfully trying tools and sharing learning (Experimentation), then measure actual day-to-day usage (Adoption), then measure effect on productivity/quality/agility (Impact) — each phase with its own KPIs.
The middle path
The calibrated position between engineers who cede too much judgment to AI ('vibe-coding', shipping large AI-authored PRs after a cursory review) and engineers who reflexively reject AI output to defend code quality — using AI for real leverage while keeping human decision-making central.
Jagged intelligence
A borrowed term (credited to a tweet) for AI capability that is unevenly distributed across tasks — strong in some areas, surprisingly weak and unintuitive in others — which is why getting good results requires learning specific, non-obvious techniques rather than just 'being smart.'

Propositions

explicitAn engineering leader facing pressure to show AI adoption should start with a genuine Experimentation phase — not a usage-percentage target — because the right way to use AI coding tools is not yet known even to the leader, and the org needs a period of collective discovery before it can set a meaningful Adoption target.conf: high
explicitThe Aligned Autonomy pattern — leadership sets a clear goal and objective progress metrics, teams get full autonomy over how to hit it, leadership backs that with organizational support — is the right vehicle for AI adoption because it already worked for prior waves of change (DevOps, test automation, observability, microservices, cloud, continuous delivery) and doesn't require inventing a new change-management playbook for AI specifically.conf: high
explicitAI coding agents are genuinely useful for certain tasks today, but AI is not currently capable of producing well-designed software without a human in the loop — the engineer's job shifts to compensating for the tool's limitations and resisting the pull toward sloppy design, not to stepping back.conf: high
explicitMetrics for AI adoption should be scoped and sequenced to the current phase (pilot counts and retro cadence in Experimentation; tool usage and sentiment in Adoption; DORA/SPACE-style productivity and quality metrics combined with adoption metrics in Impact) rather than a single all-purpose KPI applied from day one.conf: high
supportsAI-Assisted Software Development: Team Profiles and Capabilities for Putting Research into Action · p3 — Hodgson's recommendation to combine DORA/SPACE metrics with AI-adoption metrics anticipates DORA's own later empirical finding that AI adoption's benefit is conditional on exactly these organizational capabilities, not adoption alone.
refines#5: AI Workflow Patterns: The Real Unit of AI Adoption in 2026 · p1 — Where that piece argues AI-adoption conversations debate the wrong unit (models/agents instead of workflows), Hodgson's phased team-level KPIs (pilot counts, tool usage by task category, sentiment) are an operationalization that already targets workflow-level usage rather than model choice.
explicitMetrics used to drive AI adoption must be visibly framed as a tool for the team's own self-assessment, not a surveillance mechanism — leaders should avoid drilling into individual engineers' numbers and avoid sharing granular metrics with leadership above them, or the metrics will corrode the trust the whole program depends on.conf: high
explicitThe most common blockers to AI adoption are organizational, not technical: tool budget treated as a line-item concern despite being marginal next to fully-loaded engineer cost, and compliance/legal friction that a leader must actively clear rather than leave teams to fight alone.conf: high
explicitTeams will not spend time experimenting with AI unless a leader explicitly carves out capacity in the roadmap and says so out loud — absence of an explicit mandate to spend time on this defaults teams back to pure feature/bug-fix delivery.conf: high
explicitA Community of Practice should be seeded by leadership (clear accountability to bootstrap it, initial cadence of meetings) but should remain grassroots and practitioner-centered in substance — leadership's job is infrastructure, not content.conf: high
explicitcorroboratedUsing AI productively is a distinct, learnable, and currently non-obvious skill set (because AI capability is 'jagged' — strong and weak in unintuitive places) and therefore merits a structured training curriculum, not just access to tools.conf: high
supports ←Co-Intelligence, by Ethan Mollick: a Summary · p2 — Hodgson independently argues that using AI productively is a distinct, learnable skill precisely because capability is jagged (strong/weak in unintuitive places); this summary's account of Mollick's Jagged Frontier is the originating research behind that same diagnosis, applied here to general knowledge work rather than engineering specifically.
explicitLeaders must address the fear that AI will take engineers' jobs or remove the most rewarding part of their work directly and empathetically rather than dismissing it, because this fear is legitimate and widespread, not a morale problem to be managed around.conf: high
supportsResearch: Why You Shouldn't Treat AI Agents Like Employees · p5 — Both identify visible, empathetic leadership behavior (role-modeling, direct acknowledgment of fear) as more effective for driving genuine adoption than top-down mandates or hype framing.
explicitcorroboratedAI will likely automate the tedious parts of engineering work rather than the job itself, and Jevons Paradox implies that cheaper software production increases total demand for software enough to keep engineers employed, even as per-unit cost falls.conf: medium
supports ←The third golden age of software engineering – thanks to AI, with Grady Booch · p9 — Both argue AI automates tedious/low-judgment work (delivery pipelines; rote tasks) rather than eliminating demand for engineers overall.
implicitA leader's responsibility includes translating team-level AI-adoption data into a simple upward-facing narrative (a dashboard, a trend line) so that pressure from above (like the opening dialogue's CEO) can be met with evidence of a managed process rather than an improvised answer.conf: medium

Arguments

Leaders should set phased goals with autonomy and support, rather than mandating an AI-usage percentage target from the outset. strength: medium

Explicit premises:

Generative AI's capabilities and best practices are moving too fast for anyone, including leadership, to know the 'right' usage target in advance.
Engineers hold polarized positions (over-trusting vibe-coders vs. defensive skeptics) that a blunt usage mandate would entrench rather than resolve.
Prior successful technology rollouts (DevOps, cloud, CD) used goal-plus-autonomy-plus-support, not top-down mandates.

Implicit premises:

A team that discovers for itself where AI helps and where it doesn't will produce more durable adoption than a team told to hit a number.
Analogy to prior rollouts is a valid basis for predicting what will work for AI, despite the author's own claim that AI's pace of change is unlike anything in 20+ years.

Inferences:

This implies leadership credibility with engineers is itself a scarce resource the program must protect — which is why the metrics-misuse warnings (avoid pointy-haired-boss dynamics, don't share granular data upward) are treated as load-bearing, not cosmetic.

Engineers should use AI coding tools for real leverage while keeping human judgment central — the 'middle path' — rather than either full delegation (vibe-coding) or reflexive rejection. strength: medium