The New Engineering Leader's Question Bank

what to ask, across your first 90 days

Maintained reference · Kit · Version 1.0 · September 2026

Part of The New Engineering Leader's Kit

Every question below traces to a named source: a practitioner who's run this transition before, or one of the AI-era research lanes' verified findings. None of it is generic. Where a source gives a script or an exact phrasing, it's quoted; where it gives a pattern, this bank applies the pattern to the AI-native specifics the source itself didn't cover.

Grouped by when to ask, not by topic, because the sources that specify a shape (Hogan, Button, Larson, Uplevel) converge on the same one: listen before you narrow, and narrow before you act. Don't skip ahead to Month 2's questions in week one. The order is part of what makes the questions work.

Week 1 — Before You Ask Anyone Else Anything

These go to your own manager, or to yourself, before the listening tour starts.

“What are you optimizing for?” Ask your own manager this, not “why prioritize this.” Button's framing: the “optimizing for” version surfaces the real constraint, revenue targets, shipping deadlines, a tech-debt tradeoff someone already made, where the “why” version just gets you a directive back. (Button, “The first 30 days as a director of engineering”)
“What would make the first 90 days a clear win, in your words?” Ask it explicitly rather than assuming you already know. Practitioner consensus (Larson, Uplevel) treats month one as diagnosis, not delivery. If your own manager's version of a win is delivery, that gap is worth surfacing now, not in month three. (Larson, “Your first 90 days as CTO or VP Engineering”; Uplevel, “Your First 90 Days as a New Engineering Leader”)
“Is this team AI-assisted, or something closer to AI-native, and how would you tell the difference?” Ask it of your own manager or whoever's read on the org is broadest. It sets expectations for the dual-axis assessment below, and it's a fair question to ask before you've formed your own view.

Weeks 1–2 — The Listening Tour

Run these as 1:1 conversations, roughly thirty minutes, with every direct report, and with cross-functional peers as you meet them. Lara Hogan's own structure for this window: listen only, don't act, and keep a brief prep note in the calendar invite so nobody's caught flat-footed.

With each direct report or peer:

“When you think about this team as a whole and how it works, what change do you want to see?”
“What's working so well that we shouldn't change?”
Follow-ups, only if the first two open something worth chasing: “What's the risk if we don't make that change?” “If we made that change, how would it land on you and your team specifically?” “Who else should I be talking to about this?”

(Hogan, “How to spend your first 30 days in a new senior-level role”)

With your own skip-level, used carefully. If you've inherited managers, their reports are a skip-level relationship, not a direct one, and the discipline matters before the questions do: tell each manager first, framed as support (“I want a broader view so I can support you better”), not surveillance. Share back themes afterward, never individual comments. Solve what surfaces through the manager, not around them. If you're a sitting leader rather than newly arrived, these are skip-levels you already run — the discipline still holds, just reframe the ask around the shift to AI-native ways of working rather than around getting acquainted.

“What's one thing you wish leadership understood better about the work your team is doing?”
“Where do you spend most of your time day to day?”
“If you had the power to change one thing about how this organization works, what would it be?”

(makemeacto.cc, “Skip Level Meetings Are About Insight, Not Distrust”; the discipline rules also draw on jayvilalta.com, “Managing Managers”)

Weeks 2–4 — The AI-Native Diagnostic, Two Axes

Every source that measures both finds orgs mismatched on usage and governance, not uniformly high or low on either. Ask about them separately. Run the Maturity Model and Self-Assessment alongside these conversations, not instead of them.

Usage axis:

“Walk me through where AI actually touches your build-to-ship path today. Which phase is furthest along, and which one hasn't been touched at all?” Coder's own recommendation: find the lowest-maturity phase, not the average. Their assessment of 100 organizations found nearly 80% still sitting at the first two of five maturity stages, and 70% of agents running in infrastructure that was never built to support them. (Coder, “What 100 Engineering Teams Revealed About AI Maturity”)
“If we could only prove one thing got better before we touched anything else, what would that one metric be?” (Coder, same source)

Governance axis:

“Where would you put us, roughly, on tooling maturity versus on governance maturity, and are those two numbers even close to each other?” Microsoft's own maturity model is explicit that the two can sit at very different levels inside the same org, a team at Level 400 on tooling and Level 100 on governance simultaneously. (Microsoft Learn, “Introduction to the Agentic AI adoption maturity model”)
“Do we have a registry of every agent currently running: its purpose, its identity, and what it can reach? If not, who would even know how to start building that list?” (AIMultiple, “AI Agent Sprawl: Signs & Checklist to Manage Sprawl”)

Spend, asked directly rather than inferred:

“What's our AI tooling spend today, and what share of the engineering budget does that represent?” A common benchmark is roughly 1 to 3% of engineering budget, often near $1,000 per developer per year, with a wide real range from $500 to $3,000-plus. (Laura Tacho, getdx.com, “How are engineering leaders approaching 2026 AI tooling budgets?”)
“Which of these tools are we actually confident are earning that spend, and which has nobody evaluated?” In the same survey, 86% of leaders weren't sure which of their own tools delivered the most benefit. Expect an honest answer here to be partial. (Tacho, same source)

Month 2 — The Verification and Comprehension-Debt Audit

These are closer to a structured audit than an open conversation. Run them against real, recent work, not hypotheticals.

Verification debt:

“Walk me through the last AI-authored change that shipped. Who checked it, and against what?” Sonar's 1,100-plus-developer survey found 96% of developers don't fully trust AI-generated code is functionally correct, yet only 48% consistently verify it before committing, and 53% report AI code that “looks correct but isn't reliable.” (Sonar, “Sonar Data Reveals Critical ‘Verification Gap’ in AI Coding”; LeadDev, “You can't verify all the AI-generated code”)
“Does AI-authored code get reviewed differently than human-authored code here, or does everything get the same pass regardless of where it came from?”
“If I asked five engineers on this team to define ‘verified’ for a merge, would I get five different answers?” This is exactly the gap the Definition of Verified template is built to close.

Comprehension debt, using Kevin Cushnie's four audit signals directly, each turned into a question you can ask this month:

“Has review time per pull request gone down noticeably even though the work itself hasn't gotten simpler?” A drop of more than 30% is a compression signal, not an efficiency win.
“Pick a handful of recent architectural decisions. Can anyone produce a record that actually matches what shipped?” Below 60% accurate is a warning; below 40%, nobody's capturing intent anywhere anymore.
“In our last handful of incidents, how many post-mortems named unclear intent as a contributing factor?” More than two is a real signal, not noise.
“In design reviews, are our most senior engineers hedging more than they used to when asked to explain how something works?” (Kevin Cushnie, Forbes Technology Council, “Comprehension Debt: How AI Is Re-Creating The Legacy Code Problem In Months”)

Month 3 — Close the Loop

Self-facing, mostly, and worth writing the answers down rather than just thinking them.

“What did I say I'd figure out by day 90, and did I?”
“What's the one thing that was true in week one that I still haven't acted on?” Practitioner consensus warns against both extremes here: moving before you understand the shape of the problem, and never establishing traction at all. Neither is the goal. (Larson; Hogan)
Team-facing, once the cadence has been running a full cycle: “Now that review, retro, and 1:1s are actually happening on a rhythm, what would you change about how we run them?” This feeds directly into the next retrospective, not a separate conversation.