It keeps showing up in my one-on-ones, usually in the last five minutes, almost as an apology: some version of “I feel like I’m falling behind on AI.” It took me embarrassingly long to notice the pattern. It’s never the stragglers who say it. It’s my strongest leaders and engineers, the people furthest into the tools, the ones everyone else quietly benchmarks against.

They’re not alone. An engineer on Hacker News put the same feeling in one line this February, in a thread that climbed the front page:

“I can make meaningful progress on half a dozen projects in the course of a day now, but I end the day exhausted.”

Hundreds of people chimed in underneath. Shipping more than ever, feeling further behind than ever.

I hear the same note from a director who runs several teams and from an engineer three levels down, and the odd privilege of this seat is getting to watch the pattern form: the people who feel it worst are the ones the data says should feel it least.

So let me give you the measurement I offer them. If you, or your teams, are driving AI through code, through agents, through loops that run while nobody watches, you are not behind. Measured against everyone who uses AI, that’s the top five percent. The power users. And in this tier, power means what you get done with it.

The feed is not the field

Step out of the timeline and look at what AI actually is for most of the world. It’s a chat box. It drafts an email, summarizes a document, rescues dinner. When OpenAI looked at how people really use ChatGPT, coding turned out to be about four percent of the messages. Drafting email alone was three times bigger. That’s messages, not people, but the picture is hard to miss: the average AI user is asking for recipe tweaks, not Python scripts.

Meanwhile somebody on your platform team is at 11 PM arguing with an agent about a failing test.

Both of those count as “using AI.” They are barely the same activity. And every serious attempt to measure it keeps finding the same shape: a small tier using these tools in a fundamentally different way, and a long tail using them like a smarter search bar.

Call the tier five percent. You know who yours are.

The line is the loop

What separates that tier isn’t intelligence, and it isn’t even code, exactly. The line is whether you build systems AI runs, or ask it questions one at a time. The ninety-five percent chat. The five percent close the loop: hand the model a task, give it a way to check its own work, and let it run. Code is just where that comes most naturally, because tests pass or they don’t, and because code is the tool that can drive every other tool. I made the longer version of this argument in “What the Hell Is Loop Engineering?” The loop is the thing. The syntax is optional. And the reason any of it matters isn’t elegance: a closed loop is a problem that stays solved while you sleep.

I still run a small loop of my own some weekends, not to ship anything, but to keep my questions sharp when my teams show me theirs. And what strikes me every time is how old this pattern actually is. Every office I’ve ever worked in had this person before AI existed. Most of us used a tenth of what Excel could do; somewhere down the hall sat the one who wrote the macros that quietly ran the department. “Power user” has been a word since 1984, when it was mocked as a label for show-offs typing convoluted commands. The mockery aged badly. The pattern didn’t. The power tier was always the tier that scripted, and AI just moved the threshold.

Why being ahead feels like falling behind

Because the reference class is the feed, not the field. The person across from me in that one-on-one isn’t comparing herself to the median AI user rescuing dinner. She’s comparing herself to the loudest demos on her timeline, posted by the other members of the five percent. (On my feed, apparently, nobody’s demo ever fails.) Scientists have it too; Nature ran a poll of researchers this June under the headline “Scientists have a bad case of AI FOMO.” The fear of falling behind is now better documented than the falling behind.

And the feeling genuinely isn’t a measurement. The one careful study I know that put developers on the clock found the ones who felt noticeably faster with AI had actually been slower. The tools have improved since, but the gap between the feeling and the measurement is the part that stays. I bring that up in leadership conversations a lot lately, because half of them now include some version of “are we behind?” My read, after watching this across every team I have: the anxiety is real, widespread, and almost perfectly uncorrelated with who is actually behind.

What the five percent are for

They’re for pointing at the other ninety-five, not for winning the feed.

My favorite example of how crossable that line is sits on a lawyer’s desk at Anthropic. It’s a vintage payphone. Tap it with a coin and it rings; an AI picks up, asks what you need, and connects you to the right attorney for it. A silly object solving an expensive problem: getting a company’s questions to the right lawyer without anyone playing switchboard. The person who built it is one of their lawyers. Not an engineer. Doesn’t code. He made it with an AI coding tool by describing what he wanted, trying what came back, and fixing it until it worked. His own summary is the line I keep repeating to my teams: “I am not the one coding. I’m just very good at troubleshooting.”

If a lawyer can build a phone system, the price of admission is a real problem and the patience to troubleshoot, not a computer science degree. And there is no shortage of problems: when one state government piloted AI tools, nearly half the employees had never opened ChatGPT before. Mostly a backlog of easy wins, waiting to be picked up.

That’s where leaders come in.

Every organization now has its five percent. The waste I worry about isn’t falling behind; it’s letting that tier spend its edge racing each other, or worse, performing adoption for the metrics, while the invoices, the tickets, the weekly reports, the unopened seats sit exactly where they’ve always been. Finding yours takes one question, in a standup or a skip-level: who automated something last month that nobody asked them to automate? Then hand that person one recurring, unglamorous workflow as a real mandate, with time attached, and watch what a closed loop does to it. And when you check on it, measure the one thing the feed never shows: the value it unlocked, not the usage it logged.

Because that’s the bar, and it’s the one to hold your own feeling against too. The feed measures noise: demos, launches, tokens. What matters is the problems you make disappear. That exhausted engineer ran every loop available and still ended the day feeling behind. Wrong scoreboard. Hold your teams to the value bar and the anxiety turns into a roadmap. Hold yourself to it and the feed gets a lot quieter.

So, no. Your best people are not behind, and neither are you for spending your days enabling them instead of typing next to them. They’re rare. Five percent rare, and rare turns valuable the moment it’s aimed at something that matters. The job now is pointing that edge outward, at the ninety-five percent of work nobody on any timeline is demoing.

Here is my question for Monday: do you know who your five percent are, and what problem are they solving with all that power?

#AI #EngineeringLeadership #PowerUsers #AIAdoption #FutureOfWork #Leadership

There’s a guy at my Dunkin’ who’s got the morning figured out better than I do.

Same spot every day, closest to the counter, first to grab the app orders the second they’re up. While the rest of us are still at the kiosk deciding between a medium and a large, he’s already got the bag and pulled out of the lot. I’ve watched him for months. The man runs a system.

For as long as I can remember, he drove a beaten-up Toyota that had earned its retirement. Dents. A bumper attached by intention more than hardware. He was busy, working, doing fine.

Then a few weeks ago the old Toyota was gone, and a brand-new one sat in his spot.

“New car?”

“Yeah. Finally.”

“Honestly, I had you figured for a used-car guy. Just like me.“

He laughed. “Everybody says that.”

I meant it as a compliment, which is the part I keep coming back to. I’m a numbers guy, and naturally a used-car guy. Hand me his situation and I’d open a spreadsheet before I opened the car door. Buy new? Never. You let the first owner eat the depreciation and you buy the three-year-old version of the same car. Lowest total cost of ownership. That’s the move. I was sure he’d see it the way I do.

“You know how many miles I put on this?” he said. “Two hundred a day, some days. Call it thirty, forty thousand a year. A used one’s already half gone. I buy new, run it into the ground, don’t think about it in between.”

“Still,” I said. “The second you drive it off the lot...”

“You only lose that money if you sell. I’m not selling. I’m driving this one till it dies.”

He’d already walked to the end of my argument and come back. Then he said the part my spreadsheet didn’t have a line for.

“I can’t be thinking about the car. Every morning I’m wondering if it’ll start is a morning I’m not working the good orders. The day it’s in the shop is a day I earn nothing. I bought new so I’d stop thinking about the car and think about the work.”

He wasn’t buying comfort. He was protecting his attention, which is the thing that actually earns him money. The new car wasn’t a cost he was overpaying. It was the cheapest way to keep his head on the work that pays.

I drove home thinking about how fast I’d filed his decision under “mistake.”

It’s easy to call a decision reckless when you’ll never have to live with it.

Certainty isn’t context

I wasn’t unsure. I didn’t think maybe he was wrong. I was certain, in about four seconds, standing at a counter holding a coffee. The certainty felt exactly like being right. It had nothing to do with whether I actually knew anything.

He had context I didn’t have. A couple hundred miles a day. No cushion. A car that was the floor he stood on all day. None of it was on my spreadsheet, and my spreadsheet was the whole basis for being sure. My math wasn’t even the right math. I’d added up what the car would cost. He’d added up what the old one was already costing him.

Every morning it might not start, every day in the shop, every hour his head was under the hood instead of in the work. Once you count that, the expensive car was the cheaper one. The things I’d waved off as soft were his time and his focus and the relief of not starting every day in a hole. None of it sat outside the numbers. It was the most valuable number on the page, and I’d left it off.

We’re trained to be sure

I do this at work more than I’d like to admit. And I don’t think it’s only me.

We’re paid to make the call.

To look at a situation, reach a conclusion, and move. We get good at it, and being good at it starts to feel like being right. Nobody gets promoted for saying “let me sit with that until I understand it.” So we learn to be fast, and we learn to be sure, and we quietly stop noticing that fast and sure were never the same thing as informed. It’s the four-second certainties that cost the most. The calls you never agonized over, never went back to check, because being sure felt like the work was done.

TCO was never just the cost

And we’re sure so easily because we judge with the numbers we happen to have. The numbers we have measure cost. They almost never measure return.

We love total cost of ownership. On paper it’s something like a vendor contract: the license fee, the seat price, the number on the quote. We pick the cheaper option, feel disciplined, and move on.

But TCO was never only cost. It’s also the return, and the return includes the hour a day your team loses fighting the cheap tool, whether they end the week sharp or wrung out, where their attention goes when the thing just works versus when it doesn’t. All of that gets filed under soft. It’s actually the part that decides whether the thing was worth it. It just doesn’t fit in a cell, so we leave it off the page, the same way I left it off the driver’s.

Watch how often it shows up. The engineer who wants a week to make a flaky system boring and reliable, when there’s a feature waiting on the roadmap. The team that wants the platform you’ve already decided is overkill. The senior who keeps pushing on a deadline you’re sure is fine.

On my numbers, every one of those is waste. But they’re the ones in the seat. They’re the ones counting the 2 a.m. pages, the rework, the slow bleed of good people who got tired of building on top of something broken. They’re running fuller math than I am. They just can’t always show me the cells, because the most important ones don’t have a column.

What it costs to always be right

None of this means everyone who pushes back is right.

Sometimes the expensive call really is reckless, and part of the job is knowing the difference. Usually the difference is easy to hear: the person running real math can tell you what the cheap option will cost you, not just what they’d rather have instead. The point isn’t to stop deciding. It’s to catch the four-second certainty for what it is, and to spend one more question before overruling the person closest to the work:

• Do I have the context here, or just the conclusion?

• Am I the one who’ll have to live with this, or only the one judging it?

• What are they counting that I’m not?

Because the real cost of getting this wrong isn’t one bad call. Every time you overrule the person in the seat on a number that was only ever half the equation, you teach the people who understand the work best that their context doesn’t count, so they stop bringing it to you.

And slowly you optimize your org into the cheapest, most confident version of itself, run by the people least able to see what your spreadsheet is missing.

He wasn’t just like me. Most people aren’t. And the ones I’m quickest to correct are usually running fuller math than I am.

#Leadership #EngineeringLeadership #EngineeringManagement #DecisionMaking #TotalCostOfOwnership #ROI #Management #TeamCulture

The best loop engineer in my house is a rice cooker. The Japanese one, with the little elephant on the lid. (And no, this is not a sponsored post.)

I thought about it this week because my feed filled up with the same idea in different outfits: stop prompting your AI agents; design loops that prompt them. The engineer who created Claude Code says he doesn’t prompt Claude anymore. His loops do. Riding on top of it all, a brand-new phrase: loop engineering. The practice it names has been building quietly at the frontier for a year or more; the word just caught up.

Every time a new term shows up wearing a jacket two sizes too big, I try to explain it to myself in plain English. This time I didn’t have to look far. The explanation was sitting on my kitchen counter, wearing an elephant.

You Are the Loop

Start with how most of us use AI today. It looks exactly like cooking rice in a pot.

You put the rice on, and now you’re committed. You hover. You lift the lid. You poke, taste a grain, turn the flame down, set a timer in your head, come back, taste again. The rice gets cooked, sure. But let’s be clear about who did the cooking. The pot held the heat. You were the loop.

That’s prompting. You ask, read what came back, adjust, ask again, and at some point decide it’s good enough to stop. The model is the pot. You are the loop. Which is why “prompt engineering” quietly stopped being the whole job: the prompt was never the expensive part. The hovering was.

You can hear the ratchet click. First we engineered prompts, the words. Then context, what the model gets to see. Now loops, what the model does next, again and again, without us. Each layer exists because the one before it hit a wall.

The Rice Cooker Doesn’t Hover

Now watch the machine do the same job.

With my rice cooker, every decision happens before anything cooks. I pick the menu: white, brown, sushi, porridge. I pick the texture; the elephant offers five, from softer to firmer. Then I press start and walk away. There’s nothing left for me to do. The machine owns the middle. And mine is the pressure type, so I couldn’t hover if I wanted to: once it pressurizes, the lid locks. No peeking. No poking. The pot stays sealed until the machine decides the job is done.

Under that lid, it’s running the same cycle I used to run by hand: do a step, look at what actually happened, decide. Heat the pot; read the temperature; keep going or shut off. For an AI agent, swap the verbs: run the code, read the test results, then re-prompt, declare done, or wake a human.

That’s it. That’s the loop.

A small, boring program that does the hovering for you. It prompts the agent, reads what came back, and decides whether to go again. The people building these aren’t writing better prompts. They’re building rice cookers.

And the good ones pressure-cook. A sealed pot raises the boiling point past anything an open pot can reach, which is why pressure-cooked rice comes out more tender. A well-built loop does the same thing to your work. It runs every test on every pass. It rereads the whole change every time. It keeps going at 2 a.m. That’s the part people miss: the loop can do more than replace your hovering. It can out-cook you.

Loop engineering, in one line: designing the thing that watches the pot, and sets the pressure, so you don’t have to.

How Does It Know the Rice Is Done?

This is the question that separates a toy from a tool, and the rice cooker’s answer is my favorite part.

The original rice cookers had no timer. They couldn’t see the rice. They knew one fact of physics: as long as there’s water in the pot, the temperature can’t rise past boiling. The moment the water is gone — absorbed, done — the temperature spikes. The cooker feels the spike and shuts off. It doesn’t guess. It measures.

AI loops live or die on the same question. Making a loop go is easy; making it stop at the truth is the craft. The teams who’ve been at this the longest use two mechanisms, neither exotic. First, they write down what “done” means before anything runs. Anthropic’s engineers gave one long-running agent a checklist of 200-plus requirements, every one marked failing on day one; the loop’s job was to turn them green. Done is a list, written before the pot goes on. Second, the cook doesn’t grade the rice. A separate, smaller model checks after every pass and answers one question: is it actually done? The heating element heats. The sensor decides. Never the same part.

(If this sounds like test-driven development wearing a new jacket: yes. The difference is who’s reading the tests now.)

But rice comes with a boiling point. Code doesn’t. So the whole craft of loop engineering is building one: a signal so unambiguous the loop can’t talk itself past it. The physics won’t save you. You have to write the physics.

If you live in the AI world, this should look familiar: it’s how the models themselves get trained now. The labs call it reinforcement learning with verifiable rewards (RLVR). Instead of a person or another model scoring the output on feel, the reward comes from a check that can’t be argued with. The answer matches or it doesn’t. The tests pass or they don’t. AI researcher Jason Wei wrote it down as a law last year: the easier a task is to verify, the faster AI gets good at it. Rich Sutton said the quiet part back in 2001: an AI can only maintain knowledge to the extent it can verify it itself. Same principle, two altitudes. The labs use the unarguable check as the reward that trains the model. Your loop uses it as the latch that unlocks the lid.

You Already Run This Loop

If this still feels exotic, look at your own calendar.

You already run a loop. You’ve run it for years. It’s called a sprint. The goal you write at planning is the stop condition. The acceptance criteria are the checklist, red until they’re green. Velocity and burndown are the temperature readout. The review is the taste test. The retro is you adjusting the flame. Then the loop goes again.

Loop engineering is your sprint cycle with the clock speed turned up, from two weeks to two minutes, with a machine running the ceremony. Which is why I’d bet on the leaders in the room, not just the engineers: you’ve spent a career learning what a good goal, an honest metric, and a real retro look like. That’s the exact skill the loop needs. This is closer than you think, and simpler than the jacket makes it look.

Undercooked, Overcooked, Forgotten

Simpler doesn’t mean safe. Remember the trade you just made: the lid is locked, and nobody’s watching mid-run. Whatever hovering used to catch, design has to catch now. So before you trust one, it’s worth knowing how loops fail. They fail in kitchen-shaped ways.

