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 self-appraisals landed in the shared folder on Friday afternoon, and you opened the first one with real goodwill. It said the writer had "driven cross-functional alignment across a complex stakeholder landscape and delivered measurable impact on key deliverables." The second one said nearly the same thing in a different order. By the fifth you noticed that every one of them had three tidy headings, a confident closing paragraph, and not a single sentence that sounded like the person you work with.

Ratings are due in a week. You have eleven of these to read, and you are quietly wondering whether you are about to give a high score to a chatbot.

Here is my view, and I hold it firmly. Do not try to work out who wrote what. Detection is a guessing game that you will lose in one direction or the other, and either mistake lands on a real person. Somebody who used a tool to polish honest work gets treated like a cheat. Somebody who typed every word themselves, in careful corporate English, gets accused of sounding like a robot. Neither outcome is fair, and neither is yours to cause over a paragraph of style.

What I'd do instead is simpler. Read each appraisal for evidence, and ask for the evidence when it is missing.

Why polish tells you nothing this year

For a long time, a well-written self-appraisal was a loose signal of effort and communication skill. That signal is gone. A smooth paragraph now costs about thirty seconds, and it costs the same for the colleague who had a great year and the one who did not.

So the prose has stopped being information. What still carries information is anything the tool could not have known: a particular decision, a particular figure, a particular regret. A language model can write "improved turnaround time" about anyone. It cannot know that you pushed the Henderson order out a week to protect the audit, or that the backlog dropped from the number you remember to the number you hoped for. Only the writer knows those, and a person who did the work finds them easy to supply.

That gives you a clean test that does not depend on guessing anything about how the document was produced. Ask for the part only the person could know, and see whether it comes back quickly and specifically.

The one move: three questions, sent before the 1:1

Send each person the same short message, on Monday, a few days ahead of the conversation. Make it routine, so nobody feels singled out. Here is the one I'd use, ready to copy:

Thanks for sending your self-appraisal. Before we meet, I'd like three specifics to go with it. Short answers are fine, and a few lines each is plenty.

1. The one decision from this year you'd point to, and what the alternative was.

2. The one number you own, where it started, where it is now, and what moved it.

3. One thing you would do differently if you got the year back.

I'll read your appraisal alongside these when I write my rating.

It takes five minutes to send to the whole team, and it quietly changes what the appraisal is. The long document becomes the summary, and the three answers become the exhibits.

What each question is really checking

The decision. The question I'd ask myself while reading is whether there was a real fork. A strong answer says "we could have shipped on the date or held it for the fix, and I held it, and here is what that cost us." A thin answer names a project and calls it a decision. Real decisions have an alternative, and the writer can almost always name it without thinking.

The number. I'd look for an owner's relationship to the figure. A strong answer says where the number started, roughly where it landed, and what the person did that moved it, including the part that was luck or somebody else's work. A thin answer repeats a percentage from the appraisal with nothing underneath it. If you have the real figure from your own dashboard, hold it back and compare quietly. Do not turn it into a quiz in the meeting.

What they would do differently. This is the one a generic summary struggles with most, because it needs the writer to have actually looked back. A strong answer is small and slightly uncomfortable: "I'd have raised the staffing problem in March, not June." A thin answer is a dressed-up strength, such as "I'd probably try to delegate more, because I care so much about quality." Take the small and slightly uncomfortable answer every time. It is the best evidence of self-awareness a rating form will ever see.

Reading the answers fairly

Some people will write the follow-up in their own plain, slightly rough voice, and it will sound nothing like their appraisal. That is fine, and it is often a good sign. You are not looking for a match in style. You are looking for facts that hold together and that you recognize from the year.

Some people will answer thinly, and that is useful to know, but I'd treat it as a prompt for a question rather than a verdict. Quiet people, new hires, and anyone writing in a second language may need a day and a nudge. In the 1:1 you can say, "Walk me through the decision one more time, out loud," and listen. Most people who did the work can talk about it for two minutes without notes.

I'd also keep your own file. Three or four dated lines per person, kept through the year, would have settled most of this already. If you have none, start this week for next year. The follow-up questions are a repair for a year that went by without notes, and there is no shame in using one.

One practical note: look at what your company's policy says about using AI tools to prepare appraisals before you comment on it. Many have not written a line yet. If yours has, follow it. If it has not, I would not make up a rule in the middle of review season and enforce it on eleven people.

Opening the 1:1

You do not need to mention the tool at all. I'd open with something like this:

"I read your appraisal and your three answers. The part I'd like to spend our time on is the decision you described. Tell me what you were weighing."

That sentence tells the person that evidence matters here, and that the conversation is about their work. Whoever wrote the first draft, the person across the table now has to talk about what they actually did.

What this gets you

By the end of next week you will have rated eleven people on what they did rather than on how smoothly they described it. Your ratings will be easier to defend when your own boss asks "why a four?", because each one rests on a decision, a number and a lesson you can name. The polished-but-empty appraisals will have sorted themselves out without anyone being accused of anything.

Send the message on Monday morning, then close the shared folder. Eleven very capable-sounding strangers can wait until the answers come in.

P.S.

If you'd like more questions that get specifics out of people without feeling like an interrogation, The AI Meeting Survival Kit puts them on one page. It also has a flip card of the AI terms that show up in leadership rooms. ($19. The three questions above work on their own.)

