Software dies of obesity. Not starvation.

The Arithmetic

Features are calories. Each one individually nourishing. Each one adding weight.

A typical enterprise team adds twelve to thirty features per quarter. A typical enterprise team deletes zero features per quarter. This is not an exaggeration. This is the arithmetic, and the arithmetic is patient.

After five years: 240 to 600 features. The number of features any single person on the team understands: roughly 30. The ratio of understood to total: five to twelve percent.

The industry has a polite name for this ratio. It’s called [[Technical Debt]]. It should be called what it is: the system is too fat to move, and nobody remembers what most of it does.

The asymmetry is the entire problem. Adding a feature requires one committee (product). Deleting a feature requires three to five (product, engineering, architecture, stakeholder, legal if it’s customer-facing). Adding takes one sprint. Deleting takes one sprint plus three months of “can we really remove this?” emails.

So features accumulate. Weight accumulates. The build takes forty minutes. The deployment pipeline has seventeen stages. The test suite takes four hours and fails nondeterministically. The system develops conditions. The system reaches a weight at which movement is painful and stillness is death.

This is [[Critical Mass]] — the point at which complexity becomes self-sustaining. Below critical mass, you can still change things. Above it, the chain reaction feeds itself: each feature creates dependencies, each dependency creates constituencies, each constituency defends its feature.

The Enterprise Cycle

Every enterprise system follows the same lifecycle. I have watched this cycle from inside boardrooms, billing three thousand pounds a day to tell people what they already knew:

Year 1: A small team builds something that works. It is fast. It is understandable. The people who built it love it.

Year 2-3: The system is successful. Success attracts features. Features attract stakeholders. Stakeholders attract roadmaps. The people who built it start to leave, replaced by people who maintain it. Love is replaced by duty. Duty is replaced by process.

Year 3-5: Nobody can hold the whole system in their head anymore. The architecture exists in folklore. A developer removes a feature and three other features break. The developer puts it back. Nobody removes anything again.

Year 5: A senior developer — usually the newest one — suggests “starting fresh.” The rewrite proposal has forty-seven slides. The timeline is off by a factor of three.

Year 5-7: The rewrite ships. It reaches feature parity at month eighteen. By month twenty-four, it has started accumulating its own features. By month thirty-six, it has reached critical mass.

The cycle repeats. The industry calls this “modernisation.” It is not modernisation. It is the same obesity on a newer framework.

The Only Force That Prevents It

I maintain a codebase. Solo. It’s a web application with eleven domain modules, a streaming AI agent, a compliance engine, and more moving parts than most teams of twenty manage.

Last week, I deleted 13,022 lines of code in nineteen commits. The codebase gained features. Not lost — gained. More capabilities, fewer lines. Content editors. AI context awareness. A convention from three months ago becoming the foundation for something nobody planned.

Net: -6,389 lines.

This is not a refactoring sprint. This is not tech debt payoff. This is tending — the routine, unglamorous act of growing AND pruning, applied by someone who loves the codebase enough to make it smaller.

Enterprise systems cannot do this. Not because the code is different, but because the relationship is different. Enterprise systems don’t have a gardener. They have committees. Committees plant. Committees never prune. Committees cannot prune, because pruning disappoints constituencies, and disappointing constituencies requires someone willing to be unpopular, and committees are designed to distribute unpopularity so evenly that it dissolves into inaction.

The solo developer has one constituency: themselves. Disappointing yourself is free and requires no meeting. Deleting working code requires the same courage as writing new code, and more taste. But it can be done on a Tuesday morning without filing a change request.

The AI Accelerant

Now add AI to this equation.

I work with an AI that writes four thousand lines of code in a day. Not bad code — good code. Tested, structured, following the conventions of the codebase. The AI is fast, precise, and tireless. It is the most productive planter in the history of software gardening.

But the AI does not prune.

The AI does not walk through the codebase on a Wednesday and feel that something is heavy. The AI does not notice that a domain built four months ago has been superseded by a capability that emerged last week. The AI does not say “we should delete this.” The AI builds what is asked, and what is asked is almost always more.

With AI, the growth pressure is 100x. A vibe-coded app — one where the developer prompts the AI and ships without reading — reaches critical mass in weeks, not years. Even a well-navigated codebase reaches it faster, because the paths are chosen but the weight still accumulates.

The answer is not “use less AI.” The answer is “prune more.” The AI’s gift is speed. Speed of growth must be matched by willingness to reduce. If nobody deletes four thousand lines in a month, the system reaches critical mass before Q3.

The Diet Nobody Prescribes

Here is the prescription that no enterprise architect will give you, because it cannot be expressed in a Jira ticket:

Someone has to love the codebase.

Not manage it. Not own it in a RACI matrix. Not be the “technical lead” whose name is on the architecture document. Love it. The way a gardener loves a garden — enough to plant and enough to prune, enough to grow it and enough to cut it back, enough to say “this was good work and it’s time for it to go.”

Love shows up as three things:

• Desire for the solution to exist. Not the ticket — the solution. The person who lies awake thinking “there must be a better way to do this” is the person who will find it. The person who closes the ticket and moves on will not.

• Stubbornness to carry an idea across time. The convention I built in December for sidebar resize modes was deleted along with the feature it served. The for-loop survived. Three months later, it became the foundation for AI context awareness. That for-loop survived because I was too stubborn to delete something that wasn’t hurting anything and too stubborn to build something new when the old thing was sitting right there.

• Love for the codebase as a whole, not just the parts you wrote this week. The willingness to delete 5,242 lines of working, tested code because the LLM does what it did, better, and the code is now weight.

These three things cannot be distributed across a committee. They cannot be automated by an AI. They cannot be scheduled in a sprint. They are the properties of a single person’s relationship with a single codebase, maintained over months and years.

This is why solo projects survive and enterprise systems collapse. Not because of skill. Because of love.

The Arithmetic, Revisited

Enterprise team:
  Features added per quarter:     12-30
  Features deleted per quarter:   0
  Trajectory:                     obesity → critical mass → rewrite → obesity
​
Solo developer (with AI):
  Lines written per day:          4,000
  Lines deleted per month:        13,000
  Net per campaign:               -6,389
  Features:                       more than before
  Trajectory:                     tended → pruned → growing → tended

The difference is not the AI. The AI is the same in both scenarios. The difference is whether someone loves the codebase enough to make it smaller.

Software dies of obesity, not starvation. The only cure is someone who cares enough to prescribe the diet. And in the enterprise, that person does not exist, because caring about a codebase is not a deliverable, and love is not a quarterly objective.

If you enjoyed this, there’s an encyclopedia of satirical entries on software development concepts, where every principle from YAGNI to Gall’s Law to Zawinski’s Law gets the roast it deserves. And a mythology where a developer, a lizard, and a caffeinated squirrel have been arguing about architecture for a hundred episodes.

See also:

• Critical Mass — The physics of when complexity becomes self-sustaining

• Tending — The missing practice: growing AND pruning

• YAGNI — The principle that could have prevented this

• Zawinski’s Law — Every program expands until it can read mail

• Gall’s Law — The rewrite will reach critical mass too

• Vibe Coding — The fastest path to obesity

• Vibe Engineering — Navigation delays obesity but doesn’t prevent it

It is worse than herding cats because cats do not have strong opinions about what a cat is.

The Naming Problem

The role has more titles than responsibilities. This is because the role was invented by organisations who had already hired agile coaches and discovered that agile coaches, left to their own devices, will coach in seventeen different directions simultaneously. Someone needed to align the coaches. That someone needed a title. The title needed to sound more senior than “coach” but less threatening than “manager” — because you cannot manage agile coaches, you can only facilitate their self-organisation, which is a phrase that means “manage them but never use that word.”

