⚙️ Hi {{first_name_tally|Operator}},

The first Bottleneck Talent Network meet and greet was yesterday and I am happy to announce we will be doing another in April (Date TBD)! We laughed, got to exchange tips and tricks, and met fellow Bottleneck readers from around the world (literally).

This poll was inspired by one of our deepest discussions:

-Michael

^{_{PRESENTED BY 3RD BRAIN}}
3rdbrain.co

3rdBrain embeds vetted experts in tools like Clay, ClickUp, Notion, Airtable, Claude Code, N8N, Make, Zapier, and more directly into operator-led teams on hourly or monthly contracts. Operations, automation, and AI experts who build until the wins compound. All ravenous self learners.

Disclosure: 3rdBrain is a company I founded. This weeks link goes skips the sales team and goes straight to my calendar.

Stop Managing People. Start Managing Tasks.

⚙️ Hi {{first_name_tally|Operator}},

The first Bottleneck Talent Network meet and greet is at 2pm CT, (3PM ET, Noon PT) next week on Thursday, March 4th.

Sign Up Here

I’m so excited to meet and give you sneak peak some of our upcoming projects as well!

-Michael

^{_{PRESENTED BY GLIDE}}
Start with a spreadsheet at Glide

There's software hiding in your spreadsheet. You just can’t see it yet.

While you’ve been building complex Excel files, rich with formulas, formatting, charts, and data, you’ve also been unintentionally building a map of your operations.

This is your sign to turn your spreadsheets into software.

How (Not) to Scale

The Bottleneck Talent Network

⚙️ Hi {{first_name_tally|Operator}},

The first Bottleneck Talent Network meet and greet at 2pm CT, (3PM ET, Noon PT) on Thursday, March 4th.

Sign Up Here

Can’t wait to meet you!

-Michael

^{_{PRESENTED BY 3RD BRAIN}}
3rdbrain.co

3rdBrain embeds AI and automation engineers directly into operator-led teams. No consulting decks, just ravenous autodidacts who build until the wins compound.

Disclosure: 3rdBrain is a company I founded. The case studies in today's essay come from my client work when I was leading the team. I'm writing about them because I was in the room for all of them.

