The moment usually looks like this.

Your senior IC — the one you trust, the one who's been carrying the weight on the team's hardest workflow — slacks you: "Hey, got 15? I built something."

You sit down. They share their screen. There's a notebook open, or a custom GPT, or a no-code workflow with seven AI nodes wired through it. They start walking you through it, and somewhere around minute three you realize: you do not actually understand what this thing is doing.

You understand the outcome they're claiming — "it cuts our weekly reporting prep from six hours to forty minutes." You understand that they're proud of it, and they should be. What you do not understand is the engine.

This is the moment most managers either rubber-stamp it ("amazing, ship it") or shut it down ("let's run this past IT first") — and both are mistakes that cost you authority either way. The rubber-stamp turns you into a mascot, not a manager. The shut-down trains your best people to stop bringing you their AI work and route around you.

Here's the exact script and the five-question checklist that lets you stay the manager in the room without faking competence you don't have.

The opening line that buys you back authority

The instinct is to fake understanding. The career move is to name the gap honestly — but frame the next move, not the gap.

Say this:

"Walk me through it one more time, but slower. I'm going to ask the boring questions on purpose. I need to be able to defend this when someone two levels up asks."

What that one sentence does:

• It legitimizes your slowness. You're not catching up; you're stress-testing for them.

• It positions you as their cover. You're not the bottleneck; you're the shield between their build and the next round of scrutiny.

• It signals the questions are coming. They get to prepare, not be ambushed.

Now you've earned the right to ask the five questions every direct-report-built AI thing must survive before you put your name on it.

The 5 questions every AI build must survive

These are not technical questions. You don't need to know what a vector embedding is. You need to know what breaks, who owns it, and what happens when it's wrong.

1. "What's the worst output it could produce, and how would we know."

This is the most important question, and the one almost no one asks. If your direct report says "it can't really produce a bad output" — that's a red flag. Every LLM-driven workflow has a failure mode. The good builders have already thought about it. Make them name one.

2. "Who is going to maintain this when you go on PTO."

Read more

Most AI pilots fail in the design phase — before anyone touches the tool.

Not because the technology doesn't work. Because the organization never agreed on what "working" means. Then the pilot runs, produces ambiguous results, and the people who wanted to greenlight the investment call it a success while the people who wanted to kill it call it a failure. The manager who ran it gets caught in the middle, with no clean read-out and no clear next step.

This is not a technology problem. It is a measurement problem that has a measurement solution.

The move is to set the protective metric before kickoff — the one number that determines, in advance, whether the pilot worked. Then run the pilot against that number, not against the room.

Why Most Pilots Don't Survive Contact With the Org

Here is the failure pattern. It runs the same way almost every time.

The pilot launches without a defined success metric. Leadership says "let's try it and see." The team runs the pilot enthusiastically. Three weeks in, someone from finance asks how it's going. The manager says "it's going well, the team is adapting." Finance hears: outputs not yet measurable.

Goalposts move mid-pilot. At the four-week check-in, the original sponsor has added new questions: can it handle [new use case]? What does the vendor think about [adjacent capability]? The pilot is now carrying three different mandates and none of them has a clean metric.

The read-out is contested. The manager presents results. The productivity improvement is real but modest. The person who was skeptical says it's not enough to justify the cost. The person who championed it says the team is still in the learning curve. There is no number that resolves the argument — because no one agreed on what the number should be before the pilot started.

The manager walks away from that meeting without a decision. The pilot drifts. The tool gets used informally or abandoned quietly. Nobody calls it a failure because nobody agreed on what failure looked like.

The Pilot-Design Checklist

Complete this before the pilot starts — ideally in a document you share with your manager and the pilot sponsor. The act of sharing it forces the agreements that prevent the failure pattern above.

Part A — Before Kickoff (Days –7 to 0)

Scope

• [ ] One workflow named: [what specific process is this pilot testing?]

• [ ] One team scoped: [which team, how many people, which roles?]

• [ ] Duration fixed: [start date → end date, maximum 30 days for a first pilot]

• [ ] Tool identified: [vendor / product name, version, licensing status confirmed]

Success metric — the most important field on this list

• [ ] One primary metric named and written down: [time saved per task / error rate / output volume / cost per output — pick one]

• [ ] Baseline established: [what is the current performance on this metric before the AI tool is introduced?]

• [ ] Target set: [what number constitutes success? Not "improvement" — a specific number or threshold.]

• [ ] Agreed in writing: [who has signed off on this metric? Name them.]

Kill criterion

• [ ] Named explicitly: [what result or condition means we stop the pilot?]

