The calibration meeting is forty minutes in, and you have reached the name that was always going to be awkward. Their numbers are up by a margin that would have been remarkable a year ago. Someone across the table says, lightly, "Well, that's mostly AI." Someone else says the same thing about a different person, except this time it is a compliment, and the room is suddenly arguing about two people who may have done almost identical things.

Nobody is being unfair on purpose. The room simply has no shared way to talk about this yet, so everyone reaches for the nearest instinct. Half of them want to discount the work because a tool helped. The other half want to reward the numbers because a number is a number. I am wary of both instincts, because each one scores the tool and neither scores the person.

Here is where I land on it. You do not need a new policy to survive this meeting. You need to move the conversation from the tool to the person, and to do it with sentences that sound like ordinary good judgment rather than a position on AI. Below are the lines I'd say, and a page you can paste into your prep so the argument has something to point at.

Read more

The evaluation went well enough. You checked the seven things, sent the note upward, and the answer came back the way it usually does: "Sounds good, let's move forward." Then the vendor sent a contract. It is for twelve months, it renews automatically, and the price assumes every person on your team uses the tool every day.

Nobody in that chain was wrong, exactly. Your boss wanted progress, the vendor wanted a signature, and the contract is simply the shape vendors prefer. It is also the shape that turns a promising demo into a line item you are still defending next September.

Here is where I land on it. "Move forward" does not have to mean "sign for a year." It can mean a short, paid pilot with six terms written down before anyone starts: what it covers, how you'll judge it, when you'll decide, what it costs, what happens to your data, and how you walk away. Vendors agree to this more often than people expect, because a well-run pilot is their best path to the big contract too. The managers who ask for it look careful rather than difficult, and the ones who don't ask usually end up owning the renewal.

Read more

Every team has one now, and they are rarely the person you would expect.

They are good at their job, often the best on the team at the part that matters. They sat politely through the AI training, closed the tab afterwards, and went back to doing the work the way that has always worked. When someone mentions the tool in the stand-up, they go quiet and look faintly tired, like someone who has been asked to admire a colleague's holiday photos for the third time.

Meanwhile you have been asked to "drive adoption," a phrase that has never once caused anyone to adopt anything.

I'd resist treating this person as a problem, and I feel fairly strongly about it. The holdout is usually holding out for a reason, and it is often a reason you would respect if you heard it said plainly. Your job this week is to hear it. Everything useful follows from that one conversation, and everything that goes wrong with holdouts starts from skipping it.

Read more

Somewhere in your company there is an AI pilot that has been "going really well" for six months.

You know the one. It has a Slack channel with a rocket emoji. It gets a line in every monthly update. When someone senior asks how it is going, the answer is warm and general, and then the room gets very interested in its laptops.

If that pilot is yours, this issue is for you, and I want to say the uncomfortable part first. "Going really well" without a number is not a status. It is a hope with a project code. The reason nobody has pressed you on it is not that they believe you. It is that they have not needed to yet. Budget season fixes that.

The good news is that finding out the truth takes one afternoon, and the truth is useful whichever way it lands. Here is how I'd spend the afternoon, what I'd write down, and what I'd say upstairs if the number turns out to be bad.

Read more

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