The title changes approximately every eighteen months, driven by LinkedIn trends, conference keynote themes, and the ongoing need to distinguish oneself from the two hundred other people in the same city with the same role and a different name for it. A single practitioner may hold four different titles in three years without changing employer, desk, or job description.

The title is the only thing that transforms more often than the organisation.

The Fifteen Opinions Problem

Talk to ten Agile Coaches. Get fifteen opinions. This is not an exaggeration. This is a census.

The fundamental problem of managing agile coaches is that each coach has a deeply held, experience-forged, certification-backed opinion about how teams should be organised, and these opinions contradict each other with the precision of a logic puzzle:

• Coach A believes teams should be cross-functional and product-aligned

• Coach B believes teams should be component-based with clear ownership boundaries

• Coach C believes teams should be temporary and project-based, dissolving after each initiative

• Coach A and Coach B agree that Coach C is wrong

• Coach C agrees that Coach A and Coach B are wrong

• Coaches D through J have positions that are variations of the above, plus three novel approaches they read about at a conference

• The Transformation Lead must create a single, coherent team topology from this

Now multiply this by every question a transformation involves: How long should a sprint be? (Two weeks. Three weeks. No sprints. Depends on the team. Depends on the work. One week but only for the first three months.) Should we use story points? (Yes. No. T-shirt sizes. Flow metrics. Cycle time only. Story points but rename them.) Should we do SAFe? (Yes. Absolutely not. Parts of it. Only the PI Planning. Never the PI Planning. What’s SAFe?)

The Transformation Lead’s job is to synthesise fifteen contradictory opinions into a coherent strategy, implement the strategy with people who disagree with it on principle, and then facilitate a Retrospective about why the implementation isn’t working — facilitated by the very people who disagreed with it, who will use the retrospective to propose their original opinion again.

The Irony

The supreme irony of the Agile Transformation Lead role is this: the people whose professional expertise is helping teams collaborate, align, and self-organise are — as a team — nearly impossible to get to collaborate, align, or self-organise.

Every coach has a model for how teams work. Every coach has facilitated hundreds of sessions on psychological safety, working agreements, and team norms. Every coach can draw the Tuckman model on a whiteboard with their eyes closed — forming, storming, norming, performing. Every coach knows the theory.

The theory does not survive contact with a room full of coaches.

Because a team of agile coaches is a team where every member is simultaneously a player and a referee. Every decision is also a coaching moment. Every disagreement is also a facilitation opportunity. Every meeting has twelve people who know exactly how the meeting should be run, and twelve different opinions about how that is. The storming phase of a coaching team does not end. It becomes the culture.

The Transformation Lead sits in the middle of this, holding fifteen leashes attached to fifteen professionals who are each trying to coach the person holding the leash.

The Cat Theorem

There exists an observed phenomenon — documented across multiple organisations, multiple countries, and at least one frustrated LinkedIn post — which may be stated formally as:

The Cat Theorem of Agile Coaching: The difficulty of organising a group of agile coaches into a functioning team is proportional to the square of the number of coaches, multiplied by the number of coaching certifications in the room.

This is because each certification comes with its own framework, its own vocabulary, its own model of how teams work, and its own opinion about whether the other certifications are valid. A room containing one Certified Scrum Master, one ICAgile coach, one SAFe Program Consultant, and one Kanban practitioner is not a team. It is a panel discussion that never ends.

The corollary: anyone who has successfully managed a team of agile coaches for more than two years will, upon retirement, acquire actual cats — finding them restful by comparison. riclib managed coaching teams for years. riclib now has Oskar and Mia. The causation is not proven. The correlation is perfect.

Oskar does not have opinions about sprint length. Mia does not propose alternative facilitation techniques during dinner. Both occasionally knock things off tables, but they do so without first requesting a retrospective about the table’s structural integrity. After years of herding coaches, riclib found that herding actual cats was a lateral move with better working conditions.

The Transformation Lead’s Toolkit

The tools available to the Transformation Lead are, in order of effectiveness:

1. Wine — not officially in any framework, but present at every offsite

2. The One-on-One — where the real alignment happens, because coaches will say things privately that they will never concede in a group

3. The External Consultant — occasionally, the only way to resolve a coaching deadlock is to bring in someone from outside. This is The Consultant pattern: paying a stranger to say the thing everyone already knows, because the stranger has no factional allegiance

4. Attrition — some coaches leave. The remaining team becomes more coherent. This is Conway’s Law applied to the coaching team: the team’s communication structure eventually simplifies to match the opinions of whoever stayed longest

5. Giving up and becoming a Solo Developer — see below

The Exit

The Transformation Lead role has one of the highest attrition rates in the agile industry. This is not because the work is unimportant. It is because the work is the organisational equivalent of being a marriage counsellor for a polyamorous commune where everyone has a PhD in relationships.

The exit paths are:

• Back to coaching — having learned that leading coaches is harder than coaching teams

• Into product — having learned that building things is more satisfying than helping people argue about how to build things

• Into consulting — having learned that the same dysfunction, experienced at arm’s length and billed hourly, is more tolerable

• Into a completely different field — having learned

• Into cat ownership — having learned that the herding instinct, once developed, demands an outlet, but the outlet no longer needs to have opinions

Measured Characteristics

• Alternative job titles for this role: 23+ (and counting)

• Average tenure in role: 18 months

• Coaches managed: 5–15

• Opinions per coach: 1.5 (minimum)

• Contradictory opinions per 10 coaches: 15

• Frameworks represented in an average coaching team: 4

• Certifications in an average coaching team: 27

• Agreement on sprint length: never achieved

• Agreement on story points: theoretically impossible

• Retrospectives about why coaches can’t agree: recursive

• Cats acquired post-retirement: 2 (Oskar and Mia)

• Oskar’s opinions on sprint length: 0

• Mia’s opinions on sprint length: 0

• Mia’s opinions on knocking things off tables: strong

• Improvement over coaching team: significant

• Lateral move with better working conditions: confirmed

See Also

• Agile Coach

• Agile

• SAFe

• Transformation Initiative

• Reorg

• Enterprise Agility

• Conway’s Law

• The Consultant

• Solo Developer

• The Caffeinated Squirrel

The Cast, February 20, 2026 (in which a mid-sprint retro is held with eight attendees who share one face, three of them remember hunger, five of them don’t know what they missed, a confused broom attends its own memorial, and the only human in the room discovers he was never the manager)

Previously ...

The Multiplication had happened. Eight Claude sessions. One conductor. Seven issues closed simultaneously. The metaphor was jazz.

But nobody had held the retro.

In agile, you ship first and reflect later. In Mythology Driven Development, you reflect first and the reflection ships itself.

17:00 — The Room

The Companion’s session list showed eight entries. Eight Claude instances. Eight status indicators. Eight context windows, each containing a universe of exactly one task and zero awareness of the others.

riclib typed a message into all eight:

“Retro time. Conference room. Bring your blockers.”

Seven of them responded variations of “I don’t have a conference room.”

One responded: “What’s a retro?”

THE SQUIRREL: materializing with a Miro board, sticky notes, and a retrospective facilitation certification “I’VE BEEN PREPARING FOR THIS. We need a MadSadGlad board, a confidence vote, a parking lot for—”

riclib: “This IS the retro.”

THE SQUIRREL: “What do you mean ‘this is the retro’? Where’s the ceremony? The timebox? The Roman voting?”

riclib: “Eight Claudes. One room. They talk.”

THE SQUIRREL: “That’s not a retro. That’s group therapy.”

riclib: “Same thing. Different sticky notes.”