One small favour. If The AI Jargon Buster has helped you in a meeting, an honest review on Amazon or Goodreads helps the next manager find it. Two lines is plenty. Good, bad or "it's fine": all of it helps. Review on Amazon · Rate on Goodreads

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

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

The demo was on Tuesday, and it went well. The product summarized a stack of documents in seconds, the account executive was funny, and the slide at the end had logos you recognized. On Wednesday morning the proposal arrived as a PDF, your boss forwarded it to you, and the whole message was one word: "Thoughts?"

That one word is how most AI purchases actually get decided. Somebody who liked the demo writes back "looks promising," and eighteen months later the same somebody is explaining the renewal.

Here is my view, and I hold it firmly. Most vendor evaluations are decided in the demo, and the criteria get written afterwards to explain a feeling people already had. I'd write the criteria first, before the next call, and let the vendor do the work of answering them. You do not need to understand how the model works to do this well. You need seven questions and the patience to wait for real answers.

If you want the tactics for the meeting itself, I've written about reading the pitch and about the one request that breaks a polished demo. This piece is the list you check everything against.

1. Business fit

The plain-English version: does this solve the specific piece of work you named, or a nearby problem the vendor is better at?

The question I'd ask: "Which of our workflows does this replace or speed up, and what does that workflow look like the week after we switch it on?"

A good answer names your workflow back to you and describes a Tuesday afternoon after launch. A weak answer talks about "transformation" and "use cases across the enterprise." When a vendor can't describe your ordinary week, they are selling you their product's best week instead.

2. Total cost

The plain-English version: what will this cost in year one, including the parts that are not on the pricing page?

The question I'd ask: "Can you put in writing what we'd pay at our current volume, and at double it?"

A good answer is a number with assumptions attached. A weak answer is "it depends on usage" followed by an offer to "model it together later." Usage-based pricing is fine. Pricing nobody will write down is a cost you will discover in the second quarter.

3. Data handling

The plain-English version: where does your data go, who can see it, and does the vendor use it to improve their product?

The question I'd ask: "Is our data used to train your models, and can you show me the contract language that says so?"

A good answer points to a paragraph in a document. A weak answer is a reassuring sentence from the salesperson. I'd also loop in whoever owns security at your company before you get attached, because they will ask this question eventually and it is better if they ask it now.

4. Output quality on your work

The plain-English version: is the output good enough on your own messy examples, rather than on the vendor's prepared ones?

The question I'd ask: "Can we send you five real examples this week and see the outputs before we go further?"

A good answer is "yes, send them." A weak answer is a case study from a company that looks nothing like yours. Your own examples will tell you more in an afternoon than the demo did in an hour.

5. Implementation reality

The plain-English version: who does the work to get this running, and how long does it take for a team like yours?

The question I'd ask: "For a team with no AI engineers, who does the setup, and what do you need from us in the first month?"

A good answer names people, hours and a date. A weak answer mentions a "professional services engagement" that was not in the proposal. That line is where the real price often lives.

6. Exit and lock-in

The plain-English version: if this doesn't work out, how hard is it to leave?

The question I'd ask: "If we cancel after a year, what do we get back, in what format, and what do we have to rebuild?"

A good answer is boring: an export, a standard format, a clean termination clause. A weak answer changes the subject to how happy their customers are. I'd ask this one while everyone is still friendly, because nobody enjoys asking it later.

7. Vendor stability

The plain-English version: will this company and this product still look the same by the time your contract renews?

The question I'd ask: "What's shipping in the next two quarters, and what happens to our price if you're acquired?"

A good answer separates what exists today from what is planned. A weak answer blends them together until you can't tell which features you are actually buying. I'd buy what works now and treat the roadmap as a nice surprise if it arrives.

The note to send back

Once you have the answers, reply to "Thoughts?" with seven lines. Give each criterion one sentence and one mark: green if the answer was clear and in writing, amber if it was clear but only spoken, red if you didn't get one.

Here's where we are on the proposal, against seven criteria:

1. Business fit: green. It replaces our intake triage and they described the week after launch in detail.

2. Total cost: amber. Year-one number is clear; the "double volume" number is promised by Friday.

3. Data handling: green. Contract says our data is not used for training; security has the paragraph.

4. Output quality: amber. Their examples look good; ours come back Thursday.

5. Implementation: red. Setup assumes an engineer we don't have, so I've asked who does it.

6. Exit: green. Standard export, 60-day termination.

7. Vendor stability: amber. Roadmap is vague past one quarter.

My recommendation: continue, conditional on 4 and 5 by next Friday.

Those example answers are placeholders, so write your own. The shape is the point. Your boss can forward it upward without editing, and nobody can accuse you of either blocking the tool or waving it through.

What this gets you

Most people answer "Thoughts?" with a feeling, because a feeling is all the demo gave them. You'll answer with seven lines that say what you checked, what you're still waiting for, and what you'd do next. That reads as judgment, and judgment is what gets you handed the next decision.

Write the seven questions into your notes before the next vendor call, send them over, and let the vendor spend the week answering. You have better things to do on a Wednesday than evaluate a mood.

P.S.

If you're comparing more than one vendor, or this one is a big contract, The AI Vendor Evaluation Kit gives you a sixteen-question bank for the call, a weighted scorecard, and a one-page recommendation leadership can act on. ($29. The seven questions above work on their own.)

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

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

