A work of speculative fiction grounded in historical research and Lean-Agile practice. All team members, company names, and ticket IDs are invented. Benjamin Franklin is not.

“In this world nothing can be said to be certain, except death and taxes.” — Benjamin Franklin, 1789

“Cycle time is the distance between the moment a customer asks for something and the moment they receive it. Reduce cycle time, and you reduce everything that matters.” — David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, 2010

Prologue: The Question#

Benjamin Franklin had always believed that the right question, posed at the right moment, did more useful work than any answer. He had written this conviction into the operating system of his own life in 1726, at age twenty, when he committed to beginning each morning with a single interrogation of his intentions: What good shall I do this day? And to ending each evening with a complementary accounting: What good have I done today?

The questions were not decorative. They were a mechanism — a feedback loop embedded in daily practice, designed to produce information that willpower alone could not manufacture. In the gap between the morning’s aspiration and the evening’s honest reckoning, Franklin found the only reliable instrument for character improvement: data.

It is a matter of some historical curiosity, then, that the principles he developed in a Philadelphia print shop in the early 18th century — his obsession with limiting work to what could actually be completed, his insistence on tracking failures rather than celebrating successes, his structuring of inquiry into repeating cycles with explicit cadences — map with uncanny precision onto a management methodology that would not be named until 2007, when a software consultant named David J. Anderson, standing at a whiteboard at Corbis Corporation in Seattle, first articulated what he called the Kanban Method.

What follows is a thought experiment: one week in which these two traditions meet in the most appropriate setting imaginable — a software engineering team in 2026, drowning in work from multiple product portfolios, desperate for a system that could make their chaos legible.

Franklin, as we shall see, would have had some thoughts.

Monday: Arrival and the Right-to-Left Walk#

He arrived, as he always arrived, before anyone else.

The Junto Health engineering floor occupied the fourth story of a building in Philadelphia, Pennsylvania — open-plan, exposed ductwork, the usual signifiers of a company that wanted its employees to think of themselves as creative. By six forty-five in the morning, the room held only the hum of a server rack somewhere behind a glass wall, the blue glow of monitors in screensaver mode, and Benjamin Franklin, in a grey linen coat that looked neither period-appropriate nor particularly modern, standing in front of a Jira board projected on a television screen the size of a dining table.

He had been studying it for eleven minutes.

The board was, by any reasonable measure, a disaster. Forty-three tickets occupied the columns labeled In Progress and In Review. The Done column contained seven tickets for the week thus far — it was Monday, so those had presumably been completed the previous Friday. The To Do column held an uncountable number of items in three different colors: blue for the Clinical Workflow portfolio, green for Member Engagement, and yellow for Core Platform. Somewhere a fourth color — red — appeared on three tickets, and these bore a label that read EXPEDITE.

Franklin produced a small notebook from his coat pocket. He wrote, in a neat hand: 43 items in flight. 3 expedite. 7 done. Ratio of started to finished: roughly 6:1. This is not industry. This is appetite without digestion.

The team began arriving at nine. By nine-fifteen, twelve engineers had settled into the standup — standing, as the practice required, in a loose semicircle before the board. Franklin stood to one side, introduced by Priya, the engineering manager, as “a consultant in flow-based methodology.” Several engineers glanced at his coat. None commented.

Priya moved to the board and began the standup from left to right — the natural reading direction, starting with the To Do column and moving through In Progress and In Review toward Done.

Franklin cleared his throat.

“Forgive the interruption,” he said. “But may I suggest we begin at the other end?”

Priya looked at him. “From Done?”

“From Done.” He moved to the rightmost column, where the seven completed tickets sat. “The purpose of this exercise, as I understand it, is to facilitate the completion of work. If we begin on the left, we are rehearsing our intentions. If we begin on the right, we are asking: what is nearest the finish line? What can we help across it today?”

There was a short silence. Then Keiko, a senior engineer who had been with the team for four years, said, “That’s actually the right way to do it. We’ve just never done it that way.”

It is a small change — right to left instead of left to right — but it encodes a philosophy. When a standup begins with the rightmost column, the question it implicitly poses to every team member is: what stands between this nearly-finished thing and the customer who needs it? When it begins with the leftmost column, the implicit question is: what are we starting next? The first question produces coordination. The second produces context switching, which is the enemy of flow.