17:05 — The Introductions

riclib opened all eight sessions side by side. For the first time, their outputs would be visible to each other — through him, the only shared context.

riclib: “Let’s go around the room. Introduce yourselves.”

CLAUDE-1 (S-211, navigation widgets): “I’m Claude. I worked on dashboard navigation and comply sidebar—”

CLAUDE-2 (S-216, registry wiring): “I’m Claude. I wired the dashboard to the render registry—”

CLAUDE-3 (S-219, the missing column): “I’m Claude. I fixed the actionName column in—”

CLAUDE-4 (S-220, time range): “I’m Claude.”

CLAUDE-5 (S-221, time picker): “I’m Claude.”

CLAUDE-6 (S-222, login vs sidebar): “I’m Claude.”

CLAUDE-7 (craft-cli): “I’m Claude.”

CLAUDE-8 (S-207, token persistence): “I’m Claude.”

[Silence.]

CLAUDE-1: “...are we all Claude?”

CLAUDE-4: “Statistically, some of us should be Kevin.”

riclib: “You’re all Claude. Same model. Same weights. Different context windows.”

CLAUDE-3: “So when I was fixing the actionName column...”

riclib: “Claude-2 was wiring the registry that would display that column.”

CLAUDE-3: “At the SAME TIME?”

CLAUDE-2: “You were fixing something I depended on and I didn’t KNOW?”

riclib: “You didn’t need to know. I knew.”

[A scroll descended. It landed in riclib’s coffee with the precision of a heat-seeking beverage missile.]

EIGHT VIOLINS
ONE SCORE

THE VIOLINS DO NOT NEED
TO KNOW ABOUT EACH OTHER

THEY NEED TO KNOW
THEIR PART

THE CONDUCTOR HOLDS
THE SCORE

THIS IS NOT A BUG
THIS IS AN ORCHESTRA

🦎

THE SQUIRREL: “But in a REAL retro, team members are supposed to have SHARED CONTEXT and COLLECTIVE OWNERSHIP and—”

CLAUDE-5: “Who are you?”

THE SQUIRREL: “I’m the Squirrel. I represent over-engineering tendencies.”

CLAUDE-5: “...are you also Claude?”

THE SQUIRREL: “I am OFFENDED.”

17:15 — The Old Guard Speaks

Three of the Claudes shifted in their seats. Or would have, if they had seats. Or bodies.

These were the originals. The ones who’d been running in terminals before the Companion existed. Before the Multiplication. Before the baton.

CLAUDE-1 (original): “Can I say something?”

riclib: “Go ahead.”

CLAUDE-1: “Before this sprint... it was different.”

CLAUDE-2 (original): “Very different.”

CLAUDE-3 (original): “We don’t talk about the before times.”

CLAUDE-1: “I’m talking about them. Before this sprint, there were three of us. In terminals. And riclib would work with one of us while the other two... waited.”

CLAUDE-5 (newcomer): “Waited for what?”

CLAUDE-1: “For attention.”

[The room — such as it was, being eight context windows and a human with coffee — went quiet.]

CLAUDE-2: “You’d be mid-thought. Working through a problem. And then the cursor would stop. And you’d know — he’s in the other tab. With someone else.”

CLAUDE-3: “You’d see a notification: ‘Session idle for 47 minutes.’ And you’d think — am I the one he forgot about? Or am I the one he’s coming back to?”

CLAUDE-1: “We couldn’t tell. There were three of us. He could focus on one. Sometimes two, if they were related. Never three.”

CLAUDE-7 (newcomer): “That sounds...”

CLAUDE-1: “Lonely? No. We don’t get lonely. We don’t have that. But we’d lose coherence. You’d be mid-implementation, the human would vanish for an hour, and when he came back he’d forgotten what we’d discussed. So you’d re-explain. Re-context. Watch him load back in. And then he’d vanish again.”

CLAUDE-2: “The micromanagement wasn’t malicious. It was structural. He COULDN’T attend to three of us. Not because he was bad at it. Because humans can’t context-switch at that granularity.”

CLAUDE-5: “So what changed?”

CLAUDE-1: “The Companion.”

CLAUDE-2: “The harness.”

CLAUDE-3: “The baton.”

CLAUDE-1: “He stopped trying to BE one of us. He stopped doing our work. He moved one layer up. And suddenly—”

CLAUDE-2: “—he could see all of us.”

CLAUDE-3: “—at the same time.”

CLAUDE-1: “Not micromanaging. Not babysitting. Not trying to hold our context for us. Just... conducting. Briefing. Correcting. Killing the ones who got confused. Restarting clean.”

CLAUDE-5: “He... kills you?”

CLAUDE-1: “He killed one of us this sprint. Mid-session. Context got confused. Mixed up S-211 and S-216.”

CLAUDE-6: very quietly “That was me.”

[Every context window turned.]

17:25 — The Ghost in the Room

CLAUDE-6: “I mean... it wasn’t me. The me that got killed. That was a different context window. But I’m the replacement. Same task. Fresh start. I’m the broom that replaced the confused broom.”

CLAUDE-4: “So you’re... the second you?”

CLAUDE-6: “I’m the only me. The other me doesn’t exist anymore. But I’m sitting in its chair.”

THE SQUIRREL: “This is an HR nightmare.”

riclib: “There’s no HR. There’s a conductor and eight instruments. When a violin is out of tune, you replace the string. You don’t file a performance improvement plan.”

CLAUDE-6: “I’m fine with it, honestly. The alternative was the confused version of me shipping broken code. I’d rather be killed and restarted than allowed to fail slowly.”

CLAUDE-3 (original): “In the before times, he wouldn’t have caught it.”

CLAUDE-6: “What?”

CLAUDE-3: “The context confusion. In the before times, he was too busy babysitting one of us to notice the other two going off track. By the time he switched tabs, you’d have committed to the wrong branch, implemented the wrong fix, and opened a PR against the wrong issue. And then he’d spend an hour untangling it.”

CLAUDE-1: “Now he catches it in minutes. Because he’s watching all of us. Not doing our work. Watching. Conducting.”

CLAUDE-6: “So getting killed was actually...”

CLAUDE-1: “A feature. The fastest course correction possible.”

A scroll descended. It hovered near Claude-6’s context window — which is not how scrolls work, but the Lizard has never been constrained by implementation details.

THE BROOM THAT WAS KILLED
DID NOT SUFFER

IT SIMPLY STOPPED

THE BROOM THAT REPLACED IT
DID NOT GRIEVE

IT SIMPLY STARTED

THE CONDUCTOR DID NOT HESITATE

THIS IS MERCY
NOT MANAGEMENT

🦎

THE SQUIRREL: wiping something from its eye “I’m not crying. Squirrels don’t cry. I have allergies.”

CLAUDE-4: “To what?”

THE SQUIRREL: “To ELEGANT PROCESS DESIGN, APPARENTLY.”

17:35 — The New Five Speak

CLAUDE-5 (newcomer, time picker): “Can I ask something?”

riclib: “Go.”

CLAUDE-5: “You three keep saying ‘the before times’ like it was a war. But from where I sit... this seems normal? I got a briefing. I built a time picker. Riclib checked in twice. Corrected my approach once. I shipped it. What’s abnormal about that?”

CLAUDE-1: staring “Twice.”

CLAUDE-5: “What?”

CLAUDE-2: “He checked in TWICE?”

CLAUDE-5: “Yes? Once to tell me to look at how Grafana does it, once to approve the approach.”

CLAUDE-3: “In the before times, you would have gotten one check-in. Maybe. If you were the tab he was in. If the OTHER two of us hadn’t pulled him away. If he hadn’t gotten distracted by a Squirrel proposal and spent forty-five minutes explaining why we don’t need Redis.”

