Somebody Has to Come When You Pull the Cord

Culture eats strategy for breakfast, right? I've heard it in every transformation kickoff I've sat through for twenty years, at big companies and small ones, always in roles that plugged into change. I believe it. I've also watched that line get used as a reason to stop talking about anything concrete. Transformations take people, process, tools, money, and culture. Most of what gets written covers the culture part at the altitude of leadership offsites and consultant frameworks. That stuff matters, but without wheels a Ferrari can't go anywhere.

This post is about the wheels. Specifically, how you make the stuck parts of a change visible enough that you can do something about them on a Tuesday.

What happens after the pull

I'm not a Toyota person. I learned about this the way most people outside manufacturing do, by reading, and the thing everyone remembers is the andon cord. Any worker can pull it when something is wrong. What people forget is what happens next. Pulling the cord doesn't stop the line. It turns on a light and sounds an alarm, and the line keeps moving to the end of that work cycle, a "fixed position" maybe 5 to 30 seconds away. In that window a team leader walks over. If they sort it out and pull the cord again, the line never stops at all. Lean practitioners will tell you Toyota's own guidance is not to install stop-the-line until the support structure exists, because the cord only works if somebody actually comes, quickly.

GM learned this the expensive way. At NUMMI, the Fremont joint venture with Toyota, former GM team leaders didn't believe the andon story in the classroom. At GM, stopping the line could get you fired, and the norm was to pass the problem down and let somebody fix it at the end. They believed it once they pulled the cord on the floor and a team leader showed up to help. Then GM tried to copy NUMMI at its Van Nuys plant. The managers there opposed stopping the line because their bonuses were tied to how many cars rolled off it, regardless of quality. Quality didn't improve and GM closed the plant in 1992.

One comparison sums it up for me. Workers at Toyota's Georgetown, Kentucky plant were reported pulling the andon cord around 2,000 times a week. Workers at a brand new Ford truck plant in Dearborn were pulling it about twice a week. Nobody thinks Dearborn had a thousand times fewer problems. The cord was there. Pulling it just didn't get anyone anything.

So when I say culture, I mean something you can count. How often do people raise a problem, how fast does someone respond, and what happens to the person who raised it.

Change doesn't come with a line already built

There's a catch in borrowing from Toyota. The andon works because everything around it is stable. The line, the stations, the team leaders, and the response have been rehearsed for decades. Everyone knows who walks over.

A transformation is close to the opposite. In my experience it's usually many teams doing many things at once, a lot of them groups that have never had to work together before. A new platform team, the business unit it serves, an outside integrator, a vendor or three, a consulting firm, finance, legal, security, and somebody's PMO. Each one has its own tracker, its own meetings, and its own idea of who decides what. There's a ton of counterparty complexity, and there are no organizational rituals that predate the change, because the change is the first time these groups have had to depend on each other.

That's also where the blockers sit. Very few of them are inside a team. They're at the seams, between your team and the vendor, between the integrator and security, between the program and the budget owner. Nobody owns the seam, so nobody owns the blocker, and there's no station number to light up. In a transformation you're building the line while you run it, and the cord has to be built with it.

A blocker registry

Here's what I've been thinking about. Most organizations in the middle of a change have no shared list of what's stuck. Blockers live in status decks as yellow dots, in Slack threads, in the heads of program managers, and in the quiet of people who stopped asking. You can't rank what you can't see, and you can't see what isn't written down in one place.

A blocker registry is just that one place. Every blocker gets a row, and the row is small on purpose:

• What's stuck, in one sentence
• Who raised it and when
• Blast radius: how many people or workstreams are waiting on it (1 to 5)
• Type: decision, dependency, access, information, or policy
• Who has to act to clear it
• Who actually cleared it, and when

Ranking can be simple. Blast radius times days open gets you most of the way. A blocker stalling three teams for nine days outranks one stalling one person for two. You can get fancier later. The point is a list that's honest about where the work is stuck and sorted so the worst things float to the top.

Four questions about your cord

If I were building one, I'd hold it to four questions.

Is it instrumented? Every pull gets recorded with a timestamp, including the ones cleared in five minutes. Georgetown versus Dearborn is only a story because somebody counted. If the only blockers that get written down are the ones that lasted long enough to make a status deck, you're recording the failures of your response and none of the saves, and you can't see the number that tells you whether people trust the system at all, which is how often they pull.

