Tim Cook is Leaving. Good.

Mike's Notes

The key takeaway of this copied article.

"make products you’d be proud to use yourself."

Resources

• https://routerjockey.com/tim-cook-is-leaving-good/
• https://routerjockey.com/tools/
• https://www.blog.ajabbi.com/2026/02/my-fitbit-buzzed-and-i-understood.html
• https://www.blog.ajabbi.com/2025/03/the-rot-economy.html
• https://www.blog.ajabbi.com/2025/02/enshittification-tarpits-and-other.html

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
• Home > Handbook > 

Last Updated

05/05/2026

Tim Cook is Leaving. Good.

By: Tony Mattke 

Router Jockey: 27/04/2026

I’m Anthony Mattke, aka Tony. I’m a network engineer, infrastructure architect, and general-purpose technology geek located amidst the endless cornfields of north central Indiana. I’m a husband and father, and I hope to have superpowers one day. Seriously.

Your AirPods just connected to the wrong device. Again.

iMessage is taking twenty minutes to sync a message between your laptop and your phone sitting six inches apart. HomeKit forgot the kitchen lightbulb exists, and will remember it again in three hours like nothing happened. System Settings, which used to be one of the cleanest preferences UIs ever shipped, now feels like a bad Electron app pretending to be macOS.

These aren’t dramatic failures. They’re worse than dramatic failures. They’re daily proof that somewhere along the way, Apple stopped caring about the texture of using its own products.

This is Apple in 2026. And this is the Apple that Tim Cook built.

Cook announced his departure last week, and most of the coverage you’ll see is going to be a victory lap. A lot of it is earned. Apple is a three-trillion-dollar company. Services revenue is at record highs. Apple Silicon is one of the great hardware bets of the last decade. He took a company already at the top of its industry and made it bigger than the GDP of most countries.

So why am I glad he’s leaving? Because somewhere in all that growth, Apple stopped making products it was proud of.

What Steve Actually Said

There’s a passage in Walter Isaacson’s biography of Steve Jobs that gets quoted less than the famous ones. Jobs talked about how great companies die, and his theory was that the rot has nothing to do with competition or markets or innovation cycles. The rot starts when the salespeople end up running the company.

He named names. He pointed at IBM under John Akers. He pointed at Microsoft under Ballmer. He even pointed at the Sculley era of his own Apple as the cautionary tale. The phrase Jobs kept circling back to was that the people running these companies eventually “have no conception of a good product versus a bad product.” They can’t tell the difference. They can run a supply chain better than anyone alive, but they couldn’t tell you whether the radius on a button looks right.

That’s not a small criticism. That’s the founder of Apple, on the record, naming the disease and warning the company against catching it.

Then, in 2011, Apple promoted its head of operations to CEO.

I’m not saying Cook was a bad pick at the time. He was the right person to keep the trains running while everyone caught their breath after losing Steve. But fifteen years later it’s worth asking the question Steve himself would have asked. What kind of products are we shipping now?

The Tenet Cook Forgot

Of all the things Steve Jobs believed about Apple, one of them stands out as the most quietly violated under Cook: make products you’d be proud to use yourself.

Not just sell. Not just ship. Use. Sit down at the Mac on a Tuesday night, put your AirPods in, fire off a Message, set up a HomeKit automation, and feel proud of every single one of those things working the way you wanted them to.

Today’s Apple doesn’t pass that test. And the failures aren’t dramatic ones. They’re the small, persistent, daily-friction kind that the founder used to personally drive teams to fix.

You know the list. The 2022 System Settings redesign managed to take a perfectly usable preferences app and ship it as something worse, then leave it that way for three OS releases and counting. Notifications have been re-architected three times in five years and still work inconsistently across iOS, iPadOS, and macOS. Mail rules have been broken since the Obama administration. The Photos library will quietly drop items, sync ghosts, and offer no diagnostics when something goes wrong. HomeKit loses devices the way a child loses socks. Spotlight returns stale results and pauses for seconds at a time on hardware that should make it instant.

Each one of these, on its own, is just a bug. Together, they’re a culture.

They survive because they don’t move metrics. They don’t reduce revenue. They don’t show up in the quarterly. But they’re exactly the kind of paper-cuts that would have annoyed Steve at 9pm on a Tuesday, and they would have been fixed by Wednesday morning.

That’s the difference. Steve used the products. Cook signs the budget.

Before Someone Says This Is Just Nostalgia

Yes, I know. Apple under Steve wasn’t perfect. MobileMe happened. Antennagate happened. The hockey-puck mouse happened. Plenty of bad calls happened. Nobody is arguing for some flawless golden age that didn’t actually exist.

The argument is about standards, not perfection. Old Apple shipped mistakes too, and it visibly hated them. The bad release, the launch-day disaster, the public mea culpa, the engineering re-org. The whole company would visibly recoil and try to do better.

Today’s Apple ships friction and treats it like background radiation. That’s not the same thing.

The Counter Argument (-ish)

Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras and better screens and better batteries. The hardware story under Cook is strong, and pretending otherwise would be silly.

But here’s the thing about hardware. You can grow it through operational discipline. You can squeeze a process node, you can negotiate a better deal with TSMC, you can lean on a thousand suppliers until they bend. That’s exactly the kind of work Cook is good at, and it’s exactly the kind of work that doesn’t require a product person at the top.

Software is different. Software lives or dies on judgment calls a thousand times a day. Should this preference go in this menu or that one? Should this notification fire silently or with a sound? Should this Bluetooth handoff be aggressive or conservative? Those decisions can’t be operationally optimized. They have to be made by someone who actually uses the thing and has an opinion. Cook is famously not that person.

And the rot follows that exact line. Apple’s hardware reviews are still glowing. Apple’s software reviews… are not. The number of “I’m switching to Linux” or “I’m switching back to Windows” essays from longtime Apple loyalists has gone from a trickle to something that should worry someone on Apple Park’s executive row.