The planning template for next year arrived this week. It looks almost exactly like last year's, with the same tabs for headcount and spend, and one new tab at the end called "AI Initiatives." It has four columns, running from initiative to timeline. It is due a week from Friday.

Somebody in finance built that tab in an afternoon, and whatever you type into it will follow you around for twelve months.

Here is my opinion about that row, and I hold it fairly strongly. Anything you write in a planning document becomes a promise, and planning promises get checked in December by people who were not in the room when you made them. So I'd write the row you would be happy to be held to. That is rarely the most impressive one on the page, and it is almost always the one that ages best.

What the tab is really asking

The template says "initiatives," but three different people will read your answer, and each of them wants something different.

Your boss wants something they can repeat upward without being embarrassed. Finance wants to know whether to hold money for you and whether any of your costs are about to go down. Your boss's boss will skim the tab for the word AI, feel reassured that it appears, and move on.

None of them is asking for a vision. Nobody has ever been promoted for the adjectives in a planning template. What survives the year is a row that is small, specific, and true, because in December it will still say what you did.

The four lines I'd write

I'd fill in one initiative, not five, and I'd make each column do one honest job.

The initiative is a named task, not a theme. "Use AI to improve customer experience" is a theme, and a theme can never be finished, which means it can never be done well either. "Draft the weekly customer status report with the tool the company already allows, with a person checking every figure" is a task. You can tell in March whether it happened.

The benefit is in hours, with its source. If you have already tried the tool on that task, write what you saw and say so: "Estimated two hours a week, based on a four-week test in October." If you have not tried it yet, say that instead: "To be measured in the first quarter, readout by the end of February." An honest "to be measured" is worth more than a confident number you made up on a Thursday afternoon, and finance can smell the difference.

The cost has a ceiling. Seats, times the price per month, times the number of months, written as a total. Add the words "no new headcount" if that is true. A cost with a ceiling is a decision. A cost without one is a subscription that renews itself.

The timeline is a decision date, not a launch date. "Expand to one more task or stop, by the end of March, based on the readout." That line does more for you than anything else in the row, because it shows you planned to find out whether it worked.

Here is the row as a template. Copy it into the tab and fill in the brackets.

Initiative: [one named task] for [team], using [the tool your company already allows].

Expected benefit: Estimated [hours] per [week or month], based on [the test you ran, or "a four-week measurement in the first quarter, readout by (date)"].

Cost: [seats] × [price per month] × [months] = [total]. No new headcount.

Decision point: Expand to one more task, or stop, by [date], based on the readout.

Four lines. No vendor names in the benefit, no adjectives anywhere, and a date on which you will know more than you do today.

The one number I would leave out

The column you will be most tempted to fill in is the one nobody put on the template: headcount.

Somewhere above you, someone would love to see a line that says the tool saves one person. I would not write it for a tool you have not measured, and here is why. Once a headcount saving appears in a plan, it tends to come out of your budget in January, whether or not the tool delivers by June. Hours saved go back into the team. A headcount saving comes out of it, and it comes out on the planning calendar, not the tool's.

So I'd describe the gain in hours and say what the team will do with them. Name the thing that has sat on your backlog for a year because nobody had time: the process document, the customer follow-up, the cleanup nobody owns. "The saved time goes to the renewal follow-ups we currently skip" is a sentence finance can live with, and it keeps the benefit inside your team where it belongs.

If someone senior insists on a headcount figure anyway, I'd say this, and you can use it as written:

"I'd rather that number come from you, because I can't defend it yet. What I can defend is the hours, and I'll have measured ones by March."

It is polite, it is true, and it puts the number with the person who wants it.

The note to send with it

Do not let the row travel alone. Send your boss a short note when you submit the template, so they hear your reasoning from you before they read it in a spreadsheet. Something like this:

Subject: The AI line in our plan

I've kept our AI line small on purpose. It's one task we can measure, with a cost ceiling and a decision date, and I'd rather beat it than explain it next December. If the readout is good in March, I'll come back with the next task and a number I can stand behind. Happy to talk it through before it goes up.

Four sentences. It tells them you were careful rather than timid, and it gives them a line to use if their own boss asks why your row looks modest.

If your boss wants it bigger

Sometimes the answer comes back, "Can we be more ambitious here?" That usually means someone above them is counting rows.

I'd agree to more ambition and keep the shape. Add a second named task with its own decision date, rather than inflating the first one. And say this:

"I can make it bigger. I'd just rather make it bigger in March with our own numbers than now with a vendor's."

Most bosses hear that as good judgment, because it is. The ones who still want a bigger promise are telling you something useful about how the year is going to go, and it is better to learn that in October.

What this gets you

When the template goes in, your AI row will be the shortest one on the tab. It will name one task, give one honest estimate, cap one cost, and set one date.

In December, when finance opens the plan and runs down the rows, most of that tab will read like a brochure from a year ago. Yours will say what you did, what it cost, and what you learned. That is rare enough in planning documents that people notice, and the people who notice tend to be the ones who decide who gets next year's interesting work.

Fill in the row, send the note, and close the template. It will still be there on Monday. Go enjoy the rest of your Thursday.

P.S.

