Martin Tyminski

Category: Adoption

  • The pilot that goes nowhere

    A pilot that succeeds and then dies is not a failed experiment. It’s a decision nobody was willing to make, wearing the costume of one.

    Every organization I’ve been near keeps a graveyard of successful pilots. Not failed ones — successful ones. The tool worked. The small team liked it. The numbers, such as they were, pointed the right way. And then a year later nothing had changed, and nobody could quite say why.

    The failed pilot is easy. You learn something and move on. The successful pilot that goes nowhere is the expensive one, because it costs you the effort of running it and then costs you again in the quiet conclusion everyone draws afterward: we tried that, it didn’t take. That sentence closes a door that was never actually opened.

    The pilot worked because it was volunteers

    Six people, a few weeks, real enthusiasm. Look closer and the flaw is hiding inside the success. Pilots are staffed by the curious and the already-convinced — the people who raised their hand. That is the one condition you cannot reproduce when you scale.

    A pilot measures what motivated people do with a new tool. It tells you very little about what the other thirty-four will do, because the thing that made the pilot work — wanting to be there — is precisely the variable that doesn’t come in the box. You proved the tool works for people who were going to make almost anything work. That was never in doubt.

    Nobody owned the word “after”

    Here is the reliable tell. At the start of a pilot there is a sponsor, a champion, and a little budget. There is almost never a named person who owns what happens if it works.

    Who decides to scale it. Who absorbs the cost of the rollout — not the license, the disruption. Whose job it is to teach the thirty-four people who never volunteered, while they are busy and skeptical and temporarily worse at their own jobs for having to change. That person was never named, and the reason they were never named is that naming them would have required a decision. The pilot was chosen so the decision could wait.

    Sometimes the pilot is the delay

    This is the uncomfortable version, and it’s more common than anyone admits. Often the pilot isn’t a step toward adoption at all. It’s a way to look like motion without committing to any. It buys a quarter. It gives everyone something true to say in the meeting — we’re piloting it — that obliges no one to actually change how they work.

    A pilot with no decision pre-committed to its outcome is not an experiment. It’s a delay with a dashboard. And the tell for that one is simple: ask what happens if the pilot succeeds, and watch whether anyone has an answer.

    What a real pilot settles first

    A pilot worth running answers three questions before the first person logs in, not after.

    What, specifically, are we deciding at the end of this — and who decides it. What result would make us say yes, and what result would make us say no, both written down in advance, because a pilot with no defined failure condition will simply confirm whatever we already wanted to believe. And who owns the rollout if the answer is yes: named, resourced, and clear-eyed that the hard part is not the tool but the people who didn’t raise their hand.

    Answer those three and you have an experiment. Skip them and you have a nice afternoon that ends in a graveyard.

    The tool was never the variable under test. A pilot tests a tool. Adoption tests an organization’s willingness to decide and then to teach — and those are different problems, run by different muscles, and the second one was always going to be the hard one.

    So a successful pilot that dies didn’t fail at the experiment. It passed the experiment and failed at the sentence that was supposed to come next. Three words, and nobody was willing to say them: so we’re committing.

    I write about creative leadership, AI adoption, and the parts of the job nobody puts in a keynote. One post every two weeks.

  • The demo lies

    A demo is an argument dressed as a fact. The trick is that nobody showed you the conditions.

    I have run demos built to land, and I have sat through demos built to land on me. The second is the more instructive seat. You can feel the machinery working even while it works on you.

    Here is what matters: nobody in the demo is lying to you. The tool really did do that. The output really was that good. What you are not being shown is the frame around it — the example that was chosen, the prompt that was rehearsed, the three attempts that came before the one you saw, and the absence of everything that makes your actual work hard.

    A demo is a controlled experiment

    Someone chose the example. The whole result of a demo lives in the setup, and the setup is invisible by design. That isn’t malicious — a good demo is supposed to be clean. But clean is the tell.

    The chosen example has no history. No twelve-year-old file with three designers’ fingerprints on it. No brand system with forty rules, half of them unwritten. No stakeholder who looks at the perfect output and says I don’t know, it doesn’t feel like us, and cannot tell you why. The demo removes the exact things that eat your week, and then shows you how fast the remainder goes.

    What the room never sees

    The demo is always a first attempt at a friendly problem. It is never the second time, when the novelty is gone and the person is tired and the brief contradicts itself. It never includes the moment under deadline when someone abandons the new method and reverts to the one their hands already know — which is the moment that actually decides whether adoption happened.

    And it never shows you the person who has to own the output. In the demo, the output belongs to no one. In your organization, someone has to put their name on it, stand behind it in a review, and answer for it when it’s wrong. That person is the whole story, and that person is not on the screen.

    How to watch one

    You don’t need to be technical to evaluate a demo well. You need three questions, and the discipline to ask them out loud.

    What did you not show me? Hand over your file. The ugly one, the real one, the one with the contradictions in it. Then watch what happens to the nine-second number. If the answer is “we’d need to set that up,” you have just found where the cost actually lives.

    Whose Tuesday does this land on? Name the person whose working method has to change for this to be real. Are they in the room. Do they want it. Because if adoption depends on someone who wasn’t consulted and isn’t convinced, the demo measured nothing you can use.

    What does the second week look like? The demo is a honeymoon. Adoption is a marriage. Ask what happens after the interest wears off and the tool is just one more thing on the list — because that is the only condition under which it has to survive.

    None of this makes the demo worthless. A rendering of a building isn’t worthless — it tells you the building is possible, that someone thought it through, that the light will fall a certain way. It just doesn’t tell you what it costs to pour the foundation, or whether the ground will hold it.

    So believe the demo about the ceiling. Disbelieve it about the floor. Believe it about what the tool can do at its best, and refuse to believe it about what it will cost you to get there. The distance between those two numbers is not a tooling gap you can close by buying a better tool. It is the entire job.

    I write about creative leadership, AI adoption, and the parts of the job nobody puts in a keynote. One post every two weeks.

  • Your team already uses AI. You just haven’t asked.

    The usage report is not measuring adoption. It’s measuring the tool you paid for.

    Somebody pulls the numbers before the meeting. Fourteen percent monthly active. It’s a disappointing figure, and everyone in the room treats it as a starting point — early days, adoption curve, we’ll get there.

    The number is wrong. Not slightly wrong. Wrong in a way that changes what the meeting should have been about.

    It counts seats on the platform you licensed. It cannot count the tab open on somebody’s own laptop at nine at night. Or the phone that rewrote a difficult email in a parking lot. Or the person who has been running first drafts through something for the better part of a year and has never mentioned it, because nobody asked and there was no visible upside to volunteering.

    Real usage in most knowledge organizations is not fourteen percent. Nobody knows what it is. That is the finding.

    You are not at the beginning of this

    The model most leadership teams are running is we are deciding whether to adopt this.

    That decision was made some time ago, without you, one person at a time, by people with deadlines.

    What is actually in front of you is not an evaluation. It’s an unsupervised rollout already in progress, at unknown scale, with no standards, no review, and no shared idea of what good looks like. That is a considerably less comfortable meeting, and it’s the accurate one.

    Why nobody tells you

    It feels like cheating. In any organization that sells craft, the first instinct about assisted work is that using help is a confession of not being able to do it alone. So the work gets submitted and the method doesn’t.

    There is no upside to disclosure. Best case, you say something and nothing happens. Worst case, you become the example in a policy nobody has finished writing. People are good at that arithmetic. They do it instantly and they get it right.

    Rank filters everything. You don’t hear it because of what you are, not because of anything you’ve said. Conversation about method travels sideways — between peers, at lunch, in a message thread you’re not in. It travels upward only when there’s a reason. An open-door policy is not a reason.

    I have presented usage figures I believed. They were off by a wide margin, and the dashboard wasn’t the problem. I had made it very slightly costly to tell me the truth. Slightly is all it takes.

    What the invisibility costs

    The risk everyone names first is data — what gets pasted where. That one is real, and it is also the easiest thing on this list to fix, because it’s a sentence, said clearly, more than once.

    The three that matter more are harder to see, which is precisely the problem.

    There is no standard. Twelve people are each deciding privately what counts as good enough to ship. No shared bar, because there has never been a shared conversation. The bar is now whatever twelve separate Tuesdays produced.

    Nothing compounds. Somebody has genuinely solved something — found the method that turns a four-hour task into forty minutes. Nobody else will ever have it. The organization pays for the same discovery over and over and books it as individual talent.

    Nothing gets corrected. Weak output ships. Not obviously weak — plausibly weak. Confidently wrong in a register that reads as competent. And nobody upstream knows to look for it, because officially it didn’t happen that way.

    Ask like an amnesty, not an audit

    The instinct is to send a survey. Don’t. A survey asks people to write down, with their name attached, the thing they have spent a year not saying.

    You say it first, out loud, in a room. That you assume people are already using these tools. That you are not looking for who. That you want to know what’s working, so it can become a standard instead of a secret.

    Then be specific about the rules in the affirmative. “Approved tools only” is a fence, not guidance. People need to know what they may do, what may never leave the building under any circumstances, and who to ask when it’s ambiguous. One page. Written down. Ambiguity is not caution — it’s the thing that drives the behaviour underground in the first place.

    And then the part that decides whether any of it was real: something has to happen to the answer.

    If people tell you and nothing changes — no clarified rule, no adopted method, no visible thanks — you have taught them something efficient and permanent about what honesty is worth here. You will not get a second attempt at that question.

    The uncomfortable reading of shadow adoption is that it isn’t a discipline problem at all. It’s a report card on the teaching.

    People went and taught themselves — alone, unevenly, in private — because nothing was offered and asking cost more than not asking.

    They didn’t wait for permission. They just didn’t tell you they’d stopped waiting.

    I write about creative leadership, AI adoption, and the parts of the job nobody puts in a keynote. One post every two weeks.

  • AI adoption is a teaching problem

    Everyone in the room nods. Nobody changes anything on Tuesday.

    You have probably sat through the demo.

    Someone opens a laptop and shows the thing doing in nine seconds what used to take a morning. There’s a small involuntary noise from around the table. Someone says okay, that’s actually impressive. Someone else asks about security. The meeting ends on time and everybody leaves genuinely excited.

    Then nothing happens.

    Not nothing, exactly. Two people try it. One uses it for a week and stops. Six months later you buy the license anyway, because it seemed like the responsible thing to do, and the usage dashboard shows four active seats out of forty.

    I’ve watched this happen. I’ve also caused it, which is the more useful qualification.

    The wrong diagnosis

    When adoption stalls, organizations reach for one of three explanations. All three are wrong in the same way.

    We picked the wrong tool. So you evaluate more tools. This is the most expensive form of procrastination available to a large organization.

    People need training. So you run a session. Forty people attend a webinar, nod, and return to their inboxes. Attendance is recorded. Nothing transfers.

    We need a policy. So you write one. A policy tells people what they may not do. It has never once told anyone what to do instead.

    Each of these treats adoption as an information problem — as if the reason nobody’s using the tool is that they don’t know it exists, or don’t know the rules.

    But everyone knows it exists. That was never the bottleneck.

    The bottleneck is that using it requires a person to change how they do their actual job, under deadline, in front of colleagues, while being temporarily worse at it than they were last week.

    That is not an information problem. That is a teaching problem.

    What teaching actually is

    I did a graduate degree in teaching within the creative field. For most of my career it read as an oddity on my résumé — the line people asked about politely and then moved past.

    It doesn’t read that way anymore.

    Here’s what that training gives you that a tooling background doesn’t.

    You don’t teach a tool. You teach a judgment. Anyone can be shown which button to press. That takes an afternoon. What takes months is knowing when the output is wrong.

    The valuable skill in an AI-assisted workflow isn’t generating. It’s rejecting. And rejection requires taste, standards, and the nerve to say this isn’t good enough about something that arrived fully formed and looked entirely plausible. You cannot demo that. You have to build it, in a person, over time.

    Transfer is the whole game. In education, transfer is the gap between doing something in the classroom and doing it in the world. It’s where nearly all training fails — and it fails quietly, because the workshop itself went great.

    Everything that happens in a demo environment is a lie about Tuesday. The only training that counts happens on real work, on a real deadline, with a real chance of being wrong in front of someone.

    Nobody learns without feedback. Not encouragement. Feedback. Someone has to look at the output and say this is bad, and here’s why.

    Organizations are already poor at this, and they’re worse at it with AI, because criticizing the output feels like criticizing the tool, and criticizing the tool feels like announcing you’re a Luddite. So nobody says anything, and the standard quietly drops to whatever the machine produced.

    And you cannot teach a person who believes the lesson is about replacing them.

    This is the one nobody says out loud. Every AI rollout in a knowledge organization is happening in a room where some people believe — correctly or not — that the project’s logical conclusion is their redundancy.

    Fear does not produce learning. It produces compliance, quiet sabotage, and very convincing performances of enthusiasm in meetings.

    If you haven’t addressed that directly, plainly, in words, more than once — nothing else you do will work. Everything built on top of it is theater.

    The expert is usually the wrong teacher

    Here’s the awkward part.

    The person in your organization who is best with the tools is frequently the worst person to lead the adoption.

    Not because they’re bad at their job. Because they’ve forgotten what it was like not to know. Educators call this the expert’s blind spot, and it’s why the most fluent person in the room reliably gives explanations that are technically complete and practically useless.

    They skip the steps they no longer see. They answer a question the learner didn’t ask. They are, without meaning to be, faintly contemptuous.

    The right person to lead adoption is usually someone competent but recent — close enough to their own confusion to still remember its shape.

    So what do you actually do

    Not a list of ten prompts.

    Pick one workflow a real team does often and hates. Not a showcase. Something boring and load-bearing.

    Do it with them. On live work. At deadline. Be wrong in front of them.

    Define what “good enough to ship” means before anyone touches a tool — because the tool will cheerfully produce something that clears no bar at all, and if you haven’t set the bar in advance you’ll accept it out of politeness.

    Say the quiet thing about jobs. Out loud. And be honest about what you don’t know, which is more than you’d like.

    Then do it again, with the next workflow.

    That’s the method. All of it. It’s slow, it doesn’t demo well, and it’s the only thing I’ve seen work.

    The part that won’t fix itself

    The tools will keep getting better whether or not you do anything. That’s the one part of this you can safely ignore. Next year’s model will be better than this year’s, and it will ask less of you, not more.

    The teaching won’t improve on its own.

    There is no version of the model that makes an organization braver, or gives a team the standards to reject bad work, or tells a frightened person the truth about their job.

    That’s the work. It always was.

    I write about creative leadership, AI adoption, and the parts of the job nobody puts in a keynote. One post every two weeks.