The grumbling isn’t about features. It’s about the texture of using the products. Which is the thing Steve cared about most, and Cook seemingly cares about least.

The Era of *aaS

There’s a related thread here. Cook’s Apple has gradually rebuilt itself as a services company that happens to make hardware. iCloud subscriptions. Apple Music. Apple TV+. Apple Arcade. Apple Fitness+. Apple News+. Apple One. AppleCare+ tiers within tiers. The recurring monthly nudges that show up in apps that used to be one-and-done.

There’s a real argument that this was a defensive move, and it worked. The Services line is now bigger than the GDP of small nations. But there’s also a reason long-time Apple users are uneasy. The company that ran the iPod silhouette ad is now the company that nudges you to try Apple Fitness+ when you open the Watch app for an unrelated reason. The texture changed. The thing that made Apple feel different is, slowly, less different.

And here’s where it loops back to the bug list. When recurring revenue becomes the thing the company optimizes for, the tolerance for friction goes up. A slightly annoying subscription upsell is acceptable as long as the funnel still works. A weird Settings menu is acceptable as long as nobody actually leaves. That’s how product standards quietly erode. Not through one dramatic bad decision, but through a thousand tolerated ones.

Was that the right business call? Maybe. Was it the right product call? Different question. And it’s the question Steve would have asked.

Enter John Ternus

The honest read on Cook’s tenure: he was the right operations CEO for the post-Steve transition, and he stayed long enough to also become the wrong product CEO for the post-iPhone era. That’s not a damning legacy. It’s just a long career with two halves that needed different people.

So who’s getting handed the keys? John Ternus.

If you needed to pick someone inside Apple to course-correct away from the operations-CEO failure mode, Ternus is the right person on paper. He’s been SVP of Hardware Engineering for years. He came up working on the Mac, ran iPad development, and was a key player in the Apple Silicon transition. He’s the one Apple keeps putting on the keynote stage to talk about new hardware. By any honest read, he’s an engineer and a product person, not a salesperson, not an operator. That’s the pick Steve would have nodded at.

BUT…

The piece I just spent a thousand words complaining about isn’t a hardware problem. Apple’s hardware under Cook has been excellent. The thing that rotted is the software experience. The bug list. And Ternus, for all his strengths, has spent his career running hardware, not software. Whether his product instincts translate into fixing the software stack is the open question of his tenure.

The hopeful read is that an engineer-CEO will demand engineering rigor across the whole company, including from the software org that’s been getting away with shipping half-baked work for a decade. The cynical read is that hardware engineers and software engineers are different cultures, and you can lead one without knowing how to fix the other.

I’m cautiously in the hopeful camp. The fact that Apple chose a builder over another finance type or another operations type says they noticed the thing this article is about. That’s not nothing.

But the proof is going to be in the next macOS release. Does System Settings get rebuilt? Does AirPods routing finally stabilize? Does Mail get a rewrite? Do notifications get a coherent strategy across all four operating systems? If yes, this was the right pick. If we get another year of shiny new features with five new bugs and zero fixes for the old ones, then Apple just rearranged the deck chairs.

Because that’s what made Apple. The rest is supply chain.

So yes. Tim Cook is leaving. Good. And John Ternus is taking the keys at exactly the moment Apple needs to remember what it was supposed to be.

My Fitbit Buzzed and I Understood Enshittification

Mike's Notes

Kent, as always, nailed the problem right on the head.

Resources

• https://tidyfirst.substack.com/p/my-fitbit-buzzed-and-i-understood
• https://www.blog.ajabbi.com/2025/03/the-rot-economy.html
• https://www.blog.ajabbi.com/2025/02/enshittification-tarpits-and-other.html

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > Software Design: Tidy First?
• Home > Handbook > 

Last Updated

16/02/2026

My Fitbit Buzzed and I Understood Enshittification

By: Kent Beck

Software Design: Tidy First?: 15/01/2026

Programmer, artist, coach coach, singer/guitarist, peripatetic. Learning to be me. Full-time content producer.

My Fitbit started buzzing at me a year ago. “It looks like you’re exercising.”

Yeah. No shit. I’m walking. I know I’m exercising. I’m the one doing it.

I didn’t ask for this notification. I don’t want this notification. Nobody wants to be told what they’re already doing. And yet, here we are.

I was annoyed for about thirty seconds. Then I started thinking about what it must be like to be a product developer inside Fitbit. That’s the advantage of walking as exercise. Time to think.

The View From Inside

You’re a product owner. You have a feature to ship: “Automatic Exercise Detection.” It’s a reasonable feature. The watch notices when you start moving in exercise-like ways and begins tracking.

But here’s your problem: how do you know the feature is working? How do you prove it’s valuable? How do you keep your job?

You need metrics. You need numbers that go up.

So you add a notification. “It looks like you’re exercising.” Now you can measure engagement. Users are responding to your feature. They’re seeing it. They’re interacting with it. Your numbers go up. Your feature is a success. You get to stay employed.

Then users get annoyed. Some of them complain. So you add a setting to turn it off. But you default it to “on” because that keeps your numbers up. Most users won’t find the setting. Most users will just... tolerate it.

I can’t blame this product owner. They’re playing the only game available to them. The company set up incentives that reward exactly this behavior. What else were they supposed to do?

This Is The Mechanism

I’ve been thinking about this pattern ever since Cory Doctorow coined “enshittification” to describe how platforms decay. But I don’t think we’ve been precise enough about the mechanism.

It’s not that companies decide to make their products worse. Nobody wakes up thinking, “Let’s annoy our users today.” The mechanism is subtler and more tragic:

1. Individual contributors need to demonstrate value
2. Demonstrating value requires metrics
3. Metrics create incentives
4. Incentives shape behavior
5. Behavior optimizes for the metric, not the user