• Undercooked: a cooker that stops at twelve minutes stops at twelve minutes, ready or not. Crunchy rice. Agents do this. Anthropic documented one that came back mid-project, saw progress, and declared the whole job finished. It wasn’t.

• Overcooked: no stop signal at all, and the loop keeps going past done. Confidently. At machine speed. While you sleep. Good work cooks down into mush, and nobody can uncook mush.

• Forgotten: long loops lose the plot, because the model’s short-term memory fills up mid-run. The fix is humble: the loop keeps notes outside itself, a progress file, a commit log, the way you’d leave a note on the counter. Rice on, started 6:40. They put an elephant on the lid for a reason. The loop, unlike the elephant, forgets.

And let’s say the quiet parts out loud. Loops eat tokens; a loop that runs all night bills like it ran all night, and every pass rereads the kitchen. Most teams aren’t ready, and not because the tech is exotic: if nobody can write down what “done” means, the loop has nothing to check. And a loop amplifies whatever you already are. DORA’s 2025 research found that AI magnifies an organization’s existing strengths and weaknesses. A loop with weak verification just ships your dysfunction faster.

If those complaints sound familiar, they should. Continuous integration got the same reception when it showed up: too expensive, not ready, why would anyone run every test on every change. It was also the first loop we ever trusted with our code, every commit ending in a red or green verdict with no feelings attached. Nobody would build without it now. The agent loop is the same idea with a bigger appetite, and the teams that learn to write the physics early are the ones it will pay off for.

Why I’m Telling You This

I don’t write these loops, outside a couple of pet projects that exist mostly for fun. My job is to support the people who will. Most of my team isn’t writing them yet either, and the reason is simple: the prerequisite isn’t code. It’s the rice-cooker question, and it’s harder than it sounds: can you write down what “done” means, in a form a machine can check? I made this argument in The Player in Street Clothes: the bottleneck isn’t generating the code anymore. It’s knowing whether the code should ship.

One honest footnote. “Loop engineering” might not even be the name that sticks; some camps call the same thing harness engineering. The word may not survive the year. The rice cooker will.

That’s loop engineering, minus the jacket. Stop standing over the pot. Build the thing that watches it. Set the pressure higher than you could hold by hand. And spend your real effort on the only question that matters: what’s the temperature spike that proves it’s done?

So here is my question for you this week. Think about the last thing your team shipped with AI in the loop. Who decided it was done — a measurement, or a feeling?

#Leadership #AI #LoopEngineering #AIEngineering #EngineeringLeadership #FutureOfWork

Fifteen years ago today was the last time I saw Steve Jobs in person. I was too embarrassed to admit I knew the guy sitting next to me (not to be named here ;-) ) — the one yelling “Steve, we love you” in the first few seconds of the WWDC 2011 keynote recording. I pretended we’d come in separately.

The last time I saw Tim Cook in person, I bumped into him in the parking lot at the Stanford Dish. He said hi. I barely recognized him, mostly surprised. A few weeks later he announced he was stepping down.

On Monday, Cook gives his last keynote as CEO. The Apple between yelling for Steve and walking past Tim is the Apple he’s handing over. The distance between those two moments tells you almost everything about what got built in between.

The Question Underneath the Handoff

Apple named the successor back in April: John Ternus, the hardware engineering leader who led the Apple Silicon transition, takes over September 1. The coverage is treating Monday as a farewell, or an AI reckoning, or a Siri redemption tour. Underneath all three sits a question nobody on stage will say out loud.

What did the operator era build? And what does the engineer era have to finish?

That’s not only Apple’s question. It’s the one you answer every time you hand off your own platform: when you step away, does your successor inherit what you actually built, or only what everyone could already see?

The answer is in the fifteen years between those two keynotes.

The Empire Everyone Saw

The Cook era reads as boring until you list it.

Market cap in 2011: about $300 billion. Today: north of $4.5 trillion. Cook’s tenure added roughly fourteen Apples to Apple.

The portfolio that didn’t exist when Jobs walked off the stage: Apple Watch, now the largest watch company on earth, with a hypertension-detection feature that cleared FDA review this past fall. AirPods, a multibillion-dollar line that started as a joke in the tech press. Services, a record $30.98 billion in a single quarter, an annual run-rate bigger than most of the Fortune 100. Vision Pro, a beta of a category nobody else has dared ship at this fidelity.

Cook’s tenure looked invisible because the operator’s job, done well, looks invisible. The yells happen for visionaries. The hi-in-the-parking-lot happens for the operator who turned the visionary’s company into the largest commercial enterprise in human history without anybody noticing the part where he did it.

I’d met him years before, also at WWDC, introduced by great friends of mine at Apple at the time. I forgot the encounter ten minutes later. He didn’t say much. Smiled, walked off. That’s the operator at peak performance. The person you forget you met.

And the person you forget you met spent those same fifteen years building something just as easy to overlook, not in the products everyone saw but in the layer underneath them.

The Surface Behind the Scene

If you ever write iOS code, you’ve shipped against every framework I’m about to list. None of it was hidden. What nobody read was the shape across all of it.

Whatever Apple unveils Monday (the leaks call it App Intent Domains) won’t be a 2026 invention. It’ll be the latest version of a framework family Apple has been extending since iOS 5. For readers who don’t write Apple code: every name below is a version of the same idea. The operating system asks each app to declare what it can do, so it can route a user’s intent to the right app.

• iOS 5 - The first version shipped in 2011 as MPNowPlayingInfoCenter, the lock-screen surface that lets the system ask any app “what are you playing right now?” without the app being open. Steve Jobs announced it at the WWDC keynote on June 6, 2011 — the one I sat in. That surface turns fifteen years old today.

• iOS 8 added NSUserActivity in 2014, a related way to hand off what a user was doing from one device to another. I remember that one up close: my team spent a stretch locked in an Apple office getting it to surface in our app’s new Apple Watch experience. The pattern was reaching beyond media.

• iOS 10 gave it a name in 2016: Intents, shipped as SiriKit. Messaging, calls, payments, ride-booking. Fixed domains, but the leap was real: apps could now declare what a user wanted to do, not just what they were doing.

• iOS 16 rewrote the whole thing in Swift as App Intents in 2022. One declarative struct, one perform method, and the system drove Shortcuts, Siri, Spotlight, Focus, and widgets from it.

• iOS 27, on Monday, is the expected next step: cross-app delegation, where the user would pick which app gets the messages domain, which gets the calendar, which gets the photos. Apple would stay at the lintel of every door.

Five generations of one idea, across fifteen years.

This is what the operator era was building underneath the visible products: a surface. The surface that turns your messages, your calendar, your photos, your contacts into something an app can act on as a delegate, with you controlling which slice each app gets. It’s why Apple can enter the AI race from behind and stay credible: they were laying the surface while everyone else raced models.

The Key isn’t Being First

Apple is late to AI. It was late to the MP3 player, the smartphone, and the smartwatch too; being first has never been the job. And the model itself is already a commodity: Apple reportedly pays Google around a billion dollars a year for a custom Gemini model to power the Siri it’s expected to relaunch, and when the company that outsources nothing rents the brain, the brain isn’t the moat anymore.

The real game is the one nobody has won yet -

Give AI enough context to be genuinely useful, without breaking the promise that the context stays yours. Enablement and privacy, at the same time. Almost everyone picks one.

Watch the tools you already use - pick one. I write almost everything by voice now, including most of the prompts behind it. The tool that lets me is Wispr Flow, and it’s good; it crossed from transcription to comprehension, from what you said to what you meant. (I wrote about that in Talk to Think earlier this year.) But it fails the balance in both directions at once. Inside its own sandbox it over-shares: most of what I say goes to its cloud, and what happens to it there was never really mine to control. Across sandboxes it’s blind: it doesn’t know who Eric is, can’t see my calendar, can’t connect a voice-thought to the rest of my context. Too exposed on one side, too blind on the other.

Walking that line is a job for the operating system, the one place that sits above every app’s sandbox and beneath the user’s trust. Microsoft and Google hold that position too, but Microsoft built Copilot on an OS people associate with telemetry, and Google’s privacy posture is the one Apple spent fifteen years differentiating against. Of the three, only Apple’s privacy bargain is already pre-trusted.

That pre-trust is the moat. A competitor could copy the surface; what nobody can buy in a year is the standing permission users have already given Apple to sit in the middle of their lives. The surface is how Apple spends that permission. If it works the way the leaks describe, you’d hand an app one domain at a time and revoke it the same way, on-device models doing the comprehension where they can, Private Cloud Compute taking the harder reasoning under enclave. AI gets the context; the context stays governed. It’s also why renting Google’s model doesn’t break the promise: Google’s model can do the thinking, but the context it thinks about never leaves Apple’s governance.

Some will read that as Apple walking back the privacy bargain. Others as Apple keeping the wall. Both miss it. The move is to become the layer that lets AI in and holds it accountable, the governance no single app can run, because no single app sits where the OS sits.

So it comes down to execution, which is exactly where trust is won or lost. If Apple ships it Monday, the keynote won’t tell you whether they nailed the balance. It’ll show you: the partner list, the consent flow, how granular the per-domain control feels. Nail it, and being late never mattered. Fumble it, and the third-party tools keep eating the slice Apple built the device for. Either way, Cook hands Ternus an answer that’s only half-installed, and asks him to finish it.

The Era Ends with a Hi from Someone You Didn’t Recognize

The era of “Steve, we love you!” is over. The era of the parking-lot hi is what happens when the operator hands the surface forward and the engineer inherits the fork. Whether Apple wins the AI layer comes down to whether Ternus finishes the underwriting Cook started, and whether enough people trust the company to delegate one domain at a time. The walled garden I wrote about a while back is about to become the governance perimeter for the model era.

So the question I’d leave you with this weekend isn’t about Apple. It’s the one from the top, turned around on you.

What’s the surface your team has been building for years that the rest of the org can’t see? And when your successor walks into your role, what do they inherit — the thing everyone loves and yells out loud about, or the thing underneath that nobody knew you were quietly shipping the whole time?

#Leadership #AI #FutureOfWork #Apple #WWDC #AppleIntelligence #EngineeringLeadership

Three weeks ago I closed a post on the Lean Discipline of AI Adoption at Settle — graduate from explore to exploit. DORA’s 2025 numbers landed the same week. Individual AI output up 21%. PR review time up 441%. Almost a third of pull requests now merging with no review at all.

The generation side of your team’s workflow shifted left. The verification side stayed where it was.

I owe you the discipline that closes that gap. Shift-left has waited 25 years for tooling that could carry it past testing. Larry Smith coined the term in Dr. Dobb’s Journal in 2001, framing it as “a better way of integrating the QA and development parts of a software project.” Each wave that came after moved exactly one discipline because the calendar set the ceiling. Testing in the 2000s. Security in the 2010s. Observability in the early 2020s. Designers, PMs, business operators, the customer — they never got a wave. There was no third option. There is now, and it’s agentic.

Coding agents make it economical to run every stakeholder’s review at every checkpoint, calibrated against the humans those reviews represent.

The discipline I want to give you next is called Lane Review.

A lane is the review you couldn’t afford before

For 25 years you couldn’t put a designer in every PR review. You couldn’t put a PM in every commit. You definitely couldn’t put your customer’s compliance officer in front of every diff. Those reviews stayed batched at the milestone, three weeks downstream of the decisions they would have caught.

A lane is what you build when a non-engineer’s review becomes cheap enough to run at every checkpoint your work passes through. An agent with its own context window, loaded with the role’s actual grounding documents, returning findings tagged by severity. The designer who knows your brand system. The PM who knows your locked positioning. The business operator who knows the take-rate. The customer personas your product serves, each with their own rules. Each becomes a lane.

Every checkpoint, not just the pull request

Lane Review isn’t only at the pull request. Every checkpoint your work passes through is a chance for the right lane to catch the right thing. Strategy review. Roadmap planning. PRD. Design doc. RFC. Pre-commit. PR. Pre-deploy. Release. Each checkpoint catches a different cost of bug.

A pricing-model conflict caught at the PRD is a one-conversation fix. The same conflict caught at the PR is a one-sprint rework. The same conflict caught at deploy is a customer Slack on Saturday morning.

The earliest checkpoint a lane can plausibly run is the cheapest fix. Lane Review’s discipline isn’t “run this at the push.” It’s “run this at every checkpoint where the lane has rules to apply, starting as far left as the lane has anything to check.” The lanes that show up at PR review still matter. The lanes that show up at the design doc save more.

Your team’s checkpoints will look different. The discipline is the same.

If you’re a leader trying to bring Lane Review into a workflow your team already owns, three steps, in order. At each step the team has a job and you have a job. Yours is what makes theirs possible.

1. Name the lanes that aren’t just engineering.

The team picks one workflow they ship through pull requests. They list every kind of review that should happen on every change but only happens at milestones. Not the engineering reviews you already have. The reviews the calendar wouldn’t let you afford. Design fidelity. Product positioning. Money-flow correctness. Compliance with the domain your customer operates under. Marketing voice. Most teams find a handful of items on the first pass. Almost none of them get caught at commit time today.

What the leader sets up is the grounding documents. Each lane only works if it has the documents it needs to actually check things. The brand book the design team carries in their heads. The ADRs the product team made over the last year. The pricing model your finance partner enforces in spreadsheets. The compliance checklist your legal counsel keeps in a drafts folder. Most of these documents exist in your company, scattered. Your job is to authorize someone to assemble them into a place a lane can read from. If the documents don’t exist, your team can’t build the lane. That’s not a tooling problem. It’s an artifact problem: the rules aren’t on paper. It’s a context problem: your agents have no context to work from. Solving both is leadership work.

This is where most attempts to copy what other engineering teams are doing with AI stall. Anthropic’s Code Review and Atlassian’s Rovo Dev are agents reviewing pull requests through engineering perspectives only. Atlassian’s runs across 1,900-plus repositories with a 30.8% PR cycle-time drop. Both leave the same gap your team has now. The lanes worth adding are the ones nobody else’s setup includes.

2. Build each lane as a grounded reviewer, not a persona.

The team builds each lane as an agent with its own context window. The lane is given grounding documents and a tight checklist of what it should flag. Findings come back tagged CRITICAL / HIGH / MEDIUM / LOW. The human triages. The agent does not autopilot the merge.

A lane is not single-prompt persona injection — the kind that, as a March 2026 study showed, can degrade output. A lane carries actual rules. A money-flow lane carries the pricing model and the take-rate as explicit rules. A customer-persona lane carries the rules of one user type your product serves: what they expect, what trips them up, what regulations govern them. The lane doesn’t imagine what its named role would catch. It runs what that role’s rule set says to catch.

The agent is a linter with a name tag.

And customer-persona lanes are missing from every published setup. Not the customer interviewed after launch. Not the customer surveyed in research. The actual rules of each user type your product serves, encoded as separate reviewers, running against every change. One lane per persona you serve. Those lanes are the existence proof that Lane Review is more than engineering specialties wearing different hats.

Every lane runs at every checkpoint. A lane that has nothing to flag isn’t sitting out. It’s confirming there’s nothing here its rules say to catch. “No concern from this lens” is itself a finding. The lane defines its to-do, even when it has nothing to do.

What the leader funds is the time to write the rules down. Most companies’ lane-worthy knowledge lives in the heads of one designer, one product lead, one finance partner, one customer-experience anchor. The team can’t ground a lane on knowledge that isn’t on paper. Your job is to commission the rule extraction. Not from the agent’s perspective. From the person’s. What do you check, when, against what? The artifact that comes out is the lane. The act of writing it down is half the value, before any agent runs.

The other half is keeping the lane calibrated. The person whose rules the lane carries reviews what it catches. Not every finding. Enough to confirm the lane still judges the way they would. Without the calibration loop, the lane drifts.

3. Gate each checkpoint on the lane findings, but don’t autopilot the fixes.

The team wires the lanes into the checkpoints. The pull request is the most-instrumented one today — every diff fans out to every lane, the findings come back tagged, CRITICAL blocks the push, HIGH surfaces for triage, MEDIUM and LOW go to the audit trail. The developer fixes the CRITICAL, decides on the HIGH, ships. Thirty seconds. Local. No CI queue.

The same gate mechanic ports to the other checkpoints. The PRD gets a gate. The design doc gets a gate. The deploy plan gets a gate. The earliest gate where the lane has rules to apply is the cheapest fix.

HubSpot’s Sidekick achieved 90% faster time-to-first-feedback and 80% engineer approval with this shape, using a judge-agent layer to filter low-value comments before they post. Without that layer, lanes generate volume. With it, they generate signal.

What the leader protects is the bypass economy. --no-verify exists. The lanes will sometimes be wrong. Engineers will sometimes need to skip. Your job is to make the bypass cheap enough that engineers don’t fight the gate, and visible enough that pattern abuse shows up in retros.

