{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Michael Chang",
  "home_page_url": "https://printers-notes.zeabur.app/en/",
  "feed_url": "https://printers-notes.zeabur.app/en/feed.json",
  "description": "Personal essays on business, decision-making, and technology. Long-form, not news.",
  "language": "en",
  "authors": [
    {
      "name": "Michael Chang",
      "url": "https://printers-notes.zeabur.app/en/about/"
    }
  ],
  "items": [
    {
      "id": "https://printers-notes.zeabur.app/en/posts/ai-project-second-month/",
      "url": "https://printers-notes.zeabur.app/en/posts/ai-project-second-month/",
      "title": "Why Most AI Projects Die in the Second Month",
      "summary": "The first month's success is an illusion. The real problem surfaces the moment the demo ends and someone has to change how they work.",
      "content_html": "<p>The first month goes well. The demo runs, the boss nods, there is applause in the meeting room. Someone starts talking about rolling it out to other departments.</p>\n<p>In the second month someone asks: so how does my workflow change?</p>\n<p>That is where the real problem begins.</p>\n<h2>The first month's success is an illusion</h2>\n<p>The demo went smoothly because it ran on a curated dataset, operated by one highly motivated person, and <strong>nothing in the existing process had to give way for it</strong>. All three conditions disappear in month two.</p>\n<p>I watched a warehouse picking-route project go through this. In the demo phase the model cut picking distance by 23% — a number so good it needed no explanation. Four weeks after rollout, the actual saving was 4%.</p>\n<p>The gap was not in the model. The gap was that the floor supervisor had a sequencing method built up over ten years. He knew which racks jammed, which pallets were awkward, and when the forklift traffic peaked. The model knew none of it, and nobody had been assigned to feed that knowledge in — or to persuade him to change.</p>\n<h2>What fails is not the technology but the unowned cost of change</h2>\n<p>Every process change has a cost, and that cost always lands on a specific person. Project proposals describe expected benefits in detail. They rarely describe <em>whose job gets harder for the first three months</em>.</p>\n<p>The second is the variable that decides the outcome.</p>\n<ul>\n<li>If nobody is assigned to absorb that cost, it quietly falls on whoever has the least standing to refuse — and that person will find ways to make the new process fail.</li>\n<li>If someone is assigned but lacks the authority to retire the old process, the result is identical.</li>\n<li>Adoption only happens when the person absorbing the cost and the person with authority to change the process are the same person.</li>\n</ul>\n<p>This sounds like an organisational problem rather than an AI problem. It is. <em>Almost every failed AI project is an organisational failure</em> wearing a technical costume.</p>\n<h2>A better first question</h2>\n<p>The first question most teams ask is: how accurate is the model?</p>\n<p>The question that actually predicts the outcome is: <strong>once this works, whose job gets harder?</strong></p>\n<p>If the answer is &quot;nobody&quot;, that usually means the project changes no real process, and the benefit will be zero. If the answer is a specific person, the follow-up questions become obvious — does he know? Does he agree? Does he have the standing to say no?</p>\n<blockquote>\n<p>I have never seen an AI project die because the model was not good enough. They die because nobody was willing to change how they worked for it.</p>\n</blockquote>\n<h2>What the second month is actually for</h2>\n<p>Do not expand scope in month two. Narrow it. Find the person whose job gets harder, and spend the entire month on him.</p>\n<p>Concretely: write down everything he knows that the model does not, and ask why for each item. That list is usually worth more than the model, because it is the company's real operating knowledge — and it has never been written down before.</p>\n<p>If you hold that list at the end of month two, the project will probably survive. If you do not, no accuracy figure will carry it past month four.</p>\n",
      "date_published": "2026-06-12T00:00:00.000Z",
      "tags": [
        "AI",
        "organisation",
        "adoption"
      ]
    },
    {
      "id": "https://printers-notes.zeabur.app/en/posts/weight-of-decisions/",
      "url": "https://printers-notes.zeabur.app/en/posts/weight-of-decisions/",
      "title": "The Weight of a Decision Is Reversibility, Not Difficulty",
      "summary": "We rank decisions by how hard they are to make. The ranking that matters is whether you can walk back from being wrong — and the two are often inverted.",
      "content_html": "<p>Most people rank decisions by how hard they are: how long they take to think through, whether the data is complete, whether anyone will review them afterwards.</p>\n<p>That ranking sends attention to systematically the wrong place.</p>\n<h2>Two kinds of decision</h2>\n<p>Some decisions can be walked back, and the cost is wasted time. Others cannot, and the cost is three years of taking the long way round.</p>\n<p>Switching a supplier, changing a price, shipping a feature — mostly reversible. Get it wrong and you can undo it inside two months, having learned things you could only learn by doing it.</p>\n<p>Choosing a co-founder, signing a three-year lease, deciding which market the company serves — irreversible. Not literally unchangeable, but expensive enough to change that the cost eats every benefit you were chasing.</p>\n<p>The awkward part is that <strong>difficulty and reversibility are frequently inverted</strong>.</p>\n<p>Switching suppliers is a hassle: quotes, audits, renegotiated contracts, several rounds of meetings. Choosing a co-founder often happens over one dinner, because the conversation flowed.</p>\n<p>So we spend our heaviest analysis on the reversible things and our lightest on the irreversible ones.</p>\n<h2>Reversible decisions: deliberation is the cost</h2>\n<p>If a decision can be undone within two months, three more meetings will usually yield less information than two weeks of simply doing it.</p>\n<p>The right approach is <strong>move fast, and write down exactly what you are betting on</strong>. The second half matters more. Without a record of your reasoning, being wrong only teaches you &quot;that road was blocked&quot; — not &quot;which of my assumptions was false&quot;. The first does not compound. The second does.</p>\n<p>In practice I write three lines: what I am betting, what I expect to see in two months, and what observation would mean I was wrong.</p>\n<h2>Irreversible decisions: slow the commitment, not the thinking</h2>\n<p>Irreversible decisions deserve to be slowed down, but many people slow the wrong thing. They spend longer thinking while having already quietly committed.</p>\n<p>What actually helps is pushing back the moment of commitment, and cutting the irreversible part into reversible pieces.</p>\n<ul>\n<li>A three-year lease can start as six months with a renewal option.</li>\n<li>A co-founder can first be a collaborator on one genuinely stressful project.</li>\n<li>A new market can be entered with the smallest possible offering for one quarter.</li>\n</ul>\n<p>Each of these costs a premium. The premium buys information, and it is usually cheap.</p>\n<blockquote>\n<p>What is worth paying for is not a better decision. It is deciding later.</p>\n</blockquote>\n<h2>One practical check</h2>\n<p>Before committing, ask: if this turns out to be wrong in six months, what does it cost in money and time to walk back?</p>\n<p>If the answer is &quot;two months and not much money&quot;, stop meeting about it and go.</p>\n<p>If the answer is &quot;you cannot walk back&quot;, then today's job is not to decide. It is to find a way to make the decision reversible.</p>\n",
      "date_published": "2026-05-20T00:00:00.000Z",
      "tags": [
        "decisions",
        "management"
      ]
    }
  ]
}