FPW Symposium 2026 - Post 7: Start Early, Be Lazy: How Tyson Heaton Ran Our AI Hackathon

"Be as lazy as possible." That's a strange thing to say to a room full of continuous-improvement people, and Tyson Heaton meant it literally. "Every time that you think of doing something, ask AI to do it for you." Then, when the tool pushes back: "Why can't you grab that file? What would keep you from getting that file?"

The point isn't getting out of work. It's finding where the tool stops being useful, which you only learn by pushing until it fails.

That was the afternoon of May 7, 2026, before the Future of People at Work Symposium at Carnegie Mellon University. About twenty of us spent three hours in two rooms, using AI next to each other instead of alone at a desk. The artifacts were good. The method was better.

The design was thin on purpose

Three questions around the room: what's working, where are you stuck, what would you build. Tyson listened for overlap and paired people on shared struggles, which is a different move than pairing by department or seniority.

One rule, enforced: a laptop each. "It can't be four people watching one computer." Halfway through he moved us to a bigger room and said out loud why. It gives you cover to go sit next to the person you actually want to work with, minus the awkward shuffle. Every ten or fifteen minutes he called a pulse: stop and review your inputs with your partner. He also told everyone to drop the structure if they got onto something real.

When people asked him questions, he mostly didn't answer. "Which model should I use?" became "for what type of work, what outputs, what constraints? Put all that in and ask it." Then he'd read the answer with you and point out where it was biased.

The other rule: start early

"We make this mistake of having it polish outputs rather than synthesize early to the input side." A polished output used to be evidence someone spent time at gemba. Not anymore, and he was blunt about the cost: "depth is being robbed." Left alone, AI skips gemba and jumps to solutioning, which is why he hands people structured prompts instead of a blank box. "It's really good at adding, bad at subtracting."

The technique I'm stealing

Run the same prompt in five tabs. Look at the spread. That's the model's inherent variation, and it's wider than most of us assume. Now revise the prompt, run five more, compare. "To what level is my prompting actually improving my output, and to what level is it just the variation that exists inherent in the model?"

That's common cause and special cause, applied to a probabilistic machine. Most of us have been tuning prompts with a sample size of one. He also runs parallel tabs to kill waiting time, and has the model play a chime when it finishes so he isn't watching it think. An andon light, essentially.

What the prompts produced

Dan Troye's eleven words — "create a game that simulates single piece flow vs batch production" — returned a working browser simulator. Then he used a move Tyson had been pushing all afternoon: draw it, photograph it, feed it in. He shot his own process map and got the game running on his line.

Kelly Reo and Angela Wolfrum iterated behavior maps five to ten times each; Kelly's L3Harris example in Cincinnati took new-hire attrition from 60% to 17%.

Dana Miller brought a problem that has nothing to do with tooling. Lean and business architecture are practiced by different tribes: Lean starts with "where is the waste?" and business architecture starts with "what capabilities do we need?" They optimize at different levels and rarely share artifacts, so they orbit each other instead of colliding. His chat kept pushing him past theory. You bridge two communities by building something both of them need to use, and value streams already sit in the middle — owned by architecture, used by Lean to scope improvement.

Then came the reframe I keep thinking about. Not "how do I connect these communities," but "how do I create a shared problem they both need to solve?" The business-architecture crowd won't move to support Lean, and the Lean crowd won't move to adopt architecture. Both will move for a problem they own together.

His room also ran a scan for contradictions: hand a model five assessors' raw notes and ask where the findings disagree with each other.

A shared space, not another framework

Dana kept going after the session ended. He built a prompt around the Rothko Chapel in Houston, the non-denominational room founded by John and Dominique de Menil that holds fourteen Rothko paintings in varying hues of black, an octagon inside a Greek cross, about 110,000 visitors a year. People from different religious and philosophical traditions come together there without any tradition having to give up what it is.

His question: could Ways of Working do that for Lean, business architecture, Agile, systems thinking, and organizational development? Not another methodology, and not a ruling on which approach is right, but a space where those perspectives meet around the reality of work. The common ground is the work itself. What value are we trying to create? How does the work actually happen? How do people experience it? Where does it hit friction? What can we learn?

He named the risk in the same breath: the goal is not one more set of practices for organizations to adopt, which is how you end up with a cargo cult. His own summary line is better than anything I'd write over it: "Different traditions. Shared space. Deeper understanding. Humanity at the center."

The thing AI can't do yet

None of this transfers well alone. AI has no multiplayer mode. No shared chat, no way to hand someone your ugly inputs, so most people learn it slowly and in private. Sitting next to Peter Barnett and just talking beat anything I'd have gotten from the model by myself.

We'll run it again, smaller: groups of three, show the process rather than the output. Which of Tyson's rules would break first in your organization?

Knowledge Map

Process Keywords: prompt design, structured prompts, input-side synthesis, five-tab variation test, common and special cause, parallel processing, context hygiene, context stitching, pair learning, session design, draw-photograph-feed, assessment synthesis, value streams as translation layer, shared artifacts, TWI, gemba.

Context Keywords / reader pain points: learning AI alone, tuning prompts with a sample size of one, output that looks good but isn't, AI skipping to solutions, carried context derailing a chat, waiting on the model, enterprise tool restrictions, no time to practice, coaching someone who used AI to pass your coaching, two internal communities talking past each other.

Application Triggers:

• If you can't tell whether your prompt improved anything, then run it in five tabs before and after.

• If the output is wrong, then ask whether it's the model, your content, or your question.

• If your chat keeps circling, then start a new one.

• If your team is learning AI alone, then run a paired build session with a laptop each.

• If you coach A3s, then give people structured prompts before they give themselves shortcuts.

• If two groups in your organization talk past each other, then look for the one artifact both of them need rather than a shared vocabulary.

Related Continuous-Improvement Themes: variation thinking, standard work for prompting, waiting waste, respect for people, learning by doing, leader as coach rather than expert, cross-community collaboration.

This post was developed from the May 7, 2026 pre-Symposium AI hackathon facilitated by Tyson Heaton, with contributions from the participants named above and from Dana Miller's breakout summary, and synthesized with Claude AI assistance. Editorial contributions by Dana Miller. It represents ongoing work by the Future of People at Work initiative, a collaboration of Catalysis, Central Coast Lean, GBMP Consulting Group, Imagining Excellence, Lean Enterprise Institute, Shingo Institute, The Ohio State University Center for Operational Excellence, Toyota Production System Support Center (TSSC), and University of Kentucky Pigman College of Engineering.