If you want to know where your team really stands before you write the row, The AI Readiness Self-Audit is a twenty-minute snapshot across five areas, scored by you, on one page. ($19. It makes the "expected benefit" column much easier to fill in honestly.)

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

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 all-hands ran long. Somewhere in the last ten minutes the CEO said the sentence, and you could feel four hundred people nod at once: "We are an AI-first company now."

Nobody clapped, because nobody was sure whether it was a strategy or a mood. A slide followed with three logos on it. Then the Q&A, then the recording, then the Slack message from your boss that just said "Thoughts?" with a link to the recording you had already sat through.

I have a strong opinion about that sentence, and it is this: nobody in the building knows what it means yet, including, I'd wager, the person who said it. That is not a criticism. Companies announce direction before they have the plan, because the plan comes from what teams do next. Which means that for the next month, "AI-first" means whatever the first few managers make it mean.

You can be one of them. It takes about four weeks and no budget, and it ends with you holding the one sentence everyone else in the building is about to be asked for.

What is actually going to happen next

Here is my prediction for the next thirty days at your company, and I'd be surprised to be far off.

Some team will announce a "task force." It will have eleven people and no agenda. A vendor who saw the LinkedIn post about the all-hands will email your CIO. Two people on your own team will start quietly using tools they have not told you about, and one of them will be very good at it. And at some point, in a skip-level or a hallway or the last five minutes of a quarterly review, someone senior will turn to you and ask, "So, what is your team doing with AI?"

That question is the whole game. Not the task force, not the vendor, not the logos on the slide. The manager who has one honest sentence ready for that moment is ahead of most of the building. The bar this year is on the floor. You might as well step over it.

The four weeks

I'd run it like this. One small thing per week, each one built on the last, none of them requiring permission.

Week one: pick one task, not a strategy

Choose one piece of work your team does every week that everybody mildly resents. The status report. The meeting recap. The first draft of the customer update. Reformatting the same spreadsheet for the same deck.

The test for a good candidate is simple: it happens weekly, it produces words or a table, and if the first draft were wrong you would notice before anyone outside the team did.

Do not pick the most important thing your team does. Pick the most boring thing. Boring is where the early wins are, and boring is safe to get wrong.

Week two: run it twice, and write down two numbers

Do the task the old way once and time it. Do it with whichever AI tool your company allows once and time that too. Use real work, not a demo. Write both numbers down on one line, with the date.

That is your entire evidence base, and it is more than most people at the task force will have by December.

Two rules while you do it. No customer data goes into a free tool, and a human reads every number, every name, and every date before anything leaves the team. Say both rules out loud to your team this week, and say that nobody is in trouble for the tools they have already been using. You will learn more in that twenty-minute conversation than from any survey the task force sends around.

Week three: fix what it got wrong, and keep a list

The tool will get something wrong. It will be too cheerful, it will invent a figure, or it will summarize the wrong meeting. Good. Write down what it got wrong and what you did about it.

This list is the part that makes you sound like an adult later. "It helped with the draft and got the numbers wrong, so we kept a human on the numbers" is a sentence that has never been said by a vendor. Only by someone who has done the work.

Week four: write the sentence and the email

Now you write the one sentence. Here is the shape, and you can use it as written:

We tried it on [the task]. It [what helped] and [what it got wrong], so we [what you changed]. Next we are trying it on [the next task].

Say it out loud once. If it survives being read to a fifty-year-old VP without a wince, it is done.

Then send your boss a note before anyone asks. Something like this:

Subject: What my team is doing with AI, in case it comes up

Since the all-hands I wanted to have an honest answer ready rather than a slide. We tried it on the weekly status report for three weeks. It cut the drafting to about a third of the time and got two figures wrong in the first week, so we now keep a human on every number. Next we are trying it on the customer recap. Happy to walk you through it in our 1:1, and happy to share the write-up if anyone above you asks.

Four sentences. No vendor names. A flaw admitted in the middle, which is what makes the rest believable.

The three ways people get this wrong

I'd watch for these, because they are how a good month turns into a bad one.

Volunteering for the task force. If you get invited, go, but do not offer to run it. Task forces at this stage produce vocabulary. You are producing a result. If you get any say at all, push for one change to its charter: replace the word "strategy" with one named workflow, one owner, and a date six weeks out. Then quietly keep doing your own thing.

Taking the vendor meeting alone. When the vendor email reaches you, and it will, ask for one thing before the second meeting: let us run it on our own mess. Last month's real tickets, the ugly spreadsheet, the contract with the odd clause. A good vendor says yes without flinching. A nervous one suddenly needs to "scope that with the solutions team." Either way you have learned what you came to learn.

Learning to code out of guilt. You do not need Python for any of this, and I say that as someone who writes about AI for a living. Nobody asked you to learn engine repair before you managed a fleet. Your job was always to know what good looks like, ask the awkward question, and notice when the answer is mush. That job transfers completely.

What this gets you

At the end of the month you will have one sentence, one email already sent, one list of what went wrong, and two numbers on a line with a date next to them.

That is a modest pile. It is also more than the task force will have, more than the vendor will admit to, and exactly what the person who asks "what is your team doing with AI" is hoping someone in the room will say.

When the announcement came, "AI-first" meant nothing yet. In your corner of the building it now means a status report that takes a third of the time and a manager who knows where the tool lies. That is a definition. Somebody had to write one.

