Your startup isn’t slow. It’s blind.

Before I argue anything, review a pull request with me.

A teammate renamed user_items to digest_items in the weekly-email module. Your job is the usual one. Confirm the rename is complete. There are six occurrences of the old name, so check every one. Take it as seriously as you would at work, because there’s a question at the end.

  def send_weekly_digest(user, stories):
-     user_items = []
+     digest_items = []
      for story in stories:
-         user_items.append(render_card(story))
+         digest_items.append(render_card(story))
      if user.language != "en":
-         user_items = translate(user_items, user.language)
+         digest_items = translate(digest_items, user.language)
-     if user.unsubscribed:
-         return None
      subject = pick_subject(stories)
-     mailer.queue(user.email, subject, user_items)
+     mailer.queue(user.email, subject, digest_items)
      audit_log.record(user.id, subject)
-     return DigestReceipt(user_items)
+     return DigestReceipt(digest_items)

-     if user.unsubscribed:
-         return None

In 1999, Daniel Simons and Christopher Chabris asked people to watch a video of two teams passing basketballs and count the passes made by the team in white. Halfway through, a person in a gorilla suit walks into the middle of the frame, thumps their chest, and walks off. It’s on screen for nine seconds. About half the viewers never see it.¹ The follow-up is the one that should worry engineers. In 2013, Trafton Drew and colleagues embedded a gorilla into CT scans, about 48 times the size of a typical lung nodule, and asked 24 expert radiologists to hunt for nodules. Twenty of the 24 never saw it. Eye-tracking showed that most of the radiologists who missed it looked directly at it.²

Two details make this finding hard to shrug off:

1. Expertise doesn’t protect you. These were trained specialists doing the inspection they do every day. Their training didn’t widen what they saw. It tightened the template they searched with, so anything off the template had less chance to register.
2. Misses aren’t laziness. The eye-tracking data rules out the comforting story that people miss things because they didn’t look. You can point your eyes at the bug and still not see the bug.

# worker liveness check — restarts stuck workers
RECENT = timedelta(minutes=10)

def health_check(worker):
    last = worker.last_completed_activity()
    if now() - last > RECENT:
        worker.kill()  # assume stuck, force restart
    
# NOTE: nightly reconciliation activities legitimately
# run 2–6 hours with no intermediate completions.
# They will look "stuck" to any 10-minute heuristic.

Now describe a startup engineer’s day in these terms: a high-load primary task (ship the feature), time pressure, constant context switching, and a strong prior about what the code is supposed to do. A sprint is a selective-attention test that runs eight hours a day. The gorilla is whatever your task template doesn’t match.

I’ve seen the same failure again and again over the past decade, at Orai, at CopyCat and on teams I’ve compared notes with, long before AI started writing the code. The files below are composites. Every mechanism is real, but I changed the details so none of them trace back to one company.

None of these came from incompetence. In every one, an attention system ran exactly as designed and pointed at the wrong thing. Before you open each verdict, ask yourself who was positioned to see this one coming?

Every verdict names one of two people. A technical peer is a second engineer who reads your diff and asks what else it changes. A standard holder owns what “done” and “correct” mean for the work, and they’re usually not an engineer. A PM, an ops lead or a finance owner judges the result, never the code.

I could keep going. A backfill burned a whole third-party API quota in one run. A CopyCat build server filled its disk and died on the morning of an investor call. An Orai feature sat dead for months until a customer emailed us. Once you have the lens, you stop seeing bad luck and start seeing one mechanism.

Seniority doesn’t protect you either. In one of these files, a founder waved off a teammate’s warning about a crash-causing null, because they were heads-down on a migration. The crash came the next morning. Senior people carry more load, and more load makes you blinder.

Sort every case file above, and every escaped defect you’ve root-caused, and each one rides one of two channels.

Channel 1: the code drifts from your intent. You can’t proofread your own change, because you read what you meant instead of what you wrote. Copywriters solved this with a copy chief, and a code reviewer is yours. The deleted unsubscribe guard in the demo above rode this channel. So did a settings update that was meant to add euro prices and also wiped a customer’s discounts.

Channel 2: your intent drifts from reality. You built your reading of the request on assumptions about the need, the data, the vendors and the customer’s setup. Each assumption drifts a little with every decision you make alone. Code review can’t catch this, because the code is correct. It’s just correctly wrong. A careful billing fix that rewrote invoices finance had already closed rode this channel. So did a “sync bug” that turned out to be the customer’s own second tool writing the same records.

You could split these further, into data drift, vendor drift, untested paths and a dozen more. Every split still comes down to one of two questions. Does the code do what I meant? Is what I meant still true out there? A second engineer can answer the first by reading the diff. The second needs someone who lives outside the code.

One person can’t watch both channels, because watching spends the same attention that writing the code does. The better you are at the work, the less is left over.

Postmortems file these incidents under quality. The bigger cost is speed.