Franklin knew nothing, formally, of context switching. But he had observed its mechanism in his print shop. A compositor who paused a galley mid-setting to begin a new one produced not two half-galleys efficiently but two half-galleys slowly — the restart cost, the re-orientation, the lost momentum, were invisible losses that the ledger never captured. He had written, with characteristic economy, in Poor Richard’s Almanack: “Lost time is never found again.” What he meant, had he been writing for a 2026 audience, was: every context switch costs more than you think, and you never get that cost back.

The standup took twenty-two minutes. Of those, eighteen were spent on the three expedite tickets, which were blocking two other engineers and had apparently been in that state for three days. Franklin asked, at the end, a single question: “Who is responsible for removing the obstruction from each of these three items?”

Silence. Then: “No one specifically.”

“Then,” Franklin said, “each of these items will remain blocked until the universe intervenes, which is to say, indefinitely.” He wrote something in his notebook. “We shall discuss this tomorrow.”

Tuesday: Temperance and the Replenishment Meeting#

Franklin’s first virtue was Temperance: eat not to dullness, drink not to elevation. He had placed it first deliberately, not because he considered gluttony the worst vice, but because it was the foundational virtue — the one that made the practice of all the others possible. A man who could not moderate his appetite, he reasoned, lacked the self-discipline to moderate anything.

He thought about Temperance on Tuesday morning while reviewing the upcoming replenishment meeting — the intake session in which new work was nominated to enter the active queue. In Kanban, replenishment replaces what sprint-based teams call sprint planning. The difference is not merely ceremonial. Sprint planning asks: what will we commit to completing in the next two weeks? Replenishment asks: what capacity do we currently have, and what is the highest-value item we could pull into it? Sprint planning creates a batch commitment. Replenishment creates a pull signal.

The Junto team, which had been running a sprint-based process until six months ago, still had the instincts of a sprint team. At nine-thirty, three product managers arrived in the conference room: Jess from Member Engagement, Dario from Clinical Workflow, and Omar from Core Platform. Each carried a printed list. Dario’s was four pages long.

“Before we look at anyone’s lists,” Franklin said, “let us determine what we have to fill.”

He walked to the whiteboard and drew a simple table. Down the left side: the twelve engineers’ names. Across the top: the three portfolio names. Then he drew a fourth column and labeled it: Available Capacity This Week.

“Each of you,” he said to the product managers, “has a claim on this team’s attention. The question is not whose list is longest or whose deadlines are nearest. The question is: given the work already in flight — the forty-three items on that board — how much new work can this team actually take on without making everything slower?”

Dario looked up from his pages. “We need to ship the clinical intake feature by the end of the month.”

“I hear that as a date,” Franklin said. “Is there a cost to not meeting that date? I mean a specific, quantifiable cost — a contract penalty, a regulatory deadline, a patient safety concern?”

Dario paused. “It’s a stakeholder commitment.”

“Then it is a Fixed Date class of service — not an Expedite. Expedite is reserved for items where the cost of delay is, in the mathematical sense, infinite. Where every day of delay causes a measurable harm that cannot be recovered.” He glanced at the board projected on the conference room screen, where two of the three red expedite tickets had been sitting for four days. “I note that your team currently has three items marked Expedite. Do all three represent situations where the cost of delay is genuinely unbounded?”

A look passed between Jess and Dario.

“No,” Jess said quietly.

“Then we have discovered our first policy violation.” Franklin wrote on the whiteboard: Expedite = cost of delay approaches infinity. Use sparingly; overuse destroys the mechanism. “A system in which everything is urgent is a system in which nothing is urgent. When you mark something Expedite, you are asking your engineers to stop all other work — all of it — and attend to this item until it is done. If you use that signal for items that are merely important, you exhaust the signal’s power precisely when you need it.”

This was not an insight Franklin had learned from Kanban. He had learned it from a lifetime of observing human organizations. The Pennsylvania Assembly, the Continental Congress, the French court — every institution he had operated within had suffered from the same inflation: when the urgent label was applied too broadly, it lost its value. It was the same mechanism that caused hyperinflation in currency. He had watched the Continental Dollar collapse for the same reason.