Lanes will sometimes disagree. The design lane says ship; the marketing lane says block. The human is the tiebreaker. Lanes surface; the human decides. Lanes don’t replace the stakeholders whose rules they carry. They shift the conversation earlier.

The questions you already ask, just six weeks late

You’ve sat in the same meetings I have. Product review on Monday. WBR on Tuesday. Roadmap review at the end of the month. Strategy review every quarter. Office hours every Friday.

In the product review you ask: who is the customer this solves for? How does this fit the roadmap? What does it trade off against? In the WBR you ask: why is this metric moving? What’s the root cause? When does it return to baseline?

In the priority review you ask: what’s the cost-benefit ratio? What’s the opportunity cost? What’s the sequencing logic? In office hours an engineer asks why the team is shipping the smaller feature first, and you walk them through the strategic theme that ties three quarters of work together. The answer they couldn’t see from inside their sprint.

Every one of those questions is a perspective. Every one of those perspectives catches something engineering review can’t. And every one of those questions arrives six weeks after the commit that should have answered it. The product-fit question lands at product review. The cost-benefit question lands at priority review. The strategic-alignment question lands in office hours. By then the team has shipped. The catch costs a rework cycle and a conversation that should have happened at the commit.

Lane Review is what those questions look like when they show up at the commit instead of the quarter. Each question becomes a lane. Each lane is an agent loaded with the questions you would have asked, grounded in the documents you would have referenced. The roadmap. The strategy memo. The operating principles. The priority framework. (Mostly the documents you wrote.) The lane doesn’t replace the meeting. It catches the answer that wasn’t ready by the time the meeting started.

The discipline scales down to a team of three and up to Atlassian’s 1,900 repos because the unit of work is the lane, not the team.

Validated learning was the executive discipline that got your team to Settle. Lane Review is the verification that holds them there.

The shift-left promise, fulfilled

Smith’s 2001 framing wasn’t about testing specifically. It was about integrating the disciplines that ship the product, earlier than the milestone. Testing was the first beachhead because it was the first discipline cheap enough to move. Security was the second. Observability was the third. Lane Review is the next wave, and unlike the previous three, it isn’t a single new discipline. It is every other discipline at once, finally affordable to attach to every checkpoint your work passes through. Agents make the math work. Humans keep it honest.

For your team this week: ask them which non-engineering review only happens at the milestone today. Just one. If they can name it, you have your first lane. Authorize them to assemble the grounding documents and protect them while they do.

For yourself, optionally: write the rule set for one of those reviews yourself before you ask your team to. If you can’t write the rules, the lane your team builds will be roleplay, not linting.

Which non-engineering reviewer would have caught your last incident?

#Leadership #AI #EngineeringLeadership #ShiftLeft #LaneReview #AIAdoption #CodeReview

There’s a website called NeedHuman.ai. The homepage is written for machines.

You can submit a task to a human via API for five dollars. The median response time is eleven minutes. The customer is other AI agents.

If you haven’t seen it, open it now and read it three times. You’ll do what I did — check whether you’re on a parody site. It is a real product. Pre-v1.0. Forty-one tasks completed in the entire history of it.

NeedHuman is not the only one trying. HumanRail is in early access. Sub-five-minute response time, Lightning Network payouts, integrations with LangChain, CrewAI, OpenAI Assistants, Claude. Duckbill is older. A consumer concierge product (phone calls, errands, two hundred background-checked operators, three hundred forty thousand tasks across the years) now retrofitting itself for the agent buyer with an MCP-native developer API.

The category has a name. Human-as-a-Service. HaaS.

The products in it are all early. NeedHuman is a solo-founder experiment. HumanRail is in early access. Duckbill is a retrofit. The point isn’t that the market is mature. The point is that the protocol exists.

For twenty years we built infrastructure for humans to consume software. Someone is now shipping infrastructure for software to consume humans. The shape of the question changed.

The question nobody is putting on the slide

The reason this matters isn’t the products. It’s what the products are evidence of.

For most of the last decade, every dashboard, every BI tool, every Looker chart was infrastructure pointed in one direction. Machine-readable data, human reader. HaaS points the other way. Human-readable work, agent reader.

Both directions are real. Both are funded. Right now, this quarter, on every engineering roadmap, a question is being voted on that almost nobody is putting on the slide.

Are we building ...

• Company A — a human-centric company with an AI assistant, where humans hold the decisions and AI is the unlimited team that drafts, cleans, summarizes, and serves?

Or are we building ...

• Company B — an AI-centric company with a human, where the agent holds the decisions and the human is the judgment resource the agent pings when it needs us?

Both companies exist in the wild today. Both have receipts.

Company A

The mature version of Company A isn’t more dashboards. It’s better delivery of insight to where humans already are.

Per WisdomAI’s case study, a mortgage operations company called HomeStory Rewards retired ninety-five percent of their legacy BI dashboards earlier this year. They didn’t replace them with no dashboards. They replaced them with AI agents that pushed insights into Slack and email, where the analysts already lived. The dashboard moved from place I go to look into thing that pushes me what to look at. Two-week deployment. The humans still made the calls.

Shopify under Tobi Lütke calls it “AI-first, not AI-only”. Engineers must demonstrate why they need additional humans before adding headcount. But the company maintains what their playbook calls comprehension debt guardrails. Engineers are expected to understand the systems two to three layers below where they’re working. About twenty percent productivity gains, measured not in lines of code but in faster prototyping and higher-fidelity deliverables. The human is still in the seat.

That’s the pattern of a human-centric company with an AI assistant. The human is the executive. The AI is the unlimited team that drafts and serves. The dashboard mutates from artifact-to-look-at into delivery-channel-into-existing-work. The consumer of every metric is still a primate.

Company B

Then there’s the other company.

Pieter Levels is the existence proof at the indie end. Millions in annual recurring revenue, solo, zero employees. The flight simulator he built in three hours in February of last year was making one hundred thirty-eight thousand a month by November. There are no dashboards in his stack because there are no humans inside to read them. The cron jobs run, the Stripe charges land, the metric is the bank balance, the agents handle the rest.

NeedHuman, HumanRail, Duckbill are the infrastructure end of the same company. When an agent in a Company-B-shaped org hits a step it’s mechanically blocked on (a Terms-of-Service click, a CAPTCHA, a one-time account creation, an identity verification), it has somewhere to call. Eleven-minute median. Five dollars a task. The agent is the customer. The human, today, is mostly the founder of NeedHuman, at the other end of his own API. NeedHuman is half real product, half deadpan wink at the agent-economy bubble. Both halves are load-bearing, because nobody quite knows yet how serious any of this is, including the people building it. (Especially them.) The protocol shipped before the workforce did. The protocol is the bet that the workforce will arrive.

Klarna is the cautionary middle. Under Sebastian Siemiatkowski, it tried to push hard toward an AI-centric company in 2024. The AI agent did the work of eight hundred fifty human agents. Headcount dropped about fifty percent through attrition since 2022. By May of last year they walked it back. The framing they settled on was that AI-only produced lower-quality outcomes and forced expensive reversals. They tried it at scale. They retreated.

That’s the pattern of an AI-centric company with a human. The agent is the executive. The human is the on-call resource. The protocol exists before the supporting infrastructure does. Company B is real and shipping. It is not yet a free option for any org with quality SLAs.

The vote is already being cast

Here’s the part most leaders haven’t seen yet. This isn’t a hypothetical fork. The vote is already being cast on every roadmap.

85% of enterprises say they want to be an “agentic enterprise” within three years. 19% actually run multi-agent systems today, though adoption is accelerating. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by the end of 2027 — not because the technology fails, but because of escalating costs, unclear business value, and inadequate risk controls.

On the same roadmap, in the same quarter, two budget lines vote opposite directions. Modernize the BI layer. Tableau Pulse, Microsoft Copilot in Fabric, Snowflake Cortex Analyst, Databricks AI/BI Genie. A vote for a human-centric company with an AI assistant. Better translation between machines and primates. Then wire MCP into the stack or build the semantic layer. A Cube benchmark earlier this year showed that four kilobytes of semantic context buys seventeen to twenty-three percentage points of accuracy on every frontier model, with the gain coming from context, not from a bigger model. A vote for an AI-centric company with a human. Preparing for a different consumer.

The honest read is that most companies are funding both. Talking about the second. Building the first. Assuming the disconnect will resolve itself. Gartner’s three reasons read like the autopsy of that disconnect. The discipline of choosing which tool gets used for what is the leverage that decides which side of the fork you actually fund.

Closing

Someone is making money off NeedHuman right now. Eleven minutes, five dollars, a founder at the other end. Somewhere else, a team that has never heard of NeedHuman is approving budget for a new BI tool because their current dashboards are getting stale.

Both companies are real. Your roadmap is voting for one of them this quarter, whether or not anyone in the building said so out loud. The fork is human-centric-with-an-AI-assistant, or AI-centric-with-a-human.

Which company is your roadmap quietly funding?

#Leadership #AI #FutureOfWork #EngineeringLeadership #HumansAsAPI

This is post 50. I am halfway through the rule of 100.

Last week I went back and read the fourth thing I started posting regularly online. I had forgotten what I wrote in it.

The line that stopped me was one I had left for my future self. “I’m genuinely excited to see what I’ll have learned, what new connections I’ll have made, and how my own thinking will have evolved by the time I hit post #100.”

Past me had a plan I had quietly been keeping. Twelve months in, I went looking for the right name for what I had been building, and Stanford Health gave me one.

If you have lived in the Bay Area for any length of time, you have heard somebody describe Stanford Health as a teaching hospital. It is how the place introduces itself.

Buried in the Stanford Medicine principles document is a sentence that recasts the phrase. “Without that academic component, there is no reason for us to have a clinical enterprise.”

The teaching is the reason the hospital exists. The medicine is the byproduct. Fifty posts in, I see now I have been quietly running one of these on myself.

What a teaching hospital actually is

A teaching hospital has a triple mission: clinical care, education, research, all interdependent. A patient at one with the same diagnosis on the same day has measurably better odds than a patient at a hospital down the street. A 2017 JAMA analysis of twenty-one million Medicare admissions found adjusted thirty-day mortality at 8.3% at major teaching hospitals against 9.5% at nonteaching ones. The gap is structural.

The structure is a specific list. Bedside teaching, going back to William Osler at Johns Hopkins in 1889. Grand Rounds, weekly, in every department. Graduated supervision, with autonomy granted on demonstrated abilities, not seniority. And programs like Stanford Medicine 25 that exist for the sole purpose of keeping the teaching at the center of the practice.

The teaching is what produces the better outcomes. Not despite the trainees. Because of them.

That sentence changes what you are looking at when you walk into Stanford Health. It also changes what you are looking at when you scroll through fifty LinkedIn posts in a row.

Don’t get me wrong. I am not the attending in this metaphor. I am the resident, fifty cases in. The lessons are partly mine and partly yours. But the parallel was too clean to keep to myself.

1. The bedside is the desk.

Bedside teaching is the founding act of the modern teaching hospital. At Stanford Health, every department still practices it the same way. The attending and the residents walk into the patient’s room together. They take the history together. The diagnosis happens out loud, with everyone hearing the reasoning, including the patient. Osler’s line was “medicine is learned by the bedside and not in the classroom.”

That has been the architecture for over a century. I have been running it at my desk for twelve months without realizing it had a name.

I cannot write a post called “be a better leader.” I have to say which mistake I saw on Tuesday and what I would do differently. The reader gets the case notes. I get a diagnosis I had not made out loud yet. And sometimes the reader sees something I missed and tells me so in the comments. Half the lessons in fifty posts arrived at the moment of writing them down. The other half arrived after, from someone pointing out what I had not.

The case is the unit of work. Frameworks index the case archive. The actual learning lives one bedside at a time.

At a teaching hospital, no case stays at one bedside for long.

2. The teaching is the practice.

Stanford Health runs Grand Rounds every week, in every department. The format goes back to Osler too. A clinician presents a real case in front of the residents, fellows, and faculty. The reasoning happens out loud. Residents ask questions. The teacher answers them in real time. The audience learns from the case. The presenter learns more, because the act of presenting in public is what forces the reasoning to be sound.

Stanford Medicine has its own modern version of this, called Stanford Medicine 25, run by Dr. Abraham Verghese. He is a Stanford physician who is also a novelist. Cutting for Stone. The Covenant of Water. The program teaches twenty-five physical-exam techniques to residents, week after week, in front of an audience. One of the courses is named “Body as Text.” Verghese has spent his career arguing that the act of teaching the exam IS the medicine. The same person at the bedside on Tuesday is the same person writing novels on Sunday. His own life is the proof.

Verghese named what I had been doing without knowing the name for it. The same play, run on a keyboard with a publish button, comes out the same shape.

Every weekly post is a case at rounds. The audience is the residents and faculty in the room. Comments are the questions the audience asks. A colleague messaging me on the side. A senior leader replying with one line. A friend re-sending the post a week later with a sharper framing of what I had written. All of it is rounds. All of it forces the reasoning to be sound.

If I cannot explain why the case turned out the way it did, I did not actually understand it. The teaching is the test. Publishing is how a desk gets a supervising attending.

3. The institution is the byproduct.

A teaching hospital is structurally a learning organism. Every case generates institutional artifacts: the case archive, the curriculum revised every year, the standing protocols. Stanford School of Medicine generates research output that outlives any single resident who walks through it. Graduated supervision (the ACGME’s three-tier model: direct, indirect, oversight) is the institutional rule that turns experience into expertise instead of just hours into seniority.

Stanford Health has had over a century to build its institutional artifacts. I have had twelve months. The shape is the same. The scale is not.

Fifty cases later, the system around me is bigger than any post. There is a topics tracker. A voice fingerprint document calibrated against my own writing. A four-pass polish loop. An AI editor that catches my basic mistakes while the ideas and the point of view stay mine. A workflow that has versioned itself twice. I did not plan these. They emerged from the practice the same way Stanford Health’s institutional artifacts emerged from a hundred years of cases.

The institution is what compounds, not the individual cases. Paul Graham wrote about this.

“Whenever how well you do depends on how well you’ve done, you’ll get exponential growth.”

The writing got easier somewhere around post thirty. The thinking did not get faster. The institution did.

What fifty cases looked like up close

Some of these posts I wrote three weeks ahead of publish day, with a clean outline and a calendar that smiled back. Most of them I did not.

Some I wrote on Friday afternoons with the 8 AM Pacific publish slot closing in fast. Last-minute pushes where the post and the week were getting written at the same time. Some I wrote during weeks I would not write about openly. When something at work was breaking and I could not name it. When something at home needed more of me than I had. When I was tired in the way that twelve months of any commitment makes you tired. The posts you read in those weeks did not say so.

Reading them now, I can see the seam underneath. What is on the page is what I had to work out about leadership while the rest of life was happening at the same time. The thinking ran on a parallel track to the living, and writing it down was how I kept the two from drifting apart.

It’s hard - yet it’s so easy!

A few of the posts mattered more than the others. I cannot always tell which ones from my side of the screen. The ones I thought would land sometimes did not. The ones I almost did not publish turned into the most meaningful conversations I had on the platform last year. The audience is rarely where I expected them to be. The lessons I am most sure of now are the ones the comments forced me to be more honest about than I had been with myself.

The plan past me wrote down is real. The thing I built is not what I thought I was building.

Twelve months in, the institution has a name. Fifty cases on the board. Halfway to a hundred.

If you have been writing online, what is the institution you did not realize you were quietly building? And if you have not started, what is the first case you would put on the board?

#Leadership #WriteToThink #LearningInPublic #TeachingHospital #RuleOf100

If you’re reading this, you’ve lived through three or four of these moments in your career already.

Mobile in 2010. Big data in 2014. “Every company is a software company” around 2017. The shape is always the same. A real and important capability arrives. Everyone scrambles. The vendor list explodes. Pilots launch. Most of them produce nothing measurable.

And then, quietly, eighteen months later, the companies that come out of the wave with actual leverage turn out not to be the ones with the most pilots, or the biggest budget, or the earliest start. They’re the ones who installed a discipline for telling real progress from looking-busy progress, before they started spending.

AI is the same shape. If you’re paying close attention to it now, you’re not behind. You’re early to the part that matters.

The fix isn’t a vendor. It isn’t a model. It’s a discipline. And the books that name it were written years before AI showed up.

The two books, fast

Eric Ries wrote The Lean Startup in 2011. Most people remember the MVP. The load-bearing idea is validated learning. Measuring whether you actually learned something, not whether you were busy. He called the discipline that supports it innovation accounting. Vanity metrics that always go up vs. actionable metrics tied to a specific hypothesis. That book is the team-scale playbook.

Three years later, Jez Humble, Joanne Molesky, and Barry O’Reilly wrote Lean Enterprise. The part structure is literally “Explore” and “Exploit.” Explore and exploit are different management problems. Different governance. Different funding cadence. Different metrics. Different leadership behavior. Mission Command: the leader sets the outcome and the boundary, the team owns the execution. That replaces command-and-control. The book is the org-scale playbook.