Each step is locally rational. Each person is doing their job. And the cumulative result is a product that gets progressively more hostile to the people using it.

Here’s another example. In most messaging apps, there’s a button to call someone. This button is conveniently located right where you might accidentally tap it. You’re scrolling through a conversation, your thumb grazes the wrong spot, and suddenly you’re calling your ex at 2 AM.

Why is that button there? Why is it so easy to hit accidentally?

Because someone’s job depends on “calls initiated” going up. If the button were harder to find, fewer people would use it. Fewer people using it means lower numbers. Lower numbers means maybe you don’t get to keep working on this feature. Maybe you don’t get to keep working here at all.

So the button stays prominent. And users keep accidentally calling people they didn’t mean to call.

The Metrics Arms Race

Some folks suggest the solution is more metrics. Add a “calls immediately hung up” counter. Subtract it from “calls initiated.” Now you’re measuring meaningful calls!

You’ll never win this race.

To keep their jobs, people will be extremely clever about gaming whatever measurement system you create. Add a metric, they’ll optimize around it. Add two metrics, they’ll find the corner cases. Add ten metrics, and now you’ve created a system so complex that nobody understands what “good” looks like anymore.

I’ve watched teams spend more energy figuring out how to make their metrics look good than figuring out how to make their product actually good. The metrics become the product. The users become an externality.

The Alternative Nobody Wants To Hear

At some point, you have to have principles.

Not metrics. Principles.

“Don’t interrupt the user unless they explicitly asked you to.”

“Don’t put buttons where they’ll be accidentally pressed.”

“Don’t optimize for engagement when engagement means annoyance.”

These aren’t measurable. You can’t put them in a dashboard. You can’t A/B test them (well, you can, but you’ll lose to the variant that violates them, because that variant’s numbers will be better).

Principles require someone to say: “We just don’t do this, and I don’t have to give you a reason.” And then they have to defend that line when the metrics-driven arguments come. “But the numbers show—” No. We don’t do this.

This is uncomfortable. It feels arbitrary. It feels like you’re leaving value on the table. Maybe you are.

But the alternative is a product that slowly, inexorably, turns against its users. One “engagement optimization” at a time. One “growth hack” at a time. One annoying notification at a time.

Software Design Is An Exercise In Human Relationships

I keep coming back to this phrase because it keeps being true in new ways.

Product development is also an exercise in human relationships. And when we reduce those relationships to metrics, we lose something essential. We lose the ability to say, “This would be rude.” We lose the ability to treat users like people instead of engagement vectors.

The Fitbit doesn’t know I’m annoyed. It only knows I looked at the notification. In the database, that’s engagement. In my lived experience, it’s one more small friction. One more tiny way the device that’s supposed to help me is instead demanding my attention for its own purposes.

I turned off the notification. I found the setting, buried three menus deep, and I turned it off. I’m a technical person who knows these settings exist. Most people won’t. Most people will just get buzzed, over and over, because someone at Fitbit needed their numbers to go up.

I don’t know how to fix this at the industry level. But I know this: the seemingly rational, completely legible, metrics-based product development process is how we got here. The numbers all went up. And the products all got worse.

Maybe it’s time to trust the numbers a little less and trust our sense of what’s right a little more. Even when—especially when—we can’t prove it in a dashboard.

The Andon Cord

Mike's Notes

A fascinating history that begins with Toyota.

Resources

• https://itrevolution.com/articles/kata/
• https://global.toyota/en/company/vision-and-philosophy/production-system/
• https://en.wikipedia.org/wiki/Toyota_Kata
• https://www.thehighvelocityedge.com/book
• https://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/1472439058
• https://www.profound-deming.com/blog-1/a-brief-history-of-pdsa
• https://www.sec.gov/Archives/edgar/data/1018724/000119312513151836/d511111dex991.htm
• https://en.wikipedia.org/wiki/The_Goal_(novel)
• https://books.google.com/books/about/Lean_Thinking.html?id=2eWHaAyiNrgC&redir_esc=y

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subscriptions > IT Revolution
• Home > Handbook > 

Last Updated

2/02/2026

The Andon Cord

By: John Willis

IT Revolution: 15/10/2023

John Willis has worked in the IT management industry for more than 35 years and is a prolific author, including "Deming's Journey to Profound Knowledge" and "The DevOps Handbook." He is researching DevOps, DevSecOps, IT risk, modern governance, and audit compliance. Previously he was an Evangelist at Docker Inc., VP of Solutions for Socketplane (sold to Docker) and Enstratius (sold to Dell), and VP of Training & Services at Opscode where he formalized the training, evangelism, and professional services functions at the firm. Willis also founded Gulf Breeze Software, an award winning IBM business partner, which specializes in deploying Tivoli technology for the enterprise. Willis has authored six IBM Redbooks for IBM on enterprise systems management and was the founder and chief architect at Chain Bridge Systems.

The origin of the word “Andon” in Japanese comes from the use of traditional lighting equipment using a fire burning lamp made out of paper and bamboo. This “Andon” idea was later translated for use in manufacturing in Japan. The “Andon” became used as a signal to highlight an anomaly (i.e., a flashing light). This signal would be used to amplify potential defects in quality. When a defect was suspected, a sign board would light up signaling the specific workstation having a problem. The signal event would also indicate that the system was stopped due to the defect and was waiting for the problem to be resolved.

The process of stopping a system when a defect was suspected originates back to the original Toyota System Corporation to something called Jidoka. The idea behind Jidoka is that by stopping the system you get an immediate opportunity for improvement, or find a root cause, as opposed to letting the defect move further down the line and be unresolved.

The Jidoka concept was pioneered by the original Toyota founder, Sakichi Toyoda. Sakichi Toyoda is known as the father of the Japanese industrial revolution and also the founder of the original Toyota Systems Corporation (before they manufactured automobiles).