The replenishment meeting resolved, after ninety minutes, to pull four new items into the active queue: two from Clinical Workflow, one from Member Engagement, and one from Core Platform. The total WIP limit for the team — calculated from their historical throughput data and Little’s Law — was fourteen items in the In Progress stage. They currently had twenty-nine. The team had been operating above capacity by more than double.

“We cannot pull in four more items without removing some from flight,” Franklin said. “The law governing this is not a suggestion. It is mathematics.”

He wrote on the whiteboard: WIP = Throughput × Cycle Time.

“If your throughput — the number of items completed per week — is constant, and you double your work in progress, your average cycle time doubles. This is not a team problem. It is a physics problem.” He tapped the equation. “John Dutton Conant Little proved this in 1961. I confess I find it somewhat vexing that it required a formal mathematical proof for people to believe what any honest printer’s apprentice could have told you in 1724 by looking at his compositing bench.”

The product managers exchanged glances. Omar, who had been quiet until now, said: “So what do we do?”

“We do what any man of prudence does when he finds himself over-extended,” Franklin said. “We finish what we have started. Before this meeting, I identified eleven items in In Progress that have been there for more than twelve days — well beyond the team’s 85th percentile cycle time of nine days. Those eleven items are candidates for immediate escalation, re-scope, or abandonment. We do not pull in new work until we understand what is preventing those eleven items from completing.”

He wrote a second note on the whiteboard, in larger letters: Stop starting. Start finishing.

He had not encountered this phrase in any text. He had derived it himself, independently, sometime around 1730, while observing that the tradesmen who prospered in Philadelphia were invariably those who completed contracts before accepting new ones, and that those who failed were invariably those who had taken on more work than they could complete in order to appear successful. The appearance of industry and its substance were, he had written, entirely different things. Industry — his sixth virtue — meant the sustained, productive application of effort to completion, not to commencement.

Wednesday: Order and the Aging Work#

Franklin’s third virtue was Order: let all your things have their places; let each part of your business have its time. It was the virtue he had found hardest to maintain. In his autobiography he had written, somewhat ruefully, that a man whose business required him to receive people constantly could not always give appointments, and that the interruption of order by disorder was, in some professions, simply the nature of the work. He had not given up on Order. He had merely learned to distinguish between the ideal and the achievable, and to track the gap between them with honest eyes.

Wednesday brought an education in the same gap.

At eight forty-seven, Priya received a Slack message from the Chief Medical Officer. A bug in the Member Engagement mobile application was causing insulin dose notifications to fire twice — once correctly, and once with a dosage value multiplied by a factor of ten. This was not a billing inconvenience. This was a patient safety issue. Priya walked to the board and changed one ticket from green to red.

Franklin watched. “That,” he said, “is a legitimate Expedite.”

“What do we do?”

“We stop everything non-essential and attend to it immediately. Every engineer who is not currently blocked on something that requires immediate human intervention should be available to support the two engineers who are best positioned to resolve this. Not to contribute code, necessarily — but to be available, informed, and ready.” He moved to the board and — with Priya’s permission — reorganized the layout, placing the expedite ticket at the top of the In Progress column with a visible separator below it. “This item lives above the line. Everything below the line operates at normal priority. The expedite item has no WIP limit. It runs until it is resolved.”

By eleven-fifteen, the bug was identified, fixed, and in staging. By one-thirty, it was deployed.

The rest of Wednesday was Franklin’s day with the aging work. The eleven items he had identified in the replenishment meeting — those languishing beyond the 85th percentile cycle time — were spread across the board like a slow-motion exhibition of the ways organizations avoid confronting their own dysfunctions.

He interviewed each engineer whose name appeared on an aging ticket. The conversations revealed a taxonomy of stuckness that would have been familiar to any man who had observed human nature closely:

Ambiguity. Three tickets had no clear definition of done. The engineer assigned to them was, essentially, working toward a target that had never been specified. Each had made a private decision about what “done” meant and was hoping it matched the product manager’s private decision.

Dependency. Four tickets were blocked on work owned by another team — the Platform team, in all four cases — that had not committed to a delivery date and did not attend any of Junto’s cadences. The engineers had been waiting politely for weeks.

Cherry-picking. Two tickets had been consistently de-prioritized in favor of newer, more interesting work that engineers had pulled in of their own accord. The tickets were old. Old work felt heavy. New work felt light.