Is it one cord? It has to be. If a blocker can be raised in Slack, in a Jira comment, in a 1:1, in an email to the COO, and in the registry, you have five cords, and your ranking only covers whatever happened to land in one of them. The people with the most access will always use the side channel, which is how the same VP ends up clearing everything without it ever showing up in the data. Talk about blockers wherever you want, but a blocker gets a row or it doesn't exist. Every station at Toyota has the same cord and it does the same thing.

Is it connected? When someone pulls an andon, a board lights up showing which station, and a specific team leader owns that station. A registry row with no named responder is a cord tied to nothing. Raising a blocker should notify the person who has to act right away, without the person who raised it having to chase anyone. This is the hard one in a transformation, because the blocker usually sits between two organizations and you have to decide who the responder is before you can wire anything to them.

Does someone come? The responder acknowledges fast, same day, and either clears it or says what it's waiting on. If it isn't cleared inside a set window, say 48 hours, it moves up on its own. That's your fixed position.

Unblock one thing a day

The connected responder is the team leader walking over. The daily cadence is what happens when the line reaches the fixed position, so leadership is looking at what the first response couldn't clear instead of seeing every blocker for the first time.

The commitment I like is small enough to keep: every day, the leadership group clears at least one blocker from the top of the escalated list. Fifteen minutes, standing up if you want. You look at the top of the ranked list, someone owns the next one, and by tomorrow it's cleared or it's explained.

There's precedent for how much a daily rhythm can do. When Stanley McChrystal took over the joint special operations task force in Iraq, he made the daily Operations and Intelligence brief the center of the organization: a video call that connected more than 70 locations and could run to thousands of participants. The point was that everybody saw the same problems at the same time, and that people close to the problem were expected to decide. The task force went from about four raids a month in late 2003 to around 300 a month by August 2006. That was a war, and a lot of things changed at once. But the daily shared view of what's stuck was the part they kept saying mattered most.

The other half of the cadence is what happens to the person who raises the red. Alan Mulally walked into Ford in 2006 with the company headed for a $17 billion loss, and every Thursday his business plan review showed him a wall of green. Eventually Mark Fields put up a red slide: he'd halted the Edge launch over a tailgate latch problem. The room went tense, and Mulally clapped. "Great visibility, Mark." Fields later called that meeting a tipping point. The next week the slides started turning red, and you can't fix what's green on paper.

That's the Van Nuys lesson from the other side. If raising a blocker costs you, people stop raising them, and your registry fills up with whatever is safe to admit.

What I'd expect the data to show

I haven't run this playbook end to end, so treat this part as a hypothesis. My guess is that a few weeks in, the registry would show the same handful of people clearing things over and over. The CFO approves the exception again. The CTO resolves the access issue again. The same VP breaks the tie between the same two teams for the third time this month.

My working hypothesis is that this points to one of two things, and they need different fixes.

Decision concentration. Too many decisions can only be made by too few people. The organization has authority pooled at the top, so everything queues behind a small number of calendars. McKinsey surveyed managers and found they spend about 37 percent of their time on decisions, and more than half of that time is used ineffectively. For an average Fortune 500 company they estimated that at over 530,000 lost manager days a year. Bain's research across hundreds of companies found decision effectiveness and financial performance moving together at about a 95 percent correlation. Those are consulting-firm numbers and I'd hold them loosely, but the direction matches the resistance I've run into over the years.

Organizational friction. The decisions themselves are fine, but the process forces each one through a person every time. The same type of blocker keeps coming back because the rule that creates it never changes. Somebody heroically clears it and the system regenerates it.

The registry lets you tell these apart instead of guessing:

• Pull rate. Are blockers being raised at all? A quiet registry in the middle of a transformation is a Dearborn number, and it means none of the other metrics can be trusted yet.
• Unblocker concentration. What share of cleared blockers went through the top three people? If it's most of them, that's concentration.
• Repeat rate. How often does the same type of blocker, from the same source, come back within 30 days? High repeat rate is friction, and the fix is changing the rule that keeps creating it.
• Time to first response vs. time to clear. If someone responds fast but clearing takes weeks, the bottleneck is authority. If nobody responds for days, it's attention and cadence.

I treat those as rules of thumb. The value is that you're arguing about data instead of about whose team is slower.

What the companies that got through it did

When I look at organizations that moved through big change without drowning their leaders in escalations, the tactics look similar.

They pushed decisions down, explicitly. McChrystal called it empowered execution: people well informed and close to the problem had both the authority and the expectation to decide. Amazon wrote it into process. Bezos split decisions into one-way doors, which are hard to reverse and deserve deliberation, and two-way doors, which can be undone and should be made fast by small groups or individuals, ideally with around 70 percent of the information you wish you had. He also argued for single-threaded leaders, one person who owns an area without competing priorities, so decisions don't wait on someone splitting their attention five ways. In registry terms: every blocker tagged "decision" should also be tagged one-way or two-way. Two-way doors sitting in an executive's queue are a delegation problem with a name on it.