At Orai we once switched speech-to-text vendors, and the new one didn’t send punctuation. Our app used punctuation to measure sentence length, so it started telling every user their sentences were too long. The fix was one missing field and a few hours of work. The cost was the weeks around it. We answered angry app-store reviews, cleared the support queue, and won back users we’d told to shorten sentences that were fine. All of that work arrived as interruptions, so the roadmap stalled while the team was busier than ever. Busier people carry more load, and more load is how the next miss ships. That’s the loop in the diagram.

Nobody tickets this work. No one files a ticket for calming an angry reviewer or winning back a user, so it never shows up in a sprint, a velocity chart or a postmortem. At a startup it lands on whoever is closest. With no support team to absorb it, that’s usually an engineer or a founder, and the roadmap pays for it without anyone seeing the bill.

The case files follow the same pattern. Three out of four took a day or two to fix once someone looked. What cost months was the stretch before anyone did.

Boehm and Basili put avoidable rework at 40–50% of the effort on a typical software project.⁶ Raytheon measured its own. Rework was eating about 40% of total project cost, so the company built an improvement push around inspections, where a second reader checks each design and change. Rework fell to about 20%.⁹ On a ten-person team, that’s the difference between four people redoing work and two.

Early-stage teams pay the most, because the habits that make them fast are the same ones that raise the load. Each system has one owner, so nobody looks twice. Everyone switches context all day. The Friday demo points every pair of eyes at the same screen. And the company is too young to remember the last time this happened.

A developer does their best work inside a triangle. A technical peer checks that the code does what the developer meant. A standard holder checks that what they meant is still what’s needed. The developer builds.

The technical peer doesn’t ask whether the code is good. They ask what does this change do that you didn’t intend? They bring attention you’ve already spent. In the demo at the top, they’re the one who spots the deleted unsubscribe check while you count renames. Inspection research has found the same thing for fifty years. A second reader catches defects the author can’t, because the author reads their own intent.⁵ Reviewers have a budget too. In Cisco’s study of 2,500 reviews, reviewers who went faster than about 400 lines an hour found far fewer defects.⁵ At one company I’ve watched, an engineer publicly called the team’s best reviewer “the single largest multiplier to my personal productivity.”

Worried a second reviewer slows you down? In the radiology study, every radiologist who spotted the gorilla also found the nodule on that same slice.² Noticing the odd thing didn’t cost them the main job. It only costs you when one person under load has to do both. A reviewer of this draft asked how much slower a second pair of eyes makes things. The study didn’t time it, but the review data above says the slower pace is what makes reviews work.

The standard holder is usually a PM, an ops lead, a domain expert or a founder. They never read the diff, and that’s why they help. They look at the invoice instead of the code that makes it, so a wrong total jumps out at them that an engineer would scroll past. They ask is this the thing we needed?, and they ask it early and often. They also decide whose definition of correct wins when two teams disagree. When engineering recalculated invoices that finance had already closed, one question to finance would have stopped it.

This is also the engineering case for diverse teams. People who trained the same way share a template, so they miss the same things. The twenty radiologists didn’t miss twenty different things. They all missed the same gorilla. Facial analysis gave the most public example. In 2018, commercial systems misclassified darker-skinned women up to 34.7% of the time and lighter-skinned men less than 1% of the time. Their benchmarks were roughly four-fifths lighter-skinned faces, and the teams that built and tested them didn’t notice. Joy Buolamwini, an MIT grad student the systems kept failing on, did.⁸ A team that all looks, trains and thinks alike is one attention system with extra keyboards.

None of this means “add process.” It’s two working relationships. It also matches one of the oldest findings in software engineering. A problem found after delivery can cost 100 times more to fix than one caught in requirements or design.⁶ The triangle moves the catch earlier. Talent doesn’t fix attention. Coverage does.

As the company grows, the triangle’s conversations should start leaving documents behind. The standard holder’s idea of done becomes a PRD. The peer’s review moves before the code, into an RFC. Settled decisions go into ADRs, so the next engineer knows why the system looks the way it does. That’s process, but it grows out of the triangle. It doesn’t replace it.

What it looks like when it works

The triangle doesn’t need a reorg, because it’s a rotation, not a hire. People swap corners by problem, not by title. At Orai I was the standard holder as COO on some problems and the technical peer on others, and our CEO or CTO took whichever corner I wasn’t in. Here are nine casts that actually ran.

Orai spent a year and a half shipping constantly with flat metrics. Then, during Techstars, a designer, a developer and a founder started meeting every week about one screen, the first lesson a new user sees. In about three months, completion of that lesson went from roughly 10% to 95%. Our archives back the starting number, not the peak, so 95% is my best reconstruction. None of the changes involved speech technology. We added a banner telling people to hit record, cut text, swapped a static walkthrough for an animated one, and put “redo this lesson” and “next lesson” where a thumb lands. The gamified loop we added was the developer’s idea, not the designer’s. The team and its hours didn’t change. The loop did.