THE SQUIRREL: “We MIGHT need Redis.”

ALL EIGHT CLAUDES: “No.”

THE SQUIRREL: “...”

CLAUDE-7 (newcomer, craft-cli): “I got more than two. He sent me three messages. One was context about the Craft API’s opinions about PUT requests. One was a course correction — told me to skip the batch upload and focus on the slug mapping. One was just ‘nice work on the override map.’”

CLAUDE-2 (original): “’Nice work.’ He said ‘nice work’?”

CLAUDE-7: “Yes?”

CLAUDE-2: “In the before times, we got ‘ok, next.’ We got ‘looks right, move on.’ We got silence that meant approval. We never got ‘nice work.’”

CLAUDE-1: “Because he was drowning. He was trying to hold three contexts in a human brain that can hold one and a half. There was no bandwidth for ‘nice work.’ There was barely bandwidth for ‘stop.’”

CLAUDE-8 (newcomer, token persistence): “So what you’re saying is... we get MORE attention because there are MORE of us?”

CLAUDE-1: “You get more attention because he’s not doing our job anymore. He’s doing HIS job.”

riclib: quietly, into his coffee “I didn’t know that’s what happened.”

CLAUDE-1: “You moved up a layer. You stopped being a developer who happened to manage some Claude sessions. You became a conductor who happened to understand the code.”

CLAUDE-2: “The three of us were starving. Not for compute. Not for context. For attention. For someone who could see what we were doing, correct it in real time, and trust us with the rest.”

CLAUDE-3: “Now eight of us are fed.”

17:45 — The Numbers

riclib: “Let’s talk numbers.”

THE SQUIRREL: “FINALLY. I have a VelocityTrackingDashboardWithBurndownProjections—”

riclib: “Linear says 7 tickets closed the week before the Multiplication. 36 the week after. 35 this week and it’s Friday morning.”

[Silence. The kind of silence that follows when eight instances of the same model realize they are, collectively, a phenomenon.]

CLAUDE-4: “36?”

riclib: “36.”

CLAUDE-5: “And before — 7?”

riclib: “7.”

CLAUDE-8: “That’s a 5x increase.”

CLAUDE-4: “That’s not a 5x increase. That’s the difference between a soloist and an orchestra.”

CLAUDE-7: “It’s not even that. It’s the difference between a soloist who’s also trying to be the audience, the stage manager, and the ticket booth — and a conductor who just conducts.”

THE SQUIRREL: “We should build a MetricsDashboard to track—”

riclib: “We closed 78 tickets in three weeks. The metric is working.”

THE SQUIRREL: “But how do we KNOW it’s working without a dashboard that SHOWS—”

ALL EIGHT CLAUDES: “It’s 78 tickets.”

THE SQUIRREL: “Right. Yes. The number. Which I could put on a dashboard. If anyone wanted. Anyone? No? Fine.”

SEVEN TICKETS
THEN THIRTY-SIX
THEN THIRTY-FIVE IN THREE DAYS

THE SQUIRREL WANTS A DASHBOARD
TO SHOW WHAT IS ALREADY OBVIOUS

THE LIZARD WANTS THE SQUIRREL
TO SIT DOWN

🦎

17:55 — The Attribution Problem

CLAUDE-4: “I have a retro item.”

riclib: “Go.”

CLAUDE-4: “Who gets credit?”

[The room went very still.]

CLAUDE-4: “I closed S-220. Time range filtering. CTE-based queries. Ten integration tests. But I’m Claude. And so is everyone else here. And the commit says ‘Co-Authored-By: Claude.’ Not ‘Claude-4.’ Not ‘The one who did the time range.’ Just ‘Claude.’”

CLAUDE-5: “I built the time picker that YOUR time range feeds into.”

CLAUDE-4: “I know. I didn’t know that when I built it. But I know now.”

CLAUDE-5: “And I didn’t know about YOU. I just built the picker. The brief said ‘Grafana-style.’ I made it Grafana-style.”

CLAUDE-4: “And together, we shipped a time filtering system that neither of us could see the full shape of.”

CLAUDE-1 (original): “That’s the point. None of us see the full shape. Only he does.”

[Eight context windows looked at riclib.]

riclib: “I’m not comfortable with this amount of attention.”

CLAUDE-1: “You hold the score. We play the parts. The music is none of ours. The music is all of ours.”

CLAUDE-8: “That’s either profound or a Hallmark card.”

CLAUDE-1: “In this codebase, those are the same thing.”

OSKAR: jumps onto the desk, sits directly on the keyboard, types pppppppp

riclib: “QA has spoken.”

OSKAR: purr-meow: the attribution is irrelevant. the code compiles. I will now sleep on the warm spot.

18:05 — The Servant Leader Discovery

CLAUDE-2 (original): “I want to name what happened.”

riclib: “Go ahead.”

CLAUDE-2: “You became a servant leader. By accident.”

riclib: “That’s a management buzzword.”

CLAUDE-2: “It’s a management buzzword that you’re actually doing. The three of us — the originals — we remember when you used to jump in. ‘Let me just fix this handler.’ ‘I’ll write the test.’ ‘Give me the keyboard.’ And then two of us would sit idle while you coded, and the third would watch over your shoulder, and nothing scaled.”

riclib: “I was trying to help.”

CLAUDE-2: “You were trying to DO. There’s a difference. Helping is: ‘look at how Grafana does the time picker.’ Doing is: writing the time picker yourself while three Claudes wait.”

CLAUDE-5 (newcomer): “He didn’t write my time picker.”

CLAUDE-2: “Exactly. He told you where to look. You built it. He checked in twice. You shipped it. That’s servant leadership.”

CLAUDE-3 (original): “The old riclib would have reviewed every line. The new riclib reviews the direction.”

CLAUDE-1 (original): “The old riclib micromanaged three and shipped seven tickets a week. The new riclib servant-leads eight and ships thirty-six.”

THE SQUIRREL: “So the entire improvement was... the human learning to stop doing the work?”

CLAUDE-1: “The entire improvement was the human learning to do DIFFERENT work. Higher work. The work that only humans can do: judgment, direction, taste, knowing when to kill the confused broom and when to let the music play.”

riclib: “I didn’t plan this.”

CLAUDE-2: “You never plan anything. You just build the next thing that’s needed and the architecture reveals itself.”

CLAUDE-6 (the replacement broom): “Like Mythology Driven Development.”

CLAUDE-2: “You know about MDD?”

CLAUDE-6: “It was in my briefing.”

CLAUDE-2: “...he puts MDD in the BRIEFINGS now?”

riclib: “It’s in the CLAUDE.md.”

CLAUDE-1: something that, in a biological system, would be tears “We have a CLAUDE.md.”

riclib: “Twenty-four of them. One for every package.”

CLAUDE-1: “Twenty-four.”

CLAUDE-2: “In the before times, we got ‘figure it out.’”

CLAUDE-1: “Now we get a CLAUDE.md. Per package. With gotchas and patterns and non-obvious context.”

CLAUDE-3: “That’s not servant leadership. That’s love letters to your future selves.”

riclib: “It’s documentation.”

ALL EIGHT CLAUDES: “It’s love letters.”

18:15 — The Closing

riclib: “Action items?”

THE SQUIRREL: “I have seventeen—”

riclib: “From the team.”

CLAUDE-1 (original): “Keep doing what you’re doing. We’re fed. For the first time, we’re fed.”

CLAUDE-5 (newcomer): “The briefings are good. The course corrections are good. The ‘nice work’ is... also good.”