Sakichi Toyoda invented the automatic power loom in 1924 where the loom would automatically stop if a sewing needle broke. Before his invention, the loom would continue even when the needle was broken.  When this occurred, the downstream process would produce runs in the fabric stitches of the final product. 

Toyota Production Systems

Approximately 25 years later, a gentleman named Taiichi Ohno, who is considered the father of “Toyota Production Systems (TPS)”, architected a leadership and technology model incorporating some of the original Jidoka ideas along with a lot of other interesting innovations. His ideas produced an unprecedented run of quality and manufacturing success for over 40 years.

To this day, what was done at TPS from around 1950 to 1990 still can’t be repeated in automobile manufacturing, and many have tried. An abundance of material has been written about TPS, also coined as Lean over the years, and many have tried to copy TPS from that body of knowledge.

Toyota Kata

Mike Rother in his Toyota Kata book points out that of the many who try to emulate Toyota, most miss the invisible side of what they were doing.

The key, as Rother suggests, is that it wasn’t the tools that made Toyota great, it was the culture and specific behavior associated behind those tools. One of the best examples of this was the use of the Andon Cord at Toyota.

The Andon Cord was a manifestation of the original Jidoka principle. Toyota implemented the Andon Cord as a physical rope that followed the assembly line and could be pulled to stop the manufacturing line at any time. Most western culture analysis of this type of Cord might assume this was implemented as a safety cut off switch. At Toyota, it was a tool to instill autonomic behavior patterns. This is what Rother calls Kata.

Furthermore, this wasn’t an ask permission to stop the line, the pull actually stopped the line. As the story goes, anyone could pull the Andon Cord anytime.

Sounds mad doesn’t it? Salvador Dali eloquently says “The only difference between a madman and me is that I’m not mad.” 

At TPS, the Cord was pulled often. The mechanics of the Andon Cord were if the Cord was pulled, not only did the line stop, but an “andon” would light up on a signal board to indicate the workstation that was having the issue.

Beyond the mechanics, the culture behind the Andon Cord was a lot more interesting. The first thing that would happen when the Andon Cord was pulled is that a team leader would immediately “go-see” the issue by visiting the workstation. This was unconditional.

Toyota lived by this “Show Me” culture where in a western culture organization a team lead might put down the coffee on his or her desk and call the workstation to find out what was happening. This is a key point here. The “go-see” removes any preconceived notions or potential bias related to the problem. The “go-see” process is fact based.

High Velocity Edge

In Dr. Steven Spear’s The High Velocity Edge, he describes a horrifying story of missed opportunities leading up to the 2003 NASA Columbia space shuttle disaster.

The short version of the story is that the thermal protection system on the left wing was damaged just after launch but didn’t become an issue until reentry 19 days later. After the disaster, an investigation board charged with reviewing the accident found there were at least eight attempted signaling events to notify the crew requesting that they “go-see” the damage. The first request happened as early as the fourth day of the mission. These ‘signals’ were not addressed because there was a cognitive bias at NASA regarding this particular issue. This kind of damage had happened on previous missions and they had always been successful. Diane Vaughan, a Columbia University sociologist, coined this as “normalization of deviance”. This is where an organization tends to accept risky anomalies as normal through repeated success.

This form of a blind spot is also referred to as outcome bias. Outcome bias is where people observe successful outcomes as results as opposed to addressing individual problems at face value. Sidney Dekker in The Field Guide to Understanding Human Error states this kind of the anti Murphy’s Law in that, what can go wrong usually goes right.  Organizations get desensitized due to more positive outcomes than exposed failures. 

Dr. Spear suggests some counterfactuals that are intellectually interesting, or at least proposes learning opportunities for the reader. He suggests the Columbia crew could have been notified and possibly done an extravehicular activity (EVA) inspection to look at the damage.

Instead, NASA ignored repeated attempts, andon pulls if you will, to “go-see” the factual conditions. NASA unfortunately was mired in culture bias’ and preconceived notions of what constituted a real (“go-see”) opportunity. Maybe if the crew had been notified of just one of the eight known signals, they might have been able to access the damage, and possibly NASA could have done a recovery mission.

The meta-point here is that, ironically, NASA didn’t operate like scientists, unlike Toyota’s relentless “go-see” Kata.

Safety Culture

A second important cultural aspect of the “Andon Cord” process at Toyota was that when the team leader arrived at the workstation, he or she thanked the team member who pulled the Cord. This was another unconditional behavior reinforcement. The repetition of this simple gesture formed a learning pattern of what we call today “Safety Culture”. The team member did not, or would never be, in a position of feeling fear or retribution for stopping the line.

Quite the contrary, the team member was always rewarded verbally. What Toyota was saying to the team member was “We thank you and your CEO thanks you.  You have saved a customer from receiving a defect.” Moreover, they were saying, “You have given us (Toyota) an opportunity to learn and for that we really thank you.”

No defect was too small or even if the Cord was mistakenly pulled, the response would never be negative.

In Toyota Kata, Rother says that if you look up the word “failure” in the dictionary, it never implies that “failure” is a bad word.  In a classic tayloristic western culture, we tend to shy way from failure at all cost.  We penalize failure and we typically never embrace it. At TPS, failure was embraced and rewarded. As Rother also discusses in his book, that at Toyota, at their core, believed failure created learning opportunities.

Improvement Kata

The third important behavior reinforcement of the “Andon Cord” process was that the issue was a priority. In fact, the second thing that would happen when the team leader would arrive at the workstation after the thank you, is that he or she would ask “How can I help you?”. An important aspect of this is the “you”.

The incident was not going to be some paper report or bureaucratic long tail process. The problem was going to be immediately addressed and in fact, the team member who pulled the Cord was the one who was going to fix it.