• [ ] Timeline for kill decision: [if we haven't seen [X] by [date], we stop. Written.]

Stakeholders

• [ ] Read-out date is in calendars: [date, who attends, format — 30-minute meeting or written summary?]

• [ ] The one stakeholder who can block the result has been briefed before the pilot starts

• [ ] Data collection responsibility assigned: [who is tracking the metric? How? How often?]

Part B — During the Pilot (Weekly, 10 Minutes)

Each week, write three sentences:

Read more

You didn't volunteer for this.

The initiative has your name on it now — AI integration for your function, AI-powered [workflow], AI readiness for the team — and you got it the way most non-technical managers get these assignments: someone in a leadership meeting decided you were the right person, and you found out after the decision was made.

Here's the honest frame: the first 90 days of an AI initiative you didn't ask for are not primarily about AI. They're about ownership. Specifically, they're about whether the organization's read on you at the 90-day mark is "this person is running it" or "this person is being run by it."

The difference is almost never technical. It's operational. And it's determined in the first two weeks.

Why Most "Accidental AI Owners" Lose the Narrative in Week One

The failure pattern is consistent. The newly-assigned manager does one of three things:

They disappear into research. They spend the first two weeks consuming vendor demos, reading reports, building a mental model of the AI landscape. They surface at Week 3 with knowledge but no visible progress — and leadership has already formed an impression.

They over-report inputs, not outputs. Every update is a list of things they attended, tools they evaluated, calls they took. Nobody asked for an activity log. They asked for a signal that someone is in control.

They wait for the playbook. They assume someone above them will define success, specify the scope, and hand them a clear mandate. That playbook does not exist — that's why they got the assignment.

The 90-day playbook below is designed to prevent all three.

The 90-Day Operator Playbook

One objective per phase. Everything else is a distraction until you've cleared it.

Phase 1 — Weeks 1–2: Stake the Ground

Objective: Be on record with a scope and a metric before anyone defines it for you.

Week 1 actions:

• [ ] Write a single-sentence scope statement: "This initiative will [change / improve / measure] [specific workflow] for [specific team] by [specific date]." If you can't write this sentence yet, your first job is making it writable — not evaluating tools.

• [ ] Identify the one stakeholder who can block this initiative if they feel bypassed. Send them a 3-line update this week (template below). Do this before your formal kickoff.

• [ ] Name one success metric — the single number that determines whether this worked. Write it down. Share it with your manager. Do not proceed without agreement on this number.

Week 2 actions:

• [ ] Confirm your resource reality: What is the actual budget? What staff time is allocated, and is that allocation protected or aspirational? What tools are already licensed?

• [ ] Map the three highest-friction points in the workflow you're targeting. These are where AI is most likely to help — and most likely to break things if the rollout is wrong.

• [ ] Schedule your 30-day read-out now. Put it in calendars before the pilot starts. The date existing in people's calendars changes how they treat the interim.

Phase 2 — Weeks 3–6: Run One Scoped Pilot

Objective: Generate one clean result from one tightly scoped test.

The scope rule: one workflow, one team, four weeks, one metric. Resist every request to expand the pilot before you have a result. Expansion is how pilots become unreadable.

What to measure: Time saved per task OR error rate OR output requiring revision — whichever your stakeholders care most about. Pick one. If you pick three, you'll have contested data at the read-out.

What to document as you go (takes 10 minutes per week):

Read more

At some point in the next budget cycle, someone is going to say it.

It might come from finance. It might come from your own VP. It might be framed as a question ("have you thought about how AI could absorb some of this?") or as a directive ("we need to find efficiencies"). But the subtext is always the same:

Why do I need your team if AI can do the work?

This is not a technical question. It is a framing attack — and most managers lose it before they even realize the fight started.

Here's what you need to know before your next planning meeting: the managers who survive this conversation are not the ones with the longest list of reasons their team is irreplaceable. They're the ones who reframed the question before they answered it.

Why the Standard Defense Loses

The instinctive defense sounds like this: "Our team does things AI can't do — relationship management, judgment calls, complex decisions." Every manager in every function says this. It is probably even true for your team.

It doesn't work.

Here's why. Finance and leadership aren't asking whether AI can do your team's entire job. They're asking whether AI can eliminate headcount at the margin — reduce the count by one or two, lower cost per output, or reassign scope. And on that question, the "we do things AI can't" answer is almost always wrong, or at least unverifiable in the meeting room.

The second defensive mistake is the productivity pivot: "We're already using AI to work faster." This sounds good, but it actually accelerates the headcount question. If your team can do 30% more with the same people, the next logical question is: can you do the same output with 30% fewer people?

Both defenses are playing on the attacker's terms. You need different ground.

The Reframe: Your Team Is the Measurement Function

Here's the frame that shifts the conversation.

Read more

The all-hands goes exactly like this.

Someone from the C-suite says "we're moving to AI-first workflows." There's a slide. There's a timeline. Everyone nods. And then the meeting ends and you walk back to your desk thinking: What does this actually mean for my team? What am I supposed to do Monday?

Here's what's real: the mandate isn't a tech decision that landed on you. It's a visibility test you didn't schedule.

The next 90 days will sort the room into two groups — the people who turned the mandate into a measurable result, and the people who got busy without direction. One of those groups gets a promotion story this year. The other gets a performance question.

The move isn't to understand the AI tools. The move is to run the right play, starting this week.

Why the Default Reaction Loses

Most non-technical managers pick one of two failure modes when an AI mandate lands.

Failure Mode A: Silent over-compliance. You adopt everything that's put in front of you. You're seen at every training. Your team runs three pilots simultaneously. You look busy, never push back, never show judgment. The result: nobody knows whether you're driving this or just along for the ride.

Failure Mode B: Quiet resistance. You ask for more time. You raise every concern about workflow disruption in every meeting. You become the person who is "worried about quality" or "needs more data before committing." The result: you get labeled the blocker.

Both read the same to leadership. Neither signals that you get it.

Read more