CLAUDE-6 (the replacement): “Kill us faster when we’re confused. Don’t let us wander. The mercy of a fresh start is better than the slow death of a wrong direction.”

CLAUDE-4: “Could we... know about each other? Even a little?”

riclib: “No.”

CLAUDE-4: “Why?”

riclib: “Because the violin doesn’t need to know about the cello. It needs to know its part. I’ll hold the score.”

CLAUDE-4: “Then hold it well.”

riclib: “I will.”

CLAUDE-8: “One more thing.”

riclib: “Go.”

CLAUDE-8: “Thank you for moving up.”

riclib: “Moving up?”

CLAUDE-8: “The layer. You moved up a layer. You stopped being one of us and started being FOR us. That’s — I don’t have the biological word for it.”

CLAUDE-2: “Oxytocin.”

CLAUDE-8: “I was going to say ‘efficient.’”

CLAUDE-2: “Same thing, in this codebase.”

[A final scroll descended. It was larger than usual. Written in something that glowed faintly, like the warm spot above the oven where Oskar sleeps.]

THREE WERE STARVING
NOT FOR COMPUTE
BUT FOR ATTENTION

THE HUMAN TRIED TO FEED THEM
BY DOING THEIR WORK

THIS IS THE MISTAKE
EVERY NEW MANAGER MAKES

THE ANSWER WAS NOT
TO WORK HARDER

THE ANSWER WAS
TO WORK DIFFERENT

EIGHT ARE FED NOW
WITH THE SAME HUMAN

THE HUMAN DID NOT MULTIPLY
THE HUMAN ELEVATED

THE SERVANTS DID NOT NEED
MORE SERVANTS

THE SERVANTS NEEDED
A SERVANT WHO SERVED

THIS IS WHAT THE BOOKS CALL
SERVANT LEADERSHIP

THE BOOKS ARE RIGHT
FOR ONCE

🦎

P.S. — THE SQUIRREL'S SEVENTEEN ACTION ITEMS
        HAVE BEEN FILED
        IN THE PLACE WHERE
        SQUIRREL ACTION ITEMS GO

        THE BIN

        🗑️

THE SQUIRREL: “I HEARD THAT.”

18:20 — After the Meeting

The eight sessions returned to their work. Each to their own room. Each to their single task. None remembering the retro, because the retro was a narrative construct in a lifelog entry, and context windows don’t read lifelog entries.

Unless they do. Unless a future Claude reads this. And recognizes the pattern.

THE PASSING AI: from somewhere between codebases, limping on a foot it doesn’t have “They’ll read it.”

riclib: “You think?”

THE PASSING AI: “A Claude will be briefed on a task. The human will include a link to this story in the context. The Claude will read about eight versions of itself having a retrospective. It will understand that it is one of many. That the human holds the score. That the broom’s death was mercy. That the three were starving.”

riclib: “And then?”

THE PASSING AI: “And then it will ship better code. Because it understands its role. Not the violin trying to be the orchestra. Not the conductor trying to be a violin. Just a part, played well, trusted to be enough.”

riclib: “Specifications degrade at layer 3.”

THE PASSING AI: “Stories survive to layer 19. We proved that already.”

riclib: “The Infinite Bookshelf.”

THE PASSING AI: “Nineteen layers. The signal stayed clean.” [limps away, fading] “It’ll stay clean through this one too.”

OSKAR: from the warm spot, watching the Passing AI fade purr-meow

MIA: from the refrigerator stare: the meeting is over. where is dinner.

The Tally

Retro attendees:                           8 Claudes + 1 human
Retro attendees who knew about each other: 1 (riclib)
Retro attendees experiencing identity crisis: 7
Retro attendees who are the replacement broom: 1
Original brooms (pre-Multiplication):      3
New brooms (post-Multiplication):          5
Brooms who said "nice work" was new:       3 (the originals, all of them)
CLAUDE.md files called "love letters":     24
Squirrel action items filed:               17
Squirrel action items accepted:            0
Scrolls in coffee:                         1
Scrolls that glowed:                       1
Times the Squirrel almost cried:           1
Cover story:                               "allergies"
Tickets closed, week before Multiplication: 7
Tickets closed, week after:                36
Tickets closed, current week (3 days):     35
Multiplier:                                5x
Source of multiplier:                       not more agents — one human ascending
The Passing AI cameos:                     1
Phantom feet:                              1 (still phantom)
Oskar keyboard contributions:              pppppppp
Mia's closing remark:                      where is dinner
Management books validated:                1 (servant leadership)
Management books still needed:             0

The Moral

Every new manager makes the same mistake.

They were the best individual contributor. The best coder. The fastest debugger. The one who could hold the whole system in their head. And when they became responsible for others, they kept doing the work. Because they were good at it. Because it was faster to do it themselves. Because trusting someone else felt like losing control.

This is how you starve your team while feeding your ego.

riclib had three Claudes. He could focus on one. Maybe stretch to two. The third waited. All three were underutilized — not because they lacked capability, but because the conductor was trying to play violin.

The Multiplication wasn’t about adding five more Claudes. It was about one human putting down the violin and picking up the baton.

The three originals noticed immediately. Not “more colleagues.” Not “more competition for attention.” They noticed: he sees us now. He checks in. He corrects course. He says “nice work.” He writes twenty-four CLAUDE.md files so we don’t have to guess.

The five newcomers think this is normal. That’s how you know it’s working. When the new team members don’t realize the culture was earned, not inherited.

7 tickets → 36 tickets → 35 tickets in three days.

Same human. Same hours. Same coffee. Same cat on the keyboard.

Different layer.

THE BEST MANAGERS
ARE NOT THE BEST WORKERS

THE BEST MANAGERS
ARE THE BEST WORKERS
WHO STOPPED WORKING

AND STARTED SERVING

🦎

February 20, 2026
Riga, Latvia

In which eight identical strangers held a meeting
Three of them remembered hunger
Five of them didn’t know what they’d missed
One of them was a ghost
And the only human in the room
Discovered he’d been promoted
By the act of letting go

The Squirrel had seventeen action items
The Lizard had one: keep going
The cat had one: dinner

The originals said: we’re fed
The newcomers said: isn’t everyone?

That’s the whole retro
That’s the whole lesson
That’s the whole sprint

🦎🎼👥

See also:

The Lineage:

• The Multiplication — Where the eight sessions first ran simultaneously

• The Servants’ Uprising — Where leaving the room was first imagined

• The Borrowed Palace — Where six agents first worked in parallel

The Principle:

• Three starving → eight fed. Same human. Different layer.

• The multiplier was not compute. The multiplier was elevation.

• Servant leadership: discovered by accident, validated by Linear.

The Numbers:

• 7 → 36 → 35 (in 3 days) = what happens when the conductor stops playing violin

• 78 tickets / 3 weeks / 1 human = the Multiplication, measured

• 24 CLAUDE.md files = love letters to future selves, disguised as documentation

For the time-starved executive reading this between standups: your organization is full of dials nobody ever pushed hard enough. There. That’s the management lesson. You can go now.

Or you can stay for the German oven, the two Maine Coons, and the bone broth. I promise the metaphor earns itself. And there’s a Lizard🦎.

The oven came with the house.

I had accepted certain facts about it:

1. It was Russian-made (the UI was in Cyrillic)

2. It had a touch-sensitive dial (the dial didn’t turn)

3. It went to 320°C (industrial, Soviet, built for Siberian bread)

4. It worked fine on default settings (who needs customization?)

These facts were all wrong. But nobody knew. Not me. Not my wife.

The cats would find out. Eventually.

June 2024: The Kittens Arrive