Another overarching aspect to the culture at Toyota was that everyone had a mentor. The mentor/mentee relationship was one where it was very important that the mentee understand the problem. Again in western culture organizations, even if a worker felt empowered to stop the line, they might not be inclined to do so if they thought the problem would not get fixed. Even worse, have the issue get bogged down in useless paperwork and never ending meetings. The team leader at Toyota would then proceed to ask a series of questions trying to drill down to a point where the team member would understand the issue.

Another key point in this process was that even if the team leader knew a better answer, Toyota principally felt that a solution from the team member was a better outcome. In other words, if the problem is not understood at the line level, that is the team member/mentee, then the problem was not solved.

This is what I would call learning at scale.

Plan Do Change Act (PDCA)

Furthermore, the process of solving the issues was controlled by a practice described by Dr. Edwards Deming called Plan Do Change Act (PDCA). At its core, PDCA is basic scientific method.

Rother refers to this set of tools as Improvement Kata and Coaching Kata.

The Improvement Kata was an iterative mentor/mentee PDCA loop whereas the Coaching Kata was a sort of Socratic dialog between the mentor and mentee. Again, an important point here is the team member (mentee) would always solve the problem. It was of high importance that the team member always solve the problem. Most importantly, it was critical for the team member to understand how the problem was solved. Otherwise, there would not be in inherent learning and therefore, no real improvement.

Solving problems at Toyota was not the goal, understanding how to solve the problem was. Solving problems in an Improvement Kata mode also creates a second order effect.  By solving one problem, sometimes other second order problems are exposed. 

Alcoa, the aluminum company, set out to have a zero on the job injury policy in 1987. Paul O’Neal, the new CEO at the time, created a policy that if anyone at Alcoa was hurt on the job, he needed to be notified within 24 hours. This was not slogan based safety. This was an organizational behavior modification to create a line of sight understanding of why injuries occur at Alcoa.

The results were unprecedented. However, the interesting side effect of this was that through this rigorous process of forced understanding, they exposed what they called other “pockets of ignorance”.  Their attention to detail for solving their first order problem, safety, surfaced other second order process improvements not necessarily related to safety.

At Toyota, it was important to instill an Improvement Kata based on a PDCA loop. Plan (P) a countermeasure, implement the countermeasure (D), check or study the results (C), and act on the results either it’s fixed or start the next countermeasure (A). Imagine all those masked problems that that never get noticed in large complex IT infrastructures due to a possible irregularity of the first order issues and non “go-see” approaches. 

There is a great story in the Toyota Kata book where at one point a particular Toyota plant notices that the average Andon Cord pulls in a shift goes down from 1000 to 700.  As Rother describes most western culture organizations would break out the champagne for such an occasion, not Toyota.  The CEO called an all-hands meeting to address the “problem”.

Notice I said problem.

The CEO then goes on to describe that “we” must have one of two problems here.  One, we are getting lazy and letting more defects get through the system or two, if that is not the case, then we are not operating at our full potential. He was telling everyone that if they were staffed to handle 1000 pulls per shift, then they should be pulling a 1000 Cords per shift.

The cornerstone behind this kind of thinking is that Toyota had a vision of having 1×1 flow. This is where there is no inventory build up and work flows freely at every point of the workflow. Even though 1×1 was sort of a “true north” at Toyota, the CEO was reminding all of them that their Kata should always be pointing towards that direction, what Rother calls the Vision.

In plain words, the CEO is saying more pulls equals more learning which means more improvement that gets us towards our vision. 1X1 was a means to an end to say “If we can produce cars faster, cheaper and with higher quality, we win.”

Amazon and the Customer Service Andon Cord

The Andon Cord has become a metaphor for some modern day Web Scale organizations as well.

Jeff Bezos, the CEO of Amazon, described in a 2013 letter to the Amazon’s shareholders a practice he called the Customer Service Andon Cord. This was an established practice of metaphorically pulling an Andon Cord when they noticed a customer was overpaying or had overpaid for a service.

Amazon would heuristically scan their systems looking for these kinds of potential customer service mismatches. These were considered defects at Amazon because they had a vision of being an organization that was always customer centric. They would automatically refund a customer, without the customer even asking, if the service delivery was suboptimal.

I have had this happen to me on a few occasions watching a movie on Amazon Prime, where the next day I received an email telling me they refunded my movie rental cost due to poor quality. They would also pull the Andon Cord where they found areas where a customer could be saving money. We see this all the time where Amazon reduces their Cloud Services price even though their service is considered far superior to their closest competitor.

This is a form of Kata in practice that drives Amazon towards their stated vision.

In that same shareholders letter, Bezos starts off with a line as follows: “Our energy at Amazon comes from the desire to impress customers rather than the zeal to best competitors”. It’s no mistake that two of the top 12 books on Jeff Bezos’s recommended reading list are The Goal by Eliyahu Goldratt and Lean Thinking by James Womack. In fact, The Goal is one of the three books he has all of his top executives read.

The Chaos Cord

Another example of an Andon Cord metaphor used in Web Scale businesses is at Netflix.

Netflix has an interesting way of exercising their Andon Cord, although they don’t actually call it an Andon Cord. Along the same line as Toyota, at Netflix failures are good things. Netflix has built in their own automated form of Jidoka.

As described earlier, Jidoka is a practice of stopping a process if it breaks. In the earlier example, the process we described was done via the physical Andon Cord and was a manual process. At Toyota, there were also automated forms of Jidoka practiced. Another famous engineer named Shigeo Shingo, who worked with Taiichi Ohno, is credited with the idea of pre-automation. This is a form of Jidoka that is automatic.

At Netflix, they actually inject this kind of Jidoko into their systems on purpose by intentionally trying to break systems in production. They have developed what is now famously called Chaos Monkey. Chaos Monkey is a process that randomly kills live running production servers. This behavior is known by everyone who works at Netflix. It’s part of their culture. There are no surprises about this practice.  Developers plan and Poka-Yoke their code and systems accordingly.

Poka-Yoke is another term that comes from Shigeo Shingo at TPS. Poka-Yoke means mistake-proofing. 

