Here is a real brief. I wrote it in one go, without tidying it up.
"I have been asked to write a book, AI Manager, AIM. Think if we set up a separate branch specifically to be my ghostwriter. It must be top class. AAA+++. Set up your own prompt. Iterate it 3 times to be at the right quality, then do the chapter headings, then iterate the prompt 3 more times including adversarial agent to get the right voice. > > The target market is people who are in a job and thinking they will be replaced by AI. My thesis is that if you can operate AI then you are a value to your company because you can make things 5 to 10 times more efficient and effective than now. > > It is a mindset, it is a curiosity, it is knowing how to push the AI to test it. It is an ability also to consider risks of AI and the things businesses may not be thinking of, including how tokenisation to protect PII is. It is also how you teach others to use AI and their willingness to see the benefits. It is how to use multiple systems to get the most visual way that things are understood by the team. It is how to prepare questions and great prompts and iterate prompts. It is using adversarial agents. It is getting the answers then scoring it 0 to 100 in areas then going back for more. > > We are not setting them up to be programmers. We are setting them up to manage and use any AI system and multiple to produce outcomes and think in a great mindset way to win, get job security and pay rises. > > This is a quality over speed. Set up, go in stages, get the plan. The above is the goal and you are capable of writing the book that everyone will need to read. The Bible of AI Managers. Then go over the work again with 3 agents different lenses and improve, then email me the book. This is a long running session so set up and save as you go."
Note the spelling. Note that it's one unbroken block written at speed by somebody who wasn't being careful.
Before the explanation, the numbers, because a claim about this is worth less than a count.
Fifty-five thousand words of my own recorded speech and writing went in before a line of the book was drafted. Two years of it, out of my own systems, plus every interview I had given. Every figure in these pages comes from work I did and opens a file I can produce. And the month of editing was not proofreading · one chapter had its entire spine pulled out and replaced because I read it back and did not recognise the argument as mine, a whole section went because it repeated something three chapters earlier, and a great many sentences were cut for the simple reason that I would not say them.
AI helped me write this book, however differently to what you think.
It had access to two years of me typing, to get my voice. All my interviews, so it knew my thoughts. All my programs, so it knew my work. And then I spent a month curating the book and manually editing it.
Whilst there are hundreds of instructions that the AI was given, one of the first is here, to help you learn the good and the bad of instructions. I didn't plan to bring this into the book, however it is instructive, and your learning is what I am committed to help with so that you can get paid more.
This is a real synthesis of me and what I believe, and it is manually edited and written, however my AI has helped bring it together.
If it feels like me, that is great, because it is. Because AI is powerful when it has the right instructions to match its abilities.
It states the standard before the task. “Top class. AAA+++” arrives before any instruction about what to write. That single move changes everything downstream, because a standard set early is a thing the work gets measured against, and a standard set at the end is a complaint.
It specifies the process, not only the output. Iterate three times. Do the headings. Iterate three more. Most people describe the thing they want and leave the method entirely to chance. Naming the method is how you get the method.
It builds in an adversary. “Including adversarial agent to get the right voice.” That instruction is the reason this book does not sound the way it would otherwise have sounded, and I'll show you exactly what it caught in chapter twelve.
It says what the thing isn't. “We aren't setting them up to be programmers.” One sentence, and it removed about a third of the possible wrong answers before any work started. Negative space is the most underused tool in briefing.
It names the review. Three agents, different lenses. The check was designed at the same moment as the work, which is the only time you can design a check honestly.
It names delivery and the constraint. Email it. Save as you go, because the session is long. Boring, and the reason nothing was lost.
I am not going to print my own brief and then congratulate myself on it.
It never said who the writer was. Not one word about identity. The brief said what to produce and never said who was producing it.
The result was competent prose that sounded like nobody at all. It took two rounds of hostile review to find it, and the finding was blunt: the writing was not a bad impression of me, it was an absence of me.
It said what good looked like and never said what bad looked like. “Top class” is a direction to travel. It isn't a boundary.
Nothing in that brief said this is what I'll reject, so the first drafts came back safe. Safe is the default output of any instruction with no floor in it.
It gave no rules about proof. No instruction to source anything, name anything, or link to anything. Everything in this book is now traceable to a file, and none of that came from the brief. It came later, expensively, after something went badly wrong.
And it aimed at the wrong target. Nothing in it said what the book was actually for, who would pay, or what a good outcome looked like six months after publication.
An analysis of the market eventually told me the target was wrong. By then several days of work had been pointed at it.
That last one is the expensive lesson in this chapter. A brief can be beautifully specified and pointed in the wrong direction, and the specification will make the wrong direction arrive faster.
Everything above compresses into six lines. Write them once for any task you repeat, and you will run them for a year.
1. Identity. It doesn't know who it's. Tell it, in detail. Not “you're a helpful assistant” but the actual person you want in the chair, with their experience, their standards and their bias. This is the single largest lever in the whole brief and almost nobody pulls it.
2. The goal. What outcome, for whom, by when, and which decision it feeds. Not the task itself, but the outcome the task exists to serve. Most briefs describe the task and leave the purpose in the sender's head, which is why so much work comes back technically correct and useless.
3. What good looks like. Specifically. Show it an example if you have one.
4. What bad looks like. This is the line everybody skips and it does more work than line three. Name the failure. Do not give me a summary. Do not hedge. Do not give me options without a recommendation. A boundary is worth more than an aspiration, because it can be checked.
5. Challenge. Ask for lenses. Have it look at the same thing as a customer, a finance director, a regulator. Then have something argue against the answer it just gave you. Build the opposition into the instruction rather than hoping to spot the weakness later.
6. Proof. Tell it what counts as evidence and what does not. Ask for the links. Ask it to mark anything it can't source, and then go and look at exactly those things.
Six lines. Ten minutes to write the first time, thirty seconds to reuse.
Keep them in a document. Within a month you will have eight of them, one for each thing you do regularly, and you will have quietly built the most valuable file on your computer.
Take something dull. Somebody has asked you to look at why complaints went up last month.
Here is the version almost everybody sends. “Analyse this complaints data and tell me what's going on.”
What comes back is a description of the data you already have. Volumes by category, a note that category three rose, and a closing paragraph recommending further investigation.
Now the six lines. Read them and notice that not one of them is technical.
Identity. You are an operations manager with fifteen years in a service business. You have seen complaint spikes before and you know most of them are caused by something upstream rather than by the team taking the calls.
Goal. I have to tell my director on Thursday what caused this and what we're doing about it; she will want one cause, not five.
Good. One likely cause, stated plainly, with the evidence for it. Then the two next most likely, briefly.
Bad. Do not summarise the data back to me. Do not recommend further investigation. Do not give me five equally weighted possibilities and leave the choosing to me.
Challenge. Then argue against your own answer. What would the team leader in that department say if I put this to her, and is she right?
Proof. Quote the specific rows you're reasoning from. If a claim isn't supported by something in this file, mark it.
Six lines. Perhaps eight minutes to write, and you'll use it every month for a year.
The second version comes back with a cause, a defence of it, the objection you're about to face from the person whose team it implicates, and a list of the things it couldn't support. That is a Thursday meeting you can walk into.
Look at line four again, because it's the one that did the most work. Every single instruction in it is a thing you've received and been irritated by.
Everything in that list is what you already do to people.
You set people up for success. You tell them what the job is, what good looks like, and what will get it sent back; you are specific with somebody new and light with somebody who has earned it.
Trust is earned the same way in both cases. You check closely at the start, and you check less as confidence builds, and you never quite stop.
Mistakes happen in both cases. Nobody sensible treats one error from a good employee as proof of anything. Nobody sensible ignores a pattern of them either.
And here is the one that took me longest to see, which has no equivalent in any other book on this subject.
When something changes underneath, you go back to checking.
If the code changes, I check the work again, closely, for a while. Exactly as I would if something had changed in an employee's life that might affect their output. A person going through something difficult isn't less trustworthy, and they're in a different state, and a decent manager quietly increases their attention for a bit without making it a thing.
Do the same here. These systems get updated, sometimes without announcement.
The version you spent three months learning to trust isn't necessarily the one you're using this morning. That isn't paranoia.
It is the ordinary attentiveness of somebody who manages, applied to a workforce that can be replaced overnight without anybody telling you.
There is a shortcut to all of this and almost nobody takes it, because it doesn't feel like work.
Think of the best proposal you've ever received. Or the email that made you agree to something you had been resisting, or the one-page summary that made a complicated decision obvious in ninety seconds.
You have three or four of those. Everybody does. And you've never once asked why they worked.
So ask. Put the thing in and say: take this apart and tell me what makes it work, as a pattern I could apply to something completely different. Not a summary of what it says. The structure underneath it. Where the evidence sits relative to the claim. What it does in the first two lines. What it deliberately leaves out.
Twenty minutes, on something you already admire, and you come out holding a template you'll use for years.
Two things about this that are worth saying plainly.
It does not have to be yours. Learning from something excellent that somebody else wrote isn't copying, it's what every craft has always done. You are taking the shape, not the words.
And it works better on things that persuaded you than on things you were told are good. Your own reaction is the data. If it moved you, something in it was working, and you were on the receiving end of it, which is the one vantage point nobody can give you second-hand.
Then fold what you find into line three of your brief. What good looks like stops being a description and becomes an example, and an example is worth a paragraph of adjectives.
Take the task you do most often, the one you could describe in your sleep.
Write the six lines for it. Give it an identity, a goal, what good looks like, what bad looks like, something to argue with, and a rule about proof. Ten minutes.
Then run it, and run your usual version of the same request beside it, and read the two side by side.
I have never seen anybody do that and remain uninterested. It is the fastest way I know to stop believing this is somebody else's job.
Keep both, because they are the before and the after, and in the last chapter of this book you're going to need them.
The brief tells it how to work. It doesn't tell you how much of your own attention this particular job is worth, and if you spend the same amount on everything you'll spend it all inside a fortnight.
Which means something has to happen before the brief, in the four seconds you currently hand over without noticing you have spent them.