Five different subjects this week, and one nerve running under all of them. The chart and the dashboard keep reporting that things are fine while the human system underneath tells another story. Here is the week, and then a look at why the newest number everyone is quoting has the same problem.
McKinsey published its read on AI progress on the twentieth of this month, and the useful number in it is not the one that traveled. Gallup had just clocked organizational AI adoption at 47 percent, the steepest quarterly jump it has on record, and many read that as proof the transformation was underway. McKinsey's report, From Adoption to Impact, points the other way. Seventy percent of people said they felt ready to use AI, while only 27 percent of leaders believed their organizations were ready for the changes to how work and roles are organized that turn usage into value. Adoption, the firm argues, is the easy horizon, where tools get handed out and a counter climbs, and the return arrives only once the underlying work is redesigned, which almost no one has.
Read this week's five pieces against that and they rhyme. Monday's change effort registered as adopted while it taught people to wait for a reward that never came. Tuesday's rollout was really an email with the users skipped. Wednesday's leadership survey stayed blind to the manager doing real harm, and Thursday's C-suite looked like a team on the chart while its members counted their own functions as home. Today's org chart read as efficient an hour after one executive absorbed three jobs.
Every one is a gap between the artifact leaders watch and the system they are meant to run, and the adoption percentage is the newest artifact mistaken for the thing itself. My read is that the dashboard has become the problem, because it lets a leadership team feel informed about a reality it has stopped looking at. So a question for the COOs and CTOs signing off on this quarter's AI dashboards: what are you tracking that would tell you the work itself changed, and not just that the tool got opened?
On prompt engineering, a misquoted court, and where the work actually lives
A few months ago I mentioned to some people that I was writing a book with ChatGPT in the loop. A surprising number of them got angry about it, angrier than the subject seemed to warrant. One informed me, with the kind of confidence that makes you assume the person has read the thing he is citing, that the Supreme Court had already ruled that work made with AI could not be copyrighted. I knew nothing about the case, and he said it so plainly that I believed him for about a day.
Then I looked it up. He was wrong in nearly every detail that mattered. It was not the Supreme Court, which had in fact declined to hear the case and left the decision below it standing. It was a federal appeals court, ruling on a very particular situation. A man had built an AI system, had it generate a piece of visual art with no human hand in the process, and then tried to register the copyright with the machine itself listed as the author. The court said a machine cannot be an author under the law. That is a long way from saying that a book with my judgment in every line is not mine.
The gap between what the ruling said and what I was told it said is not a small thing, because the strict version would be a disaster if it were true. If work lost all protection the moment an AI touched it, every company now using these tools would be handing away its own intellectual property. The line the law actually cares about is human authorship, and where exactly that line falls is a subjective call the courts have been careful not to draw yet. What counts as meaningful human contribution will be argued case by case for years.
What struck me is that the anger and the bad law came from the same place, a confusion about where the work in a piece of work actually lives. I had seen that confusion before, dressed up as a discipline, in the thing people started calling prompt engineering.
My own history with this goes back about four years, to playing with ChatGPT and Midjourney when they were new. It was not long before prompt engineering showed up, and it hardened almost overnight into a kind of gym-bro science, the belief that with enough tweaking and nudging you could arrive at the one perfectly arranged set of words that produced exactly what you wanted on the first try. It is a project manager's fantasy, the flawless thing conjured in an instant from a precise enough instruction. As an Agile coach I found the whole idea more trouble than it looked worth, so I never really learned it.
What I did instead was talk to the thing. I used it as a kind of philosopher-partner that would push back on my ideas hard enough that I had to go check whether I was wrong or whether it was making things up. Eventually I tried having it write prompts for me, for the other tools that kept coming out, and they were fine. But I noticed something that stuck. The carefully engineered prompt and my ordinary way of just talking produced about the same quality of result. What actually moved the needle was how well I had defined the problem I wanted solved. Get that right and you land close to what you were after. And the time spent perfecting the prompt was almost always worse spent than starting and iterating on what came back.
When I moved over to Claude I finally saw what I had been doing the whole time. I had been defaulting to the Agile way of working. I did not have to specify every feature of the thing I wanted built. I had to state the problem, give the context and constraints that helped, and then work with what it produced. The relationship that actually gets good results looks like a Product Owner and a Developer. You bring the problem and the judgment about what solves it well, and the two of you build the thing together.
This week Anthropic published guidance for its newest model saying, in effect, that the overly prescriptive prompting people spent two years mastering now tends to make the output worse, and that you do better to say what you want and why and let the model use its own judgment. I will admit to some satisfaction reading it. It validates an approach I arrived at mostly by being too stubborn to learn the fashionable one.
None of this waves away the real objection. Someone who dumps in a request, takes the first thing that appears, and ships it without reading it has produced something worthless, and the tool does not save him from that. The line that matters falls between work that was guided and verified and work that was dumped and shipped, and that has always been a question of discipline more than technology. This newsletter is written with AI in the loop, and I have never pretended otherwise. The judgment about what belongs in it, and the paragraph I cut this morning because it flattered me and said nothing, stayed with me.
Which brings me back to the man with the wrong ruling. He and the perfect-prompt crowd and the people sure that any of this is cheating are making the same mistake. They point at the most visible part of the work and assume that is where the work lives. A prompt stands in for the thinking behind it. An adoption number stands in for the value it was supposed to prove, which is the confusion this whole issue has been circling. The typing was never the work, and neither was the prompt. A book with your judgment in every line is yours, whatever a stranger tells you about a case he never read.

This week the podcast went live with Hanna Bauer, in an episode we called Declared Dead at 10. She was pronounced dead after a heart attack at ten years old, said nothing about her heart disease for the next twenty years, and turns that history into a way of reading the vital signs of an organization under strain. Watch it here:
Listen →
I don't just talk about Agile and leadership, I put it into practice in my Skool, building and shipping real products with Claude every Thursday at 12:30pm EST.
Join us →The through-line this week is the same one that opens Agile Sucks! (When You Do It Wrong), in the chapter James Wright and I titled Successful Failure, where roughly seventy percent of Agile organizations report healthy metrics and produce no business outcome anyone can actually find. It is the original version of the trap in today's article, a scoreboard that reads fine while the game goes unwatched. If that gap looks familiar, the book spends a good while on how leaders close it.
Get the book →A short read every Saturday morning. No spam, unsubscribe anytime.
Subscribe