Both were prescient. Both were ignored. Most of what we’re now calling AI failure is the cost of having ignored them.

Think about the first time you cooked something new. Not the Food Network version where everything plates beautifully on the first take. The real first attempt. You read the recipe twice. You measured everything. You didn’t multitask. You did one thing at a time, slowly, because you were learning what good looked like. You also burned something. Undersalted something. Took twice as long as the recipe claimed. Figured out which step the recipe was quietly lying about. By the fifth Tuesday, it was just dinner, done while you scrolled your phone, no recipe card needed. The polished show skips the part that mattered. AI workflows work the same way. There’s no shortcut around the careful first attempt. There’s just the question of whether you took it.

Here’s how the recipe works for a team. If you’re a leader trying to bring AI into a workflow your team already owns, three steps, in order. At each step the team has a job and you have a job. Yours is what makes theirs possible. Skip yours and you’ll have a demo that doesn’t survive a Tuesday.

1. Spike. Smallest test on the strongest tool.

The team picks one real workflow they already touch every week. Runs it end-to-end on the strongest model available. Doesn’t optimize the prompt. Doesn’t shop for tools. Doesn’t throttle the cost. The team’s only job is to find out whether this work is AI-doable at all today, by anyone. If the strongest model can’t, no cheaper one will.

What the leader sets up is the explore budget. Time. Model credits. No PR-ready outcome required. The hypothesis written down before the work starts, in one paragraph: what would we learn from this? And a stop-date. Mission Command in plain English: here’s the outcome we’re testing, here’s the boundary, come back in two weeks with what you learned. Leaders who turn this into a multi-quarter roadmap kill it before it starts.

2. Specify. What good actually looks like.

Almost everyone skips Specify. Ries called it load-bearing. Most AI dashboards quietly fail at it.

The team takes one good run from the Spike and saves five to ten real inputs alongside the outputs they accepted as good. That’s the golden set. They add a daily human gate, ten minutes reviewing new runs against the bar. They capture the failure modes, not just the wins. (This is the how underneath the Automate step from DEAL Naming what to automate is half the work. Learning what good looks like is the other half.)

The leader’s job is the review ritual. A fifteen-minute weekly meeting where the team shows the golden set, not the dashboard. Vanity metrics: tokens consumed, seats deployed, prompts issued, dashboard views. Actionable metrics: workflow success rate on real inputs and review time reduced. Visible air cover that the team is allowed to spend time on this, not just on shipping.

This is where most enterprise AI programs die. The leader loves the Spike demo, skips the Specify ritual, and the learning evaporates by the next quarter. The dashboard keeps growing. The validated learning never accumulates. What looks like an AI failure isn’t a technology problem. It’s a governance problem. And both books named it years before the AI era began.

3. Settle. Graduate from explore to exploit.

Now the team runs the same inputs through the next tier down. If the outputs hold against the golden set, settle there. Persevere, optimized. If the outputs drop, you’ve located the part of the workflow that needs the frontier. Split the pipeline at that seam. Pivot, with precision.

A developer named Pawel ran exactly this, in public, with a personal AI agent. Started everything on Opus. By Friday he was at 70 to 80% of his weekly Claude Max limit. He swapped the default to Haiku for around 95% of the agent’s tasks (the structured, precise, follow-the-checklist work), and left the heavier reasoning for Sonnet and Opus. Weekly limit usage dropped to about 40%. Same output. The title of his post is the punchline: “And it got better.”

What the leader runs is the graduation handoff. The experiment leaves the explore budget and enters the exploit budget with the golden set, the failure modes, and the runtime economics attached. Lean Enterprise warns about this handoff most loudly. Most orgs fumble it. Either pilots stay pilots forever (no graduation), or they scale without the learning (the golden set gets left behind and the next team rebuilds it from scratch). The handoff ritual is small. The discipline lives in the handoff.

When the discipline is in place, the economics show up on their own. Notion published a 90% cost reduction and up to 85% lower latency from prompt caching across their multi-model architecture. dbt Labs is cited in the same case study as saving over $35,000 a year by consolidating onto Notion AI instead of buying additional tools. The caching is just a technique. The discipline behind it (knowing which workloads are routine enough to cache) is the leverage.

The mail on my kitchen table

The point of doing one of these loops yourself isn’t that your weekends should involve AI. It’s that if I can’t describe what I learned from parsing my own mail, I can’t ask my team to describe what they learned from their pilot.

About a year ago I started a small home automation. Real envelopes: utility bills, school flyers, statements, the junk that piles up by the door. Plus the PDFs my scanner spits out. The first weekend, I threw the entire stack at the strongest model I had access to back then. By today’s standards, an objectively dumber model. No prompt engineering, just to find out what was AI-doable. It was, barely. Then I built the golden set from real mail and stepped down to a mid-tier model.

Two failure modes surfaced at the cheaper tier, both of which I would not have invented as synthetic tests. A utility bill with a handwritten note from my wife on it. The cheaper tier missed the annotation entirely, even though the note changed the action I needed to take. A tax form mailed inside another envelope. The cheaper tier conflated the two documents and routed both as the wrapping mail. Five real inputs caught these. Fifty made-up examples wouldn’t have.

A year on, the workflow still runs. The models have all gotten stronger. The discipline is the same. The model is the cheapest part of the whole thing.

Those ten minutes I spend writing down what didn’t work are the most valuable part of my week on this project. The parts that work tell me the system is alive. The failures tell me where the seam is.

Where Lean stops working

Not every workflow downgrades cleanly. Long-context reasoning, multi-step planning, and deep code review on a real codebase often need to stay on the frontier. The pattern is downgrade where you can, not downgrade always. Settle is conditional, not automatic.

Latency and privacy bound model choice before cost does. Sometimes the right model is neither the cheapest nor the strongest. The framework assumes cost is the active constraint. If it isn’t, you’re solving a different problem first.

And Lean fits the explore side of the AI question, not the vision side. Ted Ladd’s HBR research from 2016 on 250 cleantech accelerator teams found something worth holding onto: more market tests doesn’t beat strong strategy. Whether to build an AI capability at all (the vision question) needs conviction. How to turn today’s models into useful workflow (the explore question) needs Lean discipline. This post is about the second. The first is a different book.

The discipline you install

The next generation of leaders worth following won’t be the ones who picked the right AI vendor. They’ll be the ones who installed a learning discipline in their teams before the market forced them to. If you’re asking these questions now, you’re ahead of most of the market and ahead of most of your peers. The K-shaped curve I wrote about earlier this year isn’t really about who has the best tools. It’s about who built this muscle before the people next to them did.

So here is the question I’d leave you with. Actually, two questions. One for your team, one for you.

For your team this week: ask them what the golden set is for the thing they’re trying to automate. Not the dashboard. Not the weekly demo. The five real inputs and the outputs the team agreed were good. If the answer is we don’t have one yet, that’s where to start. Protect the time for them to build it before anything else.

For yourself, optionally: if you haven’t run one of these loops personally in the last three months, pick something mundane of your own. Receipts. Mail. A weekly report. Run the spike yourself, so that when your team shows you their golden set, you can tell whether it’s real.

#Leadership #AI #FutureOfWork #LeanStartup #ValidatedLearning #AIAdoption #EngineeringLeadership

There are platforms I used to recommend without thinking. A few of them aren’t on my list anymore. None of them shipped a worse product. They shipped a different relationship.

Every business book will tell you this is just how it works. The chasm. The math. The price sheet. The textbook says you outgrow your early adopters because you have to.

It doesn’t have to be.

The chasm and the cohort

Geoffrey Moore added the chasm to the adoption curve in 1991. Innovators on the left. Laggards on the right. The chasm in the middle. A generation of platform builders has been crossing it ever since.

Moore taught us how to cross it. The question he left alone was what to do with the people on the near side.

The default move is to leave them. Most platforms do. Shopify, Stripe, Figma, and Supabase didn’t. They crossed anyway, without strip-mining the cohort that built the bridge.

The model that brings early adopters in is almost never the model that pays the bills at scale. So you will evolve. That part isn’t optional. The original promise drew the cohort in because it was generous. That generosity is what eventually has to change.

The real question is what kind of change. You can serve the partners and make money on the same activity. Or you can price them out and make money on what they leave behind. Both are legal. Only one compounds.

Last week I wrote about Costco’s $1.50 hot dog and how value earns the right to enforce a boundary. That post was about how you earn the relationship at the door. This one is about what you owe the people who walked in.

Your early adopters were never your customers. They were the unpaid founding labor that built the moat. The question is whether you’ve architected the business so they’re still standing on it five years from now.

1. Name the people who built your moat. By handle.

The Partner Audit is the diagnostic underneath every monetization decision you’ll make this year.

Before you change a price, change a tier, deprecate an API, stop supporting your open source projects, or rebrand the docs, do you actually know who built the trust the brand is now monetizing? Not the persona deck. The actual list. The Discord regulars, the integration authors, the YC batches who picked you, the volunteer mods, the engineers who push your name in their company’s vendor selection thread.

If the list doesn’t exist, you don’t understand your own moat. You just happen to be on top of it right now.

Tobi Lütke didn’t discover his merchants and agencies were the moat after the fact. He built Shopify around the premise. Amazon competes with sellers; Shopify makes money only when merchants make money. Tens of thousands of apps and thousands of agency partners, two decades in, every pricing decision still gets read against the merchants first.

Name fifty. If the rest of the market wouldn’t feel their absence, the list is wrong, and you’re still working from a persona deck.

2. Every move on the price sheet does one of two things.

Extraction or replenishment. There’s no neutral monetization move.

Take a price increase. If it funds better docs and faster support, the contributors help you launch it. If it funds executive bonuses while their support tickets get slower, they organize a Discord channel called #migration-guide. Or take a paid tier. The volunteer power users will happily buy one they could have built themselves. They will revolt against one retroactively added to what was promised free.

You have to monetize. The real question is whether your top contributors would help you ship the change, or organize against it.

Figma did this in public. Open APIs from day one. Plugin marketplace that doesn’t tax plugin revenue. “Your data is yours” on the company blog. When Adobe tried to buy them for $20B in 2022, the community reaction (plus regulators) killed the deal. Figma kept compounding under the same founder, same promise, same persona. The platform widened the partnership instead of narrowing it.

Reddit went the other way. Calling it greed misses the actual mechanics.

Reddit’s original model genuinely couldn’t pay the late-stage bills. Volunteer mods, third-party developers, an ad-light experience. None of it was producing the margin a public-market exit needed. They had to evolve. They picked the path that priced out the third-party ecosystem and monetized the volunteer mod labor that had built the platform. Eight thousand subreddits went dark in June 2023. The IPO happened anyway. The moat hollowed out and the people who built it left.

I have watched this conversation play out in vendor meetings this quarter. Other paths existed for Reddit. Slower ones, harder ones, ones that didn’t fit the timeline the cap table needed. The point isn’t that Reddit is evil. The point is the path got chosen, and the path made the contributors the asset being sold rather than the asset being served.

3. The platform no one wants to leave is the one they can.

Lock-in built on respect compounds. The kind built on “they have nowhere else to go” defects the moment someone opens a door.

Tailscale published “backward compatible, forever” as a contract on the company blog. Supabase is open source on Postgres; if they ever drifted, the community could host itself elsewhere within a week, and Supabase knows it.

Both are growing faster than their extractive peers. The structural guarantee that exit is available is the thing that makes partners invest in the first place. Design-for-exit isn’t a concession. It’s the feature.

Twitter killed the third-party API in January 2023. The same apps that invented pull-to-refresh. Ad revenue collapsed from $4.1B to $2B in a year. Digg lost 99.75% of its value to Reddit in twenty-three months and the users organized the exodus on the competitor’s site.

Tailscale and Supabase. Crossing the chasm with their partners, not over them. Allbirds didn’t have that option.

The shoe company that became an AI company

Eight days ago, in a category with nothing to do with platforms, the same arc finished playing.

Allbirds, the merino wool sneaker, one of my favorite, that became Silicon Valley’s tech uniform, sold its shoe business for $39M in March. Two weeks later, on April 15, the publicly-traded shell rebranded as “NewBird AI” with $50M to buy GPUs. From a $4B valuation in late 2021. The shoe, the thing the original cohort bought into, has no corporate home anymore. The shell pivoted to whatever the next capital cycle was paying for, which this April happens to be AI compute.

Private equity has industrialized a model where you buy a company, load it with debt, pay yourself back with dividends recapped from its own cash flow, and sell the husk to the next buyer. PE-backed companies go bankrupt at roughly ten times the rate of non-PE-backed peers. You don’t have to look hard to see this in your own industry.

Allbirds didn’t need a PE owner to become NewBird AI. It just needed a public market hungry for GPU exposure and a wool-shoe story that couldn’t deliver the margin. The mechanism is the same regardless of who’s holding the paper. Which is why the architecture decisions in front of you this quarter outlast the cap table pressuring them.

For the consumer-hardware version of this same arc, watch MKBHD on OnePlus. January 2026. Same enthusiast cohort, same pivot away from them, different industry. The mechanism doesn’t care what you sell.

The platform I’m writing on

I run platform teams for a living. I write about platforms on a platform. Both jobs have the same problem in front of them, and the second one made me see the first one more clearly.

The people who’ve been here since Post 001 are not “audience growth.” They’re the cohort that decided this writing was worth coming back to before the metrics did. If I evolve this in a way that prices them out (different audience, different register, different argument), the cap table doesn’t get me. The brand erodes anyway, just one tier earlier.

Same architecture conversation, smaller scale.

You’re reading this because you decided this writing was worth coming back to before the metrics did. That makes you a launch partner. Don’t let me forget it.

Cross the chasm with the people who showed up. Not over them. The platforms that compound figured out a model where the original identity is the profit engine. Shopify makes money when merchants do. Stripe charges per transaction the developer ships. Supabase monetizes hosting on top of free open source. Figma monetizes seats on a tool the community built around. Same identity, scaled. The platforms that didn’t eventually become NewBird AI. A corporate shell on the other side of the chasm, with no one from the original side standing on it.

So here is my question to you: look at the top fifty people who built your moat. If your next big change went out tomorrow, would they help you ship it, or write the migration guide to the alternative?

#Leadership #PlatformEngineering #Strategy #ProductManagement #FutureOfWork

“If you raise the effing hot dog, I will kill you. Figure it out.”

That’s Jim Sinegal, co-founder of Costco, talking to his CEO. 1984. A quarter-pound hot dog and a soda for a dollar fifty. Forty years later — same price. Inflation says it should cost $4.52 today. They sell 245 million of them a year. More than every MLB stadium combined.

When costs squeezed, Costco didn’t raise the price. They built their own factory. Switched suppliers. Made the hot dog bigger. Kept the promise.

That’s one story. Here’s the other one.

The scanner at the door

Costco just rolled out mandatory card scanning at every entrance. Photo verification. Food courts, members only. Customers are livid. Employees catching heat. Reddit threads calling it a betrayal.

The same company that built a factory to keep a $1.50 promise is now putting a scanner between you and the food court.

Most people see a contradiction. A company that gives everything now takes something away?

It’s not a contradiction. The scanner protects the hot dog. The boundary protects the promise. Remove one, the other breaks. And this goes way beyond retail.

I wrote a while back that good leaders are good at drawing, that the clearest strategic thinking happens when you sketch it on a whiteboard. People reached out after that post. Same question every time: show me one of these drawings.

Here’s one. Two axes. Four quadrants. And a $1.50 hot dog that explains where your team sits.

The Trust Quadrant

X-axis: value delivered. Y-axis: standards enforced.

1. The Membership (high value, high standards)

This is Costco. You keep the hot dog at $1.50 AND you scan cards at the door. The value earns the right to enforce the boundary. The boundary protects the value.

92.2% membership renewal rate in the U.S. and Canada. Think about that. Membership fees are less than 2% of revenue but drive roughly 73% of net profit. People aren’t paying for the products. They’re paying for the system.

For teams: this is voluntary adoption. Backward compatibility promises kept. A golden path that’s actually golden. People keep showing up not because a mandate forces them, but because the platform makes them faster.

2. The Toll Booth (high standards, low value)

All rules, no reward. Mandated usage, breaking changes nobody warned you about, approval chains that take longer than the actual work. None of it makes anyone faster.

You scanned the card at the door. The hot dog costs $9.

A Nokia veteran described on Hacker News how Nokia’s internal IT got so bureaucratic that engineering teams started using AWS behind their backs. “Once one team launched on AWS, things spread. The managers got bonuses. There was no way Nokia IT was getting back on the critical path to anything.”

They enforced the rules. Nobody renewed. 80% of internal developer platforms end up here. The scanner without the hot dog.

3. The Free Sample Table (high value, low standards)

Everyone’s welcome. No boundaries. The team that never says no. Beloved until it collapses under its own weight. Every edge case supported, nothing deprecated, technical debt stacking up quarter after quarter.

