<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Writing — Lavi Sahu</title>
    <link>https://lavisahu.com/blog/</link>
    <description>This is where I think out loud about supply chain planning, the tools that help planners, and what games, books and trips keep teaching me. Some pieces are finished. Most are still growing.</description>
    <language>en</language>
    <atom:link href="https://lavisahu.com/feed.xml" rel="self" type="application/rss+xml"/>
    <lastBuildDate>Sat, 03 Oct 2026 00:00:00 GMT</lastBuildDate>
    <item>
      <title>Feudal Age discipline: when to defend and when to rush</title>
      <link>https://lavisahu.com/blog/feudal-age-discipline/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/feudal-age-discipline/</guid>
      <pubDate>Sat, 03 Oct 2026 00:00:00 GMT</pubDate>
      <category>Game Theory of Operations</category>
      <description>In Age of Empires II, every villager is economy or army, and every age-up trades safety now for strength later. The same trade-off sits under planning roadmaps. Pressure buys tempo, tempo buys economy, economy buys castles: quick wins exist to fund capability, and big commitments come last.</description>
      <content:encoded><![CDATA[<p>Age of Empires II is the oldest game in my life. I started in 2007, mostly on weekends in the hostel: two days straight on the LAN, friends shouting across the corridor, and long arguments afterwards about the new ways we’d found to win. I don’t remember one game. I remember those weekends. And these days, I still play for the Feudal Age.</p>
<p>For anyone who hasn’t played: AoE2 is a real-time strategy game where you build a town, gather resources and raise an army. The game moves through four ages: Dark, Feudal, Castle and Imperial. Each one unlocks stronger buildings and units, and each costs resources and time to reach. Advancing to the Feudal Age costs 500 food. Castle Age costs 800 food and 200 gold. And while your Town Center is researching the next age, it can’t train villagers, the workers who gather everything. So every age-up is a real investment: resources you can’t spend on an army, and production you give up for a couple of minutes.</p>
<p>My opening is standard. A Dark Age economy on sheep, boar, berries and wood, and I click up to Feudal with twenty-odd villagers. Then I read the room. If my ally is under pressure or the map is open, I defend: walls, towers, archers. If the enemy is greedy and has skipped defence to grow faster, I hit early. Either way, the Feudal army buys time, not wins.</p>
<p>Then I move villagers onto gold and stone, go up to Castle Age, and build castles forward, closer to the enemy, to take ground one strongpoint at a time. A castle costs 650 stone, a big, slow, deliberate commitment. You don’t build one on a whim.</p>
<p>I boil it down to one line: pressure buys tempo, tempo buys economy, economy buys castles.</p>
<p>Under the build order there are really three decisions, and all three are the same trade-off: what you spend now against what you get later.</p>
<p>The first is allocation. Every villager is either gathering for the economy or feeding the army, never both. Every unit of capacity in a supply chain has the same property. A production line running this month’s demand isn’t running trials for next year’s product. A planner firefighting today’s shortages isn’t building the segmentation that would prevent next quarter’s. There’s no free capacity, only capacity you’ve decided to point somewhere.</p>
<p>The second is defend or rush. Defending protects what you have, at the cost of not pressuring anyone. Rushing can win time and space, but if it fails you’ve spent your economy on an army that died. In planning terms, it’s the choice between protecting current service (more buffer, more expediting, more attention on today) and pushing hard on something that might pay off quickly, like a pilot or a quick fix. Neither is right in general. It depends on what the other side is doing and how exposed you are.</p>
<p>The third, and the hardest, is when to click up. Go too early and you’re caught without an army. Go too late and your opponent out-grows you. Many investment decisions in planning look like this: a new planning system, a network redesign, a capability like demand sensing. All of them take capacity away from today and pay back later. The useful question is rarely ‘is this a good investment?’ in the abstract. It’s ‘are we safe enough right now to afford the dip?’</p>
<p>Here’s how I’d translate pressure, tempo, economy and castles into a planning roadmap. It’s a parallel from the game, not a framework I’ve run on a project, so read it as a lens rather than a recipe.</p>
<p>Pressure: the few short moves that stop the bleeding and earn trust. Fix the master data on the items that drive most of your volume, clean up the worst allocation rule, get the S&amp;OP meeting to make a decision instead of reviewing a forecast. These are the Feudal archers. Their job is to buy time, not to be the strategy.</p>
<p>Tempo: the time and credibility those quick wins buy. A steady planning rhythm that leadership trusts is worth a lot, because it’s what lets you ask for investment without being told to fix today first. Tempo is fragile, though. Spend it on more quick wins forever and you never click up.</p>
<p>Economy: the capabilities you build with that time. Cleaner data flows, sensible segmentation, a planning tool actually used the way it was meant to be, people trained to use it. Slow, unglamorous, and the part that compounds.</p>
<p>Castles: the few big, deliberate commitments that change the shape of the map. A regional warehouse, a postponement strategy that holds generic stock and finishes it close to the customer, a second source of supply in another region. Like a forward castle, they work best when you commit late and close to the fight, once the economy can pay for them and the signal is clear.</p>
<p>The lesson I take from the game is about order. Players who go straight for castles without the economy usually stall halfway, and I suspect roadmaps do too. Players who only ever do pressure stay busy and never get stronger. Short-term moves exist to protect the long-term plan.</p>
<p>I’ve marked this one ‘possible’ rather than ‘likely’. The parallel feels right to me after a lot of hours on both sides, but it’s a lens, not evidence. If you’ve lived a roadmap that broke this pattern and still worked, I’d genuinely like to hear how.</p>
<h2>So what?</h2><p>Sort your current roadmap into four lanes: pressure, tempo, economy, castles. If almost everything sits in pressure, you are defending forever. If a castle is planned before the economy that pays for it, move it later.</p>
<h2>Sources</h2><ul><li>Ensemble Studios (1999). Age of Empires II: The Age of Kings (video game). Microsoft. Current edition: Forgotten Empires, Tantalus Media &amp; Wicked Witch (2019). Age of Empires II: Definitive Edition. Xbox Game Studios.</li><li>Xbox Game Studios. ‘Lesson 1: What is Advancing?’ Age of Empires: Learn to Play. https://www.ageofempires.com/learn-to-play/advancing-aoe2/ (Feudal Age 500 food; Castle Age 800 food, 200 gold)</li><li>Liquipedia Age of Empires Wiki. ‘Castle (Age of Empires II)’ and ‘Fast Castle’. https://liquipedia.net/ageofempires/ (castle cost 650 stone; fast castle openings; verify against current patch)</li><li>Lee, H. L., Billington, C. &amp; Carter, B. (1993). Hewlett-Packard gains control of inventory and service through design for localization. Interfaces, 23(4), 1–11. https://doi.org/10.1287/inte.23.4.1</li><li>Lee, H. L. &amp; Tang, C. S. (1997). Modelling the costs and benefits of delayed product differentiation. Management Science, 43(1), 40–53. https://doi.org/10.1287/mnsc.43.1.40</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>Tilt and the bullwhip</title>
      <link>https://lavisahu.com/blog/tilt-and-the-bullwhip/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/tilt-and-the-bullwhip/</guid>
      <pubDate>Fri, 02 Oct 2026 00:00:00 GMT</pubDate>
      <category>Game Theory of Operations</category>
      <description>Tilt is overreacting to the last bad moment and making the next decision worse. The bullwhip effect is the same thing in a supply chain: a 10% change in demand can become a 160% swing at the factory. Look at the supply line, smooth the signal, and change one lever at a time.</description>
      <content:encoded><![CDATA[<p>I’m a recovering sore loser. Dota has a word for what happens after a bad fight: tilt. You die once to something silly, you get annoyed, you go back in too early to make up for it, you die again, and now the whole team is playing angry. One bad moment becomes a bad decision, then a worse one, then a lost game. The first death almost never loses the match. The reaction to it does.</p>
<p>Planning has the same failure, and it has a name much older than gaming slang: the bullwhip effect. A small wobble in customer demand turns into bigger and bigger swings in orders as it travels up the chain, from store to wholesaler to factory to supplier.</p>
<p>The cleanest demonstration is the Beer Game, a board game developed at MIT in the early 1960s by the System Dynamics Group, as part of Jay Forrester’s work on industrial dynamics. Four players each run one stage of a supply chain: a retailer, a wholesaler, a distributor and a factory. Every week they look at the orders coming from the player downstream, decide how much to order from the player upstream, and wait for shipments that take a few weeks to arrive. Customer demand is almost boring. In the classic setup it sits at four cases a week, steps up to eight once, and stays there. You can play a version of it on this site, on the Beer Game page under Work.</p>
<p>That one small change is enough to wreck the chain. Orders swing wildly, inventories pile up and then collapse into backlog, and the swings get bigger the further a player is from the customer. The factory, which never sees the customer at all, usually has the worst time.</p>
<p>In 1989 John Sterman published a careful analysis of how people actually play it. His finding, simplified: players don’t properly account for the supply line, the orders they’ve already placed but not yet received. They see a shortage, order more, see the shortage still there next week (because the beer is still on its way), and order more again. When it all arrives they’re drowning in stock, so they cut orders sharply, often to nothing. The game is simple and the players are smart. The overreaction comes from watching the shelf instead of the pipeline.</p>
<p>That’s tilt, almost exactly. Reacting to what just happened, not to what’s already in motion.</p>
<p>In 1997, Hau Lee, V. Padmanabhan and Seungjin Whang looked at the same pattern in real companies. One of their examples was Procter &amp; Gamble, which saw large swings in distributor orders for Pampers even though babies use diapers at a fairly steady rate. They named four causes, and I find it useful to read them as four ways a chain can tilt.</p>
<p>Demand signal processing: each stage treats the orders it receives as the demand signal, updates its forecast and safety stock on them, and passes a bigger swing upstream. Order batching: ordering weekly or monthly, or in full trucks, turns smooth demand into lumpy orders. Price fluctuation: promotions and discounts make buyers stock up early, then stop buying. Rationing and shortage gaming: when supply is rationed, customers order more than they need to get a bigger share, then cancel when the shortage ends.</p>
<p>I wrote about the shock side of this in an earlier post, Buffer Shock. Here I want to stay with the behaviour, because most of those causes are decisions people make in the moment, often under pressure, often a little tilted.</p>
<p>A small example shows how fast it compounds. Take four stages, each selling 100 units a week, each following one simple rule: keep one week of stock, based on the latest week of orders received. While things are steady, everyone orders 100.</p>
<p>Now customer demand rises by 10%, to 110, and stays there. The retailer sees 110, raises its stock target from 100 to 110, and orders 110 plus the extra 10: 120. The wholesaler sees 120 and does the same: 120 plus 20, so 140. The distributor sees 140 and orders 180. The factory sees 180 and orders 260. A 10% change at the shelf has become a 160% jump at the factory in a single week, and nobody did anything foolish.</p>
<p>The next week is worse. Demand is still 110, so the retailer orders 110. The wholesaler sees orders fall from 120 to 110, trims its target, and orders 100. The distributor sees 100 after 140 and orders 60. The factory sees 60 after 180 and would order minus 60, which in practice means nothing at all. From 260 to zero in a week, for a customer who simply started buying 10% more.</p>
<p>In Dota, the fix for tilt is boring: breathe, look at the whole map, go back to the plan. These are the three planning habits I’d take from that. They’re parallels from the game and the research, not a method I’ve tested on a client.</p>
<p>Look at the supply line. Before changing an order, add up what’s already coming: open purchase orders, work in progress, stock in transit. Decide on inventory position (on hand, plus on order, minus backorders), not on whatever happens to be on the shelf today. Sterman’s players would have done far better with this one habit.</p>
<p>Smooth the signal. Don’t let one week reset your forecast or your safety stock. Use a moving average or exponential smoothing, and where you can, plan on actual sell-through or point-of-sale data rather than on the orders coming from the stage below. Lee and his colleagues pointed to sharing real demand information as one of the strongest counters to the bullwhip.</p>
<p>Change one lever at a time. When service drops, the temptation is to raise the forecast, increase safety stock, expedite and add a shift, all in the same week. Pull one lever, give it the lead time it needs to show up, then decide on the next. Pull four at once and you can end up drowning in stock a month later without knowing which one did it.</p>
<p>The first death doesn’t lose the game. The second, angry one usually does. A bad week of demand works the same way.</p>
<h2>So what?</h2><p>Next time a bad week tempts you to change the plan, write down three things first: what is already on order, what the smoothed demand says, and the single lever you will pull. Then wait one lead time before pulling another.</p>
<h2>Sources</h2><ul><li>MIT Sloan System Dynamics Group. The Beer Game: “developed by Sloan’s System Dynamics Group in the early 1960s as part of Jay Forrester’s research on industrial dynamics.” https://web.mit.edu/jsterman/www/SDG/beergame.html</li><li>Sterman, J. D. (1989). Modeling managerial behavior: Misperceptions of feedback in a dynamically complex decision making experiment. Management Science, 35(3), 321–339. https://doi.org/10.1287/mnsc.35.3.321</li><li>Lee, H. L., Padmanabhan, V. &amp; Whang, S. (1997). Information distortion in a supply chain: The bullwhip effect. Management Science, 43(4), 546–558. https://doi.org/10.1287/mnsc.43.4.546</li><li>Lee, H. L., Padmanabhan, V. &amp; Whang, S. (1997). The bullwhip effect in supply chains. Sloan Management Review, 38(3), 93–102.</li><li>Forrester, J. W. (1961). Industrial Dynamics. Cambridge, MA: MIT Press.</li><li>Forrester, J. W. (1958). Industrial dynamics: A major breakthrough for decision makers. Harvard Business Review, 36(4), 37–66.</li><li>Sterman, J. D. (2000). Business Dynamics: Systems Thinking and Modeling for a Complex World. Boston: Irwin/McGraw-Hill. (Chapter 17 describes the Beer Game and its results.)</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>Kills vs objectives: the KPI trap</title>
      <link>https://lavisahu.com/blog/kills-vs-objectives/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/kills-vs-objectives/</guid>
      <pubDate>Thu, 01 Oct 2026 00:00:00 GMT</pubDate>
      <category>Game Theory of Operations</category>
      <description>Kills in Dota feel like winning, but towers and the Ancient decide the game. In planning, forecast accuracy is the kill counter; service, inventory and cash are the towers. Pick one objective per cycle, give it a counterweight, and demote everything else to diagnostics.</description>
      <content:encoded><![CDATA[<p>In Dota 2, the scoreboard at the top of the screen counts kills. It’s the first number you see, and the easiest one to feel good about. A clean fight, three kills, everyone happy. Then, ten minutes later, the enemy walks down a lane nobody was watching, takes two towers, and the game quietly turns their way.</p>
<p>It took me a few thousand hours to accept the obvious. Nobody wins Dota on kills. You win by destroying the enemy’s Ancient, the big structure in the middle of their base, and you can’t touch it until you’ve taken the towers in front of it. Kills help. They buy gold, experience, time and space. But they only matter if you turn them into something on the map: a tower, Roshan, a push into the base. A team that fights well and never converts is just farming the scoreboard.</p>
<p>Kills feel like progress. Objectives are progress. I wrote that line for the games page on this site, and the longer I sat with it, the more it sounded like a description of planning teams.</p>
<p>Every planning function has its own kill counter. The most common one is forecast accuracy. It’s easy to measure, it moves every month, and it gives everyone something to argue about in the S&amp;OP meeting. I’m not against it. A forecast that’s badly wrong will hurt you. But forecast accuracy is an input. Nobody outside the planning team feels it directly. Customers feel whether the order arrived complete and on the day promised. Finance feels how much cash is sitting in the warehouse. The plant feels whether the schedule held.</p>
<p>Those are the objectives: service (often measured as OTIF, on time in full), inventory or working capital, and cost. When a team chases accuracy for its own sake, it can spend weeks tuning models on items that were never the problem, while the orders that actually failed went wrong for a different reason: a stockout on a handful of items, a transport delay, an allocation rule nobody revisited.</p>
<p>There’s a well-known name for this trap. Goodhart’s law, in the popular phrasing usually credited to the anthropologist Marilyn Strathern, says that when a measure becomes a target, it ceases to be a good measure. Push a team on forecast accuracy alone and it will find ways to improve forecast accuracy, not all of them useful. Push it on service alone and it will buy service with inventory. The measure isn’t the problem. Forgetting what it was for is.</p>
<p>So how do you choose the tower to aim at? Here’s the short filter I’d use. It’s a lesson I took from the game, not a method I’ve rolled out anywhere, so treat it as a starting point rather than a rulebook.</p>
<p>First, someone outside planning must feel it. If only the planning team would notice the number moving, it’s a diagnostic, not an objective. Second, the team must be able to move it within one planning cycle. A number that responds only over a year is a strategy measure, not a cycle measure. Third, give it a counterweight. Service alone can be bought with stock, so pair OTIF with inventory days and agree that both have to hold. Fourth, pick one per cycle. Everything else stays on the dashboard, demoted to explaining why the objective moved.</p>
<p>In Dota terms: the objective is the tower. Kills, last hits and the gold graph are how you read whether you’re getting closer to it.</p>
<p>Here’s a small example with made-up, simple numbers. A distributor ships 100 customer orders a week. Last quarter, 88 of them went out on time and in full, so OTIF was 88%. Over the same quarter the planning team worked hard on forecast accuracy and lifted it from 62% to 68%. Good work, honestly. OTIF didn’t move.</p>
<p>Now look at the 12 orders that failed. Seven were short because three fast-moving items ran out. Five were late because of a transport problem. None of the twelve came from the items whose forecasts improved, because those items already carried enough safety stock to absorb the error. The team took the kills and never touched the tower.</p>
<p>If the objective is OTIF, the next move is clear: the three items that ran out. Say each sells about 40 units a week, with a weekly standard deviation of 15 units, and each holds one standard deviation of safety stock, 15 units. If demand is roughly normal, that avoids a stockout in about 84% of replenishment cycles. Two standard deviations, 30 units each, gets you to about 98%. The extra stock is 15 units per item, 45 in total. At 500 a unit, that’s 22,500 of extra inventory.</p>
<p>That’s the conversation the S&amp;OP meeting should have. Is 22,500 of inventory worth recovering most of those seven orders, which would lift OTIF toward 95%? The counterweight, inventory days, makes sure someone asks that out loud instead of quietly buying service. The five late orders go to the transport team, where the cause sits. And forecast accuracy goes back to being what it always was: a useful instrument, not the score.</p>
<p>None of this means forecasting work is wasted. It means it should be pointed. If the misses had been on items with poor forecasts and thin buffers, better forecasting would have been exactly the right tower. The filter just makes you check before you spend the quarter.</p>
<p>I still enjoy a good teamfight. I just try to ask the question my better games taught me: what did that fight buy us on the map? It works surprisingly well on a dashboard too.</p>
<h2>So what?</h2><p>Before your next S&amp;OP cycle, write down the one number a customer or your CFO would actually feel. Make it the objective, pair it with a counterweight such as inventory days, and use every other metric only to explain why it moved.</p>
<h2>Sources</h2><ul><li>Valve Corporation. Dota 2 (video game), 2013. Objective: destroy the enemy team’s Ancient. https://www.dota2.com/</li><li>Goodhart, C. A. E. (1975). Problems of Monetary Management: The U.K. Experience. Papers in Monetary Economics, Vol. I. Reserve Bank of Australia.</li><li>Strathern, M. (1997). ‘Improving ratings’: audit in the British University system. European Review, 5(3), 305–321.</li><li>Gilliland, M. (2010). The Business Forecasting Deal: Exposing Myths, Eliminating Bad Practices, Providing Practical Solutions. Hoboken, NJ: Wiley.</li><li>Silver, E. A., Pyke, D. F. &amp; Thomas, D. J. (2017). Inventory and Production Management in Supply Chains (4th ed.). Boca Raton, FL: CRC Press. (Safety stock and cycle service level.)</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>The Novel Is the Map</title>
      <link>https://lavisahu.com/blog/margins-and-maps/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/margins-and-maps/</guid>
      <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
      <category>Margins</category>
      <description>Four cities, four writers, and what&#39;s still standing when you go looking for the address.</description>
      <content:encoded><![CDATA[<p>I&#39;ve started reading a novel set in whatever city I&#39;m about to visit before I read anything the guidebook has to say about it. Not because fiction is more accurate — it usually isn&#39;t — but because a novelist has already done the work of deciding which street corner matters. The guidebook gives you the whole city; the novel gives you the one block the writer couldn&#39;t stop thinking about. Four of those blocks have stayed with me longer than the trips that took me there.</p>
<p>Start with St Petersburg, because Dostoevsky made the mistake of being too precise. In Crime and Punishment he never names Raskolnikov&#39;s street outright — he calls it “S. Place” — but his widow, Anna, later confirmed he meant Stolyarny Lane, and researchers have since pinned the building down to the corner of Grazhdanskaya Street and Stolyarny Lane. It&#39;s a real corner, with a real attic room reached by a real narrow staircase that roughly matches the novel&#39;s thirteen steps. Dostoevsky wrote the book a few minutes&#39; walk away, at 7 Kaznacheyskaya Street on the corner of Stolyarny Lane itself — close enough that he could have walked his character&#39;s route on the way to buy bread.</p>
<p>Dublin is the opposite problem: everyone knows the address, because Joyce gave it to you outright. Leopold Bloom lived at 7 Eccles Street, a real Georgian row house that stood until 1967, when it was demolished for a hospital extension. The only piece of it left is the front door, now on display at the James Joyce Centre. Ulysses takes place on a single day, June 16, 1904, celebrated every year since as Bloomsday — chosen, by Joyce&#39;s own account, because it was the date of his first outing with Nora Barnacle, the woman he&#39;d later marry. The entire seven-hundred-page architecture of the book rests on a personal anniversary hidden in plain sight.</p>
<p>Istanbul gave me a word before it gave me a street: hüzün, the melancholy Orhan Pamuk spends most of Istanbul: Memories and the City trying to define. It isn&#39;t the private, individual sadness the West is used to — in Maureen Freely&#39;s translation, Pamuk describes it as “hüzün, which denotes a melancholy that is communal rather than private,” something the whole city carries together, built out of a couple of centuries watching an empire&#39;s capital shrink into a provincial one. You don&#39;t need Pamuk&#39;s specific childhood streets to feel it; you need to stand on any bridge over the Bosphorus at dusk and notice that everyone around you seems to be feeling the same thing at once.</p>
<p>Lisbon is the strangest of the four, because the book most associated with it was never really finished, and its narrator was never really its author. Fernando Pessoa wrote The Book of Disquiet as the diary of Bernardo Soares, an assistant bookkeeper on Rua dos Douradores — one of Pessoa&#39;s dozens of literary alter egos, though close enough to Pessoa&#39;s own daily life (he worked as a bookkeeper himself) that scholars call Soares a semi-heteronym rather than a full invention. The book exists in competing English editions — Richard Zenith&#39;s and Margaret Jull Costa&#39;s translations arrange the same fragments in different orders — because Pessoa never settled on a sequence himself; he left the pages in a trunk and died before deciding what the finished book was. Rua dos Douradores is a real street in the Baixa district, walkable end to end in about four minutes, which feels wrong for a book this long about a man who almost never left it.</p>
<p>None of these four cities needed a novelist to exist, and none of the addresses above are secret — you can find every one of them with an afternoon and a working phone. What the novel adds isn&#39;t information. It&#39;s a reason to stand still on one particular corner instead of the next one, long enough to notice what&#39;s actually there instead of what you expected to see. That&#39;s a cheaper kind of travel than it sounds: most of it happens before you buy the ticket, in a chair, with a book that already knows which street matters.</p>
<h2>Sources</h2><ul><li>Dostoevsky Literary-Memorial Museum, St Petersburg — Stolyarny Lane / Grazhdanskaya Street and Dostoevsky&#39;s own Kaznacheyskaya Street apartment</li><li>James Joyce Centre, Dublin — 7 Eccles Street and Bloomsday history</li><li>Orhan Pamuk, Istanbul: Memories and the City, trans. Maureen Freely (Faber &amp; Faber / Knopf, 2005)</li><li>Fernando Pessoa, The Book of Disquiet, trans. Richard Zenith (Penguin Classics) and trans. Margaret Jull Costa (New Directions, 2017)</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>The Quiet Ledger</title>
      <link>https://lavisahu.com/blog/the-quiet-ledger/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/the-quiet-ledger/</guid>
      <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
      <category>Margins</category>
      <description>The Stoics were not describing a simpler world. They were describing your inbox.</description>
      <content:encoded><![CDATA[<p>Your phone is in your hand before your feet are on the floor. You didn&#39;t decide this. Somewhere between the alarm and the second blink, your thumb found the glass, and now a colleague&#39;s late-night “quick one,” a stranger&#39;s opinion, and a headline from a country you&#39;ll never visit are all standing in your bedroom. Nobody forced the door. You opened it.</p>
<p>Epictetus knew something about doors being forced — he spent the first part of his life enslaved in Rome before he was freed and began teaching philosophy. In the short manual his student Arrian wrote down, the Enchiridion, he puts it plainly: “If any person were to give your body to any stranger he met on his road, you would certainly be angry.” The rest of the passage asks why you don&#39;t feel the same anger when you hand over your mind to whoever gets to you first. For years I read that as a line about insults. It&#39;s a line about Tuesday mornings.</p>
<p>I&#39;m not a classicist — I read these men in translation, at a kitchen table, with coffee going cold next to a notebook. For a long time I assumed they belonged in a museum case, advice for a slower world. I had it backwards. They weren&#39;t describing a simpler world. They were describing this one, and they left working instructions for getting your mind back.</p>
<p>Seneca wrote On the Shortness of Life around 49 CE, and he wasn&#39;t a hermit doing it from a cave — he went on to become Nero&#39;s tutor and then his chief advisor, which means he knew exactly how a court eats a day. His description of the people everyone&#39;s heard of still lands: “Ask about the men whose names are known by heart: A cultivates B and B cultivates C; no one is his own master.” I&#39;ve been C. I&#39;ve been the X after that. In consulting, a request leaves a partner&#39;s mouth at six in the evening and becomes my calendar invite by seven the next morning — and everyone in that chain is busy, and nobody in it owns the day. That&#39;s not one person&#39;s failure. It&#39;s the shape of the system, and Seneca drew it two thousand years before anyone called it a chain.</p>
<p>What he offers instead of pity is arithmetic: “It is not that we have a short space of time, but that we waste much of it.” He isn&#39;t telling anyone to slow down. He&#39;s pointing out that you&#39;re running a ledger whether you check it or not, and most of the entries were made by someone else.</p>
<p>Epictetus gives the tool for the ledger itself, and it&#39;s the first thing in the Enchiridion, which is probably why people skip it: some things are within your control — your choices, your judgments, your effort — and some things aren&#39;t: your body, your reputation, your job title, what people say about you in a meeting you&#39;re not in. I use this as inbox triage. Every message splits into two columns. What I say, and when — mine. What the sender thinks of me — not mine, never was. The first column gets my effort. The second gets my attention for exactly as long as it takes to notice which column it belongs in.</p>
<p>The retreat doesn&#39;t fix this, and Seneca already knew it wouldn&#39;t: a weekend away with the laptop in the bag “just in case” is what he calls busy idleness — not leisure, just worry with better scenery. Marcus Aurelius, who ruled an empire and wrote his private notebook in Greek during military campaigns on the Danube frontier, had more reason than most to want a house by the sea, and he talked himself out of it: “Men seek retreats — houses in the country, sea-shores, mountains — yet it is in thy power whenever thou shalt choose to retire into thyself.” A few lines later he defines tranquility as “the good ordering of the mind” — not an absence, something you do.</p>
<p>Read too much of this and it curdles into another productivity system — more discipline, colder showers. So I keep a counterweight on the desk who isn&#39;t a Stoic at all. Epicurus founded his school, the Garden, in Athens around 306 BCE, and it welcomed people the other schools turned away. He defined pleasure narrowly, as “the absence of pain in the body and of trouble in the soul,” and got there through friendship and fewer wants rather than more acquisitions. The point of taking your mind back isn&#39;t to become harder. It&#39;s to have a smaller world to put it in.</p>
<p>None of this asks you to throw the phone in a river. Epictetus was banished from Rome under Domitian&#39;s expulsion of philosophers around 93 CE and simply opened a school in Nicopolis instead. Marcus didn&#39;t retire to a mountain; he reigned until his death, on campaign. Seneca was exiled by one emperor and ordered to his death by the next. They&#39;re useful precisely because none of them got to opt out. What they did was keep the books — noticed who they&#39;d lent their minds to, and took the books back, one morning at a time.</p>
<p>Tomorrow the phone will still be there before your feet touch the floor. You don&#39;t have to decide whether to be a Stoic. You have to answer one question, and answer it before your thumb finds the glass: who gets your mind first today — and did you choose that?</p>
<h2>Sources</h2><ul><li>Epictetus, Enchiridion, trans. Elizabeth Carter (Wikisource)</li><li>Seneca, On the Shortness of Life, Chapters I, III &amp; VII (Wikisource)</li><li>Marcus Aurelius, Meditations, Book II &amp; IV, trans. George Long (MIT Classics Archive)</li><li>Epicurus, Letter to Menoeceus (Wikisource)</li><li>Stanford Encyclopedia of Philosophy — entries on Epictetus, Seneca, Marcus Aurelius and Epicurus</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>Buffer Shock</title>
      <link>https://lavisahu.com/blog/buffer-shock/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/buffer-shock/</guid>
      <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
      <category>Planning in Practice</category>
      <description>One supplier fire hit Nokia and Ericsson in the same week. Nokia checked the supplier&#39;s reassurance and moved first; Ericsson waited and lost its phone business. Buffer isn&#39;t waste: it&#39;s how much of the future you can afford to guess wrong about.</description>
      <content:encoded><![CDATA[<p>On March 17, 2000, lightning struck a power line outside a Philips semiconductor plant in Albuquerque, New Mexico. The resulting fire lasted minutes and was out before the fire department finished driving over. Nobody was hurt. And it nearly took down one of the two biggest phone makers in the world.</p>
<p>The fire&#39;s real damage wasn&#39;t the flame — it was the smoke and sprinkler water reaching a clean room, contaminating millions of chips mid-production. Philips supplied radio-frequency chips to both Nokia and Ericsson, who together took roughly 40% of that plant&#39;s output. Philips initially told both companies the line would be back within a week. It took closer to six weeks, and full output took months longer.</p>
<p>Nokia&#39;s component team escalated the news to senior management within days, pushed Philips for real numbers instead of reassurance, and started qualifying alternate suppliers and re-engineering parts of its own phones to cut dependence on the single plant — before the scale of the problem was even confirmed. Ericsson took the initial “back in a week” estimate at face value and waited. By the time it understood how bad the shortfall actually was, Nokia had already locked up the alternate capacity. Nokia finished the year with profit up 42% and market share reaching 30%; the fire isn&#39;t even mentioned in its annual report. Ericsson booked an estimated $400 million in lost sales and a $200 million operating loss for the quarter, delayed its next phone launch, and within eighteen months had handed its phone manufacturing to a joint venture with Sony. Same supplier, same fire, same week of warning. The difference was entirely in which company treated a supplier&#39;s reassurance as a claim to verify rather than a reason to stop paying attention.</p>
<p>Toyota built its whole production system around the opposite instinct — treat every buffer as a cost to be justified, not a comfort to fall back on. Just-in-time manufacturing and jidoka (stopping the line the instant a defect appears, rather than letting it flow downstream) both came out of Taiichi Ohno&#39;s work at Toyota from the 1950s onward, and the logic was ruthless: inventory hides problems, so shrink the inventory until the problems are visible enough to fix. It works — until a disruption is bigger than the buffer, which is exactly what a 2011 earthquake proved.</p>
<p>On March 11, 2011, the Tōhoku earthquake and tsunami damaged a Renesas Electronics wafer plant that made an estimated 40% of the world&#39;s automotive microcontrollers — the chips that run everything from airbags to engine control. Toyota&#39;s global output fell 78% in April 2011 versus the year before, and the company estimates the disaster cost it roughly 150,000 vehicles of production over the fiscal year. Toyota sent its own engineers to help repair the Renesas plant, because there was nowhere else to buy the part. Seven months later, floods in Thailand — which makes nearly half the world&#39;s hard disk drives and hosts major auto-parts production — cost Toyota another roughly 240,000 vehicles and cut output from Honda and Nissan by a combined 180,000-plus cars. Two disasters, six months apart, on opposite sides of an ocean, both exposing the same lean, single-sourced logic that had made Toyota&#39;s factories the envy of the industry for forty years.</p>
<p>None of this happens in a vacuum, either. Even without an earthquake, orders amplify as they move up a supply chain — a phenomenon Jay Forrester modeled mathematically back in 1961, and which Hau Lee, V. Padmanabhan and Seungjin Whang gave a name and a measurable ratio to in two 1997 papers, “The Bullwhip Effect in Supply Chains” and “Information Distortion in a Supply Chain.” Small, steady demand at the retail end turns into large, erratic swings by the time it reaches a raw-material supplier three tiers up — not because anyone&#39;s lying about demand, but because each tier re-forecasts off the tier above it instead of the real number at the register. I&#39;ve written about how to measure that ratio on your own order data over in the Lab; the short version is that most companies are running a bullwhip they&#39;ve never computed and would be startled by.</p>
<p>Toyota&#39;s answer to 2011, once the immediate crisis passed, was a system called RESCUE — a database mapping roughly 6,800 components across more than 650,000 supplier sites, so a disruption anywhere in that map gets flagged before it becomes a production stoppage. It also moved toward a rougher rule of thumb for critical parts: no more than around 60% of volume from any single supplier, with backups able to absorb the rest on short notice, and two to six months of buffer stock on the parts that are hardest to re-source. That&#39;s a real retreat from pure just-in-time, and Toyota made it on purpose.</p>
<p>Ten years after Tōhoku, the Ever Given ran aground sideways in the Suez Canal for six days in March 2021, blocking an estimated $9–10 billion a day in trade and reminding everyone that the chokepoint doesn&#39;t have to be a factory — a single ship in a single channel is enough. Buffer, in other words, isn&#39;t waste. It&#39;s the amount of the future you&#39;re willing to guess wrong about before it costs you the business. Toyota guessed wrong twice and adjusted the number. Ericsson guessed wrong once and never got the phone business back.</p>
<h2>So what?</h2><p>List the parts you buy from a single plant. Next time a supplier says “back in a week”, ask for the numbers behind it before you plan around it. If you can&#39;t name those parts, that&#39;s your finding.</p>
<h2>Sources</h2><ul><li>Lee, Padmanabhan &amp; Whang, “The Bullwhip Effect in Supply Chains,” Sloan Management Review (1997)</li><li>Lee, Padmanabhan &amp; Whang, “Information Distortion in a Supply Chain,” Management Science (1997)</li><li>Forrester, Industrial Dynamics, MIT Press (1961)</li><li>Harvard Business School case studies on the March 2000 Philips fire — Nokia and Ericsson supply-chain response</li><li>Toyota Motor Corporation, fiscal-year 2012 production-impact disclosures (Tōhoku earthquake, Thailand floods)</li><li>Reporting on Toyota&#39;s post-2011 RESCUE supply-chain risk-mapping system</li><li>Suez Canal Authority / global trade press, Ever Given blockage, March 2021</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>The Perception Gap</title>
      <link>https://lavisahu.com/blog/the-perception-gap/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/the-perception-gap/</guid>
      <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
      <category>Automation for Planners</category>
      <description>AI coding tools make you feel faster. METR actually measured it, and the measurement disagrees with the feeling — by 39 points.</description>
      <content:encoded><![CDATA[<p>In July 2025, the AI-evaluations lab METR ran a randomized controlled trial that should have been a victory lap for AI coding tools and instead became one of the most-cited cautionary numbers in software. Sixteen experienced open-source developers, working in codebases they&#39;d maintained for years, were randomly assigned 246 real tasks — some with AI tools allowed, some without. Afterward, the developers guessed they&#39;d been about 20% faster with AI. The actual measurement: they were 19% slower.</p>
<p>That&#39;s a 39-point gap between how fast developers felt and how fast they actually were, and it&#39;s the most interesting number in the study — more interesting than either headline figure on its own. The slowdown showed up specifically on familiar, complex work inside large, mature codebases; the study&#39;s own authors noted the same tools can produce real speedups, on the order of two to five times, on greenfield projects, boilerplate, and test scaffolding. The problem wasn&#39;t the tool. It was using the tool on work it wasn&#39;t suited for, and not noticing.</p>
<p>METR tried to replicate the result in a follow-up starting in August 2025, hoping to track how the picture changed as tools improved. It didn&#39;t work cleanly: developers who knew they might be assigned to the no-AI control group increasingly opted out of the study rather than accept the control condition, which quietly biased whoever remained. METR was explicit that the result was an unreliable signal — not a reversal, not a confirmation, just noise they couldn&#39;t stand behind. Any claim that a 2026 follow-up proved AI tools now speed developers up is reading confidence into a dataset METR itself flagged as unusable.</p>
<p>The other number worth trusting more than either METR result is older and cleaner: a February 2023 randomized trial by Peng, Kalliamvakou, Cihon and Demirer gave developers an identical task — build an HTTP server in JavaScript — with and without GitHub Copilot, and measured a 55.8% speed gain for the Copilot group. That&#39;s a real, replicated result, and it isn&#39;t in tension with METR&#39;s finding; it&#39;s a different kind of task. Building something from a blank file is exactly the kind of greenfield work where AI tools are least likely to fight you.</p>
<p>The volume of AI-authored code inside the companies building these tools has climbed fast, and it&#39;s one of the more verifiable numbers in this space because it comes straight from the source: Google&#39;s leadership has stated that AI generated or suggested roughly 25% of new code internally as of late 2024, rising past 50% by late 2025 and to about 75% by April 2026. Whatever fraction of that is genuinely load-bearing versus autocompleted boilerplate, the trend line is real and it&#39;s steep.</p>
<p>Where the numbers get harder to look away from is hiring. Stanford&#39;s Digital Economy Lab, working from ADP payroll data covering millions of workers, found that employment for software developers aged 22 to 25 fell by nearly 20% between its late-2022 peak and mid-2025, while employment for experienced developers in the same roles held steady or grew. Indeed&#39;s job-posting data shows entry-level tech postings down 25% year over year in 2024, and a SignalFire analysis put new-graduate hiring at large technology companies down 25% in 2024 versus 2023. None of these studies can prove AI coding tools are the sole cause — hiring is never one-variable — but the pattern across independent data sources, academic, payroll and job-board alike, is consistent enough that coincidence is a harder position to hold than it was two years ago.</p>
<p>Put together, the honest shape of the story is less dramatic than either the boosters or the doomers want: AI tools make some kinds of coding work meaningfully faster, make some kinds of coding work slower while feeling faster, are eating a fast-growing share of the code written at the companies that build them, and are arriving at the same moment the bottom rung of the software career ladder is getting harder to find. All four of those are true at once, and none of them needed a fabricated citation to make the case.</p>
<h2>Sources</h2><ul><li>METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (July 2025)</li><li>METR, 2025–2026 productivity follow-up notes (author-flagged as an unreliable signal)</li><li>Peng, Kalliamvakou, Cihon &amp; Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” arXiv preprint (February 2023)</li><li>Google leadership public statements on internal AI-generated code share (October 2024, late 2025, April 2026)</li><li>Stanford Digital Economy Lab / ADP Research Institute, early-career employment analysis in AI-exposed occupations (2025)</li><li>Indeed Hiring Lab, entry-level tech job-posting trends (2024)</li><li>SignalFire, State of Talent report — new-graduate hiring at technology companies (2024)</li></ul>]]></content:encoded>
    </item>
    <item>
      <title>The Kerning Room</title>
      <link>https://lavisahu.com/blog/the-kerning-room/</link>
      <guid isPermaLink="true">https://lavisahu.com/blog/the-kerning-room/</guid>
      <pubDate>Wed, 23 Sep 2026 00:00:00 GMT</pubDate>
      <category>Margins</category>
      <description>A font is supposed to disappear. The best story about typography is what happens on the rare day it doesn&#39;t.</description>
      <content:encoded><![CDATA[<p>On July 4, 2012, CERN announced it had found strong evidence of the Higgs boson — a scientific result forty years and several billion dollars in the making — and did it on slides set partly in Comic Sans. Within an hour, “Comic Sans” was trending on Twitter ahead of “God particle.” Nobody disputed the physics. The internet was distracted by the typeface, which is itself the whole argument for why typefaces matter: the choice was loud enough to compete with a discovery about the fundamental structure of matter.</p>
<p>Comic Sans wasn&#39;t built for that room. Vincent Connare designed it at Microsoft in 1994 for Microsoft Bob, a friendly interface aimed at new computer users, after deciding that Times New Roman looked wrong coming out of a cartoon dog&#39;s speech bubble. It shipped as a casual, rounded font built for exactly one register: informal. CERN&#39;s slide wasn&#39;t wrong because Comic Sans is a bad typeface — legibility researchers have defended it for years for dyslexic readers. It was wrong because a typeface carries a register whether you intend it to or not, and a discovery about the universe&#39;s mass mechanism and a cartoon dog don&#39;t share one.</p>
<p>The designer Beatrice Warde made the opposite case ninety years earlier, in a speech to London&#39;s typographers in October 1930 still handed to design students under the title “The Crystal Goblet.” Her argument: a glass of wine should be served in crystal, not a jeweled goblet, because you want the wine, not the cup, to hold your attention — and printing should work the same way. “Type well used is invisible as type,” she said. Most of the time, that&#39;s the entire job: get out of the reader&#39;s way.</p>
<p>Most of the time isn&#39;t all of the time, though, which is where Massimo Vignelli&#39;s stubbornness comes in. Vignelli designed the original New York City subway map and much of the 1970s corporate identity for American Airlines and Knoll, almost always in Helvetica, and defended the choice with something close to a dare: “You can say, ‘I love you,’ in Helvetica. You can say it with Extra Light or Extra Bold.” His claim was that a single, disciplined typeface family, used with total consistency, can carry more range than most designers give it credit for — that the personality lives in the weight and the spacing, not in switching fonts every time the mood changes.</p>
<p>London&#39;s Underground made almost the same bet a full sixty years before Vignelli, and it&#39;s still paying off. Edward Johnston designed the original Johnston typeface for the Underground Group in 1916; Eiichi Kono redrew it as New Johnston in 1979 to survive modern printing. It&#39;s been in continuous use on every sign, map and poster for over a century, making it one of the longest-running corporate identities anywhere — not because anyone protects it out of nostalgia, but because Transport for London has never found a reason a passenger would notice if it changed.</p>
<p>IKEA found out what happens when a company does swap it out. In 2009 the catalog moved from a customized Futura — geometric, disciplined, on-brand for fifty years — to Verdana, a typeface Microsoft designed specifically for legibility on low-resolution screens. IKEA&#39;s stated reasons were practical: Verdana rendered consistently across every language and script IKEA sells in, and it was effectively free to license at IKEA&#39;s print volume. Designers objected loudly anyway, because a font built to survive a blurry monitor is not the font most would choose to represent fifty years of design discipline — and the mismatch between the typeface&#39;s original purpose and its new job was exactly the kind of thing ordinary customers aren&#39;t supposed to consciously notice, and did.</p>
<p>The clearest demonstration that readers notice typefaces without knowing they&#39;re noticing came from an unlikely source: a 2012 New York Times experiment by documentary filmmaker Errol Morris, run as a fake personality quiz so the roughly 45,000 people who took it wouldn&#39;t know what was actually being tested. Everyone read the same paragraph, arguing that Earth faces unusually low odds of being destroyed by an asteroid — the only variable was which of six typefaces it appeared in. Readers presented with the passage in Baskerville were consistently more likely to agree with it than readers who saw it in Helvetica, Comic Sans, or three other faces — a small but statistically real “Baskerville effect” of roughly one to two percentage points. Nobody in the study could have told you why they believed what they read. The typeface was doing work underneath the sentence, exactly the way Beatrice Warde said it should — except this time it wasn&#39;t invisible, it was persuasive, and the two turned out to be closer to the same thing than anyone likes to admit.</p>
<p>AIGA, the main U.S. professional body for graphic design, now lists typography as one discipline among a couple dozen it recognizes — next to branding, motion design, UX and information design — which is really just an admission of how far the job has spread since Warde&#39;s crystal goblet. But the goblet argument hasn&#39;t aged out. Most type, on most days, should still disappear. The interesting cases — CERN&#39;s slide, Vignelli&#39;s Helvetica, the Underground&#39;s century-old letters, IKEA&#39;s font swap, Morris&#39;s fake quiz — are interesting precisely because they&#39;re the exceptions, the days the glass turned out to have a taste of its own.</p>
<h2>Sources</h2><ul><li>CERN and contemporary press coverage of the July 4, 2012 Higgs boson announcement and its Comic Sans slide</li><li>Beatrice Warde, “The Crystal Goblet, or Printing Should Be Invisible” (address to the British Typographers&#39; Guild, 1930; published 1955)</li><li>Massimo Vignelli, interviews and The Vignelli Canon (2010) on Helvetica usage</li><li>Transport for London / London Transport Museum — Johnston and New Johnston typeface history</li><li>Design-press reporting on IKEA&#39;s 2009 Futura-to-Verdana catalog typography change</li><li>Errol Morris, “Hear, All Ye People; Hearken, O Earth,” New York Times Opinionator (2012) — the Baskerville typeface-trust experiment</li><li>AIGA, design discipline taxonomy (aiga.org)</li></ul>]]></content:encoded>
    </item>
  </channel>
</rss>
