The New Engineering Leader's Kit for the AI-Native Era
navigating your first 90 days
Free. No email required.
Built for a VP or Director stepping into a new engineering org, whether you're new to the role or newly handed a team you didn't build. It holds up just as well if you're not new at all. A sitting leader taking their existing org into a new way of working runs into most of the same open questions a first-time VP does. Earlier-stage leads will find most of this useful too.
Michael Watkins named this transition years before AI entered the picture, and The First 90 Days is still the book most people reach for first. This kit borrows the same instinct (diagnose before you act) for a narrower moment: an engineering org, in an era where verification debt and comprehension debt are failure modes his book never had to cover.
What's Different at Day 90
This kit doesn't promise fluency across every practice area in the field guide. It promises five things, each pointing at something that already exists today, not a stub waiting on future writing:
- A running operating cadence. 1:1s, feedback, review, and retro are already sequenced into one calendar, not still being invented.
- Verification defined before you need it. A Definition of Verified in hand, not written after the first bad merge.
- An incident plan that predates the incident. The Agent Incident Runbook filled in before something breaks, not after.
- A real read on your team's AI maturity. Usage and governance, measured separately, not guessed at from one impression.
- Comprehension debt actively managed. Checked against named audit signals, not discovered the hard way.
The 30/60/90 Flow
Three blocks, roughly a month each, each building on the last: get the baseline running, then define what's still undefined, then close the loop before you need it. Most new leaders inherit rollouts already in motion, not a blank slate. The flow below is built around auditing what's already running as often as it's built around starting something new.
Days 1–30 — Get the Baseline Running
- Two diagnostics, run separately. The AI-Native Engineering Maturity Model (org-level, free download) and the Leader's Self-Assessment (team-level, sixteen questions, about five minutes). Run both. A team's AI usage and its AI governance move at different speeds, and asking only “are we using AI” answers the wrong question.
- The 1:1 Playbook. Weekly, every direct report, thirty minutes, starting week one. The single most load-bearing move in this kit: establishing 1:1 rhythm with an inherited team is almost always a new leader's first real action.
- The feedback playbooks: Giving and Receiving. Not scheduled. Continuous from day one, both directions: giving it well, and getting something usable out of what arrives unplanned. When you're ready to go ask instead of waiting, Soliciting is the third of the set.
- The AI Operating Model for Teams. Fill in the “as of” date and hand it to your team as the week-1-to-30 document: how we work, the tier scale, what breaks a tie.
- The Agent Rollout Pre-Flight Checklist, read as an audit, not a future-rollout form. Walk it against the agent work already running, not something you're about to launch. For each rollout you inherited, ask which of these boxes the team would have been able to check when they set it up. It's the fastest concrete read on governance maturity available in the first month, and it turns a checklist meant for what's next into a read on what's already here.
Days 30–60 — Define What's Still Undefined
- The Definition of Verified. Stood up before the first disputed merge, not written the week after one ships that shouldn't have.
- Verification debt and comprehension debt, audited together. Detail below.
- The Review Playbook. A fixed cadence, established rather than left to happen ad hoc. Every two weeks is the default absent a reason to run differently.
- The Retrospective Playbook. Slotted between the review and the next planning session, team-only.
Days 60–90 — Close the Loop Before You Need It
- The Agent Incident Runbook. Filled in before the first agent-caused incident, not improvised in the moment.
- Inheriting an agent fleet. Principle-level only, on purpose. Detail below.
- The cadence, now running as one system. 1:1s weekly, review on its fixed cycle, retro between review and planning, feedback continuous underneath all three. See The Cadence Calendar for the full compiled sequence.
Verification Debt
Verification debt is what builds up when code gets produced faster than any human review process was built to check it. Chris Stokel-Walker's reporting for LeadDev put a number on the gap: 96% of developers don't fully trust that AI-generated code is functionally correct, yet only 48% consistently verify it before committing, with AI-authored code already at 42% of all committed code as of that reporting, on a trajectory toward 65% by 2027. A separate 1,100-plus-developer survey from Sonar found the same shape from a different angle: 53% report AI generating code that “looks correct but isn't reliable,” and 88% report at least one negative technical-debt impact from AI use, even though most of the same respondents also report real benefits.
Two questions worth asking your team directly in this window: does AI-authored code get reviewed differently than human-authored code, or does everything get the same pass regardless of origin. And if five engineers on this team each defined “verified” for a merge, would you get five different answers, or one. The second question is exactly what the Definition of Verified template exists to close.
Comprehension Debt
Comprehension debt is the gap between how much code exists in a system and how much of it anyone can still account for. Comprehension Debt Is a Debt covers the full argument. Kevin Cushnie's treatment for Forbes Technology Council gives a new leader something more useful than the definition alone: four concrete signals to check in the first weeks.
- Review-time-to-complexity ratio. If review time per pull request has narrowed by more than 30% while complexity hasn't, that's compression, not efficiency.
- Architectural decision-record accuracy. Pick a handful of recent architectural decisions. Below 60% match between what's on record and what shipped is a warning; below 40%, intent isn't being captured anywhere anymore.
- Post-mortem pattern-matching. More than two recent incidents citing unclear intent as a contributing factor is a real signal, not noise.
- The explanation hedge. Listen for your most senior engineers hedging more than they used to when asked to explain how something works in a design review.
Cushnie's own line is the sharpest summary available: the codebase nobody understands is also the codebase nobody can defend.
Inheriting an Agent Fleet
This section stays short on purpose. Verification debt and comprehension debt above are both well-sourced, with hard numbers and named signals behind them. Inheriting someone else's agent fleet, with its tools and spend nobody fully mapped, is the weakest-sourced piece of this kit, and there's no real client moment here yet to anchor it with. Nothing below is invented to fill that gap.
What does exist: AIMultiple's agent-sprawl checklist recommends one concrete first move for anyone inheriting an estate they didn't build. Run a systematic inventory of every agent already running — its purpose and what it can reach — because retrofitting governance onto a fleet that's already operating is harder than building it in from the start. On spend specifically, Redress Compliance's 2026 audit of enterprise software spend found off-books AI spend running 4 to 9% of total software budget at the audited organizations, a 6% median, typically two to three times what finance had actually budgeted for it. Treat this as a directional finding from a small sample, not a number to expect exactly. Separate practitioner survey data puts common AI tooling budgets around 1 to 3% of total engineering spend, often near $1,000 per developer per year, with most surveyed leaders (86% in that survey) uncertain which of their own tools are actually earning their spend.
The honest version of this section, for now: inventory before you add anything new, and expect the spend picture to be less mapped than the org chart suggests. A deeper, story-grounded version of this section is on the roadmap once real client moments surface to build it from.
Also Relevant
Outside the five outcomes above, several existing essays speak directly to a new VP or Director, without being part of the ruled flow: Before You Schedule a Skip-Level, Ask This First, Emotional Acuity: The Leadership Capability Most VPs Never Learned, Surround Yourself with Courageous Truth-Tellers, Not Sycophantic “Yes Men”, The Steadiness Test, and Tone in Digital Communication. The full argument this kit draws its vocabulary from lives in the AI-Native Ways of Working field guide.
The kit has two standalone pieces, each its own document: the questions to ask in each part of your first 90 days, The New Engineering Leader's Question Bank, and the compiled calendar all four rituals run on, The Cadence Calendar. The PDF edition is all three in one printable document.
This Is a Fit Question, Not a Recipe
The shape above is a strong default, not a finished map of your specific org. Where your team actually sits against it, and what that's costing, is what the Engineering Ways of Working Diagnostic is built to find.