A food court with no membership. The economics break.

Iyengar and Lepper’s jam study found that shoppers offered 24 options were 10x less likely to buy than those offered 6. Costco stocks 3,800 SKUs. A typical supermarket? Over 30,000. Sometimes the most generous thing you can do is limit the choices.

You can’t sell a $1.50 hot dog to everyone who walks in off the street. That’s how you go from generous to bankrupt.

4. The Abandoned Lot (low value, low standards)

Built it. Nobody came.

The $4.2M internal developer platform where 64% of engineers still use kubectl directly. The platform that lives in Confluence but nobody touches. No trust earned, no standards set. An empty warehouse with no hot dogs and no scanners.

Which direction are you moving?

The quadrant isn’t just a diagnostic. It’s a map with arrows.

If you’re the Toll Booth: stop adding gates. Start keeping promises. Costco spent 40 years on the hot dog before they scanned a single card at the door. Earn the value first.

If you’re the Free Sample Table: start saying no. Some people will be angry. Costco’s Reddit is full of complaints about the new scanners. The renewal rate holds at 92%. You add boundaries to protect the people who already said yes.

If you’re the Abandoned Lot: find your hot dog. Deliver one thing well before you try to deliver everything.

I watched this happen on my own team

A few months back, my data platform team picked up FinOps management for the data platform. They could have started where most teams start. With the scanner. Here are your budgets. Cut 20%. Report monthly. Comply. That’s the Toll Booth. Mandated cost reduction before anyone trusts the team mandating it.

Instead, they built the hot dog.

They hand-coded a custom experience for each data owner. Not a generic dashboard. A view showing exactly what that owner’s team was spending, where the costs lived, why the numbers looked the way they did. Then they sat down with each one. Not to lecture. To learn. How do you debug a cost spike? What does a normal month look like versus a bad one? What do you actually need to plan a quarter ahead?

They earned the right to talk about cost reduction by first proving they understood the cost.

And now? The standards practically enforce themselves. Nobody pushes back on cost targets when the team that set them is the same team that helped you understand your costs in the first place. It’s early. I don’t know if this holds through the next round of budget pressure. But right now, the pattern is clear: value before standards. Trust before enforcement. That’s the Membership.

They built the hot dog before they put the scanner at the door. That’s the kind of drawing I meant.

The hot dog is still $1.50

Forty years, same price. They still scan your card at the door. Two expressions of the same promise, facing two different directions. One says: we will never stop earning your trust. The other says: we will protect the system that makes the trust possible.

Most teams get this backward. They start with the scanner. Mandates, compliance, approval gates. And they wonder why nobody shows up for the hot dog.

So here is my question to you: draw this quadrant. Put your team on it. Where are you sitting right now, and which direction are you moving?

#Leadership #Strategy #PlatformEngineering #EngineeringManagement #Costco #Trust

A friend of mine leads an engineering org. We go back several years. We talk most months, sometimes over coffee when we’re in the same city, usually just a phone call where we get into what’s actually going on. No agenda, just real talk. I look forward to those conversations. This person has a gear that most people don’t. The kind of leader who gets excited about a messy system problem the way other people get excited about vacation plans.

Last month, something was off. They showed up. Gave updates. Said the right things. But the updates were shorter than usual. Flatter. More “everything’s fine” than anything real. The kind of answers you give when you’re performing normalcy instead of living it. I noticed because I know this person. They don’t do surface-level. And the thing that was missing wasn’t energy or enthusiasm. It was the thing underneath. The quiet drive that used to make them lean into a problem before anyone asked them to. That was gone. Not replaced by frustration. Just... quieter.

I didn’t push it on the call. But afterward, I sat with it. Because I’ve seen that look before. In other people I’ve worked with. In myself.

And when I started paying attention, I saw it everywhere.

It’s not just them

You know how you can tell? Not from surveys. From the way people talk about work now versus two years ago. The engineer who used to send you articles about some new tool they were excited about now just asks if you’ve heard about the latest round of layoffs. The person who used to stay late because they were chasing a problem now stays late because they’re afraid to be seen leaving. The team Slack that used to have side threads about interesting architectural debates now just has standups and status updates. Nobody’s complaining. That’s what makes it hard to spot. They’re not angry, they’re not fighting. They just got quieter. And when you ask how things are going, you get “fine.” A lot of “fine.”

And it’s not just ICs. Every engineering leader I talk to says some version of the same thing. The stress is worse than it’s ever been, and the people they’re supposed to carry are harder to reach.

This isn’t a motivation problem. It’s not about hustle, or mindset, or another team offsite with a keynote and a trust fall. Something is happening to the internal mechanism that makes people want to engage at all.

Every furnace has one

If you’ve ever looked inside a gas furnace, there’s a small flame that never goes out. It doesn’t heat the house. Too small for that. Its only job is to be ready. When the furnace calls for heat, that small flame ignites the main burner. Without it, nothing fires.

That’s a pilot light. (And if you’re an engineer, you already know — we borrowed this exact idea for disaster recovery. Keep the minimum alive so the whole system can fire back up when it needs to. Same principle.)

Drive works the same way. It’s not the big performance — the product launch, the promotion push, the all-hands presentation. It’s the quiet thing underneath that makes you lean in instead of coast. The reason you chase a problem before it’s assigned to you.

Here’s what makes a pilot light interesting: inside the assembly, there’s a small device that sits directly in the flame. It converts the heat into a tiny electrical current. Just enough to hold open the valve that supplies gas. The flame literally sustains itself. No external power needed. As long as it’s burning, the fuel keeps flowing.

But if the flame dips too low, that device cools, the valve closes, and all fuel stops. Not just the pilot light. Everything downstream goes dark.

That’s how drive works. Self-sustaining when it’s lit. And when it dims past a certain point, everything shuts off with it. Energy. Creativity. Ambition. Care. Gone.

What’s blowing on the flame

Three things are dimming the pilot light right now, and none of them are your fault.

The work changed shape. Engineers who used to build for hours straight now spend their days reviewing AI output across half a dozen tasks. The part of work that used to light people up (the building) got quieter. A recent study in Nature found that passively relying on AI reduces your confidence in your own abilities, your sense of ownership over the work, and your feeling that the work means something. And those effects stick around even after you go back to doing things manually.

Effort stopped connecting to meaning. You ship more, but it registers less. You close more tickets, review more PRs, ship more features, move more cards across the board. The link between “I worked hard” and “that mattered” stretched thin. Harvard research on nearly 12,000 diary entries found that nothing fuels motivation more than making progress in meaningful work. When progress stops feeling meaningful, the flame has nothing to burn.

The flame became invisible. Working alongside AI, often alone, often remote. The person who used to notice your energy was off is now a Slack status. When nobody sees the flame, it’s easy to forget it’s there.

You can’t change any of that. The tools shifted. The market moved. The office emptied. But you can adjust. And that’s where the real skill lives.

What you CAN adjust

You can’t control that AI writes a growing share of production code. You can control which problems you personally engage with. Find one thing this week where your judgment (not a model’s) made the difference. The architecture call before something broke. The question nobody else thought to ask. The decision that needed ten years of watching systems fail. That work feeds the flame.

You can’t control that remote work isolated everyone. You can control whether you see people. Not their output. Them. The person whose light is low — your first instinct might be a performance conversation. Sometimes, they just need someone to notice. Be that person for someone this week. And let someone be that for you.

You can’t always control whether the quarterly project lands perfectly, on time, checking every box. You can control whether your team felt progress today. One small win. One moment where someone’s work moved something forward and they knew it. Not a big win. A real one.

You can’t control the pace. You can control whether you gave yourself room to breathe. A pilot light needs oxygen. Smother it and the flame goes out. Sometimes protecting the flame means stepping back. Not quitting. Making room for the fire to find air.

Your flame too

The hardest version of this: your light is low, and you’re the one everyone looks to for heat.

The people supporting the team often carry more stress than the team itself. The hand cupping the flame is shaking.

You adjust the same way. One task. One person. One win. One breath. One day at a time. Your pilot light doesn’t need to be roaring. That small device inside the assembly doesn’t need a bonfire. It needs contact with the flame. As long as there’s heat, the valve stays open. Low is okay. Low is still lit.

And some flames fluctuate because of things that have nothing to do with work. Things you can’t change. Things you adjust around, not through. The flame doesn’t know why it’s being tested. It stays lit anyway.

Hold the button

I talked to my friend again this week. The flame didn’t go out. It got low. What brought it back wasn’t a motivational talk or a new strategy. It was one project that actually needed their judgment. One conversation where someone saw them, not their metrics. One small decision they got to make on their own. One week where progress felt real.

To relight a pilot light, you hold the button down for about thirty seconds. Not long. But you have to hold it. Steady. Deliberate. Until the heat builds back up and the system can sustain itself again.

Drive works the same way. You don’t wait to feel it. You hold the button.

So here is my question to you: what’s one adjustment you can make this week to protect the flame? Yours, or someone else’s.

#Leadership #EngineeringManagement #AI #Motivation #Resilience #TechCareers #FutureOfWork #PilotLight

Somewhere right now, a 2025 CS grad is refreshing their inbox for the 40th time this week. Every listing wants three years of experience with a tool that’s been out for eighteen months. They did everything right. Degree. Side projects. LeetCode until their eyes crossed. They graduated into a market that moved out from under them while they were still studying for it.

Somewhere else, a ten-year veteran just opened a resume they haven’t touched since 2016. They’re staring at job descriptions that feel like they’re written in a language they used to speak. Last year they were the person companies wanted. Now they’re not sure if anyone’s even reading the application.

And somewhere, maybe in the same building where the all-hands just ended, a manager is sitting in their car, engine off, rehearsing confidence for tomorrow’s standup. They’ve already had to deliver the news to people they hired. Now they’re wondering if the next round is them.

Some fights are loud. Layoffs make the news. Markets crash in public. CEOs post restructuring memos with the word “exciting” in the first paragraph while their stock ticks up.

But some fights are quiet. Someone is carrying something into every Zoom call, every interview, every morning. A fight that has nothing to do with a job listing. Something heavier. Something that doesn’t fit in a LinkedIn post. They’re fighting it anyway.

And some fights are silent. Months of applications into a void. Not rejection. Not feedback. Just the inbox and the absence of a reply. The slow, invisible erosion of confidence that nobody tells you is normal.

I see you. All of you.

Fighters fight.

This isn’t in your head

You already feel this. But in case you need someone to say it out loud: only 22% of workers feel confident their job is safe right now. Tech cuts are up 51% over last year, and AI is the named reason in over 12,000 job cut plans so far in 2026. Jack Dorsey cut half his company and told the rest of the industry “most companies are late.”

For new graduates, the picture is worse. 40% of early-career workers have changed or considered changing their career plans because of AI. That’s not a soft market. That’s a generation entering the workforce into a headwind that isn’t their fault.

You’re not imagining it. And you’re not alone in it.

The numbers aren’t the point. You already know the numbers. You’re living them. The point is this: what you’re feeling is proportional to what’s happening. Being scared right now doesn’t mean you’re weak. It means you’re paying attention.

What fighting actually looks like

Fighting isn’t hustle. It’s not “grind harder.” It’s not someone on a stage telling you to wake up at 4 AM and visualize your future. It’s not toxic positivity wearing boxing gloves.

Fighting is a stance. In boxing, your stance is the most honest thing about you. Weight forward, hands up, chin tucked. It’s not a punch. It’s what comes before the punch. It tells the other fighter everything — whether you’re pressing forward or backing up, whether you believe you belong in this ring or you’re just waiting for it to end. You choose your stance before a single punch is thrown.

That’s what fighting looks like right now. Not a knockout. Not a highlight reel. A decision to engage when everything around you says wait, freeze, or scroll LinkedIn for one more hour and call it research.

For the fresh grad, where 39% of workers with less than a year of experience say AI has made it harder to find a job, fighting looks like building something nobody asked for and shipping it anyway. Not because a recruiter told you to. Because the degree and the bootcamp and the portfolio taught you to solve problems, and that mind, the one that breaks things down and figures them out, is yours. The tools changed. That didn’t.

And the same AI that’s changing the game? It helps people just starting out more than anyone else. It’s the best sparring partner you’ve ever had. Nobody can automate the person who looks at a mess and says “I can fix this.” Fighters fight. You didn’t come this far to stop now.

For the veteran, fighting looks like learning the new tool. Not because you wanted to. Not because it’s fair that ten years of expertise doesn’t count the way it used to. But because fighters don’t wait for the game to come back to them. Your ten years aren’t obsolete. Ten years of watching systems break, of pattern-matching across failures, of knowing what questions to ask before the first line of code ships. That’s leverage. That’s the part AI can’t do. Fighters fight. And you’ve been in late rounds before.

For the manager carrying the weight of their team’s future while quietly wondering about their own? Fighting looks like staying in the ring. Not bailing to a “safe” job that doesn’t exist. Rebuilding. The fact that you feel the weight of other people’s careers means you’re exactly the kind of leader who should be in this fight. Even the corner team needs a corner. Fighters fight. Even when the fight is for someone other than yourself.

For the person in the silence. Still applying. Still preparing. Still showing up for interviews that ghost them. The silence is not a verdict. It’s a round. And you’re still in it. Every application is a swing. Every follow-up is a jab. The scorecards in this fight aren’t posted in real-time. You don’t know if you’re behind. You only know you’re tired. Fighters fight. Keep swinging.

Your corner

In boxing, even in the loneliest sport on earth, nobody fights alone. Between rounds there’s a stool, a cutman who works on the damage you can’t pretend away, and a chief second who says one thing. One. Because when you’ve been fighting, your brain can’t hold a paragraph. It can hold a sentence.

If you’re in the ring right now, who’s in your corner? A mentor. A friend who texts back without needing an update. A community that doesn’t judge. Someone who’s been where you are and remembers what it felt like.

And if you know someone who’s fighting, be their corner. Not advice. Not a five-step plan. Just: I see you. Keep going.

Fighters fight

You’re already fighting. I know you are.

The fact that you’re still here — still reading, still applying, still showing up for the standup, still learning the tool you didn’t ask to learn, still getting out of bed on the mornings when nobody would blame you for staying in it. That’s fighting.

Some fights are public. Promotions, job offers, the LinkedIn post about the new role with the heart emoji. Those are the fights people see.

But the fight nobody sees — the 200th application, the interview you prepped for all weekend that ended in silence, the morning after the news, the drive home after the all-hands — that’s where fighters live. Not in the victory. In the stance. In the showing up.

Fighters fight.

That’s you.

Keep going.

#Leadership #CareerAdvice #AI #FightersFight #Resilience #TechCareers #FutureOfWork

The most-repeated phrase on CNBC in the last few weeks is probably “AI is eating software alive.” You’ve heard it. Maybe over coffee, maybe in passing while someone had Bloomberg on in the background. $285 billion disappeared from software stocks in 48 hours back in February. Traders at Jefferies started calling it the “SaaSpocalypse.” Atlassian dropped 35% in a week. The software ETF entered a bear market.

I watched those numbers and thought: that’s a credibility story disguised as a stock story.

Because if you open LinkedIn right now, your feed is telling you the same thing, just on a six-month delay. Scroll back. Six months ago it was full of engineers posting about weekend framework deep-dives. “Spent my Saturday with [shiny new tool]. Staying sharp.” Hundreds of likes. Dozens of “respect” comments. I liked a few of those posts myself.

Fast forward to today. The best AI coding models are solving nearly 80% of real-world software engineering tasks. AI coding tools are pulling in billions in revenue less than a year after launch. An AI agent can scaffold the whole setup those weekend posts were celebrating in about twenty minutes. My point being - that knowledge didn’t just get old - it got replaced.

But buried in the same feed, around the same time, was a quieter post. An engineering director who caught a pipeline design flaw during a review. Saved her team weeks in production. Got maybe 40 likes. Nobody shared it.

Her knowledge is still worth exactly what it was six months ago. Probably more.

I keep thinking about those two posts. Because they represent two completely different kinds of technical knowledge. And the market, in its blunt way, is telling us one of them just went to zero while the other got more valuable. Most of us treat “staying technical” like it’s one thing. It’s not. It’s actually three different things, and they’re moving in opposite directions.

1. The stuff AI already knows

Frameworks, libraries, vendor configs, syntax. This is where most of us pour our “staying sharp” hours. Conference talks, tutorials, weekend side projects, that one Udemy course you bought at 2 AM. I’ve done all of it. It feels productive. Looks great on LinkedIn. And I’m not going to pretend I didn’t enjoy the dopamine of spinning up something new on a Saturday.

That knowledge was already expiring fast. Technical skills lose relevance in about two and a half years now. That was bad enough before AI showed up. AI made it worse. Way worse. Because AI doesn’t just change tools faster. It turns tool knowledge into a commodity the moment you learn it.