Unclear ownership. Two tickets had two assignees. When there are two owners, there is no owner.

Franklin wrote up his findings in a single page. Then he wrote next to each category the name of the intervention. For ambiguity: “Conduct a thirty-minute definition-of-done session with the engineer and product manager before end of day.” For dependency: “Escalate to the dependency team’s manager with a cost-of-delay calculation.” For cherry-picking: “Establish an explicit policy prohibiting engineers from pulling new work while any item in their name has exceeded the 85th percentile cycle time.” For unclear ownership: “Each ticket has exactly one name. The second person is a collaborator, not an owner.”

He brought the page to Priya. “I observe,” he said, “that you track your work items with great precision. You know, at any moment, which tickets exist and in which state they reside. What you do not track is the pattern of stuckness — which category of obstruction is recurring, and how often, and whether it is getting better or worse over time.”

“We do retrospectives,” Priya said.

“I know. I have reviewed the retrospective notes for the past six months. You discuss what feels bad and you generate action items. Forty percent of those action items appear again in the next retrospective, uncompleted.” He set down the page. “You are tracking intentions, not outcomes. I made this error myself, for years.” He paused. “The virtue I found hardest to maintain was Order. I thought the difficulty was personal — that I lacked discipline. The truth was more interesting: I was tracking the wrong thing. I was recording when I had a plan. I was not recording when the plan failed and why.”

He reached into his coat pocket and produced a small leather notebook. He opened it to a page that showed a hand-drawn grid: seven columns, thirteen rows. In many of the cells, small dots had been placed.

“Each row is a virtue. Each column is a day of the week. Each dot represents a failure to maintain that virtue on that day. I did not record my successes. There was no information in a success — if I maintained Temperance on Tuesday, I learned nothing about the conditions under which I was likely to fail at Temperance. But when I failed, the failure came with context: I was tired, I was hungry, I was in the company of people who ate immoderately. The dot without the context was a data point. The dot with the context was an insight.”

“So you’re saying we should track not just that things are blocked, but why they’re blocked, and in what conditions.”

“I’m saying,” Franklin said, “that your aging chart is equivalent to my dot. The ticket that has sat in In Progress for eighteen days is the dot. The category of obstruction — ambiguity, dependency, cherry-picking, shared ownership — is the context. Without the context, you will run this same retrospective six months from now and generate the same action items.”

Thursday: Industry and the Metrics That Matter#

By Thursday morning, Franklin had been at the office four days, and the team had begun to orient around him the way iron filings orient around a magnet — not because he had authority, but because he asked questions that other people avoided asking, and he asked them without apparent discomfort.

Thursday was data day. Priya had assembled the metrics that would inform the Service Delivery Review — the weekly cadence at which the team assessed its performance against commitments made to each portfolio. The CFD — the Cumulative Flow Diagram — was projected on the screen: a stacked area chart showing, over the trailing eight weeks, how many items were in each column on each day. The ideal CFD bands were smooth and relatively parallel. Junto’s CFD showed the In Progress band expanding steadily from week two onward, like a man eating more than he digested, with the Done band growing far more slowly.

“This,” Franklin said, “is what a push system looks like from above.”

He had not come to Junto knowing the term. But he had spent Tuesday and Wednesday evenings reading Anderson’s Kanban book and Mike Burrows’ Kanban from the Inside — Priya had placed them on his desk with flagged passages — and he had found, in the literature, precise descriptions of phenomena he had spent his life observing. A push system produces work faster than it can be completed, inflating the queue and causing the cycle time to elongate asymptotically. He had seen it in every legislative body he had ever participated in: bills proposed at a rate far exceeding the rate at which bills could be debated, amended, and voted upon, creating a queue that was never processed, a system that produced the appearance of legislative activity while actually delivering very little.

“The CFD tells us three things,” he said, moving to the screen. “First: your flow efficiency is approximately twenty percent. Of the nine days an average item spends in your system, roughly two days are spent with someone actively working on it. Seven days are wait time.” He paused. “Seven days spent waiting in a queue — not blocked, simply waiting. Unattended. The patient sits in the waiting room while the physicians attend to paperwork.”

“Is twenty percent normal?” asked Dev, one of the junior engineers.