I was told by Adrian Cockcroft, one of the primary architects behind Netflix’s IT infrastructure, that not knowing about the Chaos Monkey mode coming into a job interview at Netflix was pretty much an immediate no-hire decision.

Imagine that Netflix’s Kata is so obsessed with failure they create their own failures on purpose. As you can imagine, Netflix is a learning organization and every one of these failures is treated as a science experiment.

They might not literally practice PDCA, but either one of two things happens when a server is killed by their Chaos monkey.  One, they learn that there were dormant defects in the process and fix them, or two, the injected failure was corrected automatically. The best case was where the injected failure caused no customer disruption. Their Improvement Kata was always moving in that direction.

Like any good operating Kata based organization, Netflix has been practicing their Kata for quite a few years now. You don’t get to Chaos Monkey overnight. Much of their Kata has been based on continual learning improvements.

One interesting method or Poka-Yoke, if you will, is something they do called Circuit Breaker Pattern.  Circuit Breaker Pattern comes from a book called Release-It by Mike Nygard.

These are software delivery patterns where the software code is designed very much like a circuit breaker in your home. If one service dies it isolates or is bounded to only fail the things it controls and not create cascading service outages. Think about a fuse in your home. If you inadvertently load up to much power in one area of your house you only wind up losing power in an isolated section.

Netflix does a similar implementation for their software services. Their application design is such that one thing breaking should never create cascading failures (like a overloaded circuit/fuse combo in your house).

The main point here is that implementing an Andon Cord in an organization is not something you do overnight. It takes a continuous improvement roadmap to get there and must have behavior reinforcement built into the process. It takes a fierce commitment and practice of improvement (Improvement Kata) and an equally skilled leadership coaching approach (Coaching Kata).

If you want to investigate the concept of Kata more deeply, I highly recommend reading Mike Rother’s Toyota Kata.

Selling to the Enterprise

Mike's Notes

Me trying to understand their mindset.

Resources

• https://staysaasy.com/product/2020/08/26/selling-enterprise-like-marriage.html

References

• Reference

Repository

• Home > Ajabbi Research > Library >
• Home > Handbook > 

Last Updated

13/11/2025

Selling to the Enterprise

By: 

Stay SaaSy: 26/08/2020

Writing about scaling enterprise SaaS product and engineering teams from $0 to IPO and beyond.

The enterprise SaaS industry is booming. Much has been written about how to scale B2C tech, as consumer technology companies such as Google, Facebook, or Netflix enjoy near-monopolies, employ hordes of people, and command appropriately dominant mindshare. A relative lack of material has been written about building enterprise software, particularly from a product & engineering point of view.

In this post series we’ll describe techniques on building an easily sellable SaaS product. To set the stage, we’ll define “enterprise buyers” as companies that:

• Employ 500+ people
• Are prepared to pay around $100,000 or (much) more for strategic products
• Regularly make long-term, multi-year software buying commitments

Enterprise Sales is Like Marriage

SaaS covers a wide spectrum of businesses: from enterprise products that cost tens of millions of dollars over multiple years, to freemium products that start at $10/month. The strategies that help you sell one will not (typically) work for the other. The process of settling on the former product is like getting married: months to years building the relationship, multiple suitors, and meetings with the parents, all with the intention of making a decades long commitment. Buying a $150/year utility SaaS, by comparison, is like a Tinder date that ends with getting busy in the back of a Prius.

Once you see the similarities between enterprise buying and marriage, many dimensions of how to sell high-value SaaS become more clear:

• Like a marriage, it’s important to have integrity. Don’t oversell – put your best foot forward (brush your teeth before the first date!) but have integrity in how you sell yourself (don’t lie about your job, your height, or where you went to school).
• You need to offer something differentiated. Nobody wants to settle – you need to be the best catch in at least one, and preferably multiple important dimensions.
• There are a lot of stakeholders. “Meeting the parents” is a key step in serious dating; meeting your buyer’s Procurement and Infosec teams can be a (disturbingly) similar experience.
• You need to be the right partners for each other. Enterprise sales relies upon product/customer fit – you should solve a need for your buyer, and you should be able to actually deliver. A common example: over-selling to a Fortune 500 company as a 40-person company, when you don’t have the stability, maturity, or headcount to deliver the service that they expect. Maybe you all are just meeting at the wrong moment in your lives.

When I began my career I didn’t understand this dynamic at all. I imagined that enterprise sales was like trying to meet someone at a bar: look as hot as possible, go to a few steak dinners, dance poorly and hope for the best. Superficial stuff. In reality, building a product that can sell to big-company buyers requires scoring well across a broad constellation of factors: the equivalents of getting a good education, having a steady job, and demonstrating that you know how to clean your apartment. Enterprise buyers expect to be courted, and as a builder you have the tools to put your best foot forward.

The Anatomy of an Enterprise Sale

These posts on how to sell to the enterprise are rooted in the core drivers that impact huge software purchases. Understanding these drivers as a product builder can help you navigate the arcane “dating” process behind closing your first (or next) enterprise logo:

• Spending millions of dollars on a software solution is necessarily a complex process due to the sheer amount of “stuff” going on at a large company.
• Enterprise software deployments have a complex web of stakeholders. The buyer of enterprise software is often different from the user, as software is (often) bought by executives but used by their teams. Decisions on which vendors to use can take on a political dimension, as they can make or break careers.
• Change is extremely expensive to enterprise buyers because they’re massive and built for momentum over agility. Like a battleship, they can carry a lot of people very far but are a pain to turn. Enterprise companies value stability, and they want to commit upfront to a long-term partner.

In this series, we’ll discuss strategies for building a product that will sell to the enterprise, and that will keep them happy for years. Following posts will break down strategies we’ve found helpful, and hopefully provide some ideas as you develop your own products.

Takeaways