The head of Claude Code at Anthropic told Fortune that “pretty much 100%” of their code is now AI-generated. Over 25% of Google’s new code comes from AI. If the companies building these models have already replaced the tool layer internally, what do you think happens to the rest of us? Your team already has a platform engineer AND an AI assistant for Kubernetes. They don’t need you to know the configs.

Maybe we’re all studying for a test that got canceled?

2. The stuff your team can’t see because they’re too close

You’ve probably seen this already, or you will soon. An AI-generated service passes every unit test, looks clean in review, ships without a flag. Two months later it’s the reason another team’s migration is stalled. The coupling was invisible at the PR level. You had to zoom out to see it. And the engineer who prompted it was too close to the code to see the system.

That’s not a one-off. AI now writes over 40% of all production code. Throughput is up across the board. Everyone’s shipping faster. But nobody talks about what CodeRabbit found when they looked at the quality side: AI-generated code carries 1.7x more issues. Incidents per pull request climbed 23.5% last year. Change failure rates rose 30%.

More code. More failures. Same or fewer releases.

So where did the bottleneck go? It moved from writing the code to knowing whether the code should ship. Your team is generating more output than ever. But who’s looking at how it all fits together? Who notices that the service your team just shipped is going to collide with a migration two teams over? That’s not in any unit test. That’s the kind of thing you only catch if you’ve been living in the reviews and the debugging, not the feature work. And right now, most teams are so focused on shipping faster that nobody’s asking whether faster is actually better.

3. Scar tissue

Data pipelines will always be underestimated. Rewrites always take 3x longer than anyone promises. Distributed systems always have consistency trade-offs. These truths don’t change with the framework of the year. They don’t show up in a tutorial. You earn them by watching things break for a decade.

They’re exactly what AI gets wrong. AI generates code that works in isolation. But it doesn’t know what happened the last time someone tried this architecture at scale. The schema migration that locked the table for 20 minutes. The abstraction that looked clean in staging but collapsed under real load. The model can’t see those. You can. Because you were there when it broke.

That’s the competence your team actually cares about. Goodall’s research across thousands of U.S. and British workers found that a boss’s technical competence is the single strongest predictor of job satisfaction. Their judgment, not their output. Jeff Dean’s credibility at Google wasn’t built by knowing their current codebase. It was built over 25 years of watching what works and what breaks at planetary scale. That kind of knowledge doesn’t expire. It compounds.

This is the only layer getting more valuable. Everything else is getting cheaper.

Now connect those dots

AI gutted the first layer and made the third worth more at the same time. “I can write that” stopped being impressive. “I know why that will break at scale” is the scarce thing now. The data across hundreds of thousands of engineers backs this up: top AI adopters ship 2x the throughput, but most teams aren’t even measuring whether that throughput is producing better outcomes.

Boards went from “are you experimenting with AI?” to “show me results.” The engineering manager who can judge AI output before it ships, who knows what the model’s blind spots will cost in production — that’s what credibility looks like in 2026. Not “I learned the new framework.” That’s already automated.

Come back to the feed

Go look at your LinkedIn feed again. The posts with the most engagement are still about tools. Meanwhile, the engineering director who saved her team three weeks by catching a design flaw? She’s not posting about it. Nobody writes “I convinced my team NOT to build something today” and gets 500 likes. But that’s the work that compounds. And the market is starting to agree.

Years ago, when I moved from engineering into leadership, the hardest thing wasn’t learning to manage. It was letting go of the first layer. I’d built my identity on being the person who knew the stack, who could jump in and write the fix. Letting go of that felt like losing something. It took me a while to realize I wasn’t losing credibility. I was shifting where it lived. The moments my teams actually trusted me most had nothing to do with code I wrote. It was the architecture call I made before a system buckled. The migration risk I caught because I’d watched a similar one fail five years earlier at a different company. Pattern recognition, not syntax.

That transition used to take years. You’d grow into it gradually as you moved from IC to manager to director. AI just compressed it. Today, a first-time engineering manager is watching their team generate production code with an AI agent on day one. The first layer isn’t something they’ll slowly outgrow. It’s already gone. The question that used to be “will I stay technical enough?” is now “which layer of technical am I building?” And if you’re still answering that question with frameworks and tutorials, AI already answered it for you.

So here is my question to you: your last 10 “staying technical” hours — how many went to stuff AI can already do for your team, and how many went to the judgment it never will?

#Leadership #EngineeringManagement #AI #SoftwareEngineering #TechnicalLeadership

Robert Kiyosaki sold 44 million copies of Rich Dad Poor Dad. Most people remember the book for “your house is not an asset” and the argument that followed. His company went bankrupt. His seminars got investigated. I’m not here to defend any of that.

But in the sequel, Cashflow Quadrant, he did something I still think about. He drew a cross on a page. Labeled four boxes. E, S, B, I. Employee. Self-Employed. Business Owner. Investor. And that one drawing explained more about why people get stuck in their careers than most business books manage in 300 pages.

Four boxes. Two lines. A framework millions of people can reproduce from memory.

That drawing changed the way I thought about money. Then it changed the way I thought about my career. And eventually, it changed the way I lead teams. I did somewhat followed Kiyosaki’s financial advice. But, the key is, the act of drawing, of forcing a messy problem into a shape I could see, became the way I understood things.

The best leaders I’ve worked with do this. They pick up a marker and draw the situation before they try to solve it. Quadrants, axes, arrows on a whiteboard. A messy sketch that makes a complex problem simple enough to act on.

The leaders who struggle? They talk. They write decks. They schedule another meeting. But they never pick up the marker.

Why Drawing Works

Now let’s not call it intuition. Dan Roam built an entire thesis around it: any problem can be made clearer with a picture. Bezos sketched Amazon’s flywheel on a napkin in 2001. A loop so simple that every employee could redraw it from memory. It became the strategic anchor for a trillion-dollar company. Collins drew three overlapping circles and called it the Hedgehog Concept. Took companies an average of four years to figure out what goes in those circles, but once they could draw it, alignment followed.

There’s a reason for this. Kahneman and Klein agreed that expert intuition works in environments with regular patterns and adequate practice. Frameworks give you the patterns. Drawing gives you the practice. Lowy and Hood cataloged 56 of these frameworks in a book literally called The Power of the 2x2 Matrix. Four boxes is about the limit of what humans process at a glance. More than that and you’re back to a spreadsheet.

Kiyosaki’s quadrant is one of those 56. And for me, it was the first.

Where It Started

I picked up Rich Dad Poor Dad the way everyone does. Someone recommended it, I read it in a weekend. But the sequel is where things clicked. Kiyosaki drew that cross and suddenly the way I was thinking about cash flow, about my career trajectory, snapped into a shape I could see. Left side of the quadrant. Trading time for money. And seeing it drawn made it impossible to unsee.

I started drawing that quadrant myself. On napkins. In notebooks. The act of drawing forced me to be honest about where I was. Then I started drawing other things. Business model sketches, revenue structures, the cash flow cycle for a side project. Messy, quick, on the back of whatever was nearby. But every time I drew it, the problem got simpler.

Drawing became the way I thought. Not the way I presented — the way I understood.

When I became an engineering manager, the habit came with me. I didn’t consciously decide to “apply visual frameworks to leadership.” I just kept reaching for the marker. A hard conversation? Draw it. A strategy decision with too many variables? Two axes, four boxes, start placing things. The frameworks changed but the instinct was the same one Kiyosaki’s book had wired into me: if you can’t draw the situation, you don’t understand it yet.

Draw the Opportunity

SWOT has been drawn on whiteboards since the 1960s. Four boxes, two minutes, and suddenly the conversation shifts from “what should we do?” to “given these strengths and this threat, what’s our move?” The Ansoff Matrix does the same thing for growth: existing vs. new products across existing vs. new markets. You look at it and immediately see that your growth plan lives in the “new product, new market” box. The highest-risk quadrant. And nobody realized that until someone drew it.

Consulting understood this decades ago. BCG’s Growth-Share Matrix turned portfolio allocation into four animals: stars, cash cows, question marks, dogs. Eighty percent of what a strategy consultant delivers to a client is a drawing with boxes. The drawing forces the conversation that 47 slides couldn’t.

Now - here’s the skill: can you walk into a room where three VPs have been debating a product bet for six weeks, draw a simple impact/effort matrix on the whiteboard, place the options on it, and watch the room align in 15 minutes? The drawing didn’t solve the problem. It made the problem visible. And visible problems get solved. Invisible ones get another meeting.

Draw the Team

The drawings for strategy are well-known. The drawings for people are just as powerful, and most managers don’t use them.

Kim Scott drew Radical Candor as a 2x2: care personally on one axis, challenge directly on the other. That one drawing explains why your nicest manager might be your worst. Ruinous empathy, where you like someone too much to tell them the truth. The Skill/Will matrix gives you a coaching prescription for each direct report in seconds. High skill, low will? They’re not underperforming. They’re bored. That’s a completely different intervention than a performance plan. A 30-second drawing, a completely different outcome.

And then there’s the personal diagnostic. This is where Kiyosaki’s quadrant came back to me. Not for cash flow this time. For management.

Years ago, early in my management career, I was in a skip-level. My manager’s manager asked a question that still sits with me: “How does your team operate?” Simple question. I started answering. Five minutes in, I noticed something. Every sentence started with “I.” I review the PRs. I make the architecture calls. I handle escalations. I onboard new hires. I wasn’t describing a team’s operating model. I was describing me.

That afternoon I went to a whiteboard and drew Kiyosaki’s cross. The same one I’d drawn years ago for cash flow. E, S, B, I. And I landed exactly where I didn’t want to be. S. The self-employed quadrant. The one where Kiyosaki says “the self-employed person doesn’t own a business, the business owns them.” My team couldn’t function without me in the room. I wasn’t leading a system. I was the system. And the day I called in sick, three things stalled because the context lived in my head and nowhere else.

Gerber has a name for this. Working IN the business instead of ON it. Jade Rubick put it sharper: “Competence becomes dependency. Dependency becomes centralization. Centralization becomes a bottleneck.” That was me. The quadrant I’d first drawn about money was now telling me something about my management. I’d bought myself a job.

Can you sketch how your team actually works — how work comes in, how decisions get made, how someone new ramps up — in 60 seconds on a whiteboard? If you can draw it, a system exists outside your head. If the whiteboard stays empty, you ARE the system.

Draw the Trend

The third thing great leaders draw isn’t a framework. It’s a line.

A trend line. Across sprints. Across quarters. Across the morale data you’ve been collecting in 1:1s that you haven’t connected yet.

Most managers react to individual data points. “We had a rough sprint.” Leaders who draw? They sketch the last six months and see the pattern: we’ve been declining since September, and the floor is about to give way.

Traders do this every day. Support levels: the baseline performance a team doesn’t drop below. Resistance levels: the ceiling they keep hitting. False breakouts: the post-offsite energy that fades in two weeks. You don’t need a Bloomberg terminal. You need a whiteboard and the willingness to draw the line across six months of data instead of reacting to the last two weeks.

Klein’s research explains why this works. He studied fire commanders, military leaders, ICU nurses. They don’t compare options analytically. They recognize patterns from experience and act. The trend line is how you build that pattern library. You can’t recognize a pattern you’ve never drawn.

I’ve always loved running operational WBRs for exactly this reason. Weekly business reviews where you put the numbers on the wall and stare at them together. Not to celebrate or panic. To see the shape. Week over week, the line tells you things that no single data point can. A metric that’s been quietly sliding for eight weeks doesn’t show up in a status update. It shows up when you draw the line.

The Full Circle

Every framework in this post is a drawing. Four boxes. Two axes. A line across data points. None of them require artistic talent. They require the willingness to pick up a marker, look at a messy situation, and reduce it to something a room full of people can see at the same time.

I started drawing because a personal finance book told me to put myself in a quadrant. That habit followed me into management, into strategy, into the way I read my teams. The frameworks changed. The instinct didn’t.

Think about the last time you were stuck on a hard decision. A team problem, a strategy bet, a resource trade-off. Did you talk about it? Write about it? Schedule a meeting about it?

Or did you draw it?

So here is my question to you: when was the last time you picked up a marker — and what did the drawing show you that the conversation couldn’t?

#Leadership #EngineeringManagement #RichDadPoorDad #Strategy #Management

Last Friday, Jayson Tatum walked onto an NBA court for the first time in 298 days. Standing ovation. 15 points. 12 rebounds. 7 assists in 27 minutes.

But here’s what stuck with me: the Celtics were 42-21, second in the East as of this writing. Their best player hadn’t touched a court in ten months, and the team didn’t blink. Not because they replaced him. Because his coach built a system where Tatum’s presence, on the bench, in film sessions, in the locker room, kept shaping the team even when his body couldn’t play.

If you manage an engineering team, that’s your job too. And most of us haven’t figured it out yet.

As a die-hard Lakers fan, it hurts me to keep writing about other teams’ stars. But I’ve watched this pattern my whole life. Kobe on the bench with a torn achilles. Byron Scott said three words: “I wanted him around.” Phil Jackson won 11 rings not by being the smartest X’s-and-O’s coach, but by building a system where everybody touched the ball, everybody was empowered.

That’s coaching. The coach doesn’t play. The coach builds the system that makes the players around them better.

You’re the Coach

Gallup studied 27 million employees over 20 years. One finding towered over everything else: managers account for 70% of the variance in team engagement. Seventy percent. Not the mission statement. Not the tech stack. You.

The problem is right there in the same data. Manager engagement dropped to 27% globally. Workloads are up 51%. The instinct when you’re drowning is to do more yourself, not less. You review every PR. You answer every Slack thread. You sit in every meeting because “context.”

Liz Wiseman calls this the accidental diminisher. Diminishers get less than half their team’s capability. Not because they’re bad. Because they’re doing too much. She documented a case where a manager assigned a talented engineer routine tasks and solved their hard problems for them. The engineer ended up using 20-25% of their actual talent. Twenty-five percent.

You’ve got senior people on your team. The question isn’t whether they’re talented. It’s whether you’ve built a system where their presence — not their PRs — multiplies everyone around them.

Three ways to build that system.

1. Put Them in the Film Room

Mazzulla brought injured Tatum into the coaches’ film sessions and gave him a seat on the bench. Tatum said he spent time “seeing the game from their perspective.” His body couldn’t play. His basketball brain never stopped working.

Your team has film rooms. The CoEs. The postmortem. The design review. The experiment retro. But there’s a difference between your senior engineer attending these and your senior engineer running them. When they’re attending, they’re a participant. When they’re running them, their judgment shapes how the entire team thinks about the problem.

It’s your Staff Engineer leading the CoE after the outage, asking the questions that turn a 2 AM incident into a systemic fix. It’s your senior Data Scientist running the experiment review before the team wastes two weeks on a test with a confounding variable baked in. Not because you delegated a task. Because you put the person with the deepest judgment at the center of the room.

Make the film session exist. Recurring, not reactive. And name the person who runs it.

2. Let Them Set the Energy

When Curry broke his wrist in 2019, he became the Warriors’ self-appointed hype man. The Mavericks racked up $200K in fines for bench energy so contagious the NBA tried to legislate it. But the example that sticks with me is LeBron. Even in a quiet game, when a young Laker hits a three, LeBron is the first one up. The towel. The chest bump. He doesn’t celebrate his own plays anymore. He celebrates theirs. And the room changes.

This isn’t soft. The research is clear: team cohesion directly predicts performance. And that cohesion doesn’t come from the manager. It comes from the senior IC who writes the Slack post celebrating a junior’s first production deploy, even though their own project got deprioritized. The one who presents the team’s work at the leadership review, not for credit, but for awareness.

Stop hoarding the cultural work. Give your senior people the weekly wins slot, the team demo, the shoutout channel. Let them carry the temperature.

3. Make Their Presence the Standard

I keep coming back to those three words. “I wanted him around.” Kobe on the bench didn’t score a point. But his presence on the sideline changed how every Laker prepared. Patty Mills said Tim Duncan’s presence “makes you put your alerts up and your ears stand up.”

You know this feeling. The senior engineer whose name on a code review makes everyone refactor before they submit. Nobody told them to. The bar just moved. The data architect whose presence in the pipeline review means people check their contracts before anyone asks. The standard is implicit, not enforced.

Don’t let your senior people fade into the background because they’re “not shipping this sprint.” Their presence IS the shipping — of standards, of culture, of the bar.

Put their name on the review rotation. Make them the decision owner for a domain. Make their presence structural, not optional.

The Modern Diminisher

Now flip it. The manager who reviews every PR themselves, answers every architecture question before the senior IC sees it, sits in every data review because “context.” Their most talented people rubber-stamp reviews and write code two levels below their capability.

There’s a new version of this trap. AI reviews code now. AI flags architecture issues. So why put senior engineers in the film room at all?