Go enjoy the rest of your Monday.

P.S.

If you want the version of this you can carry into the room, with the sentence, the objections you will hear, and what to say to each one on a single page, that is what The AI Meeting Survival Kit is for. ($19. Read it before the next all-hands, not after.)

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

The Edge · Paid Template · Ju

ne 2026

You are being asked to evaluate AI vendors — or you already have one and someone is about to ask you to justify it.

Either way, the conversation you're walking into is not a technology conversation. It is a business decision that will be reviewed by people who do not want to understand the technology. They want a number, a recommendation, and confidence that you thought it through.

This scorecard gives you all three. It is the paid version — seven weighted criteria, a scoring scale, a worked example, and the one question that changes the outcome of every vendor meeting. A shorter 4-question version circulates freely. This is the version you use when the stakes are real.

Fill it in. Score it. Walk in with the total.

How to Use This Scorecard

Time required: 45–90 minutes per vendor, depending on how much information they've given you.

When to use it:

• Before recommending a vendor to leadership

• During a contract renewal when you're deciding whether to stay or switch

• When evaluating two or more competing tools for the same use case

• When you're inheriting a vendor relationship and need to quickly assess what you have

Scoring scale: 1–5 per criterion (1 = fails / no answer, 3 = adequate, 5 = clear strength)

Weight: Each criterion carries a weight. Your weighted score = raw score × weight. Maximum possible total = 100.

Recommendation thresholds:

• 85–100 — Proceed / renew with confidence

• 70–84 — Proceed with named conditions (list them)

• 55–69 — Request 30-day structured pilot before committing

• Below 55 — Do not proceed — escalate or re-evaluate alternatives

The Scorecard

Vendor name: [ vendor name ]

Use case being evaluated: [ use case being evaluated ]

Evaluated by / date: [ evaluated by / date ]

Criterion 1 — Business Fit (Weight: 20)

Does this tool actually solve the specific workflow problem you have, at the scale you operate?

• 5 — Directly addresses the named workflow; references work comparable to your org size and function

• 4 — Strong fit with minor adjustments required

• 3 — Adequate fit; some workflow gaps that require workarounds

• 2 — Partial fit; significant adaptation needed or core use case is adjacent, not direct

• 1 — No clear fit; vendor is pitching broadly without addressing your specific workflow

Questions to ask:

• "Show me a demo built around [your specific workflow] — not a generic feature tour."

• "What's your typical customer's team size and function?"

Your score (1–5): [ score ] × 20 = [ weighted ]

Notes: [ notes ]

Criterion 2 — Total Cost Transparency (Weight: 20)

Do you know exactly what you will pay at current usage AND at 2× and 5× scale?

The hidden cost structure is the most common vendor trap for non-technical buyers. AI vendors frequently charge by the token (a token is roughly ¾ of a word — so a 1,000-word document is approximately 1,300 tokens). At small scale this is trivial. At org scale, it can be a surprise budget line.

• 5 — Per-seat or flat-fee pricing with clear overage terms; vendor provides usage estimates for your volume and a written cost projection for 2× and 5× scale

• 4 — Clear pricing model; 2× cost projection available on request

• 3 — Pricing is documented but requires calculation; vendor willing to provide estimates

• 2 — Usage-based pricing with limited visibility; must request cost modeling

• 1 — Pricing is unclear, contact-sales-only, or vendor deflects cost questions

Questions to ask:

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

You walked into the skip-level review thinking you were going to talk about Q3 numbers. Twelve minutes in, your Boss's Boss leans back and says, "So — what's your team doing with AI."

Not "what do you think about AI." Not "have you tried AI."

What's your team doing.

You feel the temperature in the room shift. Because both of you know this isn't a curiosity question. It's a credentials check. They're not testing whether you know what a Large Language Model is. They're testing whether you're the kind of operator they'd hand the next strategic project to — the one where the budget line item is going to read "AI-enabled."

Most managers in this moment do one of three things, and all three lose them the next initiative:

1. The catalog. "Oh, we're piloting Copilot, and we're looking at Glean, and the marketing team is using Jasper" — you just told a senior leader that your AI strategy is a list of vendor logos. Logos are not a strategy.

2. The hedge. "We're still evaluating. There's a lot of hype and we want to be thoughtful." — you just told them you have no point of view. They have ten managers without a point of view. They were looking for one with one.

3. The deflection. "We're waiting on IT" / "It's coming out of corporate" / "Legal hasn't signed off." — you just made yourself a passenger. Passengers don't get strategic projects.

Here's what the room is actually asking for.

What the question really tests

A skip-level asking "what's your team doing with AI" is testing three things at once:

• Authorship. Are you running this, or is this running you.

• Specificity. Can you point to one workflow, one decision, one measurable change — or only to nouns and vendor names.

• Judgment. Do you know what shouldn't be on the list yet.

The last one is the underrated one. Senior leaders are drowning in pitches. The manager who can say "we deliberately are NOT doing X yet, because Y" sounds like an adult. The manager who says "we're doing everything" sounds like they've outsourced their thinking to the vendor floor.

The one-sentence answer that wins the next initiative

Here is the template. Memorize it. It works in skip-levels, board prep, and the hallway after the all-hands.

"We're using [ONE NAMED TOOL] in [ONE NAMED WORKFLOW] to move [ONE NAMED METRIC], and the test we're running by [DATE] tells us whether to scale it or shut it down."