• Building a product that can sell to the enterprise is difficult but rewarding.
• Enterprise sales is like dating with intent to marry, with many of the same dynamics.
• Enterprise buyers’ decision-making is influenced by several important drivers: the complexity of enterprise businesses, complicated webs of stakeholders, and the need to plan on long time horizons.

Next Ajabbi project will use MovieLab ontology

Mike's Notes

I'm starting to map out the shape of the next project. Please note that everything is subject to change as I learn by trial and error. :)

Resources

• https://learn.ajabbi.com/eng/9/docs/ajabbi-film/
• https://wiki.ajabbi.com/eng/9/ontologies.html
• https://wiki.ajabbi.com/eng/9/engines.html
• https://movielabs.com/
• https://movielabs.com/about/
• https://github.com/MovieLabs/OMC
• https://movielabs.com/news/new-visual-language-templates/
• https://movielabs.com/prodtech/ML_2030_Vision.pdf
• https://towardsai.com/p/machine-learning/how-amd-just-made-local-ai-filmmaking-a-reality-the-future-of-desktop-filmmaking-has-begun

References

• Reference

Repository

• Home > Ajabbi Research > Library > Subject > Film
• Home > Handbook > 
• Home > Learn > Docs > Film
• Home > Wiki > Ontologies > MovieLab

Last Updated

05/07/2025

Next Ajabbi project will use MovieLab ontology

By: Mike Peters

On a Sandy Beach: 05/07/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Ontology

MovieLab has matured significantly since 2019. The ontology and schema are very easy to follow.

I will use this project to production-test Pipi by importing ontologies and automatically generating entities using these engines.

• Ontology Engine (ont)
• Boro Engine (bor)
• Entity Engine (ent)

They will also receive full documentation and have UI workspaces.

Art Department

I previously worked in the art department, so I will build that part of the MovieLab schema. I could also test this on an upcoming 40-minute film, currently in pre-production, in which I'm involved.

• Art Department
• Hair
• Wardrobe
• Props
• Sets
• Greenery

From MoveLab

"In the Summer of 2019, MovieLabs, on behalf of its member studios, published a whitepaper called “The Evolution of Media Creation”, which laid out a bold 10-year vision for the adoption of new technologies to aid in content production, post and VFX. The paper, often referred to as the ‘2030 Vision’ has now been broadly adopted by many partner companies and is accepted as the industry ‘north star’ for guiding production technologies towards a shared goal.​

The original Evolution of Media Creation paper, available as a free download, lays out 10 Principles for a more efficient media pipeline using cloud infrastructure, zero trust security and software-defined workflows. The Principles act not just as a destination, but also a roadmap for how to get there. This roadmap drives the work of MovieLabs and those of our studios and external partners as we work together as an industry to bring the promise of the 2030 Vision forward. ​

Although the 2030 Vision is a technology roadmap it’s primary focus is in empowering the creative – to be able to achieve more – to be more efficient (replacing repetitive and menial tasks so they can focus on creative tasks), flexible (so workflows can change and adapt to new situations and technologies) and faster (so there’s more of the most precious resource – time)." - MovieLab

Thinking about the next steps ahead

Mike's Notes

I had the regular meeting on Sunday night, which helped bounce ideas around. I would like to know what people think of what I have written. Just contact me for a chat.

Resources

• https://www.blog.ajabbi.com/2025/01/data-model-and-ontology.html
• https://movielabs.com/
• https://wiki.ajabbi.com/eng/9/engines.html
• https://groups.google.com/g/ontolog-forum
• https://www.infoq.com/articles/state-space-solution-to-hallucinations-state-space-models/
• https://www.mathworks.com/help/ident/ug/what-are-state-space-models.html
• https://huggingface.co/blog/lbourdois/get-on-the-ssm-train
• https://steveblank.com/2025/07/08/blind-to-disruption-the-ceos-who-missed-the-future/

References

• Reference

Repository

• Home > Ajabbi Research > Library >
• Home > Handbook > 

Last Updated

09/07/2025

Thinking about the next steps ahead

By: Mike Peters

On a Sandy Beach: 01/07/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Ajabbi uses Pipi 9 to run on, known as "dogfooding". Steady progress is being made with Pipi 9, and the first customer website, which is now well underway.

The customer's website required several reusable modules and utilises these engines and more.

• Website Engine
• Reference Engine
• i18n Engine
• Reference Engine

Documentation of these modules and engines is now required for developers and administrators.

Next Project

It was now time to determine a plan for the next project.

There are three options;

• Finish the developer documentation
• Complete the user workspace roadmap
• Build a simple SaaS application

I will go into some detail about each option.

Finish the developer documentation.

No developer will be able to build anything with Pipi unless they have some documentation on how it works. 5% is documented.

Complete the user workspace roadmap.

This will enable users to log in and use the available features, but they will still require instructions in the form of documentation.

Build a simple SaaS application.

The Movie Industry SaaS application is straightforward and utilises a compact ontology. Its ontology is over 1,000 times smaller than SNOMED, so it's an easy place to start. It would be a way to test the Ontology API and Boro engines. It builds some more reusable modules. It also provides a helpful tool that people can use for their work.

This would generate more learning opportunities for me, as I do this work by the seat of my pants.

Discussion

The advantage of building a simple SaaS application is that it requires a user workspace and some relevant documentation. 

Being product-led, would only schedule work on any necessary background systems and documentation. It also makes things more manageable as Pipi slowly scales.

Over time, more modules will be completed, more engines will be documented, and the user workspace will expand.

Show and tell

Embedding short YouTube video recordings demonstrating workspace usage could be incorporated into training and contextual help documentation.

A longer, prerecorded technical demonstration video, accompanied by slides and a PDF white paper, could then be shared with the Ontolog Forum to solicit critical feedback. I suspect they would be curious about a novel use of Ontology technology as part of constraints in State Space.

Ignoring the Wisdom of Crowds