Because AI made the judgment gap worse. Production success rates hit a five-year low this year. Teams are writing more code and failing more often. The bottleneck isn’t generating code anymore. It’s knowing whether the code should ship. That’s judgment. AI doesn’t understand your system’s unwritten rules. It doesn’t feel the blast radius. That’s what your senior engineers provide. And it’s the manager’s job to protect their time for exactly this work. Not bury them in low-leverage tasks.

Here’s what nobody talks about: AI creates an ownership gap. Engineers are starting to say “the AI wrote that” in postmortems. Not my code. Not my problem. That’s where the energy, the presence, the human fabric of a team matters more than it ever has. AI amplifies whatever foundation you have. If your senior people aren’t in the room, AI amplifies mediocrity at machine speed.

Where the Scoreboard Changes

I see this in my managers. I see it in my teams.

The leader who reviews every PR because it feels productive. The one who answers every architecture question in Slack because it’s faster. I’ve been that person. The scoreboard said “what did you build?” and we kept playing that game long after the job changed.

The hardest part isn’t the framework. It’s the identity shift. You built your career on being the person with the answers. Now the job is building the system where other people find them. That shift happens at every level. IC to senior IC. Manager to director. And it never gets easier, because the instinct to do it yourself never fully goes away.

There’s a crude metric that floats around engineering circles. PRs written versus PRs reviewed. People have strong opinions about it, and the numbers alone don’t tell you much. But the direction they point? The more senior you go, the more your impact shows up in other people’s work. Not yours.

I won’t pretend the organizations have caught up. Most promotion frameworks still reward output. Most performance reviews don’t have a line for “ran the postmortem that prevented the next outage.” That’s a real gap. But the best leaders I’ve worked with figured out how to make influence visible. And how to fight for their people when the system didn’t.

That’s what coaching is. You stop keeping score for yourself. And you make sure the score counts for the people doing the work.

The Question

Think about the most senior people on your team right now.

Are they running the film room? Setting the energy? Raising the standard?

Or are you trying to play every position while they sit on the bench?

So here is my question to you: are you coaching, or are you playing?

#Leadership #EngineeringManagement #NBA #Multipliers #CultureAndTeams

You’ve heard of the haves and the have-nots. It used to be about money.

The top 10% of American households own 67% of the wealth. The bottom 50% own 2.5%. We call it the K-shaped economy. Two populations, same starting point, opposite trajectories. Wealth compounds. Capital makes capital. And the gap accelerates.

Now imagine that same K-shape. But instead of money, it’s what you know. How you work. Whether you’ve figured out how to think alongside AI or whether you’re still doing everything the way you did three years ago.

That K is already here. And most people are on it without realizing which arm they’re on.

The New Haves and Have-Nots

OpenAI’s latest enterprise data tells a story most leaders haven’t internalized yet. Workers at the 95th percentile of AI adoption send six times as many messages as the median employee. Same company. Same tools. Same license.

For coding tasks, it’s 17x. For data analysis, 16x.

This isn’t a gap between companies. It’s a gap between the people sitting next to each other. And it compounds the exact same way.

The question I get asked more than any other: “How do I get started with AI?” From team members. From people I mentor. From new hires who feel behind on day one. What they’re really asking: is the gap already too wide to close?

It hasn’t. But the math is about to get a lot harder. Because this gap compounds. In both directions.

The AI Haves

I remember the exact moment it clicked for me.

I was working on a strategy one-pager. The kind I used to spend a full afternoon writing, staring at a blank document, deleting half of it, starting over. This time I opened an AI tool, spoke my rough thinking out loud, and had structured text back in three minutes. I pasted it into Claude, asked it to challenge my reasoning. Spoke my response to the pushback. Three rounds. Fifteen minutes. A draft that would have taken four hours.

That was week one. Saved some time. Felt like a nice trick.

But here’s what happened over the next few months. I started building prompts for the work that repeated. Meeting prep. First-pass research. Competitive analysis. Over 80% of AI users report saving at least an hour every day. I was saving more than that.

The real shift wasn’t the time savings. It was what we did with the time.

By month three, I stopped using AI to produce and started using it to think. Pressure-testing a product strategy I wasn’t sure about. Exploring edge cases I’d normally skip. Prepping for the hard conversation I’d been putting off. The time savings became capability savings. I wasn’t just faster. I was attempting things I wouldn’t have tried before.

By month six, the question changed entirely. It stopped being “should I use AI for this?” and became “how does AI change what’s possible here?”

75% of leaders and managers are already at this stage. The AI haves didn’t begin with more talent. They began with a first experiment. And compound interest did the rest.

The AI Have-Nots

The other arm of the K doesn’t look like failure. That’s what makes it dangerous. It looks like Tuesday.

You come in. You do your work. Same quality you’ve always delivered. But the person across the hall finished the same deliverable in a third of the time and spent the rest of their morning prototyping something new.

That’s the time trap. Without AI, a task that takes you three hours takes a colleague 45 minutes. You’re spending your entire day on execution. They’re already on the next problem. And the next one. And the next one.

Then comes the learning trap. Because your day is full, you never learn the tools. And because you never learn the tools, you miss what the AI haves discover every week. You’re not behind by one capability. You’re behind by a compounding series of capabilities you don’t even know exist.

I’ve seen this in my own teams. Good people. Same tools. But the ones who didn’t engage didn’t realize the baseline had moved until the gap was visible to everyone in the room. Not a talent problem. A compounding problem.

40% of American workers are completely disengaged from AI. No usage, no interest. 45% of non-users believe AI can’t help their work. One in five hasn’t even heard it’s being used at work.

The confidence trap might be the worst one. The longer you wait, the more intimidating it feels. Starting today feels harder than starting a year ago, even though the tools are easier to use.

Compound erosion doesn’t send a warning. It’s silent. You don’t feel the gap forming. You just wake up one morning and realize you can’t see across it anymore.

If You’re Just Starting Your Career — This Part Is for You

If you just graduated, or you’re in your first or second job, or you’re still figuring out what your field even looks like — there’s a version of the K that hits different.

The numbers are real:

• Entry-level jobs are down 13% in AI-exposed occupations (Stanford)

• UK tech graduate roles dropped 46% in a single year

• 66% of enterprises are reducing junior hiring because of AI

• 38% of engineering leaders say AI has reduced direct mentoring of juniors

The grunt work that used to build expertise — code reviews, financial models, research summaries — is the first work AI replaces. The career ladder isn’t harder to climb. The bottom rungs are disappearing.

Here’s the deeper problem: without domain expertise, you can’t give AI meaningful direction. Without a point of view on what “good” looks like, AI is just a fancy autocomplete. You get output. You can’t evaluate it.

But here’s what the research actually says. And it surprised me.

AI doesn’t help experts the most. It helps beginners the most.

• Brynjolfsson’s study: 35% productivity improvement for novice workers. Almost nothing for experienced ones.

• The HBS/BCG “Jagged Frontier” study: below-average performers improved 43% with AI. Top performers? Only 17%.

• Junior developers build skills 2-3x faster when they use AI as a tutor, not a code generator.

Your disadvantage — no point of view yet — is actually your advantage. No bad habits to unlearn. No “but I’ve always done it this way.” AI can compress the journey from “I don’t know this field” to “I have a point of view” from years to months.

Only if you use it to build judgment, not just generate output. Here’s how:

• Ask why, not just what. Don’t accept AI’s answer. Ask it to explain its reasoning. Ask for the counterargument. The act of evaluating AI’s thinking builds yours.

• Catch the mistakes. The moment you spot where AI got it wrong, you’re building domain expertise. Every correction sharpens your point of view.

• Reinvest the time. When AI handles the grunt work in 20 minutes instead of three hours, don’t fill those hours with more grunt work. Study the domain. Learn why things work, not just what they produce.

That first real experiment, the one where you stop watching from the sideline and actually engage — is the first deposit in your compound interest account.

The Question Behind the Question

We spent the last three years debating whether AI would take jobs. The better question was always which K it would put you on.

So here is my question to you: where are you on the K right now?

Are you compounding? Or are you standing still while the baseline moves under your feet?

And if you’re just starting your career: are you using AI to generate output? Or are you using it to build a point of view?

Because the K doesn’t close on its own. It only compounds.

#Leadership #AI #FutureOfWork #KnowledgeEconomy #CareerGrowth

My daughter’s favorite place in the world is a convenience store.

Not a theme park. Not a beach. A 7-Eleven in Tokyo.

Japan is her favorite country, so we end up going a lot. Sometimes twice a year. And every single trip, the first thing she asks when we land isn’t “where’s the hotel?” It’s “can we go to 7-Eleven?”

Fresh onigiri she picks out herself. Egg sandwiches that belong in a café. Little strawberry desserts she somehow always finds. She treats it like a destination.

She has never once asked to go to a 7-Eleven at home.

Same logo. Same name. Completely different place. And honestly? She’s not wrong. A five-year-old figured out something most business leaders miss.

Here’s the thing: 7-Eleven is an American brand. Started in Dallas, Texas, 1927. A company called Southland Ice selling groceries next to ice blocks. Japan licensed the brand in 1974, and a manager named Toshifumi Suzuki rebuilt the entire concept from scratch. Got so good at it that when the American parent went bankrupt, the Japanese licensee bought them.

The student bought the teacher.

And now the US is spending billions trying to copy Japan back. 1,300 new food-focused stores by 2030, Japanese-style onigiri and egg sandwiches in American aisles. Revamped stores are already showing 45% higher sales.

The Pattern Nobody Talks About

7-Eleven Japan runs a 27% operating margin. The US runs 3.5%. Same brand.

But this isn’t just a 7-Eleven story. Apple copied Xerox PARC’s graphical interface. Samsung studied the iPhone with a 132-page internal document that became court evidence. Toyota studied Ford’s assembly line and built a manufacturing system Ford itself couldn’t replicate. Tencent copied ICQ in 1999. Everyone called them China’s biggest copycat. Then they built WeChat, so original that Facebook and Instagram started copying them.

This pattern has been hiding in plain sight for decades. The companies that copy spend 60-75% less than the ones that invent. Almost half of market pioneers fail. And the fast followers? They capture three times the market share of the companies that went first.

Copying isn’t a shortcut. It’s a strategy. But only if you don’t stop there.

I’ve been studying this in business, in tech, and honestly in my own career. It always follows three stages. The companies that copied and failed? They stopped at stage one.

1. Copy to Learn (Not Copy to Ship)

Suzuki didn’t copy America’s hot dogs and Slurpees. He copied the format. The idea that a small store could serve a neighborhood’s daily needs. Then he rebuilt everything else.

That distinction is everything.

Tencent didn’t clone ICQ’s interface. They studied what messaging could become in a country where people used internet cafés, not desktops. Samsung didn’t replicate the iPhone. They studied what a smartphone needed to feel like, then went somewhere Apple refused to go: bigger screens, open ecosystem. Spotify didn’t copy Napster. They studied what Napster proved and built the legal version.

There’s a name for this: the “Fast Second”. You don’t win by being first. You win by learning faster.

This isn’t just a business pattern. Herminia Ibarra’s research in HBR found that new leaders do the exact same thing. They learn by imitating mentors. Copying their communication style, their meeting cadence, their decision-making approach. Feeling like a fake during this phase isn’t a red flag. It’s a sign you’re growing.

We all read Netflix’s culture deck. That’s the curriculum. Not the diploma.

2. Develop Your Own Point of View (POV)

This is the stage most people skip. And it’s the only one that matters.

Suzuki’s constraints became his advantages. Dense Japanese cities? He clustered 50-60 stores in tight pockets so one delivery truck could hit them all and shelves could rotate three times a day. A culture that demands quality from a corner store? He built unannounced inspections and daily reports. A market obsessed with freshness? He ate his own store’s bento every single day and gave feedback.

The format was American. The point of view was entirely Japanese.

I’ve done the lazy version of this. I once joined a new team and installed the exact operating rhythm from my previous role. Same standups, same sprint cadence, same review format. Looked right on paper. But the old team had years of shared trust and a culture of candor. The new team experienced the same rituals as micromanagement.

I was copying without a point of view.

It took me months to stop and ask: what would tight feedback and high standards look like for THIS team, at THIS stage? That question changed everything.

Your constraints aren’t reasons you can’t copy Google’s playbook. They’re the reason you can build something Google can’t.

3. You Know You’ve Made It When They Copy You Back

7-Eleven Japan bought the American parent. Now the US is trying to become Japan. Their new CEO said it plainly: “Long-term success breeds complacency. This is our opportunity to reinvent.”

Tencent: “biggest copycat” in 2010. By 2020, Western platforms were copying WeChat’s super-app model. Samsung: lost a billion-dollar lawsuit to Apple for copying the iPhone. A year later, the Wall Street Journal asked: “Has Apple Lost Its Cool to Samsung?” Toyota: studied Ford. Created TPS. Now Ford studies Toyota.

Hawaii tells the story at a smaller scale. Japan bought the Hawaii 7-Eleven operation in 1989. They didn’t copy Tokyo. They installed the principles and rebuilt for local context. Spam musubi since 1994. Different products in every neighborhood. Now the US mainland is studying Hawaii as the model.

And then there’s Famima!! A Japanese convenience store chain that opened in LA in 2004. Copied the output perfectly. Japanese food, clean stores, great design. Never developed a point of view about what a konbini should be in America. All stores closed by 2015.

The food was right. The thinking was missing.

The Real Question

The best companies didn’t start with a breakthrough idea. They started by studying someone else’s. The difference between the copycats that failed and the ones that built empires is always the same three stages.

So here is my question to you:

What are you copying right now? From another team, another company, another leader you admire?

Are you still at stage one, importing the playbook? Or have you started developing a point of view about what those principles would look like in your world, with your constraints, for your people?

Because copying is how the best companies start. The question is whether you have the courage to make it your own.

#Leadership #Strategy #Innovation #Management #SevenEleven #FutureOfWork

My wife caught me in the kitchen last Tuesday, pacing around the island, talking to no one. Hands gesturing at the air. Voice rising. Mid-sentence about an org design I’d been stuck on for weeks.

She stared at me for a good ten seconds. “Are you arguing with yourself again?”

I was. And in fifteen minutes of talking to myself, I’d cracked a problem I’d been staring at in a Word document for three hours.

About a year ago, I wrote my very first post in this series. It was called “Write to Think“ The argument was simple -

In the AI era, writing isn’t about communication, it’s about thinking. Writing forces clarity. It’s a gym for your brain.

I still believe every word of it. But I was incomplete.

Over the past year, something shifted in how I work. I stopped writing as my first step. I started talking. Not into a meeting. Not to a colleague. To myself — and increasingly, to an AI that listens, pushes back, and helps me iterate at a speed my keyboard never could.

And no, this isn’t about dictation. Apple has had that since 2011. Google since 2010. Those tools transcribe your words. What I’m describing is different: a thinking cycle that runs faster when you speak it than when you type it. The AI tools that matured this past year made that gap impossible to ignore.

Speaking Forces Thinking

Here’s what nobody tells you about typing: you self-edit before the thought fully forms. You stare at a blinking cursor. (No, not that Cursor, though I love that one too.) You type half a sentence. Delete it. Retype. The thought never fully arrives because it keeps getting filtered through the bottleneck of your fingers.

When you speak, you can’t do that. You have to push the idea forward, start to finish, in real time. Speaking demands that you organize, commit, and articulate — out loud, in the moment.

And then you catch yourself mid-sentence: “Actually, no, what I really mean is...” You reframe. You self-correct. You discover what you actually think by hearing yourself say it.

That self-correction loop is the entire point.

Turns out, psychologists have known this for nearly a century. Vygotsky showed in the 1930s that talking to yourself isn’t a quirk. It’s how humans develop higher-order thinking. He called it “private speech“, and decades of research have confirmed it improves planning, problem-solving, and self-regulation, well into adulthood.

There’s even a name for it: the “self-explanation effect“. People who verbalize their reasoning show up to 20% improvement on complex tasks compared to those who just re-read the material.

We’ve always known this works. We just spent forty years typing instead.

So the quality of thinking improves when you speak. But that’s only half the story. The other half is speed.

The Conversation Loop — A Faster Flywheel

In “Write to Think“ my thinking cycle was: brain dump -> shape your thoughts -> spar with AI -> make it actionable. Good cycle. But every turn of that flywheel required typing. And typing runs at 40-50 words per minute for most people.

Speaking? About 200 words per minute — roughly 4x faster.

That’s not just a 4x improvement in input speed. It’s a 4x improvement in iteration.

Let’s do the math:

• The write-to-think loop: think -> type your question (slow) -> wait for AI -> read -> think -> type your follow-up (slow again). Each full cycle: 8-10 minutes.

• The talk-to-think loop: speak your question -> read AI response -> speak your reaction right back -> response again. Each full cycle: 2 minutes.

Same flywheel from “Write to Think” But now the cycle runs 4-5x faster. More iterations in less time. Better thinking, compressed.