When every fix creates two new problems (until it doesn't)

The Bottleneck Talent Network

⚙️ Hi {{first_name_tally|Operator}},

Last week we asked if you wanted to meet each other and the response was a clear YES!

So I’m happy to announce the first Bottleneck Talent Network meet and greet at 2pm CT, (3PM ET, Noon PT) on Thursday, March 4th.

Sign Up Here

I’m excited to meet you all!

-Michael (Filling in for Rameel while he’s on paternity leave)

^{_{PRESENTED BY THESYS.DEV}}
Build chatbots that respond with interactive UI.

Help website visitors explore your site, ask questions, get support, and take actions. With Thesys Agent Builder you can build website chatbots that reply with interactive UI like cards, forms, charts, and more.

Get started in seconds:

1. Connect your data source, upload files, or enter website URL

2. Add instructions and customize style

3. Publish your agent and paste the embed snippet into your website

Your copilot goes live instantly. Build sales copilots, ecommerce agents, support bots, onboarding assistants, and more.

Trading Growth for Efficiency

The Bottleneck Talent Network

⚙️ Hi {{first_name_tally|Operator}},

Do you all know each other? I’m guessing no.

Michael, our resident chef turned partnerships guy, is heading up The Bottleneck Talent Network and pitched this to me last week.

What do you think?

^{_{PRESENTED BY DIGITAL OPERATIONS INSTITUTE}}
FREE OpenClaw Setup (ClawdBot/MoltBot)

This week, we’ve partnered with Digital Operations Institute to give you free setup sessions for plugging MoltWorker (the Cloudflare version of the AI Agent formerly know as ClawdBot/MoltBot).

Just book a call with Michael to coordinate and he’ll get introduce you to one of their vetted AI engineers for a free training and setup session the following week.

Your Best AI Engineer Probably Couldn't Code Last Year

The Bottleneck Talent Network

⚙️ Hi {{first_name_tally|Operator}},

Your relationships have an expiration date. I didn’t understand this until I got let go for the first (and luckily only) time:

Your internal network is rented. Your external network is owned.

Let me explain.

Your internal network, your manager, your peers, your skip-level, the execs who know your name, you built all of those relationships on company time, on company property, for company purposes.

You didn't do anything wrong. That's what work is. You build relationships to get things done.

But here's the thing: you don't own those relationships. You're renting them.

When you leave (whether you choose to or not) most of those relationships fade. Within 6-12 months, the people you talked to every day become people you talked to at your last job.

Your external network is different.

Relationships built outside the company context. People who know you independent of your role. Operators at other companies. People who've seen your work from a distance. Connections that exist because you built them through mutual interest, not because an org chart put you in the same Slack channel.

Those relationships travel with you.

Brandon White, one of our first contributors and a serial entrepreneur across industries, is part of my external network (I wouldn’t be writing you today without him). He’s raised millions, exited twice, and worked in executive positions across technology, government, media, and Fortune 500.

I don’t think anyone has taught me more about people, relationship management, and career building.

- Michael (Stepping in for Rameel today)

^{_{PRESENTED BY DIGITAL OPERATIONS INSTITUTE}}
Where Operations Meets Technology.

Finding people who can implement them is the #1 bottleneck in AI implementations.

That's why Digital Operations Institute launched the first certified network for AI implementation and digital operations providers.

No consultants pitching transformation decks. No agencies learning on your budget. Just advice based on real world case studies and introductions to vetted experts certified, vetted, and matched to your actual problem.

Every certified partner has multiple case studies verified by the DOI team.

After 100s of audits and AI roadmaps, Digital Operations Institute is ready to go whether you need implementation partners, full time talent in-house, or a second opinion on your quarterly plan.

Interviews Don’t Reveal The Truth

The Bottleneck Talent Network

⚙️ Hi {{first_name_tally|Operator}},

Let's say you get laid off tomorrow.

I don't mean "let's imagine a hypothetical." I mean actually picture it. The calendar invite from HR, the awkward Zoom, the "we've made the difficult decision" script.

By the end of day, your Slack is gone. Your email forwards to nowhere. Your calendar, the one with 30 hours of meetings per week, is empty.

Company relationships have an expiration date printed right on them: your last day.

Now here's the question:

Who do you call?

Not to vent. To actually figure out what's next. Who do you call?

If you're like most operators, your answer is... thin. Maybe an old boss. Maybe a founder you worked with three jobs ago. Maybe a recruiter who cold-emailed you last year.

That's the layoff test. And most operators fail it.

Not because they're bad at relationships. The opposite. Operators are great at building relationships…they just build all of them inside the company.

We’re building something new to make sure that doesn’t happen to you, and bringing back the talent network this week.

- Rameel

^{_{PRESENTED BY DIGITAL OPERATIONS INSTITUTE}}
Where Operations Meets Technology.

Finding people who can implement them is the #1 bottleneck in AI implementations.

That's why Digital Operations Institute launched the first certified network for AI implementation and digital operations providers.

No consultants pitching transformation decks. No agencies learning on your budget. Just advice based on real world case studies and introductions to vetted experts certified, vetted, and matched to your actual problem.

Every certified partner has multiple case studies verified by the DOI team.

After 100s of audits and AI roadmaps, Digital Operations Institute is ready to go whether you need implementation partners, full time talent in-house, or a second opinion on your quarterly plan.

The 1-1-1 Rule

Jobs, jobs, and more jobs

⚙️ Hi {{first_name_tally|Operator}},

I want you to try something.

Grab a piece of paper. Draw a line down the middle.

On the left side, write down every person at your company who has real influence over your career. Your manager. Your skip-level. The cross-functional leads you depend on. Anyone who could promote you, fire you, or make your life miserable.

On the right side, write down every person outside your company who would take a call from you this week. Not LinkedIn connections. Not college friends who don't know what you do. People who actually know your work and would pick up the phone.

Most operators finish this exercise with 20-40 names on the left.

And 3-5 on the right.

That ratio should scare you.

Because one side of that list disappears the moment you leave your company. The other side travels with you forever.

Michael, our new partnerships manager (and a chef turned COO) and this weeks essay contributor, is one of those on the right for me.

- Rameel  

^{_{PRESENTED BY DIGITAL OPERATIONS INSTITUTE}}
Where Operations Meets Technology.

Finding people who can implement them is the #1 bottleneck in AI implementations.

That's why Digital Operations Institute launched the first certified network for AI implementation and digital operations providers.

No consultants pitching transformation decks. No agencies learning on your budget. Just advice based on real world case studies and introductions to vetted experts certified, vetted, and matched to your actual problem.

Every certified partner has multiple case studies verified by the DOI team.

After 100s of audits and AI roadmaps, Digital Operations Institute is ready to go whether you need implementation partners, full time talent in-house, or a second opinion on your quarterly plan.

Mise En Place Is All You Need

Caramel is a one shot cook.

It’s a precise science: sugar at the right heat, cream ready, butter within reach, everything pre-measured and staged. Too slow or cold and the sugar crystallizes. Pour the cream too fast and you'll end up wearing it. Add a little water at the wrong moment and hot sugar starts spitting like napalm.

The hairless patch on my forearm is from learning this lesson.

Chef didn't yell when he saw me clutching my arm. The cream still in the walk-in, the thermometer buried under towels, the salt nowhere. All he said was:

Mise en place means "everything in place." It's the first thing they teach you in cooking school and the last thing most people internalize. Because it feels like the work before the work. The boring part you rush through to get to the real thing.

Here's the paradox: mise en place isn't prep. It is the work. The cooking is just the performance.

This week, Anthropic drove the lesson home by launching Claude Cowork AKA "Claude Code for non-code work." You give Claude access to a folder on your computer, and it can read, edit, and create files inside it.

The model isn't the bottleneck anymore. Your folder structure is. 

Now, mise en place defines the slope of your AI adoption curve.

If your knowledge base is a swamp of "Untitled doc (3)" and stale SOPs from two reorgs ago, the agent becomes confidently wrong. The forever game for AI isn't a chat window. It's your documentation showing the way, the requirements, and the process from the work you are doing.

Every wrapper you build today has a half-life. Internal tool, prompt, or automation doesn’t matter. They will all be replaced in time.

Models improve. APIs change. Someone ships a better tool. But the prep work compounds: how things flow, who owns what, where taste gets applied, what good data looks like. Those survive platform churn. 

The foundation organization often doesn’t get done because there is always a sexier win. Who wants to spend days sorting folders and documenting decision rights? 

That's intern work (5 years ago). 

If you want to scale smoothly, then you need to organize the system yourself because mise en place requires taste along with understanding the final dish. And those cannot be delegated.

Building Bridges and Writing Recipes

If your tools can't talk to each other and nobody owns the question of whether they should, then you are stuck before you start.

Maybe it’s a "We can export a CSV" (but only if Bob is online). Or maybe it’s a 20 year old SAP implementation. Most teams hit their AI ceiling before they write a single prompt because they do not have integratable tools. 

Legacy manufacturing has it worst, stuck with ERPs or custom builds from a decade ago.

It takes about 1 month for each year of legacy data. A company with 30 years of history? Plan on a year or two to reach real data clarity. I’ve seen it play out in venture backed startups and decades old holding companies the same.

As the information compounds over time, it also duplicates and obfuscates. 

Data Rules Everything Around Me

Most companies get stuck because they grew without understanding their own mise en place. Scattered databases. No cleaning processes or hygiene checks. Multiple "sources of truth" that contradict each other. 

Data ownership means choosing one source of truth per thing (Process, department, object type. Take your pick and don’t duplicate data). You have to enforce it too, so no letting sales keep using their spreadsheets instead of the CRM. 

It means building hygiene into the pipeline because cleaning can't be a quarterly project; it needs to happen at input and be checked at each transfer.

Take an hour with your coffee tomorrow and organize your Google Drive. Truly, it will pay off in spades next time you use deep research. Put every major project in its own folder with consistent naming. 

That's the difference between "Claude, research Project X" returning garbage and returning gold.

Why This Is Your Job

The kitchen taught me what most consultants miss: mise en place isn't just "everything in its place." It's everything in its place at the time you'll need it.

With caramel the cream is closer than the butter because it goes in first. The thermometer is visible because you check it constantly. The staging is sequenced to the critical path.

That's why this is an operator's job. Not IT's job. Not a CEOs job. Yours.

You're the only one who sees the whole kitchen. You know what fires first, what can wait, what dependencies exist between departments, what data has to be clean before the downstream process works. 

The critical path lives in your head.

Tools get replaced. Models get replaced. Wrappers get deprecated. But the mise en place of your operations - your process architecture - that doesn’t change. 

That’s your forever layer.

⚙️ Hi {{first_name_tally|Operator}},

My Amazon account just got flagged for adding 97 new shipping addresses shipping out your thank you books for completing our annual survey.

Almost 80% are using ChatGPT at work, but the most popular automation tool (Zapier) was only at 14% usage.

AI means operators are in higher demand than ever. But they have to be able to build a system beyond themselves. That can be with people or machines, so long as it produces results.

^{_{PRESENTED BY CIRCLEBACK AI}}
I Stopped Taking Notes. My Business Got Better.

I run 3 businesses, including The Bottleneck. That means 6-8 meetings a day—some on Zoom, some in person.

I used to spend half my time writing up what just happened instead of doing the actual work.

Now I don't take notes at all.

Circleback records everything. On Zoom, the overlay sits quietly in the corner—no awkward "AI bot has joined" notification. Meeting ends, notes hit my inbox with action items already assigned.

But here's what sold me: the in-person stuff. I pull out my phone, hit record, and forget about it. Twenty minutes later I have a full transcript and know exactly what was discussed.

Most AI note-takers only work on video calls. This one works where I actually work.

Barrels Don't Hire Anymore. They Build. 

Every scaling company hits the same wall. Not enough people who can drive projects end-to-end. Too much work. And the only answer anyone offers is "hire more."

Keith Rabois called this the barrels-and-ammunition problem. Barrels are the people who can take an idea from concept to launch while bringing others along. They're your constraint. Everyone else is ammunition: talented executors who need someone to aim them.

For twenty years, the playbook wrote itself. Find barrels. Hire ammunition. Ship more. If you wanted to scale outbound, you hired SDRs. If you wanted more features shipped, you hired engineers. Headcount was the answer.

Then I met someone who broke the model.

Andrew went dark on a Tuesday. 14 hour work days, a breakup that went sideways, and a health scare meant he needed a few months reset. When your best sales guy vanishes, deals die, meetings cancel, and your funnel leaks until you backfill. That's usually the kind of disappearance that's supposed to crater your pipeline.

Except ours didn't.

Heyreach sequences kept firing. LinkedIn automation ran on autopilot. Meetings booked themselves, two or three a week, because Andrew had built the system before he left. Lead list loaded, responses mapped, my assistant just pressed send.

We rented his account and let the machine hum. Copied it to two more accounts. Same playbook, three times the output, zero new headcount.

Andrew figured out something most operators never do: the new barrel doesn't hire ammunition. They manufacture it.

Two Skills, Rarely One Person

The person who's great at managing ten people is rarely the person who can build the system that replaces them. Managing humans is one skill. Designing workflows is another.

Andrew never managed anyone. He was an IC through and through. But he could look at his own work and ask one question: what here is actually hard? The parts that just looked hard because nobody had mapped them, he turned into systems.

Not someone who scales through people. Someone who scales through process.

The Flowchart Test

Before Andrew automated anything, he mapped everything.

Every script became a flowchart. Every objection became a branch. Every follow-up sequence became a diagram with clear inputs and outputs. He was writing the spec for his own replacement.

The test is simple: can you document it with flowcharts and checklists alone?

If the work follows a predictable path, you can map it on a whiteboard. Inputs, decision points, outputs. If you can do that, you don't need a person. You might not even need AI.

LinkedIn outreach, chat responses, follow-up cadences. All flowchartable.

Most roles bundle the flowchartable 80% with the judgment-required 20%. Companies hire full humans to do work that's mostly deterministic. Andrew's system books 8-12 qualified meetings per month. An SDR doing that volume costs $65K loaded. His automation runs on $200/month in Heyreach and Clay.

That's not efficiency. That's a different category of leverage.

SDRs may be cooked

The Automation Spectrum

Not everything needs AI. Most things don't.

Most work sits on a spectrum. At the bottom: deterministic systems. Cron jobs, spreadsheet formulas, if/else scripts. They run at 3 AM exactly the same way they run at 3 PM. No moods. No context drift. No hallucinations. Boring and bulletproof.

One level up: workflow automation. Zapier, Make, n8n. Still deterministic, still reliable, but handles complexity across systems. Andrew's Heyreach sequences sit here. Multi-step flows with branches, but no judgment required.

Then: AI with guardrails. LLMs with human review. Structured outputs. Human starts it, AI handles the middle, human approves the end. You're paying for the AI's pattern-matching, but you're not trusting it blindly.

At the top: humans. Expensive. Flexible. Required for novel situations, relationship building, taste, direction, strategy. The stuff that can't be flowcharted.

Salesforce learned this the hard way. They spent millions building Agentforce, AI agents handling enterprise workflows end-to-end. The agents kept losing context, drifting from goals, forgetting what they were supposed to do. Their fix? They built an "Agent Graph" system that added deterministic logic back into the workflow. Flowcharts and checklists. The same if/else structure a Zapier flow would've provided from day one. They spent millions rediscovering why McDonald's uses a timer for fryers.

Reach for scripts before AI. AI before humans. The simplest tool that works is usually the right one.

I See This Everywhere Now

I have a great EA. But expecting her to manually track recurring tasks across five different systems is asking her to do deterministic work badly. She was worried about being automated away when I first asked her to flowchart how she handles emails. I asked for trust. We carried on.

The first week we automated the predictable 70%, shuffling tasks and emails between tools, I could hear the stress melt from her voice. She stopped drowning in administration and started catching problems before they grew. That's not automation replacing her. That's automation promoting her.

I've watched companies hire ammunition when what they needed was someone to flowchart the existing work. Good operators quit because they were used as ammunition when they should have been barrels.

Watch what your team asks for when they hit capacity.

The old barrel says "I need another person." Stable, but slower. Fine for leading leaders. Not fine for scaling output.

The new barrel says "let me map this out and see what's actually hard." That's the difference. Find ten more of them.

The Territory Now

Andrew's flowcharts became the spec. His departure was the stress test. The system passed.

The barrels-and-ammunition framework got the constraint right. Organizations ship at the speed of their barrels. That hasn't changed.

What changed is how barrels create leverage. It's not just hiring anymore. It's flowcharts that execute, scripts that run, workflows that fire at 3 AM while everyone's asleep.

The companies eating your lunch aren't outworking you. They're not out-hiring you. They're not even out-AI-ing you.

They're running the same playbook with one-third the headcount because their barrels know the difference between a problem that needs a person, a problem that needs a prompt, and a problem that needs a for-loop.

Rabois was right about the constraint. But the barrels that win in 2025 aren't the ones who rally teams around problems. They're the ones who look at their own job and ask: which parts of this should outlive me?

⚙️ Hi {{first_name_tally|Operator}},

I was spending 90 minutes a day triaging email. That's a part-time job I didn't apply for.

So I built Dossier. It auto-categorizes everything and sends me two daily briefs with just the stuff that matters.

We're onboarding now. Schedule here.

While you schedule that timeslot…

Goals are voltage. Praise is amperage. Most managers blow the circuit by Tuesday.

Every training program that evaporates, every task that boomerangs back, every best employee who quits—that's a circuit that couldn't carry the load. You kept cranking voltage without adding capacity.

Here's how to fix it.

- Rameel  

P.S. Here's part 1 and part 2 if you missed it.

^{_{PRESENTED BY BELAY}}
What Would You Choose if Your Time Were Actually Yours?

You know the moment: the inbox wins. The day slips. You feel smaller than the leader you know you are.

Great leaders hand that weight to U.S.-based executive assistants who think at their level so they can move freely while the business scales.

Here's our guide to help you feel like yourself again.

How to Actually Rebuild Confidence Infrastructure

I've been thinking about why confidence infrastructure is so hard to fix. Most companies treat this like sentiment—"let's do a pulse check on morale"—when really it's electrical engineering.

You're managing voltage (goals, pressure, demands) and amperage (capacity to handle that pressure without blowing the circuit). Every time someone routes a decision back to you "just to check," every time a training program evaporates 90 days later, every time your best PM quits, that's a circuit that couldn't carry the load.

My PM homies out there getting burned everyday

Here's what's worked for me (and what definitely hasn't).

1. Install Circuit Breakers People Actually Believe In

The Andon cord wasn't genius because Toyota installed a rope. It was genius because they made the policy so clear and so consistently enforced that workers believed pulling it wouldn't wreck their career.

The first person who uses your "circuit breaker" is basically running a test. Everyone else is watching to see what happens.

The one metric I've found that actually matters here is time-to-surface. The gap between when someone first knew about a problem and when they told someone who could fix it. If problems only surface in postmortems, your infrastructure is already failing.

I learned this through an expensive mistake. I was at a startup where I tried to install a "no stupid questions" policy in our weekly ops review. First person who used it, a junior PM, asked why we were prioritizing Feature X over Feature Y, got a five-minute explanation from the VP about "strategic alignment" that was basically a polite way of saying "because I said so."

That PM never asked another question in that meeting. Neither did anyone else. Policy died in 48 hours.

When I tried this again at my next company, same question came up. This time I said "You know what, that's a great question and I don't actually have a good answer. Let's park this for 10 minutes after the meeting and figure it out." We did. Turned out she was right, we were building the wrong thing.

I made a point of saying this out loud in the next meeting: "Jenny caught a $40K mistake by asking why. That's exactly the kind of question I want more of."

The thing I keep coming back to is when signals decrease, treat it as an emergency.

Fewer problems being raised doesn't mean things are going better. It usually means people stopped believing it's safe to raise them.

2. Separate Feedback from Consequences (This Is Harder Than It Sounds)

Managers can't separate "what we learned about our systems" from "what I think about this person's competence." I do this. You probably do this. It's instinct.

The discipline is catching yourself and asking: "Am I learning about a broken process or am I deciding this person isn't good at their job?"

Make it explicit policy that postmortem discussions can't be referenced in performance reviews. Ever. Write it down. Enforce it.

The first time a manager says in a performance review "Well, there were those three incidents..." you've killed the program. Word spreads fast.

If people can't admit confusion, they'll pretend to understand and execute badly based on their misunderstanding.

I watched a team spend six weeks building the wrong feature because nobody wanted to admit they didn't understand what "seamless integration" meant in the spec. Cost the company $120K in wasted engineering time. Could have been prevented by one person saying "Wait, what does this actually mean?" in the kickoff meeting.

They'd learned that admitting confusion made you look stupid, so they guessed. And guessed wrong.

3. Treat Praise Like Amperage, Not Sentiment

This is the metaphor that finally made sense to me: Goals are voltage. They create pressure. Praise is amperage; it provides capacity to handle that pressure.

Keep cranking voltage without increasing amperage and you blow the circuit.

Most managers do this without realizing it. I definitely did. Stack three new projects on someone, give zero recognition for the two they just shipped, then act surprised when they burn out or start routing every decision back for approval.

A previous manager told me about this 2:1 rule: two praises for every goal assigned. Not because 2:1 is some magic ratio (it's not), but because goals create cognitive load and praise builds capacity to handle it. The ratio just ensures you're not stacking demands on infrastructure that's already overloaded.

But here's the thing that took me forever to figure out: Generic praise reads as manipulation.

Bad: "Great job on that project!"

Good: "The way you restructured that stakeholder update saved us three hours of rework by catching the missing dependency before it became a blocker. That kind of proactive communication is exactly what we need more of."

Specific praise reinforces what to do more of. Generic praise just makes people wonder what you're trying to get them to do.

I track this now like infrastructure: If I'm assigning goals weekly but only praising monthly, my amperage is too low for the voltage I'm running. The circuit's going to blow—either through burnout, boomeranged decisions, or that quiet quitting thing where people show up but stop trying.

I learned this from a mistake I made at Uber Freight. Had a program manager who was absolutely crushing it—shipping features ahead of schedule, catching integration issues early, unblocking other teams. I gave her three new projects in one month. Zero recognition for the previous work. Just "thanks, here's more."

She quit six weeks later for a lateral move at another company. Exit interview: "I felt like a machine. Every time I finished something, you just loaded more in without acknowledging what I'd done."

Cost us three months to replace her and another two months to get the replacement up to speed. All because I didn't understand I was running 120 volts through a 90-volt circuit.

4. Make Delegation Explicitly Iterative (Not Binary)

Most delegation gets framed as all-or-nothing: Either you own this completely or you don't own it at all. Which creates a terrifying amount of pressure if you've never done the thing before.

What's worked better for me: graduated autonomy with explicit checkpoints. Basically acknowledging that confidence builds through reps, not through a single declaration of "I trust you."

Level 1: I'm checking for landmines

"You own this. Run your plan by me before executing so I can flag anything you might not see yet."

You're doing the work. I'm just trying to prevent catastrophic mistakes. This is the training wheels phase.

Level 2: I'm standing by

"You've run this process three times now. This time, execute without checking in first. If something breaks, we'll fix it together."

You're doing the work. I'm watching from a distance. Training wheels are off but I'm still running alongside the bike.

Level 3: You're autonomous

"Make the call. I'll only step in if you ask."

You're doing the work. I'm not even watching anymore.

I used to skip straight to Level 3 because I'd read something about "radical delegation" and wanted to be seen as trusting. Then I'd be shocked when tasks boomeranged back.

What I realize now: Going straight to Level 3 isn't trusting more. It's asking someone to climb two ladders at once—learning the skill while also carrying the full weight of autonomous decision-making—and then wondering why they freeze.

The one metric I watch here: delegation success rate. What percentage of tasks I delegate actually complete without boomeranging back or escalating unnecessarily? If it's below 60%, I'm probably skipping levels. People are routing everything back to me because I haven't built the confidence infrastructure to support autonomous decision-making.

5. Measure Load Capacity, Not Sentiment

Engagement surveys tell you how people feel. Infrastructure metrics tell you whether the system can actually carry the weight you're asking it to carry.

These are the five load tests I've found actually matter:

Training transfer rate: What percentage of skills taught in training programs show up in actual work 90 days later? Below 30% usually means your infrastructure can't support skill acquisition. People are learning things in classroom settings that evaporate the moment they return to an environment where mistakes get punished.

Delegation success rate: What percentage of delegated tasks complete without boomeranging back? Below 60% means your infrastructure can't support autonomous decision-making.

Time-to-surface: How long between when someone discovers a problem and when they raise it? If problems only surface in postmortems, your infrastructure is failing.

Rework rate: What percentage of completed work requires significant revision? Above 15% is usually a signal of fear-based mistakes that could have been caught earlier if people felt safe asking for clarity.

Error-reporting frequency: Are people surfacing problems when they're small and fixable, or only after they've metastasized into crises? I track the ratio of "I think this might be a problem" versus "this is definitely a disaster." The ratio tells you whether your infrastructure supports early detection.

These aren't sentiment metrics. These are actual infrastructure load tests. And when the metrics are bad, the interventions tend to become pretty obvious.

What This Actually Costs

The invisible costs are huge. Projects that shipped three months late because people were too scared to make decisions. Rework from fear-based mistakes someone spotted early but was afraid to surface. The best PM who quit because she was tired of working in survival mode. The new hire who spent six months asking permission for everything.

Add it all up and Sarah's training budget was the smallest number on the page. The confidence infrastructure failure probably cost the company $3-4M in missed opportunities, wasted effort, and talent exodus.

Toyota proved the fix works in 1984. Same workers, same union, same equipment. They rebuilt the wiring and got 10x results.

You can't scale on infrastructure that's already overloaded. The training programs will keep evaporating. The delegation will keep boomeranging. Your best people will keep leaving.

Or you rebuild the wiring.

You're already paying for this. In training that doesn't transfer, rework that shouldn't exist, replacing talent you shouldn't have lost. The question is whether you're going to keep bleeding or fix the infrastructure.

⚙️ Hi {{first_name_tally|Operator}},

My inbox has 8,742 unread emails and I'm tired of pretending that's a personality trait.

So I built a tool I'm calling Dossier. It categorizes every email, archives the unimportant emails, and sends me two daily briefs (morning and evening) that summarize and pulls out the key points I actually need to act on.

I'm giving 50 operators early access for free. Reply "I'm in" and my team will onboard you.

While youre hitting that reply button, last week I wrote about confidence infrastructure, the invisible wiring that determines whether your team can actually use the skills they're supposed to have.

The response was... a lot. My inbox looked like a support group for operators who finally had language for why their $340K training programs evaporated.

Three patterns showed up in every reply:

1. "Holy shit, this explains everything"

2. "Okay, but how do I actually fix it?"

3. "Can you please stop sending me emails at 2 AM"

Fair on all counts.

This week: How Toyota rebuilt confidence infrastructure at the worst factory in America and got 10x results with the same workers, same equipment, same union.

But first: the Fremont plant in 1982, where workers showed up drunk because showing up sober was worse.

- Rameel  

P.S Here is part 1 if you missed it.

^{_{PRESENTED BY THE BOTTLENECK}}
Stop Being the Team’s Firefighter. Start Acting Like Their Future COO

Your calendar is full. Your brain is fried. And somehow, your work still flies under the radar.

Here’s the truth: You don’t get promoted for working more. You get promoted for fixing what’s broken.

Bottleneck Breakers is the system I used to:
– Trim 20 hours of busywork a week
– Fix the stuff that actually moved the needle
– And earn a COO title before I turned 30

🧠 No video lectures. Just drop-in systems that make you undeniable when promotion season hits.

How Toyota Got 10x Results from the Same Workers

 In 1982, General Motors closed its Fremont, California assembly plant. By every measurable standard, it was the worst facility in the entire GM system (and given GM's track record in that era, that's really saying something).

The numbers were catastrophic:

• 20% daily absenteeism. On any given day, one in five workers just didn't show up

• Cars rolling off the line with engines installed backward

• Vehicles missing parts like steering wheels or brakes

• Workers drinking and doing drugs on the factory floor during shifts

• Hundreds of misassembled cars piled up in the yard because they couldn't be sold

GM's diagnosis was straightforward: bad workers, terrible union, California labor market problems, unfixable culture. They shut it down and walked away.

Two years later, Toyota agreed to partner with GM to reopen the plant. The deal had a strange stipulation: Toyota would not change anything about the plant. This included staff, building or machinery.

Industry observers thought Toyota had lost its mind.

Here's what Fremont looked like after Toyota took over:

• Absenteeism dropped from 20% to 2%.

• Lowest defect rates in the United States, comparable to Toyota's factories in Japan.

• Productivity doubled. They built the same cars with 50% fewer workers.

• Highest quality ratings of any GM plant in North America.

What do you think changed?

It sure wasn't the people, not the equipment, or not the union. Instead, Toyota rebuilt the plant's confidence infrastructure.

The Andon Cord

They installed something called the Andon cord, a rope running the length of the production line that any worker could pull at any time to stop the entire production line if they spotted a problem.

This sounds simple. Maybe even obvious. But the genius wasn't in the rope itself.

The genius was in the policy. If you pulled the cord, you'd never, under any circumstances, result in punishment.

Workers were thanked for pulling the cord. Praised for it. If someone pulled the cord because they thought they saw a problem but it turned out to be nothing, they were thanked for being vigilant.

Management tracked cord pulls obsessively (but not to punish people who pulled too often). To identify sections of the line where pulls were decreasing. Because decreasing pulls meant people were getting scared again. And scared people hide problems instead of surfacing them.

Toyota employed one team leader for every eight workers. 14% of their labor force. The team leader's entire job was responding when someone pulled the cord.

Think about the economics of that decision for a second.

Toyota looked at a plant where 20% of workers didn't even show up, where cars rolled off the line missing critical components, where productivity was abysmal and their first move was to hire more people whose only job was to make it safer to admit problems.

Not to enforce standards. Not to crack down on quality issues. Not to "hold people accountable."

To make it psychologically safe to pull the cord.

What Actually Changed

The previous incentive structure was perfectly designed to produce exactly what it produced: chaos.

Before Toyota, Fremont workers showed up drunk because showing up sober meant eight hours of being screamed at for problems they couldn't fix. They installed engines backward because rushing through the work was the only way to avoid getting written up for being too slow. They didn't report defects because reporting defects meant admitting you let a defect happen, which meant your supervisor would make your life hell.

Toyota didn't change the workers. They changed what happened when workers told the truth.

Under GM: Pull the cord → Get yelled at → Possibly written up → Definitely remembered as "that guy who stops the line."

Under Toyota: Pull the cord → Team leader arrives in 60 seconds → "What do you need?" → Problem gets solved together → Public thank you at the end of shift.

The first few weeks were rough. Workers pulled the cord constantly because they'd spent years watching problems roll by that they weren't allowed to stop. The line stopped dozens of times per shift. Production crawled.

Toyota's response? Keep thanking people for pulling it.

Within six weeks, something remarkable happened.

Workers started pulling the cord earlier. Instead of waiting until a problem was fully formed and stopping the entire line, they'd pull it the moment they spotted something that might become a problem.

Defects dropped. Productivity increased.

The line stopped less frequently because problems were getting solved before they became line-stopping disasters.

Why GM's Copycat Attempt Failed

GM watched all of this happen. Took detailed notes, sent managers to observe, flew executives out for multi-day immersions. Then they tried to copy it at their Van Nuys plant.

They installed the Andon cord, told workers they could pull it anytime, put up the same visual management boards Toyota used, trained supervisors on "the Toyota way."

Complete failure.

Workers pulled the cord a few times that first week. Management did what management always does: treated people surfacing problems like they were the problem.

"Why are you stopping the line? Can't you work around it?"

"Is this really worth halting production?"

"Keep pulling that cord and we're having a different conversation."

Two weeks in, nobody touched it. Not because the problems disappeared but because pulling the cord got redefined as career suicide.

Van Nuys shut down in 1992.

GM couldn't copy Toyota because what Toyota built wasn't rope. It was a promise backed by hundreds of small daily proofs that the promise was real. That pulling the cord really wouldn't wreck your career. That admitting ignorance really was safer than faking competence. That your job was building quality cars, not hiding defects from your boss.

You can't install that with a memo.

The Pixar Version of the Andon Cord

You don't need a literal cord. You need the equivalent: a mechanism that makes it psychologically safe to say "something's wrong" before it becomes catastrophic.

Pixar has one. They call it the Braintrust.

When a Pixar movie is in development (and remember, these movies cost $200 million and take 4-6 years to make) the director shows rough cuts to a group of other Pixar directors and creative leads. The Braintrust's job is to be brutally honest about what's not working.

"This character isn't believable."

"The second act drags."

"I don't understand why the protagonist makes that choice."

"This whole sequence should be cut."

The Braintrust has zero decision-making authority. The director still controls the movie. This separation, brutal honesty with no power to force changes, enables a level of candor that's impossible when feedback and consequences are tangled together.

Ed Catmull, who ran Pixar for decades, describes their philosophy like this: "Early on, all of our movies suck. Our job is to make them go from suck to not-suck."

This is a radically different framing than "we ship perfect things" or "mistakes are unacceptable."

It's the same philosophy as the Andon cord: create a system where admitting problems is safe, then trust that people will surface problems early when they're still fixable.

Pixar's track record speaks for itself. Toy Story, Finding Nemo, The Incredibles, Up, Inside Out, Coco. Twenty-seven feature films. Most of them critically acclaimed and commercially successful. Not because they hire perfect people who make perfect movies, but because they built infrastructure that lets imperfect people make excellent movies by admitting when something isn't working yet.

The Pattern Across Industries

Toyota in manufacturing. Pixar in entertainment. Let's add one more: hospitals.

Amy Edmondson, the Harvard professor who's spent her career studying psychological safety, did research in hospitals trying to understand why some medical teams had better patient outcomes than others.

She measured error rates across different units. The surprising finding: the best-performing units reported the most errors. Not the fewest. The most.

At first, this seems backwards. Aren't better teams supposed to make fewer mistakes?

But when Edmondson dug deeper, she found that high-performing teams weren't making more errors. They were catching them earlier. Nurses felt comfortable saying "wait, this dosage looks wrong" or "I think we should double-check this chart" or "something doesn't feel right about this patient."

Lower-performing teams had the same error rates (maybe even higher) but those errors weren't getting reported until they became full-blown disasters. Because in those units, questioning a doctor's orders or admitting you weren't sure about something meant getting snapped at or dismissed or remembered as "not a team player."

Same hospitals. Same training. Same equipment. The variable was whether the infrastructure could support early truth-telling.

Why This Matters for Your Company

You're not running a car factory. Your confidence infrastructure problems probably don't involve drunk workers installing engines backward.

But the pattern is identical.

Somewhere in your organization right now, someone knows about a problem they're not surfacing. A project that's going sideways. A client who's about to churn. A process that's breaking. A decision that was made based on bad assumptions.

They're not raising it because the last time they raised something, it didn't go well. Or they watched someone else raise something and it didn't go well for them. Or the system has trained them, through a thousand small interactions, that surfacing problems is more dangerous than hiding them.

So they're waiting. Hoping it resolves itself. Trying to fix it quietly. Building a paper trail to prove it wasn't their fault.

And while they're waiting, the problem is getting bigger and more expensive.

This is the same failure mode as Fremont pre-Toyota. Different industry, different specific problems, same root cause: the confidence infrastructure can't handle the weight of truth-telling.

The cost compounds differently in a software company or a services business than it does in a car factory, but it's still compounding. Projects slip. Client relationships deteriorate. Technical debt accumulates. Your best people get frustrated and leave because they're tired of working in a system where honesty is punished.

You can keep diagnosing these as isolated skill gaps, this PM needs better project management training, this account manager needs better client relationship skills, this engineer needs to be better at estimating or you can do what Toyota did and ask whether the infrastructure can support the behaviors you're asking for.

Same People, Different Infrastructure

Here's the pattern:

Fremont: 20% absenteeism → 2%. Worst defects → best defects. Same workers.

Hospitals: More reported errors = better outcomes. Same doctors and nurses.

Pixar: "All our movies suck in the beginning" → box office hits. Same creative teams.

The pattern is consistent across industries and contexts: most organizations aren't skill-constrained. They're confidence-constrained.

The wiring can't carry the load. So problems hide until they're catastrophic. Training doesn't transfer because learning requires admitting temporary incompetence. Delegation boomerangs because making autonomous decisions requires believing mistakes won't be career-ending.

Toyota proved the wiring is fixable. Same people. Same union. Same equipment. Different promises, consistently kept over time until people believed them.

The question isn't whether your team has the capability to handle more autonomy, make better decisions, surface problems earlier, or execute at a higher level.

The question is whether your confidence infrastructure can support those behaviors.

⚙️ Hi {{first_name_tally|Operator}},

I've been thinking about the idea of Confidence Infrastructure in companies for months, ever since a conversation with a VP of Ops who spent more on leadership training in one quarter than most startups raise in their seed round—and got nothing to show for it.

The conversation stuck with me because I've seen this pattern everywhere. At Uber Freight, watching managers who knew exactly what to do but were too scared to do it without three levels of approval. At my family's gas stations, where the best employees would quit rather than make a decision that might be wrong. In my own businesses, where I'd spend $15K on a course that generated great feedback scores and zero behavior change.

We keep diagnosing these as skill gaps. Better training. More frameworks. Clearer processes.

But the real problem is infrastructure. The invisible wiring of confidence that determines whether someone can actually use a new skill or just nod along and revert to asking permission for everything.

This is Part 1 of a three-part series to close out the year. Over the next three weeks, I'm going to show you:

Part 1 (today): Why your training budget is evaporating and your delegation keeps boomeranging—and why both trace back to the same infrastructure failure.

Part 2 (next week): The NUMMI story—how Toyota took the worst workers in the GM system and got 10x results by rebuilding confidence infrastructure. Same people, same equipment. The variable was fear.

Part 3 (final week): Your playbook—how to actually rebuild the wiring without a trust fall. Specific tactics, measurable metrics, and a 30-day audit you can run in January.

Let's start with the problem nobody wants to name.

- Rameel  

^{_{PRESENTED BY BELAY}}
How COOs Win Back 10+ Hours With Better Ops Design

Every week you ignore the backlog, you lose more than time. Discover how top executives free up hours, reclaim their calendars, and accomplish more with BELAY’s proven template and tools.

Download the Executive’s Guide to Saving 10+ Hours/Week below.

The Hidden Infrastructure Problem Killing Your Operations

A VP of Ops at a Fortune 1000 company—let's call her Sarah (because that was her name)—spent ~$340,000 on leadership training in Q3 2023 for 31 managers. That's $11,000 per manager for a program that promised to "unlock delegation superpowers" and "create a culture of ownership."

Every manager went through it. Gave it high marks. Said they learned a ton.

Six months later, Sarah was still personally approving PTO requests.

Projects that were supposed to ship in Q4 didn't ship until Q2. Delegation attempts landed back on her desk with notes attached: "Just wanted to make sure this is what you wanted." "Can you review this before I send it?" My personal favorite: "I started this but I'm not sure if I'm doing it right."

The team was more bottlenecked than before the training, possibly because now everyone had a shared vocabulary for explaining why they couldn't make decisions without her sign-off.

The CEO wanted to fire the vendor. The vendor blamed engagement. HR scheduled focus groups to extract "learnings"—a word that should be banned from professional settings but somehow persists.

Nobody asked the obvious question.

Why are we stacking skill development on top of people whose nervous systems are running at max capacity?

The training wasn't the problem. The problem was the infrastructure; the invisible wiring of confidence that determines whether someone can actually use a new skill or just nod along and revert to asking permission for everything.

Most companies treat confidence like personality. You either have it or you don't, like being tall or funny or good at remembering birthdays.

But confidence is load-bearing structure. It determines how much weight your team can carry, how much autonomy, how many decisions, how much accountability, before the whole system buckles.

Companies keep stacking training programs and delegation frameworks on confidence infrastructure that was already at capacity. Then they act surprised when it collapses.

The wiring can't handle it. Training doesn't transfer. Delegation boomerangs. Your best people quit because they're tired of working in survival mode.

Same problem. Different symptom. Every time.

The Math Nobody Wants to Do

Organizations spent $200 billion on training last year. Not million—billion, with a B, which is the kind of number that should make you pause and wonder what we're getting for it.

Turns out: not much.

Research on training transfer—the field dedicated to figuring out why expensive training programs don't actually change behavior—shows that only 15-20% of what people learn shows up in their actual work 90 days later. Which means roughly $160 billion evaporated.

The mechanism isn't mysterious. When people are afraid mistakes will show up in their performance review, the brain does this:

• The prefrontal cortex—responsible for learning new things and making complex decisions—goes offline.

• The hippocampus, which consolidates memory, stops working properly.

• Every calorie of cognitive bandwidth gets redirected to one task: figure out how to not look stupid in the next meeting.

You can't teach someone in threat mode.

When confidence infrastructure is unstable, tasks don't get completed. They get returned. Half-finished because someone was too afraid to make the judgment call required to finish it. Over-engineered because they were terrified of shipping something imperfect. Never started at all because they were waiting for clarity and explicit permission that was never going to arrive.

The average manufacturing company loses 12.5% of product revenue to rework—doing things twice because they weren't done right the first time.

But nobody tracks how much of that rework traces back to fear-based mistakes. Errors someone spotted early but was too scared to surface because raising your hand felt like volunteering to be the reason the project failed. Problems that festered for weeks because admitting you didn't understand something three meetings ago seemed more dangerous than trying to figure it out quietly on your own.

Meanwhile, CEOs who are actually good at delegation—who've figured out how to get work off their plate without it boomeranging back—generate 33% more revenue than peers who can't let go.

But delegation only works when people feel safe enough to try something, fail at it, learn from the failure, and try again without that failure becoming a permanent black mark.

The Two-Ladder Problem

Picture climbing two ladders side by side. Sounds insane. Everyone does it at work without realizing it.

Left hand and foot: skills ladder. Technical ability. Domain knowledge. The thing you got hired for and keep getting better at through reps and training and gradually accruing expertise.

Right hand and foot: confidence ladder. Psychological safety. Trust that mistakes won't end your career. The belief that you're allowed to be temporarily incompetent while you're learning—that incompetence is a phase, not an identity.

Both ladders climb together. If one shakes, you freeze on both.

This isn't a metaphor about feelings or self-esteem or whether you got enough encouragement as a child, though all of those things matter in ways that are annoying to admit. This is a structural engineering problem. The confidence ladder is load-bearing. It determines how much weight the system can carry—how much new skill development, how many autonomous decisions, how much accountability pressure—before the whole thing collapses.

Most companies pour 100% of infrastructure investment into the left ladder. Better training. More certifications. Advanced workshops. Leadership programs called "Accelerate" or "Catalyst" that cost $11,000 per person and generate survey scores of 4.6 out of 5.

Six months later, nobody's climbing.

Because the right ladder—the one nobody's maintaining—is shaking so badly that people would rather stay exactly where they are than risk moving up.

When confidence infrastructure can't handle the load, you get a predictable failure pattern in four stages:

Stage 1: Cognitive overload

The brain reroutes resources from higher-order thinking to threat detection. Working memory shrinks—there's research on this, it's measurable—and decision paralysis sets in. People who used to make judgment calls autonomously start asking permission for everything, even things they've done a hundred times before.

Stage 2: Defensive work

Everything gets over-documented, over-analyzed, over-checked. Not because people don't know what they're doing, but because they're building paper trails to prove it wasn't their fault when something inevitably goes wrong. You can see this in Slack threads that should be two messages but turn into 40 because nobody wants to be the person who made the call.

Stage 3: Learned helplessness

Martin Seligman's research on learned helplessness started with dogs in a lab—I know, grim—but the pattern scales to organizations. After enough experiences where trying to change an outcome doesn't work, people stop trying even when conditions improve. The wiring is fried. Even when you create new opportunities for people to use their voice or make decisions, they don't take them because they've learned that initiative gets punished.

Stage 4: The exodus

Employees with the lowest psychological safety are four times more likely to quit within a year—12% versus 3%. The people who leave first are always the ones with options. Your best talent. The ones who could make autonomous decisions if you let them, but got tired of working in a system that treated every decision like a career-defining referendum.

You can't fix this by hiring better people. The new people just get chewed up by the same infrastructure.

You can only fix it by rebuilding the wiring.

Why Training Budgets Evaporate

Training vendors will never tell you this directly, but their programs don't fail because the content is wrong. They fail because they're asking people to learn new skills in environments where learning is punished.

There's a body of neuroscience research on the "Derring Effect" that proves—with brain scans and control groups and the whole scientific apparatus—that deliberately making errors while learning improves outcomes more than trying to avoid errors. Making mistakes on purpose, knowing they're mistakes, then correcting them creates stronger neural pathways than errorless learning.

But this only works if you feel safe making those mistakes. If you're scared errors will show up in your performance review or get mentioned in front of peers as examples of what not to do, the entire learning mechanism shuts down. Stress hormones flood your amygdala. The hippocampus stops consolidating memories. Your prefrontal cortex goes offline.

You're not learning. You're surviving.

Carol Dweck's research on growth mindset shows that students who believe they can improve through effort outperform fixed-mindset peers by 9-17%. In workplace settings, 80% of senior executives agree that growth mindsets contribute to revenue growth. But everyone forgets the precondition: a growth mindset requires an environment where mistakes are treated as data instead of career-ending events.

You can't convince someone that mistakes are learning opportunities when their last three mistakes showed up in their performance review as evidence for why they shouldn't get promoted.

Most companies respond by buying more training. Better vendors. Fancier platforms. Gamification. Microlearning. Just-in-time delivery.

That's like trying to fix an electrical problem by increasing voltage. You're not going to get better results. You're going to start a fire.

Why Delegation Boomerangs

Nobody tells first-time managers this, but delegation isn't about trust. It's about infrastructure capacity.

You can trust someone completely—believe in their intelligence, their work ethic, their judgment—and still watch every task you delegate return to your desk in one of three states: half-finished, over-engineered to absurdity, or never started at all.

The problem isn't their competence. The problem is that confidence infrastructure can't support the weight of autonomous decision-making.

When 52% of workers admit that fear of being wrong prevents them from making important decisions—and that's just the ones who'll admit it on a survey—you're not looking at a personality problem. You're looking at a rational response to a system that has repeatedly demonstrated that deviation gets punished.

When confidence is unstable, people default to three survival behaviors:

Learned helplessness: Stop trying to influence outcomes. Wait for explicit instructions on everything. Never take initiative because initiative has historically been punished more often than rewarded. This is what it looks like when someone who used to make judgment calls starts cc'ing you on every email and asking permission to do things they've done successfully a dozen times before.

Analysis paralysis: Over-research every decision, over-document every step, over-check every output. Not because they don't know what to do—they usually know exactly what to do—but because they're building a defensive paper trail to prove it wasn't their fault if something goes wrong. This is why your Slack threads are 40 messages long when they should be two.

Upward delegation: Route every decision back because "just checking" feels safer than being wrong. The manager who sends you "I started working on this but wanted to make sure I'm going in the right direction before I finish it"—which really means "I finished it but I'm too scared to hit send without your approval so I'm pretending I haven't finished it yet."

All three trace back to the same root: The system taught them that autonomy is dangerous.

Here’s a doom loop:

Manager delegates → Task executed poorly due to fear → Manager loses trust → Manager starts micromanaging → Confidence drops further → Next delegation fails worse.

Breaking the loop requires rebuilding infrastructure, not just "trusting more" or "letting go."

What Nobody Wants to Admit

The "hard" operational problems—missed projects, expensive rework, delegation failures, training waste, scaling walls—aren't usually skill gaps.

They're confidence collapses disguised as skill gaps.

You keep diagnosing skill problems because those are the visible symptoms. Someone missed a deadline, so clearly they need better project management training. Someone made a bad call, so clearly they need better judgment. Someone can't handle the workload, so clearly you need to hire someone more senior.

But the root cause is infrastructure that can't carry the load. The wiring is inadequate for the voltage you're trying to run through it.

Most companies aren't skill-constrained. They're confidence-constrained.

The wiring can't carry the load. So you keep pouring money into training programs that don't transfer, delegation frameworks that don't stick, and scaling attempts that collapse under their own weight.

Toyota figured this out in 1984 with the worst workers in the GM system. Same people. Same union. Same equipment. They rebuilt the confidence infrastructure and got 10x results (which we will talk about next week!)

⚙️ Hi {{first_name_tally|Operator}},

October 1, 2013. Healthcare.gov goes live. Four million people try to log in. Six succeed.

Not six thousand. Six people. Out of four million attempts. A 99.99985% failure rate on the most scrutinized government technology project in a decade.

The post-mortem blamed "poor project management." The GAO cited "inadequate technical assessment." Consultants pointed to "insufficient coordination." All technically true. All missing the point.

The real failure happened eighteen months earlier, in a conference room where nobody had the guts to say: "We will not integrate real-time data from 36 state systems, the IRS, DHS, and hundreds of insurance providers by October 2013."

Every stakeholder got a yes. Every feature request got approved. Every political demand got accommodated. The project manager inherited a scope that grew like a tumor, authority that didn't exist, and a deadline set by Congress.

When the site crashed, they blamed the project manager.

This pattern repeats everywhere. Denver Airport: 2,100 design changes, 16 months late, $560 million over. Sydney Opera House: 14x over budget, no defined scope. The FBI's Virtual Case File: $170 million, zero working software, 400+ change requests.

Every billion dollars in project spend bleeds $97 million to scope creep. Forty-nine percent of projects experience it.

But we keep calling this a planning problem.

It's not. It's a spine problem.

- Rameel  

^{_{PRESENTED BY THE BOTTLENECK}}
Stop Being the Team’s Firefighter. Start Acting Like Their Future COO

Your calendar is full. Your brain is fried. And somehow, your work still flies under the radar.

Here’s the truth: You don’t get promoted for working more. You get promoted for fixing what’s broken.

Bottleneck Breakers is the system I used to:
– Trim 20 hours of busywork a week
– Fix the stuff that actually moved the needle
– And earn a COO title before I turned 30

🧠 No video lectures. Just drop-in systems that make you undeniable when promotion season hits.

Why Systems Expand by Default (And Why That's Your Problem)

Scope expansion isn't an anomaly requiring explanation. It's the default state of every system.

The Second Law of Thermodynamics doesn't care about your roadmap. It states that isolated systems naturally evolve from order to disorder—entropy increases over time. Without active energy input to maintain structure, things fall apart.

Organizations are open systems (they exchange resources with their environment), which means they can temporarily resist entropy. But "temporarily" and "resist" are the operative words. The natural state is expansion, accumulation, and eventual collapse. Constraint requires continuous force. Growth is the path of least resistance.

This isn't philosophical. It's measurable in three studies I read over the weekend (I'm a dork):

1. Parkinson's Law (1955): British Admiralty study showed that between 1914 and 1928, Navy ships dropped by two-thirds and personnel by one-third, yet dockyard officials and clerks increased 5-6% annually. The number of officials and the quantity of work "are not related to each other." Bureaucracies grow independent of workload because: (1) managers multiply subordinates, not rivals, and (2) officials make work for each other.

2. Peter Klimek's 2009 study in Journal of Statistical Mechanics found that decision-making groups have a critical "coefficient of inefficiency" around 20 members—beyond that, effectiveness collapses. Administrative bodies modeled as open systems show that without constraints, bureaucracies grow while per-person output drops.

3. Brooks' Law (1975): "Adding manpower to a late software project makes it later." Why? Because if you have n workers, you have (n² - n) / 2 communication paths. A team of 10 has 45 communication channels. A team of 50 has 1,225. The coordination cost grows combinatorially while productivity per person decreases.

The pattern is universal: without explicit boundaries, systems consume available resources, generate internal complexity, and collapse under coordination costs. Scope creep isn't a bug. It's thermodynamics.

The Political Reality: Why Your Project Manager Can't Save You

Here's what operators hate acknowledging: project managers cannot control scope. They don't have the organizational authority. This isn't about competence—it's structural.

A 2019 Northumbria University study of 70 project managers in oil and gas construction analyzed 201 historical projects and found that project managers' inability to say "no" was a primary driver of scope creep. But let's be precise. The study doesn't say PMs were too weak. It says they lacked the authority to refuse.

PMI research confirms: "When PMs are expected to produce change through projects, they often lack the authority needed to 'make it happen.'" When project managers try to control scope, "they assume the responsibility of the project owner" without corresponding power.

Here's what this looks like operationally:

Healthcare.gov, 2013: One month before launch, the White House mandated user registration before browsing—a major architectural change. Project managers raised concerns about timeline. Concerns were overruled. Multiple contractors, each reporting to different stakeholders, made decisions without coordinating. The project manager at CGI Federal had nominal authority but no actual power to say "that change violates our integration architecture."

The GAO found: "Constant and abrupt policy changes contributed toward a high level of uncertainty, which significantly affected project direction and ability to plan effectively."

Translation: political pressure created continuous scope expansion, project managers couldn't refuse, and when it failed they got blamed.

Chaco Canyon Consulting research documents "scopemonging"—intentional political manipulation of project scope. One political actor expands scope to attack a rival. Troubled projects expand scope to acquire healthier sibling projects, hiding problems. In public sector work with many stakeholders, "each will have influence on project scope and funding decisions," creating a tragedy of the commons where everyone adds priorities and nobody cuts.

Project managers are politicians negotiating with stakeholders they can't refuse. They inherit responsibility without authority. When leaders don't establish and defend boundaries, the project manager becomes the organizational punching bag—accountable for failures caused by leaders who lacked the spine to say no.

Scope creep happens because saying "no" to powerful stakeholders has social and political costs that project managers cannot absorb.

Only executives can. And most won't.

The Leaders Who Had Spine

The difference between project success and catastrophe isn't better Gantt charts. It's leaders willing to defend boundaries against stakeholder pressure.

Steve Jobs, Apple (1997): Product line from 350 to 10. A 97% cut. The company was weeks from bankruptcy. Jobs didn't optimize. He amputated.

At the 1997 WWDC, Jobs told teams: "I know some of you spent a lot of time working on stuff that we put a bullet in the head of. I apologize. But Apple suffered for several years from lousy engineering management."

His philosophy: "People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying 'no' to 1,000 things."

When advising Nike CEO Mark Parker, Jobs said: "Nike makes some of the best products in the world. But you also make a lot of crap. Just get rid of the crappy stuff and focus on the good stuff."

The outcome: Apple transformed from near-bankruptcy to one of the most valuable companies in history.

Jobs emphasized that saying no "pisses people off." He did it anyway. That's the spine part.

The contrasting failures:

• Denver Airport leadership couldn't refuse United's 2,100 design changes → 16 months late, $4.8 billion total cost.

• Healthcare.gov leadership couldn't control politically-driven scope expansion → 99% failure rate on launch, $2.1 billion spent.

• Sydney Opera House leadership allowed unlimited quality goals without boundaries → 14x over budget, 10 years late.

In each case, technical teams were competent. Leadership spine was absent.

What This Means Monday Morning

Scope creep isn't a project management failure. It's a leadership boundary failure.

The next time someone pitches adding a feature, expanding a timeline, or looping in another team, your job isn't to optimize how you say yes. It's to have the spine to say: "That's not what this project is."

Three moves:

1. Define exclusions before inclusions.

Before your next project kickoff, spend 2x as long defining what you won't do as what you will. Get sign-off on exclusions. Make them visible. Revisit them weekly.

When someone asks to add scope, point to the exclusion list. Make them justify why this violates the boundary you agreed to protect.

2. Shield your project manager.

Your PM can't enforce boundaries without your authority. When stakeholders pressure for scope expansion, handle it yourself. Don't delegate boundary negotiations.

If United Airlines demands 2,100 design changes, you—not your PM—tell them no. If the White House wants architectural changes one month before launch, you—not your PM—push back or adjust the timeline.

Your PM can manage the project. Only you can defend it.

3. Model saying no.

Jobs didn't hide the 350→10 cut. He announced it at WWDC and told teams, "I apologize, I feel your pain."

Bezos publicly talks about his three-decisions-per-day rule.

When you visibly say no to attractive opportunities, you give your team permission to do the same. When you only say yes, they learn that boundaries don't really exist.

The uncomfortable truth: saying no pisses people off. You'll disappoint stakeholders. You'll frustrate ambitious team members. You'll leave money on the table.

You'll also ship on time, stay on budget, and avoid becoming the next Healthcare.gov case study.

The $97 million question isn't whether you can ship on time. It's whether you have the spine to tell your biggest stakeholder: "That's not what this project is."

Most leaders won't. That's why most projects fail.

⚙️ Hi {{first_name_tally|Operator}},

My brother and I launched a business 2 months ago. $120K revenue - cash in bank, baby.

Here's the thing we obsess over (and yeah, it sounds insane): every new lead that comes in, we go see them in person. Immediately.

Like, inquiry comes in at 3 PM? We're booking flights that night.

Car, plane, train - doesn't matter. We show up. I stole this move from Will Guidara (and wrote about this two years ago).

Will ran Eleven Madison Park (one of the best restaurants in the world), and he’s known for unreasonable hospitality.

For example, he trains servers to place every plate so the Limoges stamp faces the guest right-side up when they sit down. No one flips plates over to check. But that one obsessive detail - done with total concentration - sets the tone for how they do everything else.

How they greet guests, pour champagne, end the meal.

Same idea, different margin structure.

If we treat the first interaction like it's disposable - "let's hop on a Zoom" - that's how we'll treat the rest of the relationship.

But when we show up before they've even decided we're worth their time?

Different energy. Different close rate. Different business. I’ve attached that piece here as a fresh reminder to myself (and you) that a touch of humanity can go a long way.

- Rameel  

^{_{PRESENTED BY THE BOTTLENECK}}
Stop Being the Team’s Firefighter. Start Acting Like Their Future COO

Your calendar is full. Your brain is fried. And somehow, your work still flies under the radar.

Here’s the truth: You don’t get promoted for working more. You get promoted for fixing what’s broken.

Bottleneck Breakers is the system I used to:
– Trim 20 hours of busywork a week
– Fix the stuff that actually moved the needle
– And earn a COO title before I turned 30

🧠 No video lectures. Just drop-in systems that make you undeniable when promotion season hits.

How to Provide Unreasonable Hospitality

When a customer’s parking meter is about to expire, what should a restaurant owner do?

Be like Will.

If you don’t know Will Guidara, he is infamous for the ridiculous levels of hospitality at his restaurants like Eleven Madison Park.

Eleven Madison Park is continually ranked one of the best restaurants in the world. Many credit this ranking to always over-delivering for the customer.

As leaders of organizations, we’ve all struggled with getting our teams to provide an amazing experience to our customers.

How does Will do it?

He prides himself on recruiting those who might lack experience but bring 100% enthusiasm to the work they do every day.

Will has correctly determined that people WANT to do great work. They just need to find their zone of genius.

He hyper-focuses on the details of how his team conducts themselves. A perfect example is when Will said…

Why would Will do that?

By asking the person setting the dining room to place each plate with total concentration, Will was asking them to set the tone for:

• how they’d do everything over the course of the service

• how they’d greet our guests

• pour the champagne to begin a meal and the cup of coffee to end it.

Sloppiness has a way of spreading.

⚙️ Hi {{first_name_tally|Operator}},

AI is compressing everything. Code that took weeks now takes hours. Analysis that took days now takes minutes. But here's what's not compressing: the time it takes to make decisions about what to build with all this new speed.

I've been watching companies where disagreements still take thirty days while their market window closes in thirty seconds.

Why does that happen (and what infrastructure actually fixes it).

- Rameel  

^{_{PRESENTED BY MOMENTUM}}
AI isn’t the advantage anymore. Knowing what to ask is.

Everyone’s got access to ChatGPT. Few know how to get results that don’t sound like a middle-manager wrote them.

That’s where Momentum’s Prompt Library comes in — a private vault of prompts actually used in the field. Not “10 ways to boost productivity.”

We’re talking revenue ops reports, outbound campaigns, investor updates, even product specs.

All written, tested, and refined by operators who already made AI pull its weight. Stop guessing at magic words. Start stealing the ones that work.

Decision infrastructure and the death of consensus culture

Every disagreement in your company takes thirty seconds or thirty days. Same decision. Same people. The difference is whether you built infrastructure before the fight started.

I've been trying to figure out why this is true. Decision speed explains 18% of the variance in company growth rates—not strategy, not hiring, not product quality. How fast you decide. But that stat didn't help me understand the mechanism until I dug into how a $150 billion company died because truth couldn't travel faster than fear.

The thesis: Decision infrastructure—pre-agreed arbiters, real-time data, and execution discipline—is becoming the defining competitive advantage of the 2020s because it makes arguments irrelevant instead of making them better.

Without infrastructure, every conflict devolves into who talks loudest, who's been there longest, who can build a coalition by Thursday.

How Nokia died (and what that tells us about infrastructure)

In 2007, Nokia held 49% of global mobile phone market share. By 2013, they sold their handset business to Microsoft for scraps.

The iPhone didn't kill Nokia. Fear did.

Here's what actually happened inside Nokia between 2007 and 2013, reconstructed from organizational research: Nokia's middle managers were terrified of delivering bad news or contradicting superiors. Leadership set unrealistically bold targets backed by terrifying reputations. When the iPhone launched in January 2007, Nokia had the data showing they were years behind. Their internal reports documented the gap. Engineers knew. Product managers knew. The people building the phones knew.

The information existed. It just couldn't travel.

Middle managers buried pessimistic data under false optimism because telling the truth was more dangerous than lying. Research found "organizational fear was grounded in a culture of temperamental leaders and frightened middle managers, scared of telling the truth." Top management was directly lied to—not by malicious actors, but by rational people in a system that punished honesty.

Think about what that means operationally. You're a middle manager at Nokia in 2008. You have data showing your team is 18 months behind Apple on touchscreen responsiveness. Your quarterly review is in three weeks. Your VP has a reputation for "shooting the messenger."

Do you:

A) Present the data honestly and risk your job

B) Massage the data to show "progress" and hope someone else raises the alarm

Most people chose B. Everyone chose B. And the result was that by the time leadership saw the real numbers, catching up was structurally impossible. Apple had already captured the premium market. Android was eating the low end. Nokia had resources, talent, distribution, brand recognition.

What they didn't have was infrastructure that let truth travel faster than politics.

Nokia had no pre-agreed arbiter for what mattered (market share? profit margin? engineering benchmarks?). They had no system for receipts over theories (middle managers could bury data with no consequences). They had no execution discipline (decisions got relitigated based on whoever had leadership's ear that quarter).

The mechanism that killed Nokia is the same mechanism killing companies today—just faster. Markets move in months now, not years. The window between "we have a problem" and "it's too late" has compressed. You don't have six years to figure out that truth isn't traveling. You have six months.

Why this matters more now than it did in 2010

Remote work destroyed the informal decision infrastructure most companies were running on. The hallway conversation that resolved disagreements before the meeting. The ability to read the room and know when to push. The lunch where you built coalition with the CFO before Friday's exec meeting. All gone.

What replaced it: Zoom fatigue, endless Slack threads, and the growing realization that consensus-building doesn't scale through video calls.

Companies are splitting into two categories. Infrastructure companies built formal systems to replace informal ones—pre-agreed arbiters, real-time data, execution discipline. Consensus companies are trying to recreate hallway conversations on Zoom and losing talent to confusion.

The gap is widening every quarter.

What infrastructure actually looks like (when it works)

GitLab shows what this looks like under pressure. Engineer Kamil Trzciński argued for an integrated DevOps platform. Leadership disagreed and decided on separate products. Most engineers would have stopped there.

Kamil kept pushing with data even after the decision.

GitLab has a principle: "disagree, commit, and disagree." You execute the decision immediately—no dragging your feet, no passive resistance. But you continue presenting evidence if you still believe you're right. The system protects dissent after the decision because the arbiter is clear: customer data and platform usage, not seniority or who argued loudest in the meeting.

Kamil kept bringing data like:

• Usage patterns showing customers wanted integration

• Competitive analysis showing where the market was moving

• Support tickets revealing the pain of separate products

Leadership eventually caved in. Which resulted in GitLab CEO Sid Sijbrandij saying:

That's infrastructure enabling decisions that get better over time because truth can still travel after you commit.

The counter-argument (and why it's wrong)

Infrastructure sounds rigid. Aren't you just creating corporate bureaucracy? Won't this slow us down?

I thought that too. Then I noticed something strange: the companies with the most infrastructure consider MORE alternatives, not fewer. Three to five options simultaneously versus one or two for slow firms. They're processing more information through cleaner pipes.

GitLab's "disagree, commit, and disagree" is the opposite of bureaucracy—it's protected dissent. You can keep pushing back after the decision as long as you execute and bring receipts. Bureaucracy says "the decision is final, stop questioning it." Infrastructure says "the decision is implemented, but truth can still travel."

Teams with decision infrastructure make decisions 35% faster while maintaining higher quality. Organizations with clear decision roles are 6.8 times more likely to be high-performing. The mechanism: infrastructure lets you process more information faster because you're not arguing about what evidence matters every single time.

The math on what this compounds to

I did the math on what this means over five years.

Company A has decision infrastructure and makes decisions in 1 day average. That's 250 decisions per year, 1,250 over five years.

Company B has no infrastructure and makes decisions in 10 days average. That's 25 decisions per year, 125 over five years.

Company A executes 10x more decisions in the same timeframe. But it's not just quantity—each decision has downstream effects. Product iterations where Company A ships 10x more features and learns from users faster. Market opportunities where Company A captures windows before they close. Hiring where Company A fills roles 10x faster, compounding their talent advantage. Pivots where Company A can test more strategic bets.

By year five, Company A isn't 10x better. They're in a different league entirely.

The decision velocity gap for companies like Amazon, Netflix, and Tesla becomes so large that catching up is structurally impossible. Nokia had six years to close the gap with Apple. They couldn't do it. You probably have six months.

Three rules that actually work

These aren't personality traits. They're infrastructure you can build Monday.

Come with receipts, not theories. 

Don't say "I'm concerned about customer retention with this pricing change." Say "Yesterday we tested the new pricing with 50 users. 32% churned within 48 hours. Here's the exit survey data." Receipts end arguments. Theories extend them. When you show the screen recording of three customers dropping off at checkout, the argument ends in thirty seconds.

Pick your arbiter before the fight. 

For product decisions, it's customer usage data and retention. For financial decisions, P&L and unit economics. For hiring, revenue-per-employee versus industry benchmarks. The arbiter needs to be agreed before tension exists—not during the argument, not after someone escalates to the CEO. If you're arguing about what the arbiter should be, you've already lost. Now you're arguing about how to argue, which is where organizational energy goes to die.

Execute, don't relitigate. 

After the decision, track outcomes and document what broke. Let data argue next time instead of re-justifying. Infrastructure without execution is process theater. GitLab's "disagree, commit, and disagree" works because execution happens immediately while evidence continues flowing. High-performing teams require explicit discussion of rationale before the decision. After? Execution.

If you're building or operating a company right now: Can you make critical decisions in thirty seconds or does it take thirty days?

For your next disagreement, pick your arbiter before the meeting starts. Is this a P&L decision? Customer data decision? Velocity decision? Agree on the arbiter before tension starts, before anyone's raised their voice, before positions have hardened.

When disagreement happens, show receipts—show the customer who churned, the P&L that broke, the feature that missed the window.

The trajectory (and what I'm still figuring out)

By 2030, decision infrastructure will be as foundational as financial infrastructure or legal infrastructure. Companies that don't have it will be unable to compete. The infrastructure stack will become standardized: real-time data systems capturing customer behavior, financials, and execution; decision frameworks with arbiters pre-agreed before tension; outcome tracking showing what worked, what broke, what to iterate; cultural norms that reward infrastructure-building instead of politics.

The companies building this now will have a five-year head start that becomes insurmountable. The companies waiting will be case studies in how consensus culture killed competitive advantage.

What I'm still working through: there's a version of this that becomes too rigid. You pick your metrics, optimize for them, and eventually make decisions that look good on paper but feel wrong in practice. I don't have a clean answer for when to change the arbiter. I'm watching for the moment when the metric stops serving the decision and starts driving it.

Most operators think their job is winning arguments.

I used to think that too.

Your job is making arguments irrelevant. Nokia had the talent and resources to beat the iPhone. They died because truth couldn't travel faster than fear. Spotify spent a year beta-testing one policy and gained 16 years of productivity. GitLab created the first DevOps platform because an engineer could keep presenting evidence after the decision.

The best operators never justify. They built the system that justifies for them.

⚙️ Hi {{first_name_tally|Operator}},

You rebuilt the deployment checklist. Again.

Then you added a new approval workflow. A better standup format. A tighter sprint process.

The dysfunction came back wearing a different costume.

Here's what nobody tells you: Most of your operational problems aren't process problems. They're leadership problems you're too afraid to address.

This week's essay breaks down how to tell the difference—and what to do Monday morning when you realize which leaders you've been avoiding.

Three diagnostic tests. Five moves. One hard conversation you've been postponing.

Let's go.

- Rameel  

^{_{PRESENTED BY MOMENTUM}}
AI isn’t the advantage anymore. Knowing what to ask is.

Everyone’s got access to ChatGPT. Few know how to get results that don’t sound like a middle-manager wrote them.

That’s where Momentum’s Prompt Library comes in — a private vault of prompts actually used in the field. Not “10 ways to boost productivity.”

We’re talking revenue ops reports, outbound campaigns, investor updates, even product specs.

All written, tested, and refined by operators who already made AI pull its weight. Stop guessing at magic words. Start stealing the ones that work.

You Can't Process Your Way Out of a People Problem

Every COO knows this at 2 AM, rebuilding the deployment checklist for the third time this quarter.

The checklist isn't the issue. Sarah won't tell Marcus his code is breaking prod. Marcus doesn't trust the QA team. Your VP thinks "driving alignment" means hosting more meetings.

The price tag: Gallup estimates $8.9 trillion annually in lost engagement worldwide—roughly 9% of global GDP.

Most operational problems aren't process problems. They're leadership problems disguised as process fixes. Until you address the person underneath, you're just rearranging deck chairs while your best people jump ship.

The Pattern: Why We Keep Fixing the Wrong Thing

December 2022. Southwest Airlines cancels 16,700 flights over ten days.

The press calls it a "technology failure." DOT Secretary Pete Buttigieg gets closer: "This wasn't just a weather event; it was a systems failure decades in the making."

But the post-mortems missed what was really broken: Southwest had legitimate technical debt—a crew scheduling system built in 2014 for point-to-point flying, not 2022 scale—AND leadership that consistently chose to ignore it. The pilots had been screaming about this exact failure mode for over a decade.

November 2022—one month before the meltdown—the pilots' union predicted the airline was "one IT router failure away from a complete meltdown."

The timeline tells the story:

2018: Internal audit flags "catastrophic risk" in aging crew scheduling system. Leadership defers modernization to prioritize short-term financial metrics.

2021-2022: Smaller meltdowns occur. Pilots picket for system improvements.

Summer 2022: They take to the streets with signs about technology infrastructure.

When the predicted disaster happened, leadership blamed the technology. The weather. The "perfect storm."

What they didn't blame: A 13-member board with zero technology expertise. A CEO who "was an accountant by education" and "did not spend much time on the front lines." A decade of choosing Wall Street over operational resilience.

The technology WAS outdated. But it was outdated because leadership refused to invest in modernization despite repeated warnings from the people operating the system. The broken scheduling system was the symptom. Leadership failure was the disease.

This is your pattern too. You see a process problem. You add a new tool, a better checklist, a tighter approval workflow. Initial excitement. Maybe it works for a quarter. Then the same dysfunction resurfaces in a different form.

Gallup's research shows managers account for up to 70% of the variance in employee engagement scores across teams. When engagement is high, turnover drops 51% and productivity increases 23%. When it's low, you're bleeding talent, margin, and sanity. Only 31% of U.S. employees report being engaged at work.

You keep fixing the symptom. The underlying problem stays broken. You're avoiding the hard conversation.

When Process IS the Answer (And How to Tell the Difference)

Not every operational problem is a leadership problem in disguise. Sometimes the checklist really is broken. Here's how to tell:

Process problems affect everyone uniformly.

Team A and Team B use the same flawed deployment tool. Both struggle equally. Both teams have strong leaders who want to fix it. The bottleneck is genuinely the tool—outdated, missing key features, or poorly designed.

Leadership problems create variance.

Team A hits sprint commitments consistently. Team B is always underwater. Same process, same tools, same expectations. The variance reveals the variable: Team B's leader.

The heuristic: Look for clustering.

If the problem exists everywhere with equal intensity, you likely have a genuine process or tooling issue. Fix the system.

If the problem clusters around specific teams, leaders, or departments—if some teams thrive while others struggle using identical systems—you have a leadership problem. No amount of process will close that gap.

Run this test on your three nastiest operational problems right now. Where do they cluster?

How to See Through the Symptom: Three Diagnostic Tests

Test 1: The Variance Test (Does the Problem Have a Name Tag?)

Does this problem exist everywhere or just on specific teams?

Southwest's other operational areas worked during the meltdown. Same company, same culture, same cost focus. Some divisions had leadership that listened to frontline warnings. Others had executives who filtered uncomfortable signals.

Pick your three biggest operational headaches. Do they cluster around specific leaders? If yes, you know what the problem is. You've known for a while.

Test 2: The Five-Second Accountability Test

Name who owns fixing this. Five seconds.

Can't name anyone? No one is empowered or responsible.

Can name someone but they haven't fixed it? They either don't have authority, don't have consequences, or don't have your attention.

Named several people who "share ownership"? Everyone's responsible means no one's responsible.

Knight Capital lost $440 million in 45 minutes from a software deployment error. Emails about the bug bounced around the organization for weeks without reaching anyone with authority to act.

Victorian hotel quarantine guards used WhatsApp to coordinate during COVID. When the virus spread from quarantine hotels, the review found "no clear lines of accountability." No one could say who decided to use private security over police or military.

The CRM issue that's been "on the roadmap" for six months. The deployment pipeline that breaks every Friday. The approval workflow that takes four weeks when it should take four days.

Set a timer. Five seconds. Name the owner. If you can't, or if you name three people, you found the problem.

Test 3: Feedback Archaeology

Who knew about this before it became critical?

If the answer is "frontline teams" and it's been over 30 days, you've been ignoring them.

Southwest's pilots warned for a decade. Boeing engineers whistleblowed for years about 737 MAX flaws before 346 people died. Uber employees reported harassment for years while leadership knew but didn't act.

Your version: CRM lag for six months. Friday deployment breaks. Approval workflows taking four weeks. Customer success flagging onboarding confusion for a year.

For each operational problem, ask: "Who told me first, and when?"

If the answer is more than 30 days ago, you've been ignoring them.

The Playbook: Five Moves to Fix the Real Problem

Your tests revealed leadership issues. Here's what you do.

Move 1: Apply the Variance Test to Everything

Stop asking "What process will fix this?" Start asking "Why does Team A not have this problem?"

Team A's leader probably:

• Gives clear priorities

• Has hard conversations early

• Protects the team from thrash

• Delegates real authority

• Makes it safe to deliver bad news

Team B's leader probably doesn't. No amount of process will close that gap.

List your three operational problems. Map them to leaders. The clustering will tell you everything.

Move 2: Rename Every Problem with a Person

Strip away the abstraction. Name what's underneath.

"Our deployment process is broken" becomes "Marcus doesn't trust QA to catch bugs."

"We have a communication issue" becomes "Sarah won't give Marcus direct feedback."

"Our roadmap approval takes too long" becomes "The VP won't delegate decision authority."

This feels uncomfortable. As long as you're naming process problems, you're avoiding leadership problems.

Rewrite your current "process improvement" list as people problems. Then decide which ones you have the courage to address.

Move 3: Create Systems Where Bad News Travels Fast

Southwest's leadership filtered out uncomfortable truths. Pilots warned for a decade. Leadership optimized the signal away.

Do your frontline people believe telling you bad news helps or hurts them?

If they believe it hurts—or if they're not sure—bad news will ferment in silence until it explodes. You'll be blindsided by problems everyone else saw coming.

Ask three frontline people: "What's the operational problem you wish I knew about but haven't told me?" Their answer—and whether they're willing to give one—tells you everything.

Move 4: Apply Radical Candor to Underperformers

Kim Scott's framework: Care personally + Challenge directly = Radical Candor.

Most operational failures are Ruinous Empathy. Caring without challenging. You know Bob is underperforming. You care about Bob. You don't want to hurt Bob's feelings. So you don't say anything. For ten months.

Then you fire Bob.

Bob's response: "Why didn't anyone tell me?"

Scott's controversial claim: "If you can't offer radical candor, the second best thing you can do is be an asshole." Being an obnoxious aggressor who challenges without caring is bad. But it's better than not challenging at all.

Ruinous Empathy doesn't just hurt Bob. It hurts Bob's teammates who are compensating. It hurts the project bleeding momentum. It destroys your credibility when your best operators watch you add another process instead of addressing the person underneath.

The Sheryl Sandberg example: When Kim Scott said "um" repeatedly in a presentation, Sandberg first praised the work, then escalated: "When you say um every third word, it makes you sound stupid."

Care + challenge.

Research suggests only about 20% of organizations consistently address mediocre leadership performance. The other 80% add another layer of process.

Pick the feedback you've been avoiding. The one that makes your stomach tight. Schedule the 1-on-1. Lead with care. Challenge directly. Give them 30 days. Track it.

Move 5: Measure Leadership Health, Not Just Output

Wrong metric: "How many processes did I roll out this quarter?"

Right metric: "How many underperforming leaders did I address this quarter?"

Organizations optimize what they measure. If you're only measuring process changes, you'll keep installing new systems while the leadership gaps remain.

Manager quality correlates with up to 70% of engagement variance (Gallup), yet most organizations evaluate managers on output—revenue, delivery, efficiency—rather than team health.

You optimize output. For a quarter. Then your best people leave and output collapses.

Next quarter, track these:

• Leadership conversations held: How many hard 1-on-1s with underperformers?

• Accountability enforced: How many people moved out or up based on team health?

• Frontline signal response time: How fast did problems surface and get acted on?

• Decisions you didn't make: How many times did your team decide without you?

If you can't measure team health as closely as revenue, you're flying blind. Revenue is a lagging indicator of team health anyway.

What Changes Monday

Here's your action plan for the next five days:

Monday morning: Run the Variance Test on your three biggest operational problems. Map them to leaders. If you see clustering, you have your answer.

Monday afternoon: Run the Five-Second Accountability Test. Set a timer for each problem. Name the owner. If you can't, or if you name multiple people, schedule a meeting to assign clear ownership by end of week.

Tuesday: Pick one "process problem" from your improvement backlog. Rewrite it as a people problem. Example: "Our deployment process is broken" becomes "Marcus doesn't trust QA and Sarah won't give him feedback." Decide if you have the courage to address it.

Wednesday: Ask three frontline people: "What's the operational problem you wish I knew about but haven't told me?" Listen. Don't defend. Thank them. Track response time: How many days until you act on what they tell you?

Thursday: Schedule the 1-on-1 you've been avoiding. The underperformer you've been hoping will magically improve. Lead with care. Challenge directly. Set clear expectations. Give them 30 days. Document it.

Friday: Add one new metric to your quarterly dashboard: "Leadership conversations held." Track it as closely as you track revenue. Review it in your next staff meeting.

Your best people are watching. They see you add another tool instead of having the hard conversation. They see problems get reported and ignored. They see you optimize processes while the dysfunction stays untouched.

They're already updating LinkedIn.

Run the tests. Rename the problems. Have the conversation.

Half your operational problems vanish by next Tuesday. The other half? They were never process problems either.

⚙️ Hi {{first_name_tally|Operator}},

There's a type of email that makes everyone nervous.

Subject line: "Important Update: New [Policy Name]"

You open it. Read three paragraphs. Have seven questions. None of them are answered in the FAQ.

So you Slack your manager. Who Slacks their manager. Who Slacks HR. Who says they'll "look into it" and get back to you.

This is just... how policies work at most companies?

Spotify looked at this process and said "what if we just tested it first."

Radical idea.

Today's piece breaks down Spotify's full framework (the 20-person beta, the 50-page playbook, the metrics they tracked).

Turns out beta-testing policies is way less complicated than cleaning up the mess when you don't.

- Rameel  

^{_{PRESENTED BY ATTENTION}}
Free Guide on Increasing Sales

Deals moving too slow? Forecasts always off? The best sales teams don’t rely on luck. They master alignment, automation, and intelligent execution. This free guide shows you how.

Inside, you’ll get:

• A streamlined sales tech stack that eliminates friction

• KPI frameworks that improve accountability and forecasting

• Smarter lead scoring that goes beyond firmographics

High-performing teams don’t guess. They execute with precision.

^{_{PRESENTED BY MOMENTUM}}
AI isn’t the advantage anymore. Knowing what to ask is.

Everyone’s got access to ChatGPT. Few know how to get results that don’t sound like a middle-manager wrote them.

That’s where Momentum’s Prompt Library comes in — a private vault of prompts actually used in the field. Not “10 ways to boost productivity.”

We’re talking revenue ops reports, outbound campaigns, investor updates, even product specs.

All written, tested, and refined by operators who already made AI pull its weight. Stop guessing at magic words. Start stealing the ones that work.

Your Policies Need a Beta Test

Most companies would never ship a feature to 5,000 users without testing it first.

They ship policies that way every day.

Draft in a conference room. Get Legal to sign off. Announce at all-hands.

Hope nobody rage-quits when they realize the PTO policy they just learned about doesn't actually answer whether their Uber to the airport counts as travel or needs a different expense code.

Basecamp shipped six policy changes at once in 2021. Via blog post. No testing, no input, no warning. Thirty percent of staff walked.

Leadership teams after drafting policies without asking a single employee

Spotify spent a year beta-testing one policy. They built a 50-page playbook. Pressure-tested it with 20 employees from every corner of the business.

Anticipated 990 out of 1,000 questions before launch. Time-to-fill dropped six days. Attrition fell. Nobody quit because they couldn't figure out the rules.

Same problem. Opposite approach. The difference: Spotify treated their remote work policy the way you'd treat a product launch—iterate with users before you scale the thing.

This isn't soft HR stuff. It's survival. Bad rollouts cost you months of cleanup and your best people.

Good ones buy you leverage: faster hiring, lower attrition, teams that actually know what to do Monday morning without a 47-message Slack thread.

Try treating your policies like products. Beta test them with real users before you ship to everyone.

How Spotify Beta-Tested a Policy for a Year

Anna Lundström had a problem in fall 2019. Spotify wanted to go distributed-first by 2025. Everyone had opinions. Nobody had answers.

She could've done what most VPs of HR do: convene a task force, draft a policy, announce it at all-hands, deal with the fallout later.

She did something else. She treated the policy like a product launch.

Not HR's mindset. Not leadership's mindset. The employee trying to figure out if they can move to Denver without getting fired.

The playbook hit 40 pages. Then 50. Every question they could anticipate. Every edge case that would break.

They got executive buy-in on both strategy AND tactics—the mistake companies make is getting leadership to sign off on principles while leaving implementation details vague.

Then they did something companies skip entirely: assembled 20 employees from every corner of the business.

Engineers, support reps, PMs, someone from Legal who actually uses Slack. Not to rubber-stamp the policy. To pressure-test it.

These employees surfaced questions the working group—smart, well-intentioned people in a room—hadn't considered. Questions you only discover when someone actually tries to use the thing.

This took a year.

While the pandemic was making every other company panic-ship remote policies, Spotify held back.

Kept researching. Studied 2,000+ companies. Refined the playbook. Resisted the urge to ship fast just because everyone else was shipping.

When Spotify finally launched Work From Anywhere, employees submitted 1,000 unique questions. They answered 99% from the playbook.

A thousand questions from a workforce trying to understand how their lives just changed. The policy documentation anticipated 990 of them. That doesn't happen by accident. It happens because you tested the policy with users before scaling it to everyone.

Eighteen months post-launch, Spotify measured outcomes the way you'd measure a product release:

• time-to-fill dropped from 48 to 42 days

• Hiring spread across 40 of 50 US states instead of concentrating in NY and LA

• Gender diversity increased

• They doubled race and ethnicity hires in the US. Attrition decreased

• Engagement stayed equal between remote and office employees

Most companies don't measure this. They announce a policy, track compliance rates, call it done.

Spotify tracked whether the policy accomplished what it was supposed to accomplish—make hiring better, make retention better, make work actually work for people.

The pattern isn't unique to Spotify. It's how you ship any policy that doesn't immediately break.

Here's What Changes Monday

Before you ship your next major policy, find 20 employees across different teams and levels. Hand them the draft policy.

Don't ask what they think—make them try using it for two weeks. S

ubmit an expense under the new rules. Request PTO through the new system. Schedule a meeting with the new guidelines.

Watch where they get confused. Time how long each step takes. Count how many questions you get. That data shows you where the policy breaks before you scale the breakage to 500 people.

Then fix it. Rewrite the confusing sections. Add the FAQ addressing the top five questions. Test with a fresh group of 20 for another two weeks. Iterate until the policy works for users, not just for Legal's risk tolerance.

The instinct is to move fast. Ship the policy, iterate in production, fix complaints as they come.

That's not fast. That's expensive.

Fast is spending a year so you don't spend two years cleaning up. Fast is answering 990 questions before you ship so you're not answering them in 1,000 Slack DMs.

Spotify didn't delay their policy. They beta-tested it. There's a difference.

⚙️ Hi {{first_name_tally|Operator}},

No witty intro today. It’s my birthday tomorrow, so I’ll save my fun (per my wife, lame) dad jokes for family dinner tonight.

Cheers!

- Rameel  

^{_{PRESENTED BY ATTENTION}}
Free Guide on Increasing Sales

Deals moving too slow? Forecasts always off? The best sales teams don’t rely on luck—they master alignment, automation, and intelligent execution. This free guide shows you how.

Inside, you’ll get:

• A streamlined sales tech stack that eliminates friction

• KPI frameworks that improve accountability and forecasting

• Smarter lead scoring that goes beyond firmographics

• AI-powered tactics to personalize outreach and scale efficiency

High-performing teams don’t guess. They execute with precision.

OpEx Is Your Agility Tax (Pay It Gladly)

August 2008. Netflix's database corrupts. DVD shipping stops for three days—millions of customers, zero deliveries, and one very obvious question: what the hell do we do about this?

All of us when they crashed…

The safe move was clear: buy more servers, hire more DBAs, build bigger, better, redundant-er data centers. Own the infrastructure. Control the stack.

That's what responsible operators do when critical systems fail.

Netflix did the opposite. They decided they were in the shipping-bits business, not the data-center business.

So they stopped trying to own the thing that kept breaking and started renting from someone whose entire job was keeping it from breaking.

The results looked like magic. Provisioning dropped from weeks to minutes. Quarterly releases became daily deployments.

Streaming hours grew 1,000x over seven years while cost-per-stream fell to a fraction of what owned infrastructure would have cost.

But the CFO math looked insane. Netflix was paying 50-60% premiums for infrastructure they could have owned cheaper. Every spreadsheet said buy. Netflix said rent anyway.

That decision is worth studying because it reveals something most operators miss: CapEx bets you're right. OpEx bets you'll adapt. When the world won't sit still, adaptation beats prediction every time.

Hertz went bankrupt owning vehicles. JC Penney drowned in owned real estate. Netflix survived by renting infrastructure and got called wasteful for it.

Turns out waste and insurance look identical until the building's on fire.

Why Netflix paid a 60% premium (and why you should too)

Let's not pretend the agility tax isn't real. Research by a16z showed that repatriating $100 million in annual cloud spending typically cuts total cost to $40-50 million. Netflix was paying 50-60% premiums for infrastructure they could have owned cheaper.

So why pay it?

Because owned infrastructure is a bet that the future looks like your spreadsheet. If Netflix had invested $50M in data centers in 2008, they'd have optimized for 2011 DVD-by-mail patterns. Three-year payback, beautiful ROI, board approval locked in.

But streaming exploded unpredictably. Geographic expansion accelerated. Content delivery requirements shifted overnight. Owned infrastructure built for one future would have constrained ten others.

The OpEx model gave them something spreadsheets can't capture: reversibility.

Nassim Taleb calls this optionality—the value of strategies that don't require correctly forecasting the future. You pay small recurring premiums to keep many futures open.

OpEx turned infrastructure into an API: spin up, test, kill, repeat. The complete migration took seven years—two physical data centers eliminated, thousands of servers spun up on demand instead of ordered months in advance.

Most critically: the ability to experiment without waiting for procurement cycles.

CapEx demands you're right on the first try. OpEx lets you be wrong and recover.

When to graduate (and why most teams do it too early)

Once your workloads stabilize at 70%+ utilization and you'd genuinely bet your job on the forecast, repatriation makes sense.

Netflix didn't stay 100% cloud forever—they graduated stable, high-volume workloads back to owned or reserved capacity.

But here's the trap: most teams "optimize" before they've learned anything.

They're running cost-cutting sprints in month six while still searching for product-market fit, trading speed for pennies they'll never recover.

Repatriate when variance collapses and you're running a utility, not a lab. Even aggressive repatriators retain 10-30% of workloads in public cloud for variable demand, geographic expansion, and experimentation.

Start with options. Consolidate only when you're certain.

The operator's field guide

One-liner test: If you'd bet your job on the forecast, buy it. If you wouldn't, rent it.

What you're really choosing

This isn't about servers. It's about worldview.

CapEx bets you're right. OpEx bets you'll adapt.

Every hour your team spends wrestling hardware procurement is an hour they're not improving the product. Every dollar locked in owned assets is a dollar you can't redirect when the market shifts. Netflix chose differently.

They paid the tax, got velocity, and grew from 8.4 million to 300+ million subscribers. The company that rented infrastructure beat every competitor that owned it.

The lesson isn't "always cloud forever." It's that flexibility compounds. You can optimize for cost once you've optimized for learning. Most teams do it backwards and die before they figure out what works.

James Carse wrote that finite players play to win, infinite players play to keep playing. OpEx keeps you playing. The agility tax is the price of staying in the game when the rules change.

And they always change.

Pay the tax. Keep moving.

⚙️ Hi {{first_name_tally|Operator}},

Shopping for vendors is like touring apartments. Fresh paint, staged furniture, a landlord who “totally values long-term relationships.”

Then you read the lease and realize the exit clause is written by a Bond villain.

I just lived the operator version of that (nice lobby, brutal fine print).

So we’re talking about vendors as landlords, why “partnership” is marketing, and the three tests I now run before I sign anything.

- Rameel  

^{_{PRESENTED BY ATTENTION}}
Free Guide on Increasing Sales

Deals moving too slow? Forecasts always off? The best sales teams don’t rely on luck—they master alignment, automation, and intelligent execution. This free guide shows you how.

Inside, you’ll get:

• A streamlined sales tech stack that eliminates friction

• KPI frameworks that improve accountability and forecasting

• Smarter lead scoring that goes beyond firmographics

• AI-powered tactics to personalize outreach and scale efficiency

High-performing teams don’t guess. They execute with precision.

Your Vendor Isn't a Partner. They're a Landlord.

January 5, 2024. Alaska Airlines Flight 1282, 16,000 feet above Portland.

A door plug blows off mid-flight.

The cabin depressurizes.

Everyone survives.

you’d never catch me poking my head out of an open airplane door

Two weeks later, Boeing's CEO stands in front of cameras and admits what the company had known for years: Spirit AeroSystems—the supplier Boeing spun off in 2005 to 'optimize' costs—had been shipping defective fuselages.

Four bolts were missing from the door plug. 

Not loose. Missing.

By July, Boeing paid $4.7 billion to buy Spirit back. Add the $12.5 billion spent propping Spirit up through years of quality failures, the $2 billion in waived claims, the $1 billion in assumed obligations. Nineteen years of efficiency gains, unwound.

Total bill: ~$23 billion.

Every vendor relationship starts the same way: competitive pricing, flexible terms, promises of collaboration.

"Strategic partnership" is the phrase they use.

What they mean is something else entirely—we're your landlord now, and the lease is already signed.

and they’ve come to collect, baby

You think you're entering a partnership, but you're signing a rental agreement where the terms favor the landlord, not you.

The pricing looks great until you try to leave, at which point you discover the "flexibility" evaporated after the first renewal and the "partnership" has become a dependency trap where switching costs more than staying.

Your vendor isn't your partner. They're your landlord. And the best operators know which leases are worth signing.

Three Types of Tenants

You're one of three tenant types in the vendor economy. The difference determines whether you keep leverage or lose it entirely.

The Smart Tenants rent commodities and maintain escape routes. Nike outsources 100% of manufacturing across 530 facilities in 40 countries. No single supplier can trap them. When quality slips or prices rise, they shift volume. The relationships are deep—90% of suppliers have been with Nike for 15+ years. The dependencies are shallow—no proprietary systems, no custom tooling they can't move.

The Trapped Tenants rent core capabilities and discover too late they can't leave. Boeing outsourced fuselages—the thing that literally holds the plane together. When quality collapsed, they had no alternatives. The switching cost wasn't a line item. It was ~$23 billion.

The Homeowners refuse to rent what matters. Tesla controls 80% of its supply chain—batteries, software, motors, even seats. When the 2020 chip shortage hit, Ford and GM idled factories for months waiting for suppliers. Tesla rewrote firmware for 19 different chip variants and grew production 68% year-over-year.

Homeowners pay more upfront. Tenants pay forever.

How Nike Reads the Lease

Nike doesn't own a single factory. Every shoe, every jersey comes from contractors. If that sounds reckless, you're thinking like Boeing.

Nike knows shoes aren't their edge. Brand is. Design is. Marketing is. Stitching leather to rubber though? That's commodity work any skilled worker can do.

So Nike spreads production: Vietnam (43%), China (28%), Indonesia (25%).

No single landlord gets leverage. When one raises prices, Nike shifts volume. When quality drops, Nike walks.

This is what operational control looks like: the ability to leave without your business collapsing.

Boeing couldn't leave Spirit without planes falling apart. Nike can leave any supplier by Tuesday.

The difference? Nike rents what's replaceable. Boeing rented what kills people if it breaks.

Tesla's $15 Billion Bet

While Boeing was discovering vendor partnerships are fiction, Tesla bet the opposite: own what matters.

The 2020 semiconductor shortage proved who actually had control. Every major automaker—Ford, GM, Toyota—shut down production. Their chip suppliers couldn't deliver, and they couldn't do anything but wait.

Tesla shipped 300,000+ vehicles in Q1 2022, up 68% year-over-year.

How? They controlled the software stack. When chips became scarce, Tesla's engineers rewrote firmware in weeks to work with whatever semiconductors they could find—19 different variants.

Ford couldn't rewrite firmware because they didn't own it. Their suppliers did. So Ford waited while factories sat empty.

Tesla's vertical integration looked expensive in 2019. By 2022, it delivered 15% cost reduction plus the flexibility to navigate supply shocks while competitors bled out.

That's the homeowner advantage: when the foundation cracks, you fix it. When the market shifts, you adapt. When everyone else waits for their landlord, you're already shipping.

The Three Tests Before You Sign

Before you sign that vendor contract, run three tests. Skip them and you might pay Boeing's price.

Test 1: What Kills You If It Breaks? Boeing outsourced fuselages. Fuselages determine if planes stay in the air. That's a core competency. Nike outsources stitching. Bad stitching means returns, not deaths. That's a commodity.

Ask: Does this create customer value I can defend? Does this determine whether my product works? Can competitors easily copy this?

If you answer yes to the first two, don't rent it.

Test 2: What's the Real Exit Cost? Not the termination fee—the real cost. Oracle made one company produce 233,089 pages of documentation during an audit just to understand what they owned. Every Salesforce customization is a sunk cost you leave behind. Every employee trained on SAP is knowledge that won't transfer.

Enterprise software migrations run $100,000 to $600,000+. ERP transitions cost 40-60% of the original implementation. Cloud migrations take 18-24 months minimum.

If switching costs exceed 40% of contract value, you're not renting. You're trapped.

Test 3: Can You Run an RFP Tomorrow? Could you credibly threaten to leave? Not theoretically—actually put out an RFP and get three real bids?

If one vendor is more than 25% of category spend, red flag. If you can't name three alternatives who could start Monday, you're already captured.

Boeing couldn't run an RFP for fuselages. No one else could build them at scale. That's how four missing bolts cost $23.8 billion.

Excellence Isn't Zero Vendors. It's Right-Sized Rentals You Can Defend.

Nike rents manufacturing and dominates. Tesla owns batteries and survived the chip shortage. Boeing rented fuselages and nearly killed 177 people.

The pattern isn't "outsourcing bad, ownership good." It's simpler: know what you're renting, know what it costs to leave, and never rent what makes you competitive.

Commodities with multiple suppliers and low switching costs? Rent those. Focus capital on what differentiates you.

Core competencies that determine if your product works? Own those. The efficiency gains aren't worth the leverage you lose.

Your vendor calls it partnership. The contract calls it something else. Every lease starts with promises of flexibility and collaboration. Every lease ends with you discovering the exit costs.

Boeing thought they were optimizing costs. They were actually selling their house to rent it back from a landlord who wouldn't fix the roof.

Four missing bolts. $23 billion.

That's your rent when you outsource what matters.

⚙️ Hi {{first_name_tally|Operator}},

Confession: your inbox probably sucks. Mine too. It runs your day, interrupts your focus, and still somehow lets the important stuff slip through. Well… I wanna learn more.

This week I’ve been hopping on short discovery calls with people from the waitlist. We’ve already got a few lined up this week, and I just want one more person to round it out.

It’s 30 minutes, we’ll talk about how you handle email today, and I’ll show you what we’re building to see if it actually helps.

We’re only running these calls this week. First come, first served.

Book a time here: Calendly Link

- Rameel  

^{_{PRESENTED BY HUBSPOT}}
Discover your next AI-powered teammate on the HubSpot Marketplace

Personalized recommendations and seamless integrations help you build a connected tech stack that transforms your team's potential.

Your perfect solution is waiting! Through intelligent recommendations, the HubSpot Marketplace makes it easy to find apps, services, all-new Breeze agents, and more.

Search by outcome, discover trending tools, and accelerate your growth on HubSpot.

The Accountability Architecture

My wife is designing a custom home, and she's obsessed. (I don’t know why cause we aren’t buying a new home anytime soon).

She sends me YouTube videos constantly—mostly about finishes and layouts I'll never remember. But one video stuck.

It was about staircase design mistakes. 

s/o to this legend

The guy rattled off five blunders: ignoring building codes, inconsistent riser heights, poor lighting, slippery materials, wasted space underneath. I was halfway tuned out until he said this:

I didn't realize how many guidelines went into stairs—riser height, tread depth, handrail strength, ballister spacing. But it makes sense. By baking rules into the system, you encourage safe behavior without thinking about it.

The geometry does the work. You don't need signs that say "walk carefully." You design stairs people can't fall down.

Remote companies assume people will fail without constant watching.

Instead of building systems that force good behavior, they built systems that watch for failure. Seventy-eight percent now monitor keystrokes, screenshots, and activity logs—spending $240 per employee per year to prove they don't trust their own teams. 

Building better stairs starts with better hiring. 

The Forcing Function: Automattic's 30-Day Trial

Matt Mullenweg doesn't interview candidates. He tests them.

Automattic (the company behind WordPress.com) runs every hire through a 30-day paid trial where you're assigned real work—production code, actual projects, live collaboration—and judged on one metric: did you ship?

No one checks your hours or monitors activity. Most don't make it through. Some can't handle async communication. Others freeze without direct supervision. A few realize they need an office. But the ones who make it through? They stay. Automattic's regretted attrition sits under 5%, a third of the industry average.

The trial is the forcing function. This process filters for self-management before the first paycheck clears, which means the people who survive don't need surveillance—they've already proven they can handle autonomy.

The result for Matt is 2,000 people across 95 countries, no offices, no surveillance software, and attrition rates that make traditional HR departments question their entire retention playbook.

The hiring filter is the first forcing function. Get this wrong and everything downstream breaks. Get it right and surveillance becomes unnecessary.

The 30-day trial sounds expensive. It's not—but that's not why companies avoid it.

The resistance comes from inertia and fear dressed up as pragmatism.

1. CFOs balk at paying someone $15K before they've proven themselves.

2. HR worries about IP leaks and NDAs.

3. Hiring managers complain that their process is already too slow, and this will just make it worse.

All three objections miss the point.

A bad hire costs 1–2x their annual salary when you account for recruiting, onboarding, lost productivity, and team disruption. At $180K comp, one bad hire runs you $180K–$360K. The trial costs $15K—less than a tenth of the downside. And if cash flow is the concern, structure it as deferred compensation.

Pay a reduced rate during the trial, then true-up to full salary once they convert. The best candidates don't blink at this because they know they'll ship.

The IP concern is even easier to solve. Scope the trial carefully. Give candidates real work, but not your most sensitive codebase or strategic roadmap. Automattic assigns production work to trial candidates without handing them the keys to everything.

A sandbox environment or lower-risk project still tests their core skills. And here's the thing: if you can't trust someone with real work for 30 days, you can't trust them full-time. The trial surfaces this risk early instead of six months in when they've already seen everything.

The speed objection reveals the real problem. Your hiring process is slow because you're doing 4–6 interview rounds trying to predict performance through conversation. The trial replaces prediction with observation.

You'll know in 30 days whether someone can ship, collaborate async, and self-manage—information that no amount of behavioral interviews can give you.

Automattic's trial might add calendar time, but it collapses decision time. Did they ship or didn't they? The answer is yes or no.

The companies that avoid the trial aren't protecting their business. They're protecting a broken hiring process that optimizes for credential signaling over actual performance. The trial exposes that.

How to Implement This at Your Company

Step 1: Pick One Role (Maybe Engineering?)

Choose a role where output is measurable and the work can be scoped into a 30-day project. Engineering, design, and writing roles work well. Sales or customer success roles are trickier but not impossible—you can have candidates shadow calls, draft proposals, or run mock demos.

Step 2: Design a Real Project, Not a Test

The project needs to be:

• Real: Actual production work, not a take-home exercise

• Scoped: Completable in 30 days without heroics

• Measurable: Clear definition of "shipped" (code merged, design approved, content published)

Bad example: "Help us build a new feature." Good example: "Fix these three bugs in our codebase and ship one small UI improvement."

The project should require collaboration with the team (Slack, standups, code reviews) so you can assess async communication and cultural fit alongside technical ability.

Step 3: Set Expectations Up Front

Be clear: this isn't an extended interview where you're looking for reasons to say no. It's a mutual test—they're evaluating you as much as you're evaluating them.

Set expectations:

• What project they'll work on

• What "success" looks like

• Who they'll collaborate with

• How decisions get made at the end of the 30 days

Automattic is explicit: if you ship, you're in. If you don't, you're paid for your time. Move on.

Step 4: Track Conversion and Retention

Track two metrics:

1. Conversion rate: What percentage of trial candidates convert to full-time hires?

2. Retention rate: What percentage of converted hires are still with you after 12 months?

If your conversion rate is above 80%, you're not filtering hard enough. If it's below 50%, your trial project might be poorly scoped or you're screening the wrong candidates upfront.

If your 12-month retention rate for trial hires is significantly higher than your retention rate for traditional hires, the trial is working.

The Real Cost of Surveillance

Surveillance doesn't just cost money, but trust.

The best people leave first. They're the ones with options, and they won't stay at a company that treats them like children. The ones who stay learn to game the metrics like: 

• Move their mouse every few minutes 

• Schedule fake meetings 

• Open tabs they never read.

You end up measuring activity instead of output. And activity is the wrong proxy.

The 30-day trial solves this at the root. If someone can't self-manage for 30 days, they won't self-manage for 30 months. If they need surveillance to stay productive, they shouldn't be hired. The trial surfaces this before you've invested in onboarding, benefits, and team integration.

Automattic doesn't need surveillance software because they filtered for people who don't need it. That's the forcing function. That's the architecture.

The companies that stopped watching their teams didn't stop caring. They started hiring better. They built systems that made surveillance unnecessary—not by monitoring harder, but by testing smarter.

Surveillance doesn't scale. Hiring does.

Design better stairs. Start with who gets to climb them.