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

What is your favorite thing to do on a Sunday night?

For me, it should be watching the Lakers game. LeBron is likely doing something defying the laws of physics in his 23rd season.

But for years, I wasn’t doing that.

Okay, actually, that’s a lie. I was watching it. But I wasn’t present. I was watching it while stressing over my absolute least favorite thing.

I was staring at a folder in Evernote called _INBOX_PENDING.

If you know GTD, you know this folder. It’s the digital purgatory where you dumped every PDF, every screenshot, and every “important” article from the last week, promising yourself you’d file them “later.”

Well, later is here. And it sucks.

For the last 20+ years, I have been telling myself a massive lie about productivity. The lie is that being “organized” means having a perfect taxonomy. We are told that if we just find the right hierarchy - if we just create the perfect system of nested folders - we will finally feel in control. (for some of us from the Disney mafia, this was very much true with the legacy GoPub systems, I just picked up this context for my personal life.)

So we spend our Sundays acting like librarians. We tag. We color-code. We move files from “Downloads” to “Projects > 2026 > Q1 > Research”.

But let’s stop lying to ourselves.

It feels like work because it’s tedious. It feels like value because it’s orderly. But in reality, we are just rearranging deck chairs on the Titanic. We are spending more time maintaining our “Second Brain” than we are actually using it to think.

Now till AI became a thing, I started to realize that I wasn’t building a knowledge base. I was digging a Digital Graveyard.

Because once a file went into that perfectly organized folder structure... I never opened it again.

The Death of the Green Elephant

I didn’t come to this realization willingly. I was forced into it.

For 15-ish years, Evernote was my external hard drive. I was a power user. I had thousands of notes, meticulously tagged. I bought the different type of scanners, and digital pencils.

Then, the product changed. It got slow. The features bloated. The “Green Elephant” in the room wasn’t remembering anything anymore; it was just taking up space. And honestly it was probably the most downloaded 1-star app in Apple AppStore for a long time.

But the real breaking point wasn’t the app. It was my own workflow with AI as a new tool.

I found myself doing something ridiculous. I would open an old note in Evernote, hit Cmd+C, switch tabs to ChatGPT, paste it in, and type: “Read this and tell me if I missed anything important”.

Stop and look at that workflow.

I was manually acting as the data pipe between my storage (Evernote) and my compute (LLM). I was the friction.

Evernote didn’t grow, that doesn’t mean I shouldn’t!

It hit me like a ton of bricks: Why isn’t the compute living inside the storage?

Why am I paying rent for a storage unit that makes me do all the heavy lifting?

The “Dumpster” Architecture

That was the moment I stopped acting like a Librarian and started acting like a Data Engineer.

I moved everything to Notion. (Note: I don’t work for them, I just use them. Use whatever works for you).

(And I’m no expert with Notion either - here’s a good YouTube video if you’re interested)

But I didn’t move there to build a pretty dashboard with emojis and inspirational quotes. I moved there to build a Data Lake.

If you’re in data engineering, you know the shift. We stopped building rigid “Data Warehouses” years ago because the schema maintenance was a nightmare. We moved to “Data Lakehouse“ - just dump the raw data in one big pile and structure it later when you query it.

So I applied that to my life. I call it the “Junk Drawer” Protocol.

• I stopped tagging.

• I stopped filing.

• I stopped worrying about “where” things go.

I created one massive database called “The Archive” for all legacy Evernote notes. (The migration sync process was excruciatingly painful, and rate limited after 100 notes.) And I just dump everything there. Plus some simple main pages for home and work.

The friction of capture dropped to zero. But the magic of retrieval went through the roof.

The “Auto-Index” Ritual

Now, when I save a messy meeting notes or a rambling voice memo, I don’t format it.

I just hit a button that asks the AI to do two specific things inside the note:

1. Connect the Dots: I ask it to “extract the context and connect it to previous notes on this topic.” It reads the note and links it to the 3 previous related notes about that project. It builds the breadcrumbs for me.

2. The “Search Beacon”: I ask it to generate a Key Takeaways section at the top. This isn’t just for me to read; this summary becomes the high-quality source text for future semantic searches.

I give it a 30-second glance to make sure it didn’t hallucinate. Then I close the tab.