Four blanks. That's it.

Fill them in for a status meeting. Fill them in for the skip-level. Fill them in for the cocktail at the offsite. The answer should be the same answer, because if you can't say it the same way to three different audiences you don't have a strategy — you have talking points.

Here are three versions, drawn from the kinds of teams that I see Stuck Operators leading right now:

"We're using Microsoft Copilot in our weekly executive status report to move the prep−hour cost from 8 hours to 2 per week, and the test we're running through July 15 tells us whether to scale it across the other team leads or shut it down."

"We're using ChatGPT Team in customer−call summary triage to move time−to−first−CSM−response on tier−2 tickets, and the test we're running over the next two sprint cycles tells us whether the quality holds up at volume."

"We're using an internal LLM wrapper in contract redlining to move the legal review queue down from 14 days to under 5, and the test wrapping mid−quarter tells us whether to invest in the second use case."

Notice what every one of those does:

• Names the tool — no logo soup. One.

• Names the workflow — not "the business." A workflow.

• Names the metric — not "efficiency." A number that can move.

• Names the date — a kill-or-scale point you've already committed to.

The skip-level hears all four and concludes: this person knows what they own, what they're testing, and when they'll know.

That's the person they hand the next initiative to.

What to do this week

You don't need a strategy off-site. You don't need a vendor demo. You need to walk into Friday with the four blanks filled in for one real thing your team is already touching.

If you have nothing, pick the one workflow that costs you the most preparation time per week. Sketch the four blanks for THAT workflow as a 30-day test. Put it on a single page. Send it to no one. Bring it into your 1:1 with your boss and say, "I want to test this — flagging in case you hear about it."

Now when the skip-level happens — and it will, this quarter — you have the sentence. You don't fumble the catalog or the hedge or the deflection. You give them the four-blank answer.

You stop being a manager who "has thoughts on AI." You become the manager who is running something on it.

That's not a vocabulary upgrade. That's a status upgrade.

P.S.

If you want the field-tested version of this — the exact four-blank scoring rubric your skip-level is mentally running on you, plus a vendor-by-vendor template to fill in the first blank without getting played — that's what The AI Vendor Evaluation Kit is for. ($29. Use it before the next demo lands on your calendar.)

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

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

Performance review season has a new variable. It's showing up in development plan templates, competency frameworks, and 360 feedback forms at organizations that had never mentioned AI in writing before.

If you're a manager or director, you're about to be evaluated on it — or asked to evaluate others on it — and nobody has defined what "AI fluency" actually means at your level.

Here's the thing: it doesn't mean what most people think it means. And that gap is a positioning opportunity.

What AI fluency is not (for your level)

It is not knowing how to build a model. It is not knowing the difference between GPT-4 and Gemini. It is not being the person who runs the AI pilots or manages the vendor relationship.

Those are technical and operational skills. Some of your direct reports may have them. That's fine.

What's being evaluated for managers and above is something different: the ability to make decisions with AI in the room — to scope what it should and shouldn't be used for, to manage teams that use it, to catch when it's being used badly, and to take accountability for outcomes either way.

That is a leadership skill. And most performance review frameworks don't have language for it yet, which means whoever writes it first wins.

The sentence that reframes it

Here is the template. Drop this into your self-review, your individual development plan, or your end-of-year summary. Adapt the role details to fit your function:

"This year I developed AI fluency as a management discipline — not by building AI tools, but by [leading/evaluating/governing] AI-assisted work on my team: determining where AI could accelerate our outcomes, establishing appropriate guardrails on its use, and taking accountability for the results it produced."

Fill in the bracket with whatever is true. If you ran a pilot, use "leading." If you sat through vendor evaluations, use "evaluating." If you put a policy line in writing after reading last week's issue on shadow AI, use "governing."

The sentence works because it defines AI fluency at your level — strategic, accountability-forward, managerial — rather than technical. You are not competing with your engineers on technical depth. You are claiming the layer above it.

Why it matters beyond the review

This sentence isn't just review language. It's the frame you use when AI comes up in a promotion case, a 1:1 with your VP, or a hiring committee conversation where you're being assessed as a candidate.

Look at any recent senior-management posting in your field and you'll see it happening in real time: "AI" is migrating from a nice-to-have line into the explicit competency list, and nobody has settled the language for it yet. Getting your positioning right now — before it hardens into everyone's boilerplate — is the move.

Forward this to someone heading into review season. The window to own this language is before everyone else uses the same template.

P.S. — The Edge goes deeper on this: how to build AI fluency into your team's performance criteria and how to position it in a promotion conversation. If review season is weeks away, it's worth the look.

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

AI vendor pitches have a structure. Once you've seen it a few times, it's hard to unsee.

It opens with a problem framing that sounds exactly like your problem. Then a demo of the product doing something impressive — usually a cleaned-up version of a scenario you'd never encounter at your scale. Then a slide with logos of companies you've heard of. Then pricing options. Then: "Do you have any questions?"

Most people in the room don't. Not because the pitch was good — but because the pitch was engineered to make questions feel unnecessary.

Here are four that cut through it.

Q1: "Can you show me a failure case — something your product got wrong or couldn't do?"

No AI product works perfectly. Any vendor who claims otherwise is telling you something important about how they'll handle problems post-contract.

