How This Was Made
An essay on nuilding AI momentum inside organizations, and one weird trick leaders can do to help.
In 1727, Benjamin Franklin started a small weekly club in Philadelphia called the Junto. Its members were mostly tradesmen and craftsmen: a printer, a surveyor, a shoemaker, a joiner. Each took a turn bringing questions about ethics, politics, or the natural world. Every three months, each member wrote and read an essay on a subject of his choosing.
Franklin designed the discussions as a sincere search for truth, not a contest. Direct contradiction and declarations of certainty were discouraged under threat of a small fine. Questions were circulated before each meeting so members could read and think in advance — what Franklin described as being able to "speak more to the purpose."
The club ran for almost forty years. Franklin called it the best school of philosophy, morality, and politics then existing in the province. It helped give rise to the Library Company of Philadelphia, America's first successful lending library, and the Union Fire Company, the nation's first volunteer fire company.
What made it work was not simply the quality of the people in the room. It was that inquiry was visible. Members brought questions as well as conclusions. They exposed their reasoning and learned by watching one another learn. They were not only exchanging what they already knew. They were improving how they came to know things.
That distinction is as useful now as it was then.
The problem in the middle
Getting real value from AI inside an organization takes capable tools, people willing to experiment, and enough patience to get through the early learning curve. Most organizations that have been at this for a year have made real progress on all three. The challenge has shifted.
Early AI adoption tends to concentrate. A small group of people, usually curious and self-motivated, figure out how to use the tools well. They save time, produce better work, and become informal champions. Leadership notices and points to them as examples.
But the momentum often stays with that group. The broader organization watches, tries a few things, gets mixed results, and settles into cautious, occasional use rather than the kind of habitual reliance that actually changes how work gets done. The challenge isn't getting started, and it isn't tool access or finding use cases, because the champions have already found plenty of those. It is taking what's working in the early group and spreading it through the rest of the organization.
What spreading actually requires
Momentum at the organizational level has to travel across people. Someone learns something useful, and somehow others come to know it and act differently because of it. One reason that transfer stalls is that there's no normal channel for sharing how work gets done. Organizations share outputs constantly: decks, memos, reports, analysis. They almost never share process. The finished document moves from inbox to inbox. How it was made stays invisible.
When AI is part of the process, that invisibility has a specific cost. Other people see a good piece of work and have no idea that AI contributed to it, so they don't update their sense of what's possible. Or they suspect AI was involved but nobody says so, so the norm becomes quiet use rather than shared use. Either way, the knowledge that could fuel momentum stays locked up in the person who figured it out.
Normalizing AI means sharing AI
Norms inside organizations change when behavior changes, not when policy changes. A policy that says "AI use is encouraged" doesn't shift what people do because it doesn't shift what they see. People watch what respected colleagues and leaders actually do, and they form their sense of what's normal from those observations. When the behavior around them matches the policy, the norm becomes real. When it doesn't, the policy remains a stated preference.
When a leader produces a piece of work using AI and shares how, a few things happen. Other people learn that it's acceptable to use AI on real, important work. They get a concrete example of what that looks like. They see how the human contribution and the AI contribution fit together. And they get an implicit answer to a question many people are sitting with quietly: if I use AI to help make this, does it count as mine?
That question matters more than it might seem. Many people resolve the uncertainty by staying closer to traditional methods, where the conventions of authorship feel settled. Making the process visible answers the question with evidence rather than assertion. The work is the author's not because they typed every sentence, but because they shaped it, revised it, and remain responsible for it. AI's contribution is visible, but responsibility has not moved.
Sharing how work was made also creates the reference points that the broader organization is missing. Vendor examples don't fill that gap. What fills it is seeing someone they know, in their organization, doing real work and explaining how.
How This Was Made
The way to put this into practice is straightforward.
For substantive work you share, add a short note at the end explaining what role AI played in producing it. It is not a legal disclaimer or a measure of how much AI you used. It is a plain description of how your judgment, the tools, your source material, and your revisions combined to produce the work. The goal is that someone reading it walks away with a clearer picture of how it was actually done, specific enough to learn from.
It might say: I started with rough notes and used AI to draft this. I rewrote the first section, adjusted the structure, and added the third example. Total time was about an hour.
Or: I wrote this without AI. The recommendation depended on recent customer conversations and organizational context that weren't available to the model.
Or: An agent pulled the data. I wrote the analysis and the recommendation.
The note doesn't have to be long. It just has to be honest and specific enough to be useful.
The discipline is doing it consistently, not just when AI played a large role. A note that says "I wrote this the traditional way" is just as valuable as one that describes heavy AI involvement. It establishes that How This Was Made is a description of process, not a signal of AI adoption. And those notes accumulate into something useful: a real picture of where AI helps and where it doesn't, built from actual work rather than guesswork.
To write a good How This Was Made note, you have to think clearly about what you actually did. Which parts did AI handle well? Where did it fall short? What did you have to fix, and why? That reflection, done regularly, builds a clearer picture of your own practice than almost anything else. You start to notice patterns. You get better at deciding when to reach for the tool and when not to. Articulating what you learned forces you to understand it more completely. The writing of the note is part of the learning, not a record of it.
Over time, a collection of these notes from people across an organization becomes something genuinely useful: a real picture of how work gets made, with real tools, on real problems, by real people. That picture is what allows the knowledge of the early group to spread. It gives the middle of the organization the reference points it needs to experiment with more confidence.
How This Was Made should begin as a practice, not a policy. The purpose is to make learning transferable, not to measure adoption or evaluate whether someone used AI enough. The moment people believe the notes will be used to score their performance, honesty disappears and the useful detail disappears with it. Leaders should go first, repeatedly, in real work. Others can then copy a behavior they have seen rather than comply with a rule they have been given.
Modern organizations tend to circulate finished work while hiding the inquiry that produced it. How This Was Made reverses that. It is the Junto, updated.
Go first
Produce something with AI and say how, not as a demonstration in a town hall but in the actual work you share: a memo, a strategy document, a note to your team. Make it something real, with a short honest account at the end of how it came together.
That visibility invites curiosity. People ask follow-up questions, someone tries the same approach and tells you about it, and the knowledge starts to move.
Franklin understood that mutual improvement required people to see one another in the act of learning. Leaders trying to build momentum with AI can begin the same way: do real work with it, take responsibility for the result, and show how it was made.
PS: How this was made
I began with the core idea: that AI momentum stalls inside organizations because people see finished work but not the process behind it, and that leaders can change this by describing how their own work was made. I wanted the argument to feel inevitable rather than prescriptive, and asked for precision and clarity over rhetorical polish.
I used my own custom 'Writing Room' app to develop and draft this essay. I directed the structure and argument across multiple rounds from multiple agents: pushing on historical accuracy, tightening the language, and cutting anything that announced what the writing was about to do rather than just doing it. I wrote sections and edited by hand, shaped the direction, reviewed and revised each round, and take responsibility for the argument and the final piece.