I spend 30 seconds reading instead of 30 minutes filing.

The “Nod”

Now, for my fellow data scientists and engineers reading this - I know what you’re thinking.

“You just described RAG.”

Yes. Exactly.

I just built a personal Retrieval-Augmented Generation pipeline for my life. My messy notes are the proprietary vector embeddings; my question is the prompt.

Instead of searching for keywords (which fails if I search for “budget” but wrote “cost reduction”), I search for concepts.

I ask my Second Brain:

“When is my next doctor appointment? Any specific questions I should last based on my lab results?”

The Notion AI performs a semantic search, retrieves the relevant chunks from five different messy documents, and synthesizes an answer: “Here’s the details for your next appointment. I’d suggest to get the panel blood work done 2 days prior to it, I set a reminder for you in the Home Notes along with the list of questions to ask.”

It finds the truth, even if the keywords don’t match. It gives the LLM “long-term memory” consisting of my own life.

The ROI of Laziness

My Sundays are mine again.

I watch the Lakers game (and yes, they look good in the Sunday whites). My notes stay messy. My “Inbox” is technically overflowing but archived, but my mind is clear.

We have to stop treating “organization” as a virtue. It’s a mechanic. And in the age of AI, it’s a mechanic that should be automated.

Be honest with yourself. When was the last time you actually went back into that perfectly organized ‘Resources’ folder you spent hours curating?

Never.

Because if it takes work to file it, it’s a chore. If it takes work to find it, it’s a graveyard.

I stopped trying to be a Librarian and started building the data assets that only matter to me. My note-taking changed from ‘Just-in-Case’ filing to ‘Just-in-Time’ retrieval.

So, here is my question to you:

How much of your “Second Brain” is actually just a digital graveyard?

(Next Friday, I’ll share how I use this same “lazy” mindset to automate my boring admin work using ‘trash code’ - without writing a single line of Python myself.)

#Leadership #Productivity #AI #Notion #SecondBrain #DataEngineering #FutureOfWork

If you live on the West Coast, you know the sight.

It’s 11:00 AM in Burbank near where the Studios are. The drive-thru line is already 15 cars deep, snaking around the building and spilling out into the street to block the right lane of traffic.

You walk inside. The air hits you - toasted buns, grilled onions, and the frantic energy of the lunch rush.

To the customer, it looks like a synchronized dance. The crisp white uniforms. The paper hats. The “Animal Style” shouts. It feels nostalgic. It feels simple.

But step behind the counter, and the illusion of simplicity vanishes.

This is not a retro diner; it is more of a biological battlefield, as my AI research friend tells me. The deep fryers drift in temperature. The potatoes change chemical composition by the hour. And the entire system relies on “servers” who are essentially teenagers thinking about prom.

The Store Manager stands at the “Final Window” and spots a Double-Double. The lettuce is crisp, the bun is toasted, but the cheese fold is off by a fraction of an inch. It is edible. It is warm. It is 95% perfect.

The Manager doesn’t fix it. They trash it. They stop the line.

In 2018, it was revealed that the average In-N-Out store manager earned $160,000+ - triple the industry average. Why?

Because in a chaotic system, the person who refuses to ship “mostly okay” is the only asset that matters. The market pays a massive premium for the only person in the building who cares more about consistency than throughput.

And the reality I’ve been thinking about lately: We are all In-N-Out managers now.

The Shift

Why does this resonate so deeply? Because for the last twenty years, we didn’t have to worry about the “cheese fold.” We built with “steel.”

Traditional software engineering is Applied Physics. It is deterministic. You write a function. It executes. It does not get tired. It does not “hallucinate.” We grew accustomed to being Architects - designing structures that stood still.

But Generative AI has forced us into the kitchen. We have traded our steel for “biology.”

An LLM isn’t a calculator, it feels more like a biological system. Like that 19-year-old line cook, it has “moods” (temperature). It gets “confused” (drift). It “lies” to save face (hallucination).

The mistake I see a lot of best leaders making right now is trying to manage this biological chaos using an architect’s blueprint. We are trying to code our way out of a problem that can only be operated.