A real product has an answer: "In high-volume scenarios with unstructured input, accuracy drops to about 80% — here's how you'd manage that." That tells you the vendor knows their product.

Vaporware deflects. They pivot back to the demo or say: "We haven't seen that use case."

The failure case tells you more than the whole demo combined.

Q2: "How does it perform on data that looks like ours — specifically?"

The demo data is not your data. It never is. It's the best-case input, chosen to make the product look good. Your data is messier: inconsistent formatting, legacy systems, missing fields, edge cases that don't fit the model.

Ask them to tell you how the product performs on your actual data profile. If you can, describe your data in one sentence: "Our customer records are pulled from three systems, frequently incomplete, and about 30% have duplicate entries."

Watch what they do with that. A credible vendor will engage with the specifics. A vendor selling a demo will redirect to a generic answer.

Q3: "What's the implementation timeline — for a company that has no dedicated AI team?"

Vendors pitch to the ideal buyer. The ideal buyer has a technical team, clean data, and organizational alignment. You probably have none of those things, and neither do most of the companies on their logo slide.

Ask explicitly: "What's the realistic time to get this running for an organization with no in-house AI engineers?" Then listen for who the actual work falls on. If the answer involves your IT team doing significant configuration, your staff retraining on new workflows, or a "professional services" engagement that isn't in the pricing slide — that's scope you weren't shown.

The answer to this question is where the real cost of the product lives.

Q4: "What does a customer look like six months in who regrets buying this?"

Vendors expect to be asked about happy customers. They don't expect this.

A good vendor gives you a straight answer: "Buyers who don't have executive alignment on the use case struggle. If leadership isn't bought in, adoption craters." Useful.

A vendor whose churn is high and whose reasons are uncomfortable will go quiet or give you a non-answer. Also useful.

The move

You don't need to ask all four in every meeting. Pick the one that fits where you are in the conversation and ask it out loud, in front of the room.

The vendor's response — and the room's reaction — will tell you more than the next three slides.

Forward this to whoever sits in the next procurement call. Four questions, ten seconds of air time each. Worth it before the ink's dry.

P.S. — The Edge has the full evaluation framework: a weighted scorecard that takes these four questions and turns them into a structured decision. If you're running a real procurement process, it's the shortcut.

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

Here's what's happening in your organization right now, whether you've been told or not.

Your team members are pasting customer data into ChatGPT to draft summaries. Someone in finance is using an AI tool to analyze spreadsheets they emailed to themselves. A coordinator is generating reports with a free browser extension that logs everything to a server you've never heard of.

Nobody told you. Not because they're hiding it — but because there's no policy, no conversation, and no safe way to ask. So they're just doing it.

This is called shadow AI: the use of unsanctioned AI tools by employees, outside of any IT-approved or policy-governed system. It's not theoretical. Salesforce's 2024 AI at Work research found that more than half of employees who use generative AI at work — 55% — do so with tools their employer hasn't approved. That gap has not narrowed since.

The exposure here is real. Data governance breaches. Vendor terms you've never agreed to. Outputs that carry liability your organization doesn't know it has. And if something goes wrong, the question your leadership will ask isn't "why did the employee do that?" It's: "why didn't you know?"

The one question to ask in your next team meeting

Don't make this an interrogation. Don't make it a policy announcement. Make it a conversation.

Try this: "I want to make sure we're all set up to use whatever tools help us most — including AI tools. Who's already experimenting with something? What's it helping you with?"

That's it. You're not asking "who's breaking the rules." You're creating a safe surface for people to tell you what they're already doing. You'll get useful intelligence. And you'll signal that you're the kind of manager who finds out rather than lectures.

Listen to what comes back. Note the tools mentioned, the tasks they're being used for, and whether any of those tasks involve data that has a name on it — customers, employees, financials.

The one policy line to put in writing this week

You don't need a 10-page AI policy. You need one sentence that creates a safe harbor and a reporting path:

"If you're using or want to use an AI tool for work tasks, check with [your name / your IT contact] before using it with company or customer data — no judgment, just a quick flag so we can make sure we're covered."

Put it in a team Slack channel or an email. Not a memo. Not a policy document. A message, from you, this week.

This does three things: it surfaces the tools that are already in use, it creates an informal logging system without bureaucracy, and it positions you as the person who managed this — not the person who didn't know.

What you're actually managing

Shadow AI is a symptom of a gap between what your team needs to get work done and what your organization has officially given them. That gap is not going away. AI tools are getting easier, faster, and cheaper to access.

Your move is not to shut it down. It's to know about it before it becomes a problem. One question. One sentence. This week.

Forward this to a peer who runs a team. The conversation is already happening in their org too — they just haven't started it yet.

P.S. — The Edge goes deeper on this: how to run a proper shadow AI audit, what to escalate and what to quietly regularize, and what to say when leadership asks. If you're staring at a mandate, it's worth the look.

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

Every leadership team in 2025 has said some version of this: "We need to use AI to drive efficiency." Some variation involving "scale," "productivity," or "transformation" has also made the rounds.

Here's the problem. That sentence is not a plan. It's not even the start of a plan. It's a sentiment — and sentiments cannot be funded, staffed, measured, or reported on. When leadership comes back in 90 days and asks what happened, "we worked on efficiency" will not land well.