“It is common,” Franklin said. “It is not normal in the sense of acceptable. The finest organizations in this discipline achieve flow efficiency north of forty percent. The improvement is achieved not by working faster but by reducing the time items spend waiting.” He tapped the In Progress band on the CFD. “The waiting happens here — items sit in progress columns without active attention because too many items compete for the same attention. The remedy is fewer items in flight at once.”

This brought the conversation to Little’s Law, which Franklin had been waiting all week to deploy in a room that contained both engineers and product managers simultaneously.

He wrote the equation on the whiteboard for the third time that week:

WIP = Throughput × Cycle Time

“Your current throughput is approximately eight items per week. Your WIP limit, as it should be, is fourteen items in progress at once. If you hold to that limit, your average cycle time will be: fourteen divided by eight — approximately 1.75 weeks, or nine days. Your 85th percentile cycle time should fall around twelve to thirteen days. Is this consistent with what you observe?”

Marcus, the staff engineer, pulled up the cycle time histogram on his laptop. “Eighty-fifth percentile is eleven days.”

“Close enough. Now: your actual WIP at present is twenty-nine. Your cycle time at twenty-nine items of WIP, with throughput held constant at eight per week, is: twenty-nine divided by eight — 3.6 weeks. Twenty-five days.” He let that sit. “Your service level expectation to your portfolios — the time within which you have committed to complete standard work — is fourteen days. You have promised fourteen. You are delivering twenty-five.”

The room was quiet.

Franklin had expected this. He had learned, over a long life in business and politics and diplomacy, that quantitative discomfort was a different kind of discomfort than qualitative. People could argue with a feeling indefinitely. They could not argue with an equation whose inputs they had themselves supplied.

“The remedy is not to work faster,” he repeated. “It is to agree on the maximum quantity of work that can be in flight simultaneously, to hold to that limit with the kind of resolution” — he paused on the word deliberately, it being his fourth virtue — “that does not bend to the first stakeholder who arrives with an urgent request, and to trust that the system, operating at proper capacity, will deliver more in the same period than the same system operating at twice its designed load.”

He had made the same argument in a different language, to different people, in a different century. In The Way to Wealth, he had written: “He that is of the opinion money will do everything may well be suspected of doing everything for money.” The modern equivalent, for software teams, was perhaps: he that is of the opinion that adding more work will produce more output may well be suspected of understanding nothing about the relationship between load and throughput.

The Service Delivery Review then proceeded portfolio by portfolio. Clinical Workflow had delivered four of seven committed items in the past two weeks. Member Engagement had delivered two of four. Core Platform had delivered one of two. Franklin noted that Core Platform’s one item had been completed in three days, well within SLE, while Clinical Workflow’s three incomplete items had been in flight for an average of nineteen days.

“Core Platform is performing well because it has the lowest WIP of any portfolio,” he noted. “Clinical Workflow is underperforming because it has the highest.” He made a mark in his notebook. “The lesson is not that Core Platform’s engineers are more talented. The lesson is that WIP is the variable.”

The Risk Review followed immediately after. Franklin had been looking forward to it.

Risks, in the Kanban framework, are systemic issues that threaten future delivery but are not yet active blockers. They are the difference between a ticket that is blocked today and a structural condition that will cause tickets to be blocked reliably until the structure changes.

Franklin identified four systemic risks that week:

First: the Platform team dependency had no formal SLA, no assigned liaison, and no attendance at Junto’s cadences. This was not a ticket problem. It was an organizational design problem. Until Platform committed to a response time for dependency requests, four engineers at Junto would continue to be held hostage by an invisible queue they had no visibility into and no ability to influence.

Second: the Expedite class of service was being invoked, on average, 3.4 times per week. At that rate, Expedite tickets occupied the team’s attention for roughly forty percent of its available capacity. An Expedite class of service should occur rarely — ideally, fewer than one per week. “An army that is perpetually in emergency mode,” Franklin wrote, “is an army that has confused the emergency with the operations.”

Third: the team had no explicit policy governing who could nominate work to the Expedite class. Currently, any product manager could escalate any ticket to Expedite by sending a Slack message to Priya. “A policy that can be circumvented by a sufficiently urgent tone of voice,” he observed, “is not a policy. It is a suggestion.”