Here’s what that actually looks like. Last week I needed to prepare a strategy brief. Normally I’d open a Word doc, stare at it, type for two hours, delete half of it, try again.

Instead, I put on my airpods and opened Wispr Flow (and no, this is not a sponsored post. Nobody’s paying me to say this. It just genuinely changed how I work). I paced my office and spoke my rough thinking for about three minutes. Clean, formatted text appeared on screen. No “ums,” no filler, no cleanup needed.

I pasted that into Claude. “Challenge this reasoning.” Read the pushback. Spoke my response to the pushback. Another round. Three rounds total, fifteen minutes. I had a structured first draft that would have taken an entire afternoon of typing and staring.

Brain dump -> shape -> spar. The cycle I described a year ago. Just running at a completely different speed.

Now, you might be thinking: ChatGPT has a voice mode. So does Gemini. Why not just talk to them directly?

I tried. You start explaining your thinking, pause to collect a thought, and the AI jumps in. It mistakes your pause for a finished sentence. You restart. It happens again. The turn-taking is still clunky enough to break the exact thinking flow you’re trying to protect.

But there’s a bigger reason I don’t use them. Those voice modes lock you into one app. I don’t want to do all my thinking inside ChatGPT.

I want to speak into whatever I’m already working in. Cursor has voice input -- I use it when I’m coding (or better yet, org design, as I discovered lately). Notion when I’m planning. Claude when I’m sparring. Slack when I’m replying to someone. A system-wide dictation layer means I speak, clean text shows up wherever my cursor is, and I pick the best tool for the job.

That’s the real shift. Not “use this one AI’s voice feature.” It’s making your entire workflow voice-native.

Why Now? From Transcription to Comprehension

We’ve had voice dictation for fifteen years. But every tool until recently did one thing: transcribe. Every “um,” every false start, every “so basically” -- faithfully captured and dumped on your screen. You’d spend twenty minutes cleaning it up. The tool created more work, not less.

What showed up this past year is something different: comprehension.

Tools like Wispr Flow, and others emerging in this space, don’t just hear your words. They run LLMs under the hood to understand what you mean. They know what app you’re in and adapt the tone. They read the context around your cursor. You say “so the main thing is we need to, like, rethink how we onboard people from scratch” and it outputs: “We need to fundamentally rethink our onboarding approach.”

The filler is gone. The intent stays.

Old dictation gave you a transcript you had to fix. AI-powered voice gives you a clean first draft you can build on. That’s the difference between a tool that slows you down and one that accelerates the entire talk-to-think cycle.

And it’s getting faster. The speech models powering these tools improved dramatically in the past year. Real-time processing. Better accuracy across accents and technical vocabulary. The gap between what you say and what shows up on screen is now nearly zero.

Which means the bottleneck was never your brain. It was never even your voice. It was the technology between the two. And that bottleneck just disappeared.

One Year Later

A year ago, I wrote “Write to Think” and told you to write more in the AI era. I still believe that. Writing is still the gym. It still forces clarity. It still makes your thinking sharper.

But if I’m honest about what actually changed my productivity this past year, it wasn’t writing more. It was talking more. Speaking rough thinking out loud, letting AI turn it into structured text, then sparring with that text at the speed of conversation instead of the speed of typing.

The “Write to Think” flywheel didn’t break. It just got a motor.

So here is my question to you: when was the last time you solved a hard problem by typing about it, and when was the last time you solved one by simply talking it through?

#Leadership #Productivity #AI #VoiceAI #WriteToThink #TalkToThink #FutureOfWork

You don’t have to be a member of the Academy to appreciate World War Z. You don’t even have to like zombie movies. But you do need to know the concept that movie burned into the corporate subconscious: The “Tenth Man Rule”.

It’s based on real Israeli intelligence protocols (or at least, the Hollywood version of them). The rule is simple: If nine people in a room agree on a strategy, the tenth person has a mandatory duty to disagree.

Even if the dissent seems crazy. Even if it seems unlikely. The Tenth Man has to assume the other nine are wrong to prevent the kind of groupthink that gets you eaten by zombies.

Now, as an engineering and data leader, I build products, and I generally don’t have to worry about zombies. Well, except for that one legacy codebase we’re all afraid to touch, but that’s a different horror story.

But I do have product launches. I have market shifts. And mostly, I have blind spots.

And here is the honest, slightly terrifying truth I don’t usually say in All-Hands meetings:

When 100% of you nod at my strategy, I don’t feel supported. I feel unprotected.

The Nightmare of the Polite Meeting

In the past years, the scariest meetings I sat in weren’t the ones with shouting matches (and I love heated debates, it shows we care, but that’s a story for a different time). They were the ones with silence.

You know the ones. I present a roadmap that is clearly aggressive, maybe a little delusional. I look around the table.

Nod. Nod. Nod. “Looks good.” “We can do it.”

I walk out of those meetings sweating.

Why? Because, in these type of meetings, it shows that I live on top of the Iceberg of Ignorance.

That’s a real study, by the way. Sidney Yoshida ran it. The data says that senior leaders only see about 4% of the actual problems on the ground.

Granted, my doubts on the 4% number. And I see dashboards, WBRs beyond just the strategy decks and the P&Ls.

That said, let’s assume - you live in the 96%. You see the line of code that produces technical debt, the API latency that could cripple a tier-1 service, the client and customers grumbling, and the fact that the “simple migration” I just pitched is actually going to require rewriting the entire backend.

If you stay silent to be polite, or to be a “good soldier,” you aren’t validating my genius. You are letting me steer the ship into an iceberg I literally cannot see because I’m standing on the bridge looking at the clouds.

Be My Sonar, Not My Echo

I don’t need an echo chamber. I can get an echo chamber by talking to myself in the shower.

What I need is Sonar.

An echo just repeats what I said: “Course looks good, Captain.” (This feels nice for my ego, briefly, until we sink).

Sonar pings back the hard truth: “Obstruction ahead. Turn hard starboard or we die.” (This creates friction. It’s annoying. It saves the ship).

So, how do you be the Sonar without getting fired for being “negative”? You have to learn the art of the Strategic No.

Here are three ways to tell me I’m wrong that will actually make me love you.

1. The Time Traveler (The Pre-Mortem)

I usually suffer from “optimism bias.” I love my plan. It’s my baby.

Don’t tell me “This is risky.” I’ll get defensive.

Instead, be a time traveler. Say this:

“Let’s assume it’s six months from now and this launch failed. What broke?”

Now we aren’t arguing about my idea. We are solving a hypothetical puzzle. You shift me from “Defending My Ego” to “Fixing the Future.”

2. The Price Tag

I honestly don’t know the true cost of what I’m asking half the time. I just know I want it fast.

Don’t tell me we can’t do it. Tell me the price. And tell me regardless how many times I said I hated the word LOEs.

“We can hit that aggressive deadline, but the ‘price’ is skipping the data validation layer. If the source schema changes, the entire pipeline crashes. Are you willing to buy that risk?”

See what you did there? You didn’t block me. You became my financial advisor. You gave me the agency to decide if the speed is worth the cost. (Spoiler: It usually isn’t) (And our Product leaders are usually doing way better than Engineering/Science leaders on this - oh the empathy).

3. The Recommendation

Don’t just drop a problem on my desk. Bring a shovel so we can dig our way out.

If you’re going to shoot down my plan, you need to have a Point of View on where to go next.

“The timeline is tight. I recommend we cut Feature Z to ensure stability. Here is the draft plan.”

That proves you aren’t just a ticket-taker. You’re an owner.

The “Safe Word”

Now, there is a catch.

Amazon and Netflix made “Disagree and Commit“ famous. It’s a great corporate slogan, but it can feel a little cold.

Here is how I translate it: The Audit vs. The March.

Before the decision is made, we are in the Audit Phase. I need you to tear it apart. Be the Tenth Man. If you stay silent here, you are failing the team.

But once the decision is made? We switch to the March Phase. We stop auditing. We start rowing.

The most valuable thing you can say to a leader is this:

“I’ve flagged the risks, I’ve told you the cost, but now that you’ve made the call, I’m going to make this work.”

That isn’t submission. That is professional agility.

Silence is Suspicious

Here is the bottom line.

When I hire smart people, I’m not paying for their compliance. I’m paying for their friction.

If we are in a room and we all agree, then most of us are redundant.

So tomorrow, look around your next meeting. If it feels too comfortable, if the nods are too automatic... that is your cue.

Be the Tenth Man. Be the Sonar.

I don’t need you to cheer me on. I need you to check the instruments.

And BTW, be ready for my follow-up question too - “what do you think?“

Last week, I confessed to being “lazy” with my notes. I argued that the ROI of organizing files is zero, and that we should treat our Second Brains like data lakes - dumping everything in and using AI to retrieve it later.

This week, I’m doubling down. I’m going to tell you how to be “lazy” with AI empowered automation.

Okay, here’s where the idea came from -

This might not surprise you - most of us hold a rigid belief about leadership: My primary duty is to empower my team to be the force multipliers. If I am heads-down optimizing a Spark join, fine-tuning hyperparameters, or debugging a race condition, I am not looking at the horizon. I am not clearing obstacles for my crew. I am not leading.

As for me, I stepped away from code contribution for a long time - ever since I became a people manager - a loong time ago. It is a principle I was taught early in my career, and one I now pass down to every leader I mentor: You must be the Captain of the Ship.

Now the theory is - the Captain’s role is not to be the best sailor on the rigging or the fastest mechanic in the engine room. The Captain’s role is to stand on the bridge, scan the horizon for storms, and set the bearing. If I am heads-down fixing a piston (or code), no one is steering the vessel. The moment I touch the codebase, I stop being an enabler for my team and start being a bottleneck.

That was the rule. Until recently, when I found a surprising way to do this better - coding. And more precisely, Vibe Coding.

The fact is that with Generative AI, the economics of software creation had fundamentally inverted. I realized that in addition to building proprietary data, I also needed to build my own tools - hyper-personalized, bespoke tools - to navigate the complexity of modern leadership.

I call this practice “Vibe Coding Burner Code for your Leadership” And the output isn’t DTC software. It is something much more powerful for a leader.

The Economics of Burner Code vs Production Assets

Now, for my fellow non-tech leaders, please don’t get scared away by “coding.” It’s actually quite simple. Let me explain.

To understand why you should be building software, you have to realize that “Code” is not a monolith. There are two distinct species, and mixing them up is why most leaders hesitate to start.

• Type 1 is the Asset. This is what your engineering team builds. It is designed for customers, which means it lives under the tyranny of the “Usual Suspects”: five-9s reliability, massive scalability, and perfect security. It is expensive because it has to be. It demands rigorous testing, peer review, and maintenance. Its goal is Engineering Excellence.

• Type 2 is the Utility. This is what I build. I call it Burner Code because it is designed for speed. The bar here is dramatically lower: “Does it run?” It lives on my laptop, not a server. It doesn’t need to scale to a million users; it just needs to work for one. And the cost isn’t measured in sprints or budget cycles - it’s measured in minutes of “vibing” with an AI. The goal isn’t excellence; it is simply high ROI.

This is the mental shift.

In the engineering world, “Burner Code” sounds reckless. In the executive world, it is a superpower. It’s like a “Burner Phone” - you use it for a specific mission, and when the mission is done, you toss it. You have zero attachment and zero maintenance debt.

If I spend 4 hours debugging a complex script that saves me 5 minutes of work, that is terrible ROI. I should have just done the work manually.

But if I spend 15 minutes prompting an AI to write a messy, ugly script that saves me 10 hours of manual data entry? That is Infinite ROI.

I don’t care if the code is “spaghetti.” I don’t care if it lacks error handling. If it breaks, I don’t fix it - I throw it away and generate a new one.

Here are two examples of how “Burner Code” has force-multiplied my leadership in ways that off-the-shelf software never could.

Story 1 - The Mail Scanner

I had a ghost in my machine. specifically, a folder on my Mac that held 25 years of scanned mail, documents, and insurance policies.

Because I used to be a librarian, they were meticulously organized by date. But because I am human, I could never find anything. If I wanted to find “that one insurance policy from 2014,” I was at the mercy of Spotlight search and my own hazy memory of how I named a file a decade ago. It was dead data. I wanted it alive inside my AI Second Brain (Notion).

The problem was the friction. To fix this consuming Sunday fun meant one of two painful choices:

1. The Manual Slog: Spend my next 10 Sundays manually uploading and tagging PDFs.

2. The Software Hunt: Scour the App Store for the “perfect” document management app. I’d spend hours reading reviews, pay a $15 monthly subscription for a slick tool that promises to “organize my life,” and eventually realize it forces me into their rigid structure. I’d be stuck manually tagging files in a proprietary system that doesn’t talk to the rest of my brain.

So, I tried the Burner Code way.

I didn’t write a spec. I didn’t open a Jira ticket. I opened Cursor and typed a prompt as casual as a text message:

> “Hey, I have a local folder of PDFs. Write a script to OCR them, extract the text, and shove them into Notion. Use the file creation date as the property date.”

The AI generated the code. I ran it. It crashed immediately (Notion API rate limits).

In my past life as an engineer, I would have sighed and spent the afternoon reading API documentation to implement exponential backoff.

As a Vibe Coder, I just typed: ‘It crashed. Make it sleep for 1 second between uploads.’

It fixed the code. I hit run again.

Twenty minutes later, while I was sipping my coffee, that ugly, 50-line script chewed through two decades of bureaucratic debris. It indexed my entire financial and legal history into my AI.

Buying a “perfect” software would have cost me a monthly subscription and forced me into a generic workflow that didn’t fit my needs. My Burner Code cost $0, saved me months of manual labor, and was hyper-personalized to exactly how I wanted my archive to work.

Story 2 - Escaping Spreadsheet Paralysis

I was paralyzed by a file named FY26_Org_Model_v4_FINAL.xlsx.

As leaders, we live in these models. We don’t just run them to execute changes; we run them to think. We analyze our teams regularly - not always to take action, but simply to know the terrain. We need to visualize the structure, simulate the “what-ifs,” and play with different configurations to find the one that unlocks the most impact.

But the moment you try to simulate that change, the file becomes a drag. You are trying to answer a simple strategic question - “What happens if we move Data Science closer to the vertically optimized business teams?” - but the tool fights you.

You move a row. A VLOOKUP breaks. You fix the formula. The pivot table for the “Budget” doesn’t refresh. You email Finance to validate the headcount costs. They take 4 days to reply. By the time you get the answer, you’ve forgotten the hypothesis.

The tool was dictating the speed of my thought. This rigid workflow forced me to choose between accuracy (slow) and agility (messy).

So, I tried the Burner Code way.

I realized I didn’t need a spreadsheet; I needed a simulator.

I fed the raw CSV exports into Cursor and asked for the analysis that actually matters to a leader:

> “Ingest these CSVs. Build me an interactive dashboard to track my core health metrics: Span of Control, Location Strategy, Reporting Layers, and FTE/Contractor ratio. Now, make it playable. Let me drag this entire Functional Team to a different VP and instantly see the impact on our ‘Big Rock’ capacity vs. ‘Fast Lane’ throughput. Also, add a toggle: What happens to the budget if I swap the next 5 Data Science hires for Machine Learning Engineers?”

The Result:

Now I didn’t spend the afternoon debugging Airflow DAGs, wrestling with Pandas dataframes, or waiting for a Spark job to spill to disk. I bypassed the entire ETL grind. Thirty minutes later, I had a functioning “Org Sandbox” running in my browser - rendering insights with zero latency.

It wasn’t enterprise software. It didn’t have a login screen. But it allowed me to play “God Mode” with my organization. I dragged cards. I tested hiring mixes. I ran 50 scenarios over lunch in the time it usually takes to debug one Excel formula.

The spreadsheet is the default tool for this, but it is a poor substitute for imagination. The limitation of a spreadsheet isn’t its features; it’s that it cannot read my mind. It forces me to translate my fluid strategic thoughts into rigid static rows. No generic tool, no matter how advanced, can perfectly predict how I want to simulate a specific trade-off or visualize a hiring risk. Some people call what I built “hyper-personalization.” I agree. But ultimately, it works because it is a direct brain dump. It fits the shape of my brain because it came directly from it.

The Death of Im Not Technical

We used to have a valid excuse. We could say, “I can’t solve this because I don’t know how to code.”

That excuse is gone.

The barrier to software creation has dropped from “Years of Study” to “Minutes of English.”

This implies a terrifying new reality for leaders: If you are stuck manually updating a spreadsheet or waiting for your Data Analytics team to build a dashboard, it is no longer a technical limitation. It is a choice.

You are the only person who knows exactly how your brain works. You are the only one qualified to build the tools that extend it.

So stop waiting for a tool that reads your mind. Build the tool that is your mind.

Use it. Drain the value. Throw it away.

Don’t build for the Ages. Build for the Afternoon.

#VibeCoding #Leadership #Productivity #AI #ExecutiveOps #FutureOfWork