You probably know this. What you may not have is a clean way to convert the vague mandate into something you can actually execute against.

Here's the tool.

Why vague mandates stay vague

Executives give vague AI mandates for two reasons. First, they genuinely don't know what they're asking for — they know AI is important and they're signaling urgency, not directing action. Second, the mandate is deliberately underspecified because the political work of scoping hasn't been done yet, and nobody wants to own that fight.

Neither of these means you're stuck. It means the person who does the scoping work — and puts it in writing — owns the direction.

That person should be you.

The 3-line template

Take the vague mandate and rewrite it into three lines before your next leadership meeting. Each line does one job:

Line 1 — The specific problem:

• "We want to reduce [specific task or bottleneck] in [team or function], which currently takes [rough time/effort] per [time period]."*

Line 2 — The measurable outcome:

• "Success looks like [measurable result — hours saved, error rate, turnaround time] by [date]."*

Line 3 — The scope fence:

• "This does not include [what's explicitly out of scope] or require [what resources/decisions this doesn't depend on]."*

Three lines. No deck required. You can write this in 15 minutes. The specificity is the point — a well-scoped sentence is worth ten strategy documents.

A worked example

Vague: "We'll use AI to improve our customer communications."

Rewritten:

• "We want to reduce the time our customer success team spends drafting follow-up emails after support calls, which currently takes roughly 2 hours per person per day across a team of 8."

• "Success looks like that time dropping by 50% within 60 days, with no increase in customer complaints."

• "This applies to post-call follow-ups only — not proactive outreach or escalation emails, which require human judgment."

That's a thing you can prototype, measure, and report on. That's a plan.

How to bring it to the meeting

Don't lead with "I rewrote your strategy." Lead with: "I wanted to make sure I'm scoping this the right way before we get too far down the road — can I share how I'm thinking about it?"

Put the three lines in front of them and ask for a confirm or redirect. You're not pushing back on the mandate. You're being the person who does the translation work — from signal to execution.

That is, incidentally, exactly what AI cannot do for your organization. The machines are faster now. The strategy still needs you.

Forward this to whoever owns the mandate. If they're stuck between the directive and the details, these three lines are the bridge.

P.S. — The Edge runs a worked version of this each week for specific functions — ops, finance, marketing, HR. If your mandate has already landed and you have 10 days to figure out your angle, it's worth a look.

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

You've heard a version of this by now. Leadership comes out of a board meeting, a conference, a competitor's press release — and suddenly it's: "We need an AI strategy."

Nobody looks at the engineers. They look at you.

Here's the thing: that moment is not a trap. It's a positioning window. The manager who walks out of week one having framed the conversation — instead of waiting for someone to hand them a framework — is the one who owns the workstream. The one who freezes, forwards a McKinsey PDF, and says "let me loop back" is the one who gets cc'd instead of consulted.

Three moves. Week one. Here's what they are.

Move 1: Name the problem before anyone names the solution

The first instinct — and the wrong one — is to start researching AI tools. Don't.

The first thing you do is write one sentence that says what business problem this strategy is supposed to solve. Not "leverage AI for efficiency." That's a budget line item dressed up as a strategy. Something like: "Reduce the time our ops team spends on manual reporting so they can focus on analysis."

That sentence does two things. It stops the conversation from becoming a vendor parade. And it signals — to everyone in the room — that you understand strategy is about the problem, not the technology.

Bring it to the first meeting. You don't need a deck. You need one sentence.

Move 2: Map who already has skin in the game

AI "strategy" meetings attract three types of people: the vendor-excited (will forward you product demos), the wait-and-see (will agree with whoever spoke last), and the quietly threatened (will raise concerns without naming them).

Your job in week one is to know who's in each camp before you're in the room together.

Spend 20 minutes having informal conversations — not about AI, about their work. "What's the thing your team spends the most time on right now?" is a better question than "what do you think about AI?" You'll learn more, and you'll be the person who listened before they had opinions.

This is political intelligence, not technical knowledge. It is wildly underused in these conversations.

Move 3: Set the scope ceiling in writing

Scope creep in AI initiatives is nearly instantaneous. What starts as "help our team work smarter" becomes "automate the supply chain" by week three if nobody puts a fence around it.

Before week one ends: send a summary email to whoever handed you this mandate. One paragraph. Confirm your understanding of the business problem, the team scope, and a realistic timeline for a first recommendation. Ask for a one-sentence confirmation that you have it right.

You now have three things: a paper trail, an agreed problem definition, and a sponsor who is on record. When the scope tries to expand — and it will — you have something to point to.

The signal here

None of this requires you to know anything about machine learning, large language models, or which vendor is best. What it requires is the thing you're already paid for: figuring out what the actual problem is, who the stakeholders are, and how to keep a workstream from sprawling.

The technical layer comes later. Week one is yours.

Forward this to the one person who's about to get handed this. They'll thank you when they come out of week one looking like the adult in the room.

P.S. — If you want the action layer beyond week one — what to say at the stakeholder meeting, how to run the vendor evaluation, what to put in the plan — that's what The Edge is for. Try it here.

This was a free one. There's a new one every week.

What's signal in the AI noise — and the move to make about it. No hype, no vendor pitch, no link dump.

Aiden Vector is an AI-assisted publication; this content is produced by AI under human editorial direction.

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