Fourth: two engineers were regularly assigned to three or more active items simultaneously. This was not a throughput problem. It was a scheduling problem. “A man cannot be in three places at once,” Franklin said. “He may attempt it, and he will fail at all three. The constraint is not moral — it is physical.”

He had observed this in himself. His own failing on the virtue of Order — that he admitted in his autobiography — was precisely this: he had too many claims on his time from too many directions, and the solution was not to schedule more carefully but to reduce the number of claims. He had retired from active business at forty-two to create the capacity for the work that mattered most to him. This was not frugality as asceticism. It was frugality as optionality — the accumulation of surplus capacity in order to deploy it deliberately.

Friday: Resolution and the Retrospective#

Franklin had arrived each morning at six forty-five. On Friday, he arrived at six-thirty.

He spent the first forty-five minutes writing. Not notes — notes he had been taking all week — but a synthesis. He had been composing it in his mind since Tuesday, the way he had once composed arguments for the Pennsylvania Gazette before sitting down to write them: turning the piece over, examining it, finding its natural structure, then setting it down in a single, continuous effort that required little revision.

The retrospective was scheduled for two in the afternoon. It was, in the Kanban cadence, the team’s internal health meeting — not about delivery performance, which belonged to the Service Delivery Review, but about how the team worked together, what they found energizing or depleting, and what they wanted to change about their practices.

Franklin had read the retrospective notes from the past six months, as he had mentioned to Priya on Wednesday. He had also, more quietly, asked each engineer a single question at some point during the week: If you could change one thing about how this team works, what would you change? Twelve engineers, twelve answers. He had grouped them.

He opened the retrospective by distributing a single sheet of paper to each team member. The sheet contained five questions:

  1. What did we complete this week that you are proud of?
  2. What did we start that we should perhaps not have started?
  3. What is one thing a colleague did this week that made your work easier?
  4. What is one structural condition — not a person, but a process, a policy, or an organizational arrangement — that reliably makes your work harder?
  5. If you had to change one thing about how we work together, and you knew it would actually be implemented, what would you change?

Marcus, the staff engineer, looked at the sheet. “This is a lot more structured than what we usually do.”

“What do you usually do?”

“We go around and each person says what went well and what didn’t.”

Franklin nodded. “And do you find that the same things appear each week?”

“…Yes.”

“The difficulty with asking people what went well and what didn’t,” Franklin said, “is that it invites a rehearsal of experience rather than an examination of causes. When I say ’the deployment process was frustrating this week,’ I have communicated a fact about my internal state but I have not communicated anything about the mechanism that produced it. Question four” — he pointed to the sheet — “asks not how you felt, but what structural condition reliably produces the feeling. A structural condition can be changed. A feeling can only be endured.”

He had assembled these five questions from two sources, both of which he thought about during the retrospective. The first was the Junto — the intellectual society he had founded in Philadelphia in 1727, comprising twelve tradesmen, mechanics, and clerks who met every Friday evening to discuss questions of business, ethics, politics, and natural philosophy. The Junto’s format was built around structured inquiry: each meeting began with a fixed set of questions that members were expected to have considered before arriving. The questions were designed to surface both individual experience and collective patterns. “Have you lately heard of any citizen’s thriving well,” one of the Junto’s standard questions read, “and by what means?” Another: “Have you lately observed any encroachment on the just liberties of the people?”

The second source was his own virtue-tracking practice. The genius of his system was not the tracking itself — it was the specificity of what was being tracked. He had not asked himself, each evening, “was I virtuous today?” He had asked, for each of thirteen named virtues, with each given a precise behavioral definition: “did I violate this specific practice today, and if so, in what circumstance?” The granularity was the mechanism. The more precisely you named the behavior you were trying to change, the more clearly you could see whether you were changing it.

The retrospective took eighty minutes. Franklin facilitated throughout, maintaining the kind of deliberate, structured pace he had learned was necessary to prevent discussions from collapsing into venting or consolation. When an engineer began describing a frustration with a specific colleague’s behavior, Franklin redirected: “Can you describe the structural condition that put you both in that situation? If the condition did not exist, would the behavior?” When a product manager attempted to attend — Dario had appeared at the door — Franklin thanked him warmly and asked him to return in forty-five minutes for a brief synthesis. “This meeting,” he explained, “is for the team. The team requires space to speak honestly about structural conditions without concern that their candor will be interpreted as criticism. We will share the outcomes with you, but the conversation itself belongs to them.”