Mike's Notes

I read Jason Cohen's weekly newsletter, A Smart Bear, every Sunday night.

Resources

• https://longform.asmartbear.com/wisdom-of-crowds/
• https://en.wikipedia.org/wiki/The_Wisdom_of_Crowds
• https://press.princeton.edu/books/paperback/9780691138541/the-difference

References

• Reference

Repository

• Home > Ajabbi Research > Library >
• Home > Handbook > 

Last Updated

18/04/2025

Ignoring the Wisdom of Crowds

By: Jason Cohen

A Smart Bear: 11/01/2009

Discover how to leverage the wisdom of the crowds, but also when to avoid it, as it can easily lead you astray.

Let’s start with some fascinating, unassailable facts. Then we’ll assail them.

In 2007 Michael Mauboussin presented a big jar of jelly beans to his seventy-three Columbia Business School students. How many beans did they think it contained?

Guesses ranged from 250 to 4,100; the actual number was 1,116. The average error was 700—a massive 62%—demonstrating that the students were awful estimators.

Now here comes the weird part. Even with all these wildly incorrect guesses, the average of the guesses was 1,151—just 3% off the mark. The group’s average was closer than almost one person’s guess—only 2 of the 73 students guessed better.

So although individually everyone was woefully inaccurate, collectively the group was incredibly accurate.

Was this a fluke? Hardly. The experiment was made famous in 1987 by Jack Treynor. In his case it was 850 jelly beans and 56 students. The group average was only 2.5% off the correct number; only one student guessed better. The study has been repeated many times with similar results.

This eerie effect goes beyond jelly beans; it’s also a big help when you’re trying to make money on TV.

The best multiple-choice test ever

A contestant on the game show Who Wants to be a Millionaire wins a million dollars if she correctly answers fifteen consecutive multiple-choice questions. If she’s stumped along the way she has three “life-lines”: (1) eliminate two of the four choices, (2) telephone a friend, or (3) poll the audience. The jelly bean experiments imply that this third choice might be pretty good. Is there as much wisdom in the crowd for pop culture and science as there is in counting jelly beans? See for yourself:

The TV studio audience predicts the correct answer an astonishing 91% of the time. Remember, these are questions from all domains of knowledge, all ranges of difficulty, polling a group of people whose only qualification is that they happened spend this weekday afternoon in a TV studio.

To quantify how amazing that is, compare with the accuracy of the “phone a friend” life-line where the contestant gets 30 seconds with a pre-determined person. This accomplice is probably considered to be “the smartest person I know,” plus has access to the web of lies Google and Wikipedia.

The intelligent friend with broadband access to the entirety of human knowledge gets it right only 65% of the time.

Is the rule universal?

There’s seemingly no end to studies like these, all showing that the crowd is smarter than the individual. Is this a universal rule? Should we be leveraging this power more often?

Big companies do use crowd wisdom. You always hear about advertising campaigns being honed by focus groups of “real people.” (I’d like to see the questionnaire that distinguishes “real people” from that elusive other kind of person.)

However, company messaging, product features, advertising layouts, and the other creative aspects of business require innovation, and we know that design-by-committee is the antithesis of innovation. Average products designed for the average consumer is the opposite of innovation, and probably a bad product strategy too.

So what should we do? Can we rely on the wisdom of the collective or should we trust a stroke of inspiration?

Analysis of how “crowd wisdom” works

Let’s take another look at Who Wants to be a Millionaire.

Suppose there are 100 people in the audience and only 16 of them know that “A” is the correct answer. Of the rest, none knows the answer and they vote randomly. The result of the vote will be: 37, 21, 21, 21:

Oh gee, it’s awfully similar to the earlier graphic of a real audience poll.

(For those of you so inclined, it’s fun to try more complex scenarios, although you’ll find the result is always similar. For instance, what if only 11 know the answer is A, 15 each know that B, C, or D are certainly not the answer (and vote randomly for the other three), and the remaining 44 have no clue and vote randomly. In this scenario, the vote distribution is exactly the same as the simpler example!)

So we have the interesting result that a mere 16% of the voters were able to make choice A the clear winner—nearly double the next closest answer. The reason? The ignorant people vote randomly and their votes cancel out, leaving the few in control of the result.

The crowd vetoes innovation

Now that we understand how crowds can be right, let’s see why this same process doesn’t work for creative endeavors.

Consider what happens when you’re planning a holiday meal. There’s a range of fantastic things you could cook, but wait: Some people can’t take spicy food, Uncle Bill is allergic to garlic, Aunt Sarah doesn’t eat red meat, Timmy doesn’t eat anything green, ….

Eventually you realize there’s only way to please everyone: Cook something bland, mild, and safe, like chicken and rice. But does chicken and rice actually please anyone? Not really, it was just what everyone hated the least.

Votes don’t converge on something wonderful. Rather, votes are vetoes.

Of course if you’re a catering company for weddings, chicken and rice might be the way to go! After all, no one goes to weddings for the food, so your primary goal is to piss off as few of the 300 guests as possible. Come to think of it, chicken and rice does seem to be popular at those sorts of functions…

But this isn’t a good strategy for startups. Little companies need a niche—a market space they can completely, unquestionably own, not some gray middle-ground where your attempt to offend no one also means exciting no one.

There is “wisdom in the crowd” when there is an objectively-correct answer, and when the errors cancel out, like when estimating jelly beans or answering pop culture questions.

In creative work, votes eliminate the interesting edges, because votes result in subtracting rather than adding, leaving only the boring residue that no one hated enough to vote off the island.

That’s not how great products are made.

Further Reading

• The Wisdom of Crowds by James Surowiecki, with more stories and implications for Wall Street, and his (more expert than my) analysis on the five elements required to form a wise crowd.
• The Difference by Scott Page, explaining how diversity makes a group smarter. The inspiration for my Who Wants to be a Millionaire example.