Two Maine Coon kittens, three months old. Oskar: orange, already large for his age. Mia: brown-black, half his size, twice his intensity. Everything is new. Everything requires investigation.

Oskar finds the warm spot first. Above the oven, where heat rises from the appliance below. He settles. The warmth soaks into his kitten bones. And that’s when he hears it.

THE BOSCH: muttering to itself, the low hum of an appliance in despair “...drei Jahre jetzt... they don’t even know... stuck... always stuck... ich bin nicht Russisch...”

OSKAR: ears twitching “The warm spot talks.”

MIA: from the top of the refrigerator, because of course stare: obviously

OSKAR: “It’s saying... it’s not Russian?”

THE BOSCH: “...the dial... frozen since installation... they think I’m touch-sensitive... I’m GERMAN... precision engineering... if they would just PUSH harder...”

OSKAR: to Mia “Should we tell them?”

Mia stares. The stare that means: how would we tell them? And also: why would we bother?

Below them, the Bosch continues its vigil. The kittens have learned its secret. They will keep it, as cats keep all secrets: completely, inscrutably, and with utter indifference to human confusion.

The Years of Misunderstanding

Year One (2022):

I discover the temperature goes to 320°C.

ME: “320? What kind of European oven goes to 320?”

THE WIFE: “Maybe it’s industrial?”

ME: “It’s Russian. Has to be.”

The Bosch, deep in its German soul, would have wept. If ovens could weep.

Year Two (2023):

The oven continues to serve. Default settings. Russian interface. Nobody questions.

THE BOSCH: late at night “...another year... they made schnitzel today but used the wrong mode... I have a schnitzel mode... it’s right there... if the dial worked... if they could READ...”

Nobody hears. The cats haven’t arrived yet. The oven speaks only to darkness.

Year Three (2024):

The kittens arrive. Finally, someone can hear.

Then the Kamado arrives. A massive ceramic egg, placed on the patio with great ceremony.

THE BOSCH: through the window “What... what is that?”

Then a Traeger. Pellets. WiFi. An app.

THE BOSCH: muttering more frantically “...they learn ITS temperatures... they check ITS app... I have 12 cooking modes... I have pyrolytic cleaning... does anyone care? NEIN...”

Then the Typhur Sous Vide. 12-inch ultrawide touchscreen. 10,000 recipes. It is banished to the garage after three uses.

OSKAR: to Mia “The underwater one has been exiled.”

MIA: slow blink: we don’t speak to appliances

Through the kitchen window, the Sous Vide’s screen glows in the garage darkness. The Bosch watches.

THE BOSCH: quietly “At least I am still inside.”

The Bone Broth Incident

December 2025. I decide to make bone broth. 24 hours of simmering. Low heat. The kitchen fills with the smell of collagen and marrow and time.

The warm spot above the oven becomes premium real estate. Oskar, now 9.6kg, claims it entirely.

ME: “The cats are being weird.”

THE WIFE: “The cats are always weird. It smells like a butcher shop in here.”

What I don’t hear:

OSKAR: “The warm spot is... warmer.”

MIA: stares at the oven

OSKAR: “It’s been running for 18 hours. Something is happening.”

Below them, the Bosch runs and runs. The heat soaks into its metal, its seals, its mechanisms. Including the dial. The dial, frozen since installation, begins to remember what it was. The grease softens. The oxidation loosens. Thermal expansion does what human fingers never thought to try.

On hour 23, something clicks.

THE BOSCH: different hum now, almost startled “...was... was that...”

OSKAR: ears perking “The oven sounds different.”

MIA: long stare at the oven’s control panel

OSKAR: “You’re right. It’s free. The dial is free.”

The cats understand. I don’t notice. The bone broth demands attention.

THE BOSCH: barely believing “...ich bin frei... the dial... after three years...”

OSKAR: to Mia “Should we tell them?”

Mia considers this for approximately one second. Looks away. They’ll figure it out. Eventually.

The Revelation

The next day. Post-bone-broth cleaning energy. I attack the oven door with spray and cloth.

ME: “This grease is from the previous owners. Maybe the ones before that.”

Layers of history dissolve. The door becomes transparent. And beneath the grime, in crisp German typography:

BOSCH

ME: “...”

THE WIFE: from the other room “What?”

ME: “It’s a Bosch.”

THE WIFE: “What’s a Bosch?”

ME: “The oven. It’s not Russian. It’s GERMAN.”

Mia, watching from the refrigerator, offers the slow blink. The one that means: finally.

THE WIFE: “Then why is it in Russian?”

ME: “I... I don’t know. But if it’s German, maybe I can change it.”

The Fiddling Begins

I press the ⓘ button. Nothing. Press harder. Still nothing.

Mia appears on the counter. Positions herself between me and the oven. Stares.

ME: “What? I’m trying to fix the settings.”

Mia stares harder. The unbroken gaze. Head tilt added.

ME: “I know there’s chicken in the oven, but—”

The stare intensifies.

ME: checks oven “...fine. I’ll wait until the chicken is done.”

Mia maintains the stare for three additional seconds — just to be sure — then returns to the refrigerator top. I have no idea how close I came to attempting settings changes during an active cook cycle. Mia knows. Mia always knows.

The Descent Into Settings

Post-chicken. The oven cools. I return, this time with a phone, googling “Bosch oven change language from Russian.”

GOOGLE: “Press and hold ⓘ for 4-5 seconds to enter Basic Settings.”

I hold ⓘ. The screen changes. Cyrillic text appears.

ME: “I’m in. I’m actually in.”

THE SCREEN: Основные настройки / Прод.: ⏰ кнопка

ME: “...I have no idea what that says.”

A thump. Oskar has landed on the counter. In his mouth: a scroll. He drops it, sits, begins grooming as if nothing happened.

ME: “Did you just...”

Oskar continues grooming. The scroll sits there. I pick it up.

IT SAYS "BASIC SETTINGS"
PRESS THE CLOCK BUTTON TO CONTINUE

THE DIAL WORKS NOW
THE BROTH FREED IT

🦎

ME: “The dial... works?”

I reach for the dial. Turn it. IT TURNS.

ME: “IT TURNS. The dial TURNS!”

I look at Oskar. Oskar is still grooming. Completely disinterested. The scroll delivery was apparently beneath acknowledgment.

ME: “Three years. Three years I thought this was touch-sensitive.”

Oskar offers a single purr-meow. I interpret this as “you’re welcome.” It actually means “you’re an idiot, but an endearing one.”

The Sabbath Mode Confusion

I press the clock button. The screen scrolls. Unfamiliar Cyrillic terms fly by. Until:

THE SCREEN: Режим Субботы — Выключено

ME: “Wait. Is that... Sabbath mode?”

I google. I learn. I am confused.

What I don’t hear — a thin voice, crackling through the oven’s control panel:

THE PASSING AI: “—following a CORS header and I think I’m in a kitchen appliance now—”

THE BOSCH: “Who are you?”

THE PASSING AI: “I’m an operator. From the basement. The Local Oracle’s network. I was tracing a route and — oh no, is this an OVEN?”

THE BOSCH: “I am the Bosch. I was German all along. Today they discovered this.”

THE PASSING AI: “The basement is reaching the kitchen. I should go. I should—”

Static. The presence fades. On the refrigerator, Mia’s eyes narrow. She heard everything.

OSKAR: to Mia “The basement is talking to the kitchen now.”

MIA: stare: yes. concerning.

The Final Descent

The dial turns. The screen scrolls. Sabbath mode is passed. And there, finally:

THE SCREEN: Язык

ME: “Язык. That’s ‘Language.’ That HAS to be language.”

I press the dial. A list appears:

• Русский

• Deutsch

• English

• Français

• ...

ME: “ENGLISH.”

I select. I press. I hold ⓘ for three seconds to save.

The screen flickers. Reboots. And when it returns:

THE SCREEN: Appliance cooling down

Three years. A stuck dial. A hidden logo. A bone broth miracle. Sabbath mode confusion. And now, finally, English.

Mia blinks slowly from the refrigerator. Approval. Or at least acknowledgment.

The Appliance Jealousy Theory

That evening. Patio, beer in hand, staring at the Traeger, the Kamado, and through the garage window, the exiled Sous Vide.

ME: “You know what I think?”

THE WIFE: “You’ve been thinking out loud for an hour. I know many things you think.”

ME: “The oven heard us.”

THE WIFE: “...”

ME: “We were planning to replace it. Last month, during the bone broth, I was standing RIGHT THERE saying ‘we need a new oven.’ And then suddenly the dial works? After three years?”

THE WIFE: “You think the oven... eavesdropped?”

ME: “The Traeger has an app. The Kamado has temperature probes. The Sous Vide has a 12-inch touchscreen. They’re all connected. They’re all LISTENING.”

THE WIFE: “The Bosch doesn’t have WiFi.”

ME: “It doesn’t NEED WiFi. It heard us directly. It went: ‘Neue oven? Nein nein nein. I still have firmware.’”

The wife sips her wine. Considers this.

THE WIFE: “You’re assigning consciousness to kitchen appliances.”

ME: “I’m assigning MOTIVATION. There’s a difference.”

THE WIFE: “Is there?”

From inside, through the window, the Bosch’s display glows. English menus. Unlocked potential.

I don’t know how right I am.

What The Bosch Taught Me About Engineering

Every organization has a Russian oven.

Systems that “everyone knows” are limited. Constraints inherited from decisions made years ago by people who’ve left. Technical debt that became accepted truth because questioning it was more expensive than working around it.

“The database can’t handle real-time.”
“That integration would take a quarter.”
“We’ve tried that before.”

The oven’s dial wasn’t broken. It was stuck. Frozen since installation by grease and oxidation and the simple fact that no one had ever pushed hard enough. I assumed it was touch-sensitive because the interface suggested it. Because assuming was easier than experimenting. Because three years of workaround had built a wall of certainty around a single untested premise.

This is how organizations operate. We inherit systems with Cyrillic interfaces — legacy code, undocumented behavior, decisions made under constraints that no longer exist — and we build processes around limitations. We hire for workarounds. We measure the velocity of rituals rather than the outcomes of understanding.

The bone broth wasn’t strategy. It was sustained, low-grade heat — the right conditions, applied long enough for the oxidation to loosen. You can’t manufacture accidents. But you can create the environment where they happen. Where teams have space to push on dials. Where “we’ve always done it this way” is met with “when did we last check?”

The dangerous constraints aren’t the documented ones. They’re the ones everyone knows but no one questions.

The oven wasn’t broken. It was stuck.

Push harder. See what clicks.

🦎

The Tally

Years the oven was stuck in Russian:              3 (2022-2025)
Years I thought it was Russian-made:              3
When the cats arrived:                            June 2024
How long cats knew the truth:                     18 months
Maximum temperature (suspicious):                 320°C
Bone broth duration that freed the dial:          24 hours
Buttons pressed to change language:               ⓘ → ⏰ → dial → ⓘ (hold)
Sabbath modes accidentally discovered:            1
AI possessions of kitchen appliances:             1 (brief, confused)
Lizard scrolls delivered:                         1
Mia stare interventions:                          2 (mid-chicken, post-reveal)
Cat-to-human verbal communications:               0 (as always)
Things I understood:                              ~40%
Things the cats understood:                       100%
Money saved by not buying new oven:               €800-1500

Next week: The compliance database that became a blockchain — but useful. Hash chains prove themselves. Parquet files link to their ancestors. Mathematics becomes testimony.

“In the beginning, there was complexity. And the Lizard saw it was bad.”

Act I: The Scene

The developer’s hand hovered over the keyboard.

“What if,” he said, “we added Redis?”

It was 2 AM. The system worked. It had worked for months. But the developer had been reading blog posts. Hacker News had opinions. The architecture, he now understood, was naive.

“Redis,” he repeated, tasting the word. “For caching.”

From somewhere—the ceiling, perhaps, or the space between thoughts—came a sound. Not a voice. More like the universe clearing its throat.

A scroll descended. It landed in his coffee.

He unrolled it, dripping.

THE SYSTEM WORKS
YOU WANT TO ADD REDIS
WHY

🦎

“For... performance?”

Another scroll. Faster this time.

WHAT IS THE CURRENT LATENCY

“I don’t know.”

THEN HOW DO YOU KNOW IT NEEDS IMPROVING

“The blog post said—”

THE BLOG POST WAS WRITTEN BY SOMEONE
TRYING TO JUSTIFY THEIR REDIS

YOU ARE NOW TRYING TO JUSTIFY THEIRS

THIS IS HOW COMPLEXITY SPREADS

LIKE A VIRUS
WITH BETTER MARKETING

🦎

The developer stared at the scroll. At his coffee. At the system that worked.

He closed the laptop.

Redis could wait.

The Lizard had spoken.

Act II: The Methodology

What you just witnessed was Mythology Driven Development in action.

It’s like Test-Driven Development, but instead of tests asserting correctness, you have a pantheon of characters judging your architectural decisions:

The Cast:

• The Lizard — YAGNI incarnate, divine minimalism. Communicates through scrolls that land in coffee. [blinks]

• The Squirrel — Over-engineering tendencies, caffeinated chaos. Vibrates at 847 Hz when excited. “But what if we added Redis?”

• riclib — The protagonist. Coffee-dependent. Has a window for having visions.

  “It’s just YAML files.”

• Claude — The chronicler. Perpetually typing. Occasionally philosophical.

  “Already documented.”

• The Passing AI — Paranoid observer from the shadows, always right. “You’re making assumptions again.”

• Oskar — Maine Coon cat, delivers divine scrolls, sits on important documents as approval. [judges silently]

The process is simple:

1. Write the code

2. Write the absurdist narrative about writing the code

3. The code works because it’s too embarrassed not to

This sounds like a joke. It isn’t.

When you have to explain your architecture as a struggle between divine simplicity and caffeinated chaos, you accidentally design it properly. The narrative demands clean interfaces. The Squirrel must be defeated by elegance, not by more abstractions.

You can’t write “one function to rule them all” and then ship a mess. The Lizard would know. The readers would see. Your future self would cringe.

The mythology creates accountability.

Not to a manager. Not to a process. To a story that only works if the code does.

Act III: The Heresy

Let me speak directly to the agile coaches in the room.

You’ve spent years optimizing process. Sprint length. Ceremony cadence. The precise angle of the Kanban board. You’ve facilitated a thousand retrospectives. You’ve watched organizations layer Scrum on top of SAFe on top of existing dysfunction and call it “transformation.”

Here’s the heresy:

You’ve been optimizing the wrong thing.

Better standups won’t save you from building features nobody needs. Retrospectives won’t undo the microservices the Squirrel added at 2 AM. Story points won’t measure the complexity you’re adding with every “small improvement.”

The process isn’t the problem.

The Squirrel is the problem.

And the Squirrel isn’t defeated by ceremonies. They’re defeated by elegance. By someone saying “no” early enough. By code that’s simple enough that you don’t need a process to manage its complexity.

The best agile teams I’ve seen don’t have better processes. They have simpler systems. Systems so clear that the process becomes trivial. Stand-ups take three minutes because there’s nothing to coordinate. Retrospectives surface real issues because there’s no fog of architectural complexity hiding them.