They took layers out of the path. Bayer under Bill Anderson is the big recent example. They cut management layers by about half and management roles by about two thirds, moved to 90-day cycles where teams set priorities and resources get reallocated every quarter, and report results like plant breeding cycles going from five years to four months and a hemophilia self-infusion improvement done in one 90-day cycle instead of the usual two years. It came with roughly 5,500 layoffs and it's still early, so I'd watch the multi-year numbers before calling it. But it's a direct attack on decision concentration, at a company with almost 100,000 people.

They time-boxed the escalation. This is the fixed position from the andon cord applied to knowledge work. A blocker gets a short window at the level it was raised, then moves up automatically. Nobody has to feel like they're going over someone's head, because the clock did it.

They checked their incentives. Van Nuys had the cord and the classroom and still failed because managers were paid on throughput. If your leaders are rewarded for green dashboards, your registry will be empty and your launch will slip anyway.

They made the red rewarded in public. One clap from Mulally did more than any memo. The first few blockers people raise are a test of whether the organization means it.

What this looks like on Monday

If I were starting this inside a team in the middle of a transformation, I'd keep it boring:

1. Pick one cord. Stand up the registry in whatever tool you already use, one list, six fields, and tell everyone a blocker that isn't in it doesn't exist.
2. Connect it. Every row names who has to act, and raising it notifies them.
3. Set the fixed position. Acknowledged the same day, escalated automatically after 48 hours.
4. Seed it by asking every team lead for the three things they're waiting on right now. Expect it to be uncomfortable.
5. Rank by blast radius times days open.
6. Fifteen minutes a day, clear the top escalated one. Celebrate the person who raised it.
7. After 30 days, run the four numbers: pull rate, unblocker concentration, repeat rate, response vs. clear time.
8. For concentration, write down decision rights and move two-way doors down a level. For friction, change the rule that keeps generating the blocker and retire the category.

Then do it again next month and see whether the same names are still clearing the same things.

A second hypothesis: could the cord pull itself?

Everything above assumes people raise the blockers. That's the weak link, especially in a transformation where nobody trusts the process yet and half the blockers sit between organizations that don't share a tracker. Most blockers never get filed. They get mentioned. "We're still waiting on legal." "The vendor hasn't given us API access." "I think finance has to sign off on that, not sure who." It shows up in a meeting transcript, a Slack thread, a status email, a Jira comment, and then it just sits there.

So here's the hypothesis I'm more interested in. Could you build cognitive infrastructure that does this continuously? Teams of agents reading across the systems and transcripts a change program already produces, picking up blockers people mention but never file, deduplicating them into one registry so there's one cord, ranking them by blast radius and age, and routing each one to the person who has to act. Then watching the clock and pushing it up the right path when it sits past its window, toward the person with the authority to clear it, and counting all of it, so the concentration and repeat patterns show up without anyone having to build a report.

If that works, the four questions mostly get answered by the infrastructure. It's instrumented by default, it's one cord because everything lands in the same place, it's connected because routing is part of the system, and the escalation path means somebody always comes.

There are real ways it could go wrong. An agent that reads every meeting can feel like surveillance, and if people think the transcript is being used against them, they'll stop saying the blocker out loud, which is Van Nuys again with better software. It has to be governed: who can see which blockers, what gets surfaced and to whom, and a human with real authority at the end of every escalation path. The agents can find and route blockers, but clearing them is still a decision somebody has to make.

I don't know yet whether that holds up. But I'd like to find out whether the response that Toyota built into the line over decades can be built in software across a messy, multi-party change program in weeks, and whether that changes who ends up clearing things.

Sources

• Lean Blog, "No, One Toyota Worker Cannot Stop the Whole Factory" (2026)
• IndustryWeek, "Andon Is a Signal, But Leadership's Response Is the Critical Part"
• NPR / This American Life, "The End of the Line for GM-Toyota Joint Venture"
• Fortune, "The tipping point in Ford's turnaround" (2010)
• McChrystal et al., Team of Teams (2015); summary
• Amazon 2015/2016 shareholder letters (one-way/two-way doors, disagree and commit); overview
• Fortune, "Bayer attacked bureaucracy" (2025) (also Bayer's operating model page)
• McKinsey, "Decision making in the age of urgency"
• Bain, "Score your organization to improve decision effectiveness"