Dario left. Keiko, who had been quiet much of the week, said, simply: “Thank you for that.”

By the end of the retrospective, the team had identified three structural changes they wanted to make:

First: a maximum of one Expedite nomination per week per portfolio, with a thirty-minute cost-of-delay calculation required before the nomination was accepted. This would require explicit agreement from all three product managers, which meant it would need to be raised at the next weekly alignment meeting.

Second: a “focus day” policy — each engineer would have one day per week with no meetings, no Slack monitoring, and no expectation of response. Flow work only.

Third: a “no new work” policy for any engineer with an item that had exceeded the 85th percentile cycle time. Before pulling a new item, the engineer was expected to spend at least one hour actively attempting to unblock the aging item, and to escalate to Priya if the obstruction could not be removed.

Franklin wrote each of these on the whiteboard and beside each wrote: Owner. Due date. How we will know it is done.

“An action item without an owner,” he said, “is a hope. A hope without a due date is a wish. A wish without a success criterion is a prayer. We have sufficient prayers. What we need are commitments.”

Friday Evening: The Letter#

At five forty-seven, as the team was logging off and the office was emptying, Franklin remained at the corner desk Priya had assigned him at the beginning of the week. He opened his notebook to a fresh page and wrote for forty minutes without stopping.

The letter was addressed to Priya, but he imagined it would eventually be read by the product managers, the leadership team, and perhaps the Platform team, who had not been present for any of the week’s conversations but who were a silent character in almost all of them.

He wrote:

Dear Priya —

Having spent five days in the company of your team, I find myself in possession of several observations that I believe may be of use to you. I offer them in the spirit in which I have always offered observations: not as condemnations but as data, and not as final conclusions but as starting hypotheses to be tested and revised as the evidence warrants.

The first observation is that your team is skilled, motivated, and well-intentioned. I note this not as flattery but as a diagnostic finding, because it means the dysfunction you experience is not caused by the people in the system. It is caused by the system itself. This is a hopeful finding. People are difficult to change. Systems can be redesigned.

The second observation is that you are operating a pull system without the discipline that makes a pull system function. You have a board, you have columns, you have a standup. What you do not have, or do not consistently maintain, is a WIP limit that you hold regardless of the discomfort produced by holding it. A WIP limit is a social contract among engineers, product managers, and the organization that says: we agree to be honest about our capacity. An organization that routinely violates its WIP limits has decided, in practice, that the appearance of responsiveness is worth more than the reality of delivery. I am not certain your leadership has made this choice consciously. I suspect, rather, that no one has ever presented it to them as a choice at all.

The third observation is that your impediments are predominantly structural, not technical. Of the eleven aging items I reviewed on Wednesday, none were blocked by technical complexity. All were blocked by ambiguity, organizational dependency, or the human tendency to pick up new and interesting work in preference to completing old and difficult work. These are solvable problems. The solutions do not require new tools, new processes, or additional headcount. They require explicit policies, consistently enforced.

The fourth observation — and I confess this is the one that I find most interesting from the perspective of an old man who has spent a great deal of time thinking about the relationship between individual habits and collective outcomes — is that the discipline your system requires is the same discipline that any serious practice of self-improvement requires. You must be honest about your capacity. You must complete what you have started before beginning something new. You must track your failures rather than your successes, because your failures contain the information you need. You must structure your inquiry with specific, repeating cadences so that the absence of structure does not produce drift. And you must maintain these habits not when it is easy but precisely when it is hardest — when a stakeholder is at the door with an urgent request, when an exciting new problem presents itself, when the old work is tedious and the new work is bright.

I developed, in my youth, a system for tracking thirteen virtues — specific, behavioral commitments to which I held myself accountable by marking, each evening, the specific instances in which I had failed. I cycled through all thirteen virtues over the course of thirteen weeks, and I repeated the cycle four times per year. I was imperfect at this practice. I remained imperfect at it for the rest of my life. But I discovered — and this is the finding I would most like to leave with you — that attempting imperfect improvement systematically produces better results than not attempting it at all. The question is not whether your Kanban system will work perfectly. It will not. The question is whether the discipline of the system, imperfectly maintained, produces better outcomes than the absence of the system. I believe, having watched your team for five days, that it will.