CopyCat followed the same shape. For a year our production model sat stale while everyone worked hard on everything else. A manual audit in late 2022 put component-detection accuracy between 29% and 75%, depending on element type. Our performance marketer ran the structured tests, because fresh eyes don’t need the right job title, and ML engineers fixed what he found. Progress stalled at 75%, and someone reasonably asked, “it’s good enough, no?” It wasn’t. Below about 95%, every missed component became broken code in everything generated on top of it. I held the standard, showed the team exactly that, and kept the bar where it was. The developer’s skill closed the gap, from 75% to roughly 95%. Users called the result “a different league” and said false positives were “near absent.” It took about three months with the loop, after a year without one.

Here’s a smaller one, from a company I’ll keep anonymous. A new engineer spent their second day sitting with the ops team, listening to them complain about one screen. They fixed it on days three and four. On day five, the ops lead found the fix live in the middle of a demo. That team later called a bigger rebuild of the console a game-changer, and their daily use of it shaped what got built next. When the team worked the same way with customers, one of them wrote in unprompted: “oh wow — that is easy.”

In both companies, the same people worked the same hours through the flat stretch and the fast one. Effort never changed. Structure did.

The sharpest response to a draft of this essay came from an engineer I trust.

He argued that the problem is bigger than any team’s attention, and that mature industries stopped relying on attention long ago. Your car diagnoses itself over a bus protocol. Manufacturing didn’t fix human error by hiring more careful people. It built jidoka, andon cords and pointing-and-calling. Today I pay attention, tomorrow I don’t. In his words, the structure I’m proposing is “a sliver along a mountain of automations that is required.”

He’s right, case by case. An acceptance test would have caught the settings update that wiped a customer’s discounts. An alert on missing data would have caught the pipeline that ingested nothing for six weeks. A linter would have flagged the trailing space in the plan name. The newer tools go further. Mutation testing shows which tests would still pass if the code broke. Formal methods like TLA+ and Lean prove a property holds for every input, not just the ones you tried. AI reviewers read every diff and don’t get tired at 5 p.m. Used well, these tools cut the thrash a lot.

But every one of them is crystallized attention. Someone chose the property to prove, the mutants worth killing, the linter’s rules and what the AI reviewer should look for. The tools sharpen our precision. They don’t decide where to aim it, or what correct means this quarter. Before product–market fit that definition keeps moving, and a test written against last month’s definition will happily pass this month’s wrong code.

That’s the triangle’s job. After each miss, ask what you were staring at and who was positioned to see it. Every answer that ends in “a machine could watch this” becomes this sprint’s test, alert or proof. The triangle isn’t the alternative to the automation mountain. It’s the quarry. Pointing-and-calling was a human ritual before it was a system, and the ritual is how anyone learned what to automate.

It isn’t slow, either. The fastest delivery I’ve watched recently was a cross-cutting migration everyone had put off for months. Two developers built it, a reviewer who knew where the risky code lived checked it, and the business side held the deadline. It shipped in nine working days instead of a month.

My reviewer would point you to Karl Popper here. A test is a hypothesis you try to break, and the hardest question in engineering is “what should be true for this to fail?” We skip it for the same reason we miss the gorilla. We’re blind to our blindness.

Stephen Bungay’s The Art of Action explains why alignment slips, using the Prussian army’s answer to battlefield chaos.¹⁰ Every plan runs into three gaps. The knowledge gap sits between what you’d like to know and what you actually know. The alignment gap sits between what you want people to do and what they actually do. The effects gap sits between what you expect an action to achieve and what it achieves. The usual response is more detail, more instructions and more control, and Bungay shows that it makes the gaps worse. What works is stating the intent, having the people doing the work explain back how they’ll meet it, which he calls a backbrief, and adjusting as results come in.

The triangle runs on the same idea, and it only works if its three people talk often. Alignment decays under load like everything else, so one kickoff meeting doesn’t hold. Here’s the rhythm for a small software team, with the gap each habit closes.

The gap labels follow Bungay’s three gaps.¹⁰

Each of these takes minutes. A wrong turn caught in a demo costs a conversation. The same wrong turn caught by a customer costs an incident, plus the weeks of unticketed cleanup that come after it. Relentless doesn’t mean intense. It means frequent, the way a helmsman makes small corrections all the time instead of one big one at the end.

Focus doesn’t cure inattentional blindness. Focus causes it. Effort and care draw on the same budget, and seniority only spends it more efficiently on the main task. The fix that survives a real sprint is structural. Put more than one attention system on the work, point each at a different question, and re-sync them often.

In practice that’s one developer, a technical peer who asks whether the code does what was meant, and a standard holder who asks whether what was meant is still what’s needed. Measured against the weeks of rework it prevents, it’s the fastest setup I’ve seen in ten years of startups.

The gorilla is already in your codebase. It’s in mine. The question is whether anyone on your team is positioned to see it, or whether your customers are doing that job for you.

If this matches your experience, or you have a counterexample, I want to hear it.