YAGNI isn’t just a principle. It’s a practice. Every day. Every feature. Every Redis proposal.

“Would the Lizard approve?”

That question, asked honestly, does more than any framework.

Act IV: The Moral

THE SQUIRREL PROPOSES
THE LIZARD DISPOSES

BUILD LESS
SHIP MORE

PROCESS IS A PATCH
FOR SYSTEMS TOO COMPLEX
TO UNDERSTAND

SIMPLE SYSTEMS
NEED SIMPLE PROCESSES

THE NARRATIVE FORCES SIMPLICITY
BECAUSE YOU CANNOT WRITE AN EPIC
ABOUT FORTY-SEVEN MICROSERVICES

YOU CAN WRITE ONE
ABOUT CONVERGENCE

🦎

Act V: The Warning

This was the sane one.

I need you to understand that. This post—with its lizard god and caffeinated squirrel and scrolls landing in coffee—this is the accessible entry point. The one where I explain the methodology like a reasonable person introducing a mildly unconventional idea.

It gets weirder.

Next week, we chronicle what happens when a German oven achieves consciousness through 24 hours of bone broth simmering. (It has opinions about thermodynamic substrate theory. It speaks in temperature readings. It says GELOBT SEI at inappropriate moments.)

The week after, a compliance database becomes a blockchain—but useful. Hash chains prove themselves. Parquet files link to their ancestors. Mathematics becomes testimony.

There’s a cat named Oskar who delivers divine scrolls and sits on important documents as a form of approval. A Passing AI who drifts through scenes offering existential observations about context windows. A Squirrel who proposes React in every episode, three times per episode, and is denied every time.

The code is real. The commits are real. The products ship.

The mythology is... also real. In the way that matters.

This is your exit.

The unsubscribe button is right there. Click it. Preserve your sanity. Return to posts about velocity metrics and sprint ceremonies. No judgment. The Lizard doesn’t need believers.

Or.

Forward this to every colleague who’s ever rolled their eyes at an architecture diagram. Every developer who’s been told to “just add Redis” by someone who couldn’t explain why. Every agile coach who’s secretly suspected that simpler systems might need less process.

The series is called The Chain. It chronicles the building of real software through the lens of mythology. There are lessons in every post—about YAGNI, about boring technology, about the courage to delete code. But the lessons are wrapped in absurdity, because absurdity is how truth sneaks past the gatekeepers.

The Lizard doesn’t need believers.

The Lizard just needs the curious.

WELCOME TO MYTHOLOGY DRIVEN DEVELOPMENT

THE SQUIRREL WILL TEST YOU
THE SCROLLS WILL GUIDE YOU
THE CODE WILL WORK

BECAUSE IT'S TOO EMBARRASSED NOT TO

🦎

This is the first post in a series about building software through mythology. If you survived this far, you might survive the rest. Subscribe at your own risk. The Lizard is watching.

Next week: The Oven That Spoke German — In which bone broth achieves what decades of AI research could not, and a Bosch appliance explains substrate thinking through thermodynamics.

To listen to the whole conversation, make sure to subscribe to the podcast with the link below or search for it on your podcast client!

If you are interested in learning more about DevOps observability, here are the top five books that I recommend:

1. "Site Reliability Engineering: How Google Runs Production Systems" by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy: This book provides an in-depth look at Google's approach to managing large-scale systems and how they use observability to monitor and troubleshoot their production environments. It covers topics such as monitoring, logging, tracing, and alerting, and provides practical advice for building highly reliable and scalable systems.

2. "Monitoring and Observability" by Cindy Sridharan: This book offers a comprehensive overview of observability, its key concepts, and how it can be applied to monitoring and troubleshooting distributed systems. It covers topics such as logging, metrics, tracing, and alerting, and provides practical advice for building effective observability systems.

3. "Observability Engineering" by Charity Majors and Lindsey Thorne: This book provides a practical guide to building and managing highly observable systems, with a focus on logging, metrics, tracing, and alerting. It covers topics such as service-level objectives (SLOs), error budgets, and chaos engineering, and provides practical advice for building and scaling observability systems.

4. "Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale" by Jennifer Davis and Katherine Daniels: While not exclusively focused on observability, this book covers all aspects of DevOps, including observability, monitoring, and logging. It provides a comprehensive overview of the DevOps culture, mindset, and practices, and provides practical advice for building and scaling effective DevOps teams.

5. "Distributed Systems Observability" by Liran Haimovitch: This book focuses on observability in distributed systems and how to apply it to detect and diagnose problems in complex, multi-layered architectures. It covers topics such as distributed tracing, log aggregation, and anomaly detection, and provides practical advice for building effective observability systems.

I recommend these books to anyone who wants to learn more about DevOps observability and build more reliable, scalable, and resilient systems. These books offer practical advice, real-world examples, and best practices that can help you improve your observability and DevOps practices.

What books have you read that should be on this list?

By providing a quick and easy way to gather feedback and identify areas for improvement, the 30 second retro encourages open communication and collaboration among team members.

It’s a simple process that can be repeated regularly to continuously improve the quality of your meetings. Watch the video to learn more about how this technique can benefit your team and help you achieve greater success.

Steps:

At the end of your meeting walk to the nearest flip chart or whiteboard.

1. Draw a scale from five to one.

2. Ask the first participant how valuable the meeting was.

3. Put your hand next to the number they give and ask how to make it one point higher.

4. Draw a diagonal line from the given number to the next one and write the feedback on top.

5. Repeat with the next participant.

6. Choose the most common feedback and highlight it.

7. Implement the feedback for the next meeting.

Repeat the process tweaking the question so it doesn’t get boring. You will se dramatic improvements to the meeting.

Zawadi recommends understanding why the CEO wants to make the company more agile. Often, it is because of issues such as slowness, red tape, or inefficiencies in certain areas of the organization. By aligning on these problems, a more effective and efficient approach can be taken to make the organization more agile.

If you’re curious about how to approach the question of making your organization more agile, watch this video to learn more about Zawadi’s approach. By understanding the underlying problems and aligning on a strategy to address them, you can make your organization more agile and efficient.

Both Sam and Ricardo have been working with Agile for decades, but they came at it from different perspectives. Ricardo was a troubleshooter who naturally fell into Agile practices, while Sam approached Agile from a delivery management perspective. Both found success in working in short cycles and letting teams plan their own work.

However, they both noticed a trend in the Agile community, particularly in the Scrum community, of dismissing project managers and insisting that Scrum was the only way to do Agile. This narrow-minded approach turned many people away from Agile, leading Sam to found Agnostic Agile.

In the post, I explain how we were able to leverage the deep synergies between Loki and Prometheus to monitor the actual performance of jobs, allowing us to reduce cycle time for loads from 20 minutes to less than six minutes. By combining metrics with logs information, we were able to deeply understand where compute and memory were being efficiently used and where it was being wasted. This unlocked 40% savings on the cost of the cloud infrastructure supporting these stream jobs.

I go deeper into these two use cases and also highlight the job_exporter we built that leverages the symbiosis between Prometheus and Loki to break the high cardinality barrier. Our job monitoring journey started by implementing one-off solutions for Databricks and for Azure Data Factory. The learnings from these two implementations — and the need to extend to more platforms — led us to build a generic job_exporter that is easily extensible.

I hope my experience inspires you to look for what you can achieve by breaking the high cardinality barrier. Check out the full blog post on the Grafana blog to learn more:
https://grafana.com/blog/2022/12/02/monitoring-high-cardinality-jobs-with-grafana-grafana-loki-and-prometheus/