The friction comes from a simple mismatch: we are acting like Architects, but the job now demands a Shift Manager. We need to trade the safety of the blueprint for the heat of the kitchen and learn the sweaty, unglamorous art of Operational Rigor.

Here are three learnings from In-N-Out managers that we can apply directly to our AI strategy.

1. The “No-Avocado” Rule

In-N-Out managers face constant pressure to add items. Customers beg for avocado. They want bacon. They want chicken. It would be profitable. Yet, the answer is always No.

Why? Because avocado oxidizes. It turns brown in minutes. By introducing one new ingredient, you introduce a variable that decays faster than the meat. You create a “weak link” in the supply chain that threatens the consistency of the entire system.

In the AI world, we are currently making the opposite mistake. We are obsessed with volume, not value. We launch 100 different “menu items” - a Legal Bot, a Marketing Agent, a Coding Assistant - hoping one of them tastes good.

The result isn’t business impact; it’s a menu of shiny AI powered apps no one uses. We create a bloated portfolio of tools that look impressive on a roadmap but deliver zero sustainable business impact. We are scaling complexity before we have established value.

Earn the Expansion. Think twice about impact before you expanding the portfolio. Focus on the “Cheeseburger” - that single, boring use case that solves a real business problem with 100% reliability. You don’t earn the right to add the second item until the first one is actually feeding the business.

2. The “Sugar” Test

The potato is a liar.

It looks consistent on the outside, but its chemistry changes with the weather. A potato that looks perfect might have high sugar content. If you fry it, it burns.

So, the Manager performs a “Fry Test” every morning. They don’t trust the supplier’s rating. They slice a batch, fry it, and see how it reacts in their oil, at their temperature. They verify the ingredient works for their specific standard before serving it.

We are drowning in options. We have proprietary models, open-source weights, and home-grown fine-tunes. We look at public leaderboards and benchmarks to decide which one to use.

But public leaderboards are like supplier ratings - they tell you how the potato performs on average, not how it performs in your kitchen. No one knows your use cases better than you. A model that aces a generic benchmark might completely fail on your proprietary data.

Run Your Own Fry Test. Build your own internal evaluation set based on your specific use cases. Pre-test every model - whether it’s GPT-5 or a local Llama - against your data. Does it burn? Is it consistent? You can’t pick the right “potato” for the job if you haven’t tasted it first.

3. The Expensive Trash Can

The Manager and the Cook are natural adversaries. The line Cook’s incentive is speed. The Manager’s incentive is perfection.

The most critical tool in the store is the Trash Can.

To an outsider, the trash can looks like failure. It looks like lost money. Why throw away a burger that is 95% perfect? But to the Manager, the trash can is an investment. The cost of the wasted ingredients is the “tuition” they pay to ensure the customer never sees a mistake.

Now when building with AI, we are allergic to the trash can. We treat “discarded compute” as inefficiency. We want every token we pay for to reach the user. This is wrong. In a probabilistic system, “waste” is the only way to guarantee quality. You might need to generate three draft emails to find the one that is safe to send.

Budget for the Trash Can. Forget zero shot a perfect app. Build systems that generate, critique, and discard in the background. If you aren’t paying for “wasted” tokens - if your trash can is empty - your quality standards are just a hallucination.

The Apron Over the Hoodie

We spend so much time looking for the “10x Engineer” or the “10x Researcher”—the geniuses who invent the recipes. But the In-N-Out story teaches us that the real value isn’t in the recipe. It’s in the discipline.

The next era of AI won’t be defined by who has the smartest model. It will be defined by who has the most disciplined kitchen.

So, here is my question to you:

Look at your current AI projects. Are you acting like a Chef trying to invent a new dish, or a Manager trying to stop a bad burger from leaving the window?

I’d love to hear your thoughts.

#Leadership #AI #OperationalExcellence #Management #InNOut #FutureOfWork #Strategy

I was flying back home from the holidays last week, and the energy in the cabin was frantic.

You know the vibe. Every overhead bin is stuffed to capacity. The flight attendants look exhausted. We had finally pushed back from the gate, and I was looking at the Flighty app for the potential early arrival to beat the crowd at the immigration line. I’ve flown million+ miles; I have the system down to a science.

Then, the plane stopped. The engines spooled down.