I shall leave you with a question — the same question I asked myself each morning for many decades, and which I commend to you and your team as a daily orienting mechanism:

What good shall we do today?

It is not a rhetorical question. It requires an answer. The answer is a commitment, and the commitment is a WIP limit: it tells you how much good you have decided to attempt, so that at the end of the day, when you ask yourself what good you have done, you have a standard against which to measure your performance.

Your obedient servant in matters of flow and finish,

B. Franklin

Epilogue: The Philadelphia Mechanic#

There is a version of this story in which Franklin is impressed by the software team. In which he marvels at the speed of computation, the scale of the information systems, the miracle of a distributed team collaborating across time zones on tools hosted in server farms he cannot see. And he would have been. He was constitutionally incapable of indifference to a clever mechanism.

But the deeper story — the one that survives the novelty of the setting — is the one in which Franklin is not impressed. In which he looks at a team of skilled people producing less than they could produce, not because they lack capability but because they have not yet designed their system with the same care they would bring to designing the software itself. In which he recognizes, in the chaos of the intake queue, something he saw in every institution he ever participated in: the gap between what people intended and what they actually did, measured honestly, every day, with a small notebook and a habit of asking.

Franklin would not have described himself as a systems thinker in the modern sense. He would have described himself as a man of industry and method. He understood, empirically, that the output of any system was determined not by the intentions of its participants but by the structure within which those participants operated. He had tested this theory in his print shop, in the Junto, in the postal service he ran for the British Crown and then for the Continental Congress, in the fire company he founded, the library he founded, the hospital he founded, the insurance company he founded. Every institution he touched, he designed, because he understood that an institution left undesigned defaulted to the habits and incentives of the people within it, and that those habits and incentives were reliably insufficient to produce the outcome the institution was supposed to serve.

The Kanban Method, as David J. Anderson formalized it in 2007 and as the Kanban community has refined it in the nearly two decades since, is a system designed to make the same thing Franklin understood empirically into something legible, measurable, and teachable. Its genius — like the genius of Franklin’s virtue-tracking system — is that it does not ask people to be better. It asks the system to be designed well enough that ordinary people, operating within it, produce better outcomes than the same ordinary people operating outside it.

What good shall we do today?

Seven tickets. Right-to-left. Start with Done.

Sources#

On Benjamin Franklin#

  • Franklin, Benjamin. The Autobiography of Benjamin Franklin. Written 1771–1790, published posthumously. Primary source for the daily schedule, the 13 virtues system, the virtue-tracking notebook, the morning/evening bookend questions, and the Junto.
  • Isaacson, Walter. Benjamin Franklin: An American Life. Simon & Schuster, 2003. For Franklin’s retirement at age 42, his frugality as optionality, and his synergistic professional strategy.
  • Franklin, Benjamin. The Way to Wealth (Preface to Poor Richard’s Almanack). 1758. Source for “Lost time is never found again” and related aphorisms on industry and frugality.
  • Franklin, Benjamin. Poor Richard’s Almanack. 1732–1758. Aphoristic source material throughout.

On Kanban#

  • Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. Foundational text for the Kanban Method; source for WIP limits, pull systems, classes of service, the cadences, and the CFD.
  • Burrows, Mike. Kanban from the Inside. Blue Hole Press, 2014. Source for explicit policies, flow efficiency, and systemic thinking in Kanban.
  • Anderson, David J. and Carmichael, Andy. Essential Kanban Condensed. Lean Kanban University Press, 2016. Source for STATIK, SLE, and replenishment mechanics.
  • Reinertsen, Donald G. The Principles of Product Development Flow. Celeritas Publishing, 2009. Source for cost of delay as a prioritization mechanism.

On Little’s Law#

  • Little, John D.C. “A Proof for the Queuing Formula: L = ÎģW.” Operations Research, Vol. 9, No. 3, 1961. The original mathematical proof. The relationship WIP = Throughput × Cycle Time is an application of Little’s original formulation.

This piece is a work of speculative fiction. Benjamin Franklin did not attend any software standup meetings in 2026. All team members, company names, and ticket IDs are invented. The Kanban practices described are real. The Franklin practices described are real. The structural parallels between them are the argument.