The Manager's Own AI Toolkit

A manager who has never used these tools seriously will misjudge every proposal that crosses their desk — usually in both directions at once, overestimating what a system will do unattended and underestimating what a person with a good tool can do in an afternoon.

This lesson is about your own practice.

Where it genuinely helps

Turning a mess into a first draft. Meeting notes into a structured summary. A rambling email thread into a decision log. Six pages of policy into a one-page brief for your team. The tool is doing the tedious part; you are doing the judgement.

Interrogating a document you did not write. Pasting in a supplier contract and asking what obligations it places on you, what the termination terms are, what is unusual. Treat the answers as leads to verify, never as advice — but as a way to find the three clauses worth reading closely in forty pages, it is very effective.

Being argued with. "Here is my plan. What are the three strongest objections?" This works better than most people expect, because the failure mode of a manager's plan is usually that nobody senior enough disagreed with it out loud.

Structured comparison. Six vendor responses reduced to a table on your criteria. You will still read the responses; you will read them knowing where they differ.

Writing you find hard. The difficult message, the paper for a board that thinks differently from you, the same update rewritten for three audiences.

Where it does not belong

Three categories, and the boundary is about accountability rather than capability.

Decisions about people. Do not paste performance issues, grievances, health information or redundancy scenarios into a general-purpose tool. This is a data protection matter and a dignity matter, and the fact that the output would be fluent is beside the point.

Anything where being confidently wrong is expensive and unverifiable. Legal positions, regulatory interpretation, financial figures you cannot check. Not because the tool is always wrong, but because it is wrong in a way that reads exactly like being right.

Your actual judgement. The specific reason a course of action fits this team, this customer, this moment, is the thing you are paid for and the thing the model has no access to. A model that has read everything ever written about strategy has read nothing about yours.

🔗 Match the Pairs

Turning workshop notes into a structured summaryDrop here

Finding the three clauses worth reading in a long contractDrop here

Stress-testing your own plan against objectionsDrop here

Drafting a redundancy rationale for a named employeeDrop here

Determining whether a regulation applies to youDrop here

Deciding which of two strategies fits your teamDrop here

A verification discipline

The practical question is never "can I trust this?" but "what does it cost me if this particular thing is wrong?" Scale your checking to that.

📅 Timeline

Low cost, easily reversibleA first draft you will rewrite anyway, a brainstorm, a summary you will read the source of regardless. Skim it. Move on.

Moderate costAn internal document others will act on. Check every specific claim, number and name. Read it as though a colleague you do not entirely trust wrote it.

High cost or irreversibleAnything going to a customer, a regulator, a board, or into a contract. Verify independently from a source, and take personal responsibility for it. Your name is on it either way.

The rule that keeps you out of trouble: never pass on a specific claim you have not checked. Fluency is free; correctness is not, and the fluency is what makes unchecked claims dangerous.

Shadow AI, and what to do about it

The MIT NANDA report described a "shadow AI economy" — employees using personal AI tools to work around the limitations of whatever the organisation officially provides.

You should assume this is happening in your team. It very likely is. Prohibition without provision does not stop it; it just moves it out of sight, which is the worst of both outcomes: the same data exposure, none of the visibility, and no learning about what people actually need.

The productive response has three parts:

Provide something adequate, so the workaround is unnecessary. Most shadow use exists because the sanctioned option is worse.
Be specific about what must never go into a general tool — customer personal data, anything under NDA, credentials, unreleased financials, people matters. A short, concrete list beats a long policy nobody reads.
Ask what people are using it for, without penalty. This is free use-case research from the people closest to the work, and it is the highest-quality input to module 2 that you will get.

Most disappointing results come from prompts that are one line long. A structure that consistently works better, drawn from the same reasoning as any good brief:

Role:    You are an experienced operations manager in a mid-sized
         logistics business.

Context: We run 40 vehicles across three depots. Last quarter,
         on-time delivery fell from 94% to 88%. The depot managers
         blame a new routing system; the routing vendor blames
         driver adherence. I have the raw delivery data and the
         adherence reports.

Task:    List the competing explanations that would account for this
         drop, and for each, state exactly what I would look for in
         the data to confirm or rule it out.

Format:  A table: explanation, what would confirm it, what would
         rule it out. No preamble.

Constraint: Do not propose solutions yet. I want to know what to
         check first.

Four things this does that a one-liner does not:

It supplies the context the model has no access to. Without it you get the statistical average of all writing about delivery performance, which is a list of generic causes you already know.
It names the output shape, which removes a reformatting round.
It constrains scope. "Do not propose solutions yet" prevents the confident leap to recommendations that is a model's default behaviour and a manager's most common complaint about them.
It asks for something falsifiable. Every row of the table is a check you can actually perform. Compare that with "what should I do about my delivery performance", which produces advice you cannot test.

The last point generalises. Ask for things you can verify. It plays to what the tool is good at — generating structured possibilities quickly — while keeping the judgement, which is the part it cannot do, with you.

❓ Knowledge Check

Your team is clearly using personal AI tools that the organisation has not sanctioned. What is the most effective response?

📚 Flashcards1 / 5

Term

Where AI helps managerial work

Click to flip

Definition

Turning a mess into a first draft, interrogating documents you did not write, stress-testing your own plan, structured comparison, and writing you find difficult.

Click to flip back

💡Key Takeaway

A manager who has not used these tools seriously will misjudge every proposal they receive. Use them for drafting, interrogating documents, stress-testing plans and structured comparison; keep people decisions, unverifiable high-cost claims and your own contextual judgement well away from them. Scale verification to the cost of being wrong, and treat shadow AI in your team as a signal about unmet need rather than a discipline problem.