The Captain’s voice crackled over the intercom: “Folks, we’ve got a maintenance indication on the panel. We’re going to have to return to the gate to have a mechanic take a look”.

The collective groan was visceral.

My internal monologue kicked in immediately. Even with all my experience, I wasn’t thinking about safety. I was thinking about competence - you know - the CoE culture you have fostered and celebrated.

“Why now?”

“The plane sat at the gate for an hour. Why didn’t they catch this during the turn?”

“This is a failure of planning.”

I looked across the aisle. Sitting across was an off-duty pilot, deadheading back to his home base. He didn’t look annoyed. He didn’t check his watch. He just closed his eyes and leaned back.

“Doesn’t this drive you crazy?” I asked him, motioning to the jetway connecting back to the plane. “We were ten feet from freedom.”

He opened one eye and smiled.

“Not really,” he said. “A delay at the gate is inconvenient. A problem in the air is tragic. If we’re turning back, it means the system is working. It means someone - probably a junior mechanic or a first officer - saw something and wasn’t afraid to stop the show.”

He paused, then added ...

“I’d rather be on the ground wishing I was in the air, than in the air wishing I was on the ground.”

That conversation shifted my entire perspective.

Now, I, for one, look at a gate delay and see a broken process. But if you look closer, you realize that a gate delay is not a failure of planning. It is a spectacular success of culture.

It is a $100M+ machine stopped by a $20 decision - proof that the culture values Stop Work Authority more than the schedule.

The Last Minute Pivot

Most leaders view “last-minute” issues as a symptom of fragility. We ask, “Why didn’t we catch this upstream?”

But in complex, high-stakes environments - whether it’s launching a rocket, deploying code, or flying a jet - the “last minute” isn’t an arbitrary point where luck runs out. It is a functional boundary.

In aviation, the aircraft sits dormant at the gate until the final moments before pushback. It’s only then that the systems are fully energized, pressurized, and handed over to the human operators. That transition creates stress.

The contrarian view is this: “Last minute” catches are the only proof that your safety mechanisms are actually working.

If your team never pulls the emergency brake right before a launch, you don’t have efficiency. You have a ticking bomb.

The Red Wine Save

That conversation sparked an obsession. I wanted to see if this “culture of stopping” was just a nice theory or if it actually played out in the messy reality of the tarmac. So, I did my homework. I started digging through pilot forums and incident reports to see what “pulling the cord” actually looks like.

That is where I found this thread on r/aviation, where a pilot shared a story that perfectly illustrates the cost - and value - of vigilance.

He was performing a pre-flight walkaround in sub-zero temperatures (-20°F). He’s tired, he wants to go home, and the pressure to leave on time is immense. But he notices a long, thick stripe of frozen red liquid across the bottom of the fuselage.

In aviation, red fluid usually means one thing: Skydrol. Hydraulic fluid. The lifeblood of the flight control system.

“Well, [shoot], this looks like the mother of all hydraulic leaks,” he thought.

He makes the call. He delays the flight. Mechanics swarm the plane. They tear off panels, bleed lines, and refill reservoirs to troubleshoot the leak. The passengers are furious. The delay clocks in at over two hours.

The verdict?

It wasn’t hydraulic fluid. It was Merlot.

A flight attendant on the previous leg had poured a leftover bottle of red wine down a galley sink, which discharged overboard via a drain mast. The extreme cold had frozen it to the fuselage instantly.

Now, would it play out this way everywhere? This pilot would be reprimanded. “You delayed a flight for wine? You cost us thousands of dollars for nothing?”

But in a High Reliability Organization (HRO), this was a “Good Catch.”

The delay was the price of verification. The pilot was embodying what organizational theorists Karl Weick and Kathleen Sutcliffe call a “Preoccupation with Failure.” In their HRO framework, this principle demands that you treat any weak signal as a symptom of a catastrophic problem until proven otherwise.

The pilot prioritized investigating the anomaly over guessing the outcome. He didn’t assume the best-case scenario (it’s just a spill); he respected the system enough to assume the worst-case scenario.

He stopped the line because he didn’t know the answer.

And he can.

The Toyota Andon Cord

This brings us back to the most famous concept in manufacturing history. You likely know the story. It’s the Andon Cord.

In the Toyota Production System, the Andon Cord is a physical rope that hangs above the assembly line. If any worker - from the newest hire to the senior manager - sees a defect, they pull the cord.

The entire line stops.

It is expensive. It is disruptive. It is annoying.

But Toyota realized that fixing a defect on the line costs $1. Fixing it after the car is sold costs $1,000 (and your reputation).

In aviation, the “cord” is the logbook entry. When a pilot or mechanic writes up a fault at the gate, they are pulling the cord. They are stopping the massive machinery of the airline schedule because they see something that doesn’t look right.

The “Gate Return” is simply the Andon Cord in action.

For the fellow engineers reading this, you know this concept by a different name: “Shifting Left“. In engineering, we obsess over moving testing earlier in the development lifecycle because fixing a bug in production is 100x more expensive than fixing it in code review. A gate return is the ultimate physical manifestation of Shifting Left. It is the discipline to catch the failure while you are still on the ground (development), rather than dealing with it at 30,000 feet (production).

Leadership Takeaway

Here is the uncomfortable reality I see in many teams. We claim to want “Agile” and “Quality,” but we punish the people who pull the cord.

We create cultures where raising a “last-minute” issue is seen as being “not a team player.” So, people stay silent. They ship the code with the bug. They sign the contract with the bad terms. They launch the product with the flaw.

They normalize the deviance because they are afraid of the delay.

But if you can’t stop the line, you don’t have a process. You just have momentum.

The Andon Cord is the difference between driving the machine and just holding onto the wheel.

Do your teams have the authority - and the psychological safety that Amy Edmondson champions - to halt a product launch or a deal closing 10 minutes before the deadline if they see red fluid on the fuselage?

If they don’t, you aren’t “agile” - you’re just fragile. You are flying on luck, not on process.

So, here is the question:

Who on your team has the power to pull the Andon Cord? And when was the last time you thanked them for doing it?

I’d love to hear your thoughts.

#Leadership #AviationSafety #HighReliabilityOrganizations #Culture #StopWorkAuthority #Management #AndonCord #Resilience

Imagine I offer you a deal right now.

• Option A: I hand you a suitcase with $10,000 cash. It covers your mortgage for a few months. It’s safe. No strings attached.

• Option B: We flip a coin. Heads, you win $100,000. That’s a down payment. That’s seed capital. Tails, you get nothing.

Which one do you take?

If you calculate the “Expected Value“ Option B is worth $50,000. It is mathematically 5x better than Option A.

But if you are “managing risk” in the traditional corporate sense, you take the suitcase (Option A). It’s safe. It’s certain. You won’t look foolish for going home with zero.

But the best leaders I know? The ones actually moving the needle?

They take the flip. And if it lands on Tails... they just find another coin.

They do this because they understand the single most important truth about high-stakes decision-making: You are not playing Chess. You are playing Poker.

The reason so many brilliant leaders are currently frozen in analysis paralysis is that they are trying to play Chess on a Poker table.

The Certainty Trap - The Decay Rate of Information

In Chess, you have perfect information. You can see every piece on the board. There is a theoretically “correct” move for every configuration. If you stare at the board long enough, you can solve it.

In Business (and Poker), you have imperfect information. You can’t see the market’s hand. You can’t see the competitor’s hidden cards. You don’t know if the regulator is bluffing.

The anxiety you feel - that knot in your stomach when you look at your Q4 roadmap - isn’t because you aren’t smart enough. It’s because you are waiting for the fog to clear. You are waiting for 100% certainty.

But here is the uncomfortable reality I tell my teams: If you wait for 100% of the information, you are no longer making a decision. You are making a calculation.

And there is a hidden tax to this calculation: The Decay Rate of Information.

Every day you wait for perfect data, the data you do have becomes 1% less true. The competitor launches. The candidate takes another offer. The customer sentiment shifts.

By the time you finally feel “safe,” you arrive at a decision that is factually correct for a reality that no longer exists.

A imperfect decision made with speed often beats a perfect decision made with latency.

Bet Sizing - The Amazon Door Strategy

So, if we accept that we can’t wait for perfect info, how do we bet without going broke?

We need a system for Bet Sizing.

This is where Jeff Bezos’s “One-Way vs. Two-Way Door“ concept stops being a cliché and starts being a risk management tool.

Most leaders suffer from paralysis because they treat every decision like an “All-In” moment. They treat a $5,000 marketing experiment with the same gravity as a $50M acquisition. They fold winning hands because they are scared to bet blind.

To fix this, you have to label your bets properly:

• The Two-Way Door - These are your low-stakes, reversible bets. If you walk through and don’t like the room, you simply turn around and walk out. The strategy here isn’t perfection; it’s speed. The value of the bet isn’t just the outcome, but the information you gain from the flop. Launching a feature flag to 5% of users isn’t a marriage; it’s a date. If it goes bad, you pay the check and leave. In this zone, the “Undo” button is your single best risk management tool.

• The One-Way Door - These are the irreversible decisions where you can’t go back without paying a massive tuition. Selling the company, firing a co-founder, or migrating your entire data stack to a new cloud provider - these are the moments that require deep diligence. Here, you slow down. You gather more information. You deliberate. This is where you actually spend your precious “governance tokens” ensuring you have the conviction to push all your chips into the middle of the table.

The mistake isn’t making the wrong bet. The mistake is treating a Two-Way Door like a One-Way Door. Speed is a quality of the decision.

Playing for Position Not a Single Hand

Now, let’s look one step further. This is where the amateurs get separated from the pros.

Amateur players play the cards in their hand. Pro players play for Position.

In leadership, we tend to look at decisions in silos. “Is this a good deal?” “Is this a good job offer?” “Is this a profitable client?”

But real strategic leverage comes from Second-Order Thinking. You have to ask: “Does this decision buy me the asset I need for the next move?”

An agency leader take on a client that was a nightmare on paper. The margins were razor-thin. The demands were high. The P&L looked terrible. A novice leader would have folded instantly to “protect the bottom line.”

But this leader wasn’t playing the P&L of that specific deal. He was playing for position. He knew that having that specific logo on the website validated the agency for the Enterprise tier. He was willing to “lose” $50k on the hand to buy a seat at the table where $1M deals were happening. And he was right - that case study generated $2M in new pipeline within six months.

Now - here’s another example. This logic also applies perfectly to your own career trajectory. I often see leaders agonizing over the choice between “Golden Handcuffs” - a safe, high-paying role at a tech giant - and a chaotic, lower-paying role at a high-growth startup.

Let’s be honest: walking away from RSU grants feels like setting money on fire.

To the siloed thinker, the startup looks like a bad bet. “Why take a 30% pay cut to work harder with less stability? That’s folding a winning hand.”

But the strategic thinker isn’t looking at the salary; they are looking at the Asset Accumulation. They realize that the “safe” job is actually a plateau. They choose the messy startup role because it is the only place they can buy the specific asset they are missing: the ability to build from zero to one.

They are consciously trading short-term liquidity for long-term Career Capital. They know that the “loss” they take on their paycheck today is the tuition they pay to become a Founder or CTO three years from now. They aren’t folding; they are buying in.

Does this bet give you the chips you need to sit at the high-stakes table next year?

The Poker Mindset vs Resulting

I’ll leave you with this concept from Annie Duke‘s Resulting. It is the dangerous tendency to judge the quality of a decision solely by its outcome.

In poker, you can play a hand perfectly - calculate the odds, read the table, make the right bet - and still lose to a lucky river card. That doesn’t mean you made a mistake. It just means the 10% chance event happened.

If you judge your leadership solely on outcomes, you will drive yourself insane. You will become risk-averse. You will pick Option A every single time because you are terrified of the 50% chance of zero.

But if you judge your leadership on the quality of your process - on your ability to distinguish a One-Way Door from a Two-Way Door, and your ability to play for the next hand - you build something resilient.

The goal isn’t to be right every time. The goal is to keep playing until the odds tip in your favor.

So, here is my question to you:

Look at the biggest decision stalling your team right now. Are you waiting for 100% certainty on a Two-Way Door?

Stop waiting for the chessboard to clear. The coin is in the air. Call it.

I’d love to hear your thoughts.

#Leadership #DecisionMaking #Strategy #Management #CareerGrowth #RiskManagement #PokerVsChess