Backstory

This past week I’ve been re-reading Critical Chain, the Eliyahu Goldratt book that extended his work on theory of constraints (TOC) thinking systems. His daughter published the excellent sort of sequel Goldratt’s Rules of Flow - which took the same material (how to dramatically better manage projects) and simplified it. While incorporating the last two decades or so of thinking on Critical Chain Project Management (CCPM). I’ve read and reread Rules of Flow several times since its release. But it was 8-10 years since I reread Critical Chain. Having found myself in a business that did projects to specific time targets I suspected it was worth a refreshing of my understanding.

I’m so glad I went back to the source material. With a decade more experience with engineering projects in general and thinking about the importance of focusing on the key constraints of problems I got a lot more out of it.

I kept thinking how much unnecessary pain and suffering existed in the world just because these methods aren’t the default. Leaving many companies pushing people past the brink while still missing dates and complaining about throughout. Only to have each project feel like an episode of Gilligan’s Island (or Groundhog Day, or whatever expression Gen Z uses).

How could I get better at explaining these surprisingly simple but counterintuitive ideas to people? Then it hit me - Gen X can explain step by step how a bill becomes a law 40+ years after learning. More accurately they can sing the steps. Thus lightning bolt - FULL KIT ROCK - they key points of CCPM sung in the tradition of Schoolhouse Rock. Or as close as I can get current AI tools to get with no real effort on my part to learn how to get the sound vibes right.

Ok, maybe my nerdcore album from punk/country/metal band Normalization of Deviance put the idea in my mind. But whatever dude - you’re complaining about a succinct lesson in an incredibly powerful set of tools AND catchy songs to remember them?

that’s better … and again, YOU’RE WELCOME!

https://normalizationofdeviance.band/albums/full-kit-rock/

Don’t worry, if you’re not digging this theme I promise it will be a while until I do any more songs. I’ve got other non-musical ideas to share first

Subscribe now

Masters of Flow

Want to take your projects to the next level? Want to listen to a catchy tune?

Like the Reese’s Peanut Butter Cups of getting stuff done, these things go together better than I expected. While I’m not going to lie and say I didn’t get some serious help from AI, it’s still pretty great to see some important ideas distilled down into short songs. Every one hand inspected and tuned by an actual human.

Thus Full Kit Rock was born: ten songs (plus a bonus track) designed to capture the essentials of Critical Chain Project Management (CCPM) and Goldratt’s Rules of Flow in plain language and catchy hooks. Plus a bonus track on building vision and alignment via questions (instead of telling). This album goes to 11, literally!

Below you’ll find a short primer on Critical Chain and the Rules of Flow, a link to one of my favourite chapters from Critical Chain, and a track‑by‑track tour of the album. My hope is that this serves both as an accessible introduction to Theory of Constraints and as an invitation to sing along while you rethink how projects get done.

Why Critical Chain and the Rules of Flow?

Goldratt’s core insight is simple: organisations are like chains. The overall strength of a chain is determined by its weakest link. Strengthening a link that isn’t the weak one does nothing to strengthen the chain ; if your QA team is over capacity, throwing more developers at the sprint only piles work up in front of the bottleneck. Goldratt argues that improvement efforts must focus on the constraint - the weakest link. That’s where global performance can actually improve.

In Critical Chain, Goldratt applies this thinking to project management. Traditional schedules pad every task with extra time, creating a false sense of safety. This hidden contingency enables Student Syndrome (we don’t start until halfway through the available time) and Parkinson’s Law (work expands to fill the available time). CCPM solves this by stripping safety from individual tasks and aggregating it into shared buffers. Instead of asking “Are you on schedule?”, we ask “How much of the buffer have we burned versus how much of the critical chain have we completed?” Critical chain includes the traditional “critical path” as well as other key issues to success such as bottlenecks with expert people or teams.

Goldratt’s Rules of Flow pushes the theory further into modern engineering, IT and service organisations. It summarises eight pragmatic rules - avoid bad multitasking, verify full kit, triage work, synchronize resources, increase the dosage for recurring problems, avoid unnecessary rework, standardize where improvisation is costly, and abolish local optima. Taken together, these rules form a simplified operating system for throughput‑driven projects.

Key Concepts in Critical Chain and Rules of Flow

Here’s a quick run‑down of some of the mechanics that show up again and again:

• Identify the constraint. In any project there is a resource, skill or policy that limits throughput. Find it and elevate it; strengthening non‑constraints won’t strengthen the chain .

• Student Syndrome and Parkinson’s Law. When we pad every task, people procrastinate and polish. Student Syndrome refers to waiting to start until the last possible moment, while Parkinson’s Law notes that work expands to fill the allotted time .

• Aggregated buffers. Instead of hiding safety in each task, CCPM pools that contingency into a project buffer. A single aggregated buffer reduces the total time you need and prevents local padding from delaying the whole project .

• Remaining‑duration reporting. Rather than asking “What percentage complete are you?”, CCPM emphasises remaining duration and buffer burn. Percent complete is notoriously misleading-90 % done can stay 90 % forever .

• Feed buffers and fever charts. Feed buffers protect the critical chain from delays in noncritical workstreams . Fever charts plot buffer consumption against critical‑chain completion to provide a visual early‑warning system .

• No multitasking on the critical chain. CCPM advocates strict discipline: when you’re working on a critical‑chain activity, you don’t pick up another task at the same time .

Want to dive deeper?

Before we get to the album, you might enjoy this excerpt from Critical Chain. It’s from Chapter 11 and lays out why managers must focus on the weakest link and how local improvements often leave overall performance unchanged . The excerpt is a fun, novelised discussion between professors and industry guests, and it hits on the need to identify the constraint before trying to fix everything at once .

➡️ Read the excerpt (free on the publisher’s site).

Introducing Full Kit Rock

Below is a track‑by‑track tour. The titles are deliberately blunt - my inner Ramone (and my AI writing partner) tried for clarity over cleverness.

The Whole Is the Goal (The Whole Damn System)

We open with the big idea: the goal isn’t for your team to finish faster or for your department to look good. It’s for the entire system to deliver more. Local optimisations don’t strengthen the chain . The chorus nails it: “The whole is the goal / the whole damn system.”

Stop Starting, Start Finishing

Too much work‑in‑progress kills flow. Four people running eight sprint tickets at once means nothing actually ships. This song argues for controlling WIP and focusing on finishing before you start something else.

Fix the Blocker, Not the Noise

When everything is urgent, how do you decide what to do first? Triage isn’t about volume or politics; it’s about picking the work that unblocks flow. This track is a reminder to address the real constraint instead of the loudest complaint.

Full Kit First (Show Me the Full Kit)

Ever started a DIY project and realised halfway through that you’re missing parts? That’s life without a full kit. This tune calls for a pre‑flight checklist: names, decisions, specs, test environment—everything you need before starting so you don’t stall mid‑task.

No More Secret Safety

Padding every task with extra time doesn’t make projects safer; it invites procrastination and polishing . This song explains why hidden safety gets eaten and how pooled buffers fix the problem .

Your Schedule Is Lying (Build the Real Chain)

A traditional Gantt chart ignores resource availability. It assumes the same person can be in three places at once. This track teaches how to build the critical chain by counting scarce resources and dependencies - no fantasy scheduling.

Percent Complete Is a Lie (Show Me the Buffer)

You’ve heard “we’re 90 % done” too many times. This song argues for using the buffer burn and remaining duration to track progress. Percent complete is for suckers; fever charts are your friend.

Don’t Break the Relay

Once the critical chain is in motion, it should move like a relay race: start when the baton arrives, finish without delay, and hand it off cleanly. The song emphasises resource buffers and synchronising work so finished tasks don’t sit waiting .

Increase the Dosage

Ever fix a problem only to have it return like a villain in a horror movie? Sometimes the remedy is too weak. This track encourages you to increase the dosage - give the issue more time, more expertise, or a stronger gate - if it keeps coming back.

Stop Paying Twice

Rework is work going backwards. When requirements change after coding or tests are written after bugs, you’re paying twice. This song calls for standardising the repetitive traps while leaving room for judgment where it creates value.

Bonus: Ask Until They See It

Goldratt’s novels rarely preach; they ask questions that guide characters to discover the answers. The bonus track honours that. Instead of lecturing people about constraints, ask them where the work is waiting, what happens when safety is hidden, or what one expert being on five projects does to a schedule. People defend processes you hand them; they fight for conclusions they discover .

One More Thing…

If the idea of learning project management through song makes you smile - please share this with others. I’m proud to give Goldratt’s ideas the driving urgent rock backbeat they deserve. And if you pick up the Critical Chain Book and recognize yourself in its characters, drop me a note in the comments. After all, the goal of this random walk through tech (and project management) is to make your journey a little less random.

Share

Below is an excerpt from the last page of Goldratt’s Rules of Flow. Itself worth the price of admission to the book

“When it comes down to it, the problems are usually all the same.” - paraphrasing the coffee chat wisdom of Tim Prouty

Doing serious work and minding my own business when suddenly I got a silly idea

As an engineer I love learning from failure. Post-mortems, pre-mortems, COE’s - I dig it all. Conditions just conspire against us in a clear “the universe laughs at our plans” sort of way. Trying to outwit it is both a fools errand, and incredibly important. There’s a reason that one of my first posts was about the Galactic Empire’s single point of failure in Death Star (all of them). Being wrong quickly, not being wrong, etc. are all good mantras.

This is a long way of saying that I pause from time to note antipatterns that may be swirling around me. If you’re not familiar with the term it’s often described as “a commonly used, superficially appealing solution to a recurring problem that is actually ineffective, counterproductive, and leads to long-term technical debt." Or put in simpler terms - a way of doing things that makes sense, is thus commonly used, and is usually wrong. They’re easy to fall into without noting, so I occasionally try to think mindfully about them (and other inherent assumptions).

This is the “fun,” nerdy activity I was engaged in yesterday. Analyzing what I thought was jamming up some work. Jotting down bullet pointed notes in an open file. Wondering “I think this would be valuable discuss with others - what’s the best way to land a productive discussion?” I’ve noticed that outside of Amazon, sadly no one wants to read a doc at times, or listen to a presentation. Hence, trying to be more intentional to meet others where they are.

I was stuck, and totally not browsing the internet. Then it hit me. How about a “listicle”!? For some reason I hadn’t seen one of those in a while. Seemed worth a shot - “top antipatterns that drive work to get bad.” Maybe not the snappiest slogan - but I figured we’d “clean it up in post.”

Subscribe now

Next steps - My process

What followed is a blur. Next thing you know I quickly passed through the stages of creativity that I’m sure we’ll all recognize - make a list, get distracted, adapt it to align with a shallow nod to pop culture concepts, and write produce a 7 song album in an afternoon.

No - that’s not how you roll? Well - my mother always has said I’m different.

Here’s a look into my mental steps yesterday afternoon. I offer this as explanation - not as a suggestion for your own workflow. Though the first few steps seemed solid. It’s only later on it went off the rails a bit. Or was awesome! Determining which is left as an exercise for the reader.

1. Origin point: I thought I could see through the matrix to define set of things worth calling out as areas to improve (on a particular workstream I’m engaging with). As previously established I’m an engineer who loves learning from failure. Finding talking about it, during pre-mortems, post-mortems, and sometimes at cocktail parties, to be of great fun and value.

2. I wrote stuff down in a list. Thought about drafting a narrative around it.

3. Then I thought about whether anyone in environments outside of Amazon would listen to someone complain about stuff in a well reasoned doc? Nope - not bloody likely.

4. How about a presentation? Nope.

5. After some tears about this, and pouring out a cup in honor of the unread docs of OP1 future I decided to get real. Listicles! If it was good enough to build the unassailable Buzzfeed empire1, then why not here?

6. Thus was born a list of common antipatterns sins that cause work and teams to not meet their full potential. Seven important … maybe let’s call them sins. Even deadly ones.

7. On the first list I made was the serious entry “normalization of deviance.” A turn of phrase with grounding in safety culture. The challenger disaster often gets mentioned in the same breath.

8. As I finished the list I started wondering “that would be an awesome name for a metal band” and “how many bands exist with that cool name?”

9. After some important research I had a new, even more important question “do I really want to live in a world without a nerdcore band called ’Normalization of Deviance’?”

10. Then I got distracted and decided I should re-write the list of antipatterns to be labeled as commonly viewed Judeo-Christian “sins.” That was quickly abandoned (largely because it was too hard) and replaced with the easier problem of giving all the anti-patterns names that could be mistaken (if you squint) for Metallica song titles.

11. After basking in the glow of success, I went back and decided to fix the problem of #9 in this list. You’re welcome.

A shockingly short time later I released my AI first nerdcore2 pop/punk3 album “Sins against throughput” based on this list. It’s wild living in the future. Also - I’m not actually joking. I hope you’ll checkout the whole album - free of charge ‘natch. 4

Technically it’s more a range of punk inspired styles - not just pop-punk. Musically perhaps not that inspired, but the lyrics still are reasonably sharp and make me laugh in a knowing way. I’ve included a couple later in the article.

Sins Against Throughput

Oh … you’re still here? Maybe some of you are here for the antipatterns and not moshing your way to geeky flow nirvana.

1. Tyranny of the Urgent: Consistently choosing the short term better over the long term. Long term is harder, but more valuable.

2. Vacuum of Intent: Lacking top-down alignment on the few things that need to be true in the future. Local and short-term decisions will fill the gap.

3. Fragility of the Few: A small number of subject matter experts limit progress. If work piles up in front of these bottlenecks it’s key to have a plan. This is true about all bottlenecks - but often especially ignored with people.

4. Normalization of deviance: Serious defects should trigger an andon cord full response. Focus should remain until truly resolved.

5. Communication complexity: A risk when many people need to talk to too many other people for many decisions.

6. Oral tradition. A risk if people taken when they should write. Knowledge stays in people instead of in shared systems.

7. Perpetual Triage: Managing via expediting instead of fixing underlying constraints.

I’m sure I didn’t get them all - seven is an arbitrary number, and they’re perhaps biased towards recent experiences. In other words, don’t worry - there are more. At least enough material for a second album.

Never write your second album without new fresh collaborators. Please drop your suggestions in the comments on throughput antipatterns. I’ll be sure to at least credit you in the future liner notes. Also - I’m thinking maybe country as the next genre. :-)

Subscribe now

Lyrical Sampling

Some folks aren’t going to click a link no matter how awesome (or stupid) the content on the other side might be. So I figure I’d drop one set of lyrics in.

No North Star (Vacuum of Intent)

[Intro]

Compass spins.

Signal gone.

Everybody local.

Nobody wrong.

[Verse 1]

Every team has a map of their hallway

Every hallway has a locked door

Every door has a metric on it

Nobody knows what the building’s for

We optimized the smallest square

Made it perfect, made it fair

Then wondered why the whole machine

Dragged its heart through gasoline

[Pre-Chorus]

In the vacuum of intent

Every local truth gets bent

When the future is not named

The nearest fire gets the flame

[Chorus]

No north star

No signal, no map

Every local win tightens the trap

No north star

No line through the dark

We built the maze and called it an arc

In the vacuum of intent

We pick a direction

And call it smart

[Verse 2]

Top-down silence, bottom-up noise

Everyone busy with clever toys

A thousand arrows, none aligned

All good answers, wrong design

What has to be true?

Nobody said

So the urgent came and made its bed

[Bridge]

Name the bet

Name the scar

Name the reason

Name the star

[Final Chorus]

No north star

No signal, no map

Every local win tightens the trap

No north star

No line through the dark

We built the maze and called it an arc

In the vacuum of intent

We pick a direction

And call it smart

Stop the Line (Normalization of Deviance)

Stop the Line (Normalization of Deviance)
[Intro]
Cord hanging.
Alarm blinking.
Everybody sees it.
Nobody’s saying.

[Verse 1]
We wrote the risk in lowercase
Then shipped it with a smiling face
The warning flashed, we called it fine
Another corpse beside the line

Missing spec and broken test
Everybody knows the rest
We made a scar into a style
Then called the damage versatile

[Chorus]
Stop the line
If it’s wrong, don’t make it rhyme
Stop the line
No more later, no more fine
Don’t bless the wound
And call it shipping
Pull the cord
The whole floor’s listening

[Verse 2]
First time failed, we called it rare
Second time, we learned to stare
Third time, someone made a chart
Fourth time, it became “just part”

Part of launch, part of cost
Part of what we always lost
Fifth time, nobody pulled the cord
Now the defect owns the floor

[Bridge]
Normalization of deviance
Is how the broken learns to stay
Normalization of deviance
Is how the warning fades away

[Breakdown]
Is it fixed?
No.
Is it owned?
No.
Is it safe?
No.
Then why go?

Stop.
The.
Line.

Pull.
The.
Cord.

[Final Chorus]
Stop the line
If it’s wrong, don’t make it rhyme
Stop the line
No more later, no more fine
Don’t bless the wound
And call it shipping
Pull the cord
The whole floor’s listening

PULL IT NOW!!!

New job, new people, new problems - same questions. I’ve realized once one stumbles upon a turn of phrase that gets to deeper thinking, past defensiveness, or surfaces important assumptions - then you keep using it.

I’m just jotting down a few I’ve found especially useful. Please share yours.

I was inspired by a colleague who retried a question I’d asked him earlier.

This inspired me to collect a few more and share below. Special thanks to Lisa Scheinkopf of TOC fame who turned me onto to the “assumption hacking” phrase.

Noting assumptions is a big deal. Once you notice how many conflicts or suboptimal solutions have their roots in implicit assumptions it’s hard to unsee. Making those assumptions explicit is an incredibly powerful tool for breakthrough thinking. As many assumptions on how we do things are rooted in reasonable past solutions that may no longer apply - making underlying assumptions visible is often a winning strategy. That like many of the questions below can seem like a Jedi mind expansion trick.

• What would have to be true to cut the time to do this in half? Even if it sounds ridiculous let’s just say it out loud.

• Instead of meeting serially about this problem, would we be better off if we all just worked on it together for 1-2 focused days? How about 2 hours?

• Would this project go faster if we asked ______ who to meet with first, and have them make a list of what they’d worry about going wrong?

• We can’t decide between these 3-5 very different approaches. Can we get in a room, and go through each one and all discuss what would have to be true for each to be the best idea?

• What if we asked the people who kept asking us to experiment (or pull data for them) what are the possibly differ t outcomes, and what they would do differently in each case?

• If you can only do one item from this large list of things which would you choose first? And how did you select that choice?

• What does the team do often, that takes a lot of time, which we could automate? Given how much time we would spend automate away the work, when do we break even on the investment?

• When would this get done if we had everyone work on it, even if some people wouldn’t be 100% busy?

• Yes, that team’s position seems crazy. What do you think could be true for them for that crazy position to make sense? What did they tell you when you asked?

That’s all for now. Though I’m sure something will come to mind as soon as I hit publish. Please do share your thoughts, tips, and tricks in the comments.

Subscribe now

After my last post of a custom GPT that brought some lessons from this Substack to your chat session I received this question from my friend Ram:

Does your GPT make funny movie references (heavily skewed towards the 80’s and 90’s) and have enjoyable footnotes? :)

We then moved on to joke about how you only get those with a paid engagement of my services, the LLM commodification of outputs, and somehow a joke that sounded funny at the time about how “those TDD folks and Karl Marx might turn out to right in the long term.”

But then I started wondering to myself … “are my media references really anchored in the 80’s and 90’s? Or just recency bias since the article I last wrote has an A-Team reference?”

Years ago I would have brushed it off, or maybe done some quick random sampling of past articles to inform an opinion1. But since this is 2026 and I wasn’t using my tokens to build anything last night I decided to outsource the work and let AI find out for me. I started with a basic query to ChatGPT, and then when it didn’t nail the answer out of the gate I turned it over to my “when you have an awesome shape shifting hammer everything is sort of achievable” tool and BFF - Claude Code.

Without intending to I kicked off a “research bake off” between two of the powerhouses of our time. While it wasn’t a fair fight, it still resulted in a fascinating allegorical microview of why you really need to lean into automating testing and evals if you want your agents to amount to something you can trust. Also, and perhaps more importantly the whole exercise reinforced the importance of running a post-mortem. Not just in your own projects - but also on your AI inputs. Both yield outsized results one should not ignore.

You can skip to the end to learn if I’m distributing my pop culture references equally in time. Though I suggest reading through to relive the roller coaster Ram and I went through trying to get a straight answer out of the systems. Plus a surprise learning (or reminder) about how incredibly useful the tool of the pre-mortem2 can be.

Subscribe now

The question

After I started wondering, but before figured out a better use of my time I dashed off this to ChatGPT

Someone recently complimented (I think) my substack - randomwalkthroughtech.com by saying I excelled at "funny movie references (heavily skewed towards the 80’s and 90’s)"

I'm actually curious how many movie and TV references I've used - the date of each film/show and the distribution of those by decade. Can you please review each of my articles here: https://www.randomwalkthroughtech.com/archive and do that analysis? Be careful to read everything, don't make assumptions, and be accurate.

I saw some initial wonkiness from ChatGPT around “trying to figure out the website content” even with providing a clear starting point with an archive link. That’s when I decided I should also let Claude Code do this. I’ve experienced ChatGPT be a bit lazy when it comes to following requests to fully crawl content.

What transpired next was what felt like a modern day Marx Brother’s sketch with a big of Abbot and Costello mixed in3. Each approach counted inaccurately, with the ChatGPT web interface being the worse. It’s not a totally fair comparison in the bringing a gun to a knife fight analogy sense. Yes, I was curious about perforamcne - but not curious enough apparently to let Codex at it.

Some of the many blind alleys one or both models drove into with stunning abandon

• Dramatic undercounts of the number of movie references. In both cases because it hadn’t actually read all the articles. This failing to understand the assignment was so common I feel it constitutes a “biological” imperative to skip over harder work when there’s an easier (albeit completely wrong) choice. Hard to fully fault LLM’s when we humans are so susceptible to substitution bias ourselves.

• Weird interpretations (mostly from ChatGPT) about what constituted a movie/TV reference and some confusion about how to group Wicked and “marvel universe movies” due to what decade they were in. This makes little sense in the case of Wicked, but actually is a solid point for Marvel - I mean those movies have been going roughly since the beginning of time and will outlive us all. I’ll put this mostly in the impractical overthinking sense of things.

• Assuming things were not shows when they were - I saw some “thinking dialog” flash by which had me suggest to both systems to check with IMDb if they weren’t sure (which explaining that Murderbot4 was a show on AppleTV)

• Low curiosity - high assumption index: When I noticed each of the AI’s came back with different counts of films I fed them each other’s lists, explaining the source. Both were surprisingly quick to throw shade. Or as I remarked to Ram during my Mystery Science Theater style narration:

  

• At some point after this Claude Code got to around 70 references over my 42 articles. But then it let something slip: "I may still be missing a few subtle ones buried in articles - the WebFetch tool summarizes rather than giving me raw text, so very oblique references could slip through." I didn’t initially think this was a big deal but after asking some more questions I pushed it to download all content and run analysis through the core Opus model and not whatever had been used to generally summary. This yielded another 12 or so film references.

• At the end after feeding back the results from Claude Code to ChatGPT, the latter model came up with 95 articles referenced, vs. the 93 Claude found. When I asked for the diff it confidently explained Snakes on a Plane and McGuyver. Yeah … turns out that if you know me you’d be forgiven for guessing I’d refer to those. But I actually hadn’t.5 This was just a plain old hallucination.

• I asked Claude to writeup a post-mortem of the event after sharing the ChatGPT logs with it. It did a solid job - including when I asked it to re-write in the style of an Amazon COE. 100% nailed the style of the COE, however it completely fabricated the timeline. Even after several attempts to get it to correct things it wistfully admitted “Fixed. And the irony of continuing to make exactly this kind of error while editing a document about exactly this kind of error is not lost on me.”

Hopefully, this should be one of many cautionary tales about no matter how much good experience you’ve had with Agentic tooling to make mechanisms of your extreme paranoia are good investments. Better prompting helps - In the long form postmortem of this “event”Claude Code explained what I should have done differently in my original prompt

"My Substack at randomwalkthroughtech.com has 42 published articles. Retrieve the full list from the sitemap at randomwalkthroughtech.com/sitemap.xml. For each article, fetch the raw text (not a summary) and extract every movie, TV show, and film reference - including indirect references, quotes, character names, and embedded media links. For each reference, record: the title, the article it appears in, and whether it's explicit or implied. Before presenting results, verify your article count matches 42. If it doesn't, stop and tell me."

Putting aside the whiff of victim blaming here - it’s a key observation. As a proper scientist I re-ran the suggested prompt from a cold context window. I also wondered if a “pre-mortem” prompt would have also helped (“before you start working analyze where you might botch this job and suggest a re-written prompt that would catch potential execution defects”).

Three takeaways from the beginning to this point are;

1. Always think through in advance how to confirm whether the results you’re seeing are legit. Whether you call this evals, tests, or something else - if you don’t have a way to check for goodness then you’re the QA team, or (worse) your downstream users are. If you’re using LLM based tooling for data analysis I’d be especially cautious on thinking this through - as at least code bombs visibly in some cases before you put it in front of the CEO or invest millions in it’s conclusions.

2. Just because it seems like a flexible, super smart human - it is important to think through how to make your prompt more specific (harden against likely failure - assume models like people may take the convenient vs. the correct route).

3. I do use a shit-ton of movie and TV references. Though they’re more evenly distributed than I realized.

If you already read this far, hopefully you learned something useful. Though, to quote something not from a movie (though from the 1980’s) … “You think this story's over, but it's ready to begin.”

Well F%$K ME!

After the post-mortem, I became curious and opened a clean context window for Claude Code, giving it the suggested prompt arising from the retrospective writeup.

Claude Code6 nailed it out of the gate - one shot hot hand success! Clearly the initial problem was between seat and keyboard. Not only did it actually find all the articles and analyze them, Claude Code spawned a set of parallel agents to crank at high speed.

It somehow came up with closer to 100 instead of 93. The overages appear to be in taking an expansive interpretation on things; Moby Dick as a film, something about Baby Shark7 (yuck!), Bloom County8, etc.

I’ll be honest - I’m not going back to fully compare the results from the one-shot to the back and forth session with Claude. Clearly, the one-shot corrected prompt is a much better engineered input which lead to a way better output. Therefore, I can accept some uncertainty in the specific counts.

Seriously think about how the prompt you’re about to toss off without much consideration could be misunderstood - ie; work concept #2 above hard. It would have saved me a lot of time. Also works for any human based project too. DO NOT skip the pre-mortem.

Which brings us to our final experiment …

The pre-mortem effect

After running the prompt the post-mortem suggested, I tried something else. I gave a clean context window my original prompt, but asked it to evaluate it proactively for areas of improvement before running. Claude Code came back with an updated prompt that looked a lot like the one the post-mortem at arrived at. Obviously, that’s a big deal because just asking “what could go wrong?” got things visually almost to the same point mucking around for an hour + a retro analysis got.

But the proof is in the results of mass token consumption pudding… So how did things turn out?

Darn close. It came in with a count of around 88, which is wildly better than the initially start and stop attempts. Still low, but close enough for a cigar. I asked a version of “are you sure?” and Claude went back and explained it had been conservative in the labeling - showed where and quickly things over 100. At that stage I realized there’s not a “true number” because lots of things have been made into niche cartoons over the years, and things I intended as literary references also had movies made based on them. Importantly, the distribution was roughly the same.

I’m sure if I’d pushed the “pre-mortem” discussion a bit more intentionally the results would have been even better. It also (randomly) produced one of the best comments to come out of the exercise

“Most reference-dense article: “Vibing on vibe coding” with ~17 distinct titles -- from Cocoon to Monty Python to Airwolf to 2001: A Space Odyssey. That article alone is a film studies syllabus.“

In summary: DO NOT SKIP THE PRE-MORTEM STEP OF WORKING THROUGH FAILURE CASES UP FRONT.

Sorry to shout - I feel strongly about this. :-)

The data you’ve all been waiting for

Because of the last minute twist introduced in the last session - this graph won’t 100% match the one at the start. But it’s as I like to say “directionally true.”

Ram wasn’t wrong, but some recency biases creeped in there slightly. To have Claude summarize things after it’s glorious victory lap with the re-written prompt:

The 1980s and 2010s are your peak decades. You’ve got a heavy 80s nostalgia streak (Cocoon, Buckaroo Banzai, Greatest American Hero, Airwolf, Road House, Footloose) alongside a strong modern action/genre pull (John Wick, Frozen, Prometheus, Sharknado, Rogue One). The 1990s cluster leans heavily indie/cult (Clerks, Mallrats, Chasing Amy, Grosse Pointe Blank, Usual Suspects).

Star Wars alone accounts for roughly 30 of the 176 individual instances9 — it’s the gravity well everything else orbits.

Funny - because I’m very much not a “Star Wars” guy. At least I thought I wasn’t. If anyone is curious I’m going to drop the full list of films in the comments later on10.

Share

Subscribe now

The slightly longer list of things “we” learned

Claude Code really, really wanted to help write this article. I felt after so much hard work I should let them participate. We’ve also been working on writing without sounding like an LLM that just wants to point out that “it’s not ____, it’s _____”, explain their “honest take” and engage in endless pointless meta-commentary. Claude did a solid job here in avoiding those things and even threw in a $5 word I had to look up (epistemic). So here is Claude’s summary of “10 things I learned” doing this mini-project.

1. AI tools will confidently analyze incomplete data without telling you it’s incomplete. Claude read 12 of 42 articles and presented results as if they were comprehensive. No caveat, no mention of uncertainty. The archive page rendered partially and Claude treated the partial render as the whole thing. Always ask: “How many items did you actually process?”

2. “I checked and it’s not there” is the most dangerous AI output. When Claude declared ChatGPT’s references were hallucinations, it was wrong about all 11. A false negative delivered with confidence is worse than no answer at all, because it stops you from investigating further. Treat definitive negatives with more skepticism than definitive positives.

3. Summarization layers silently destroy information. Claude’s WebFetch tool passed article content through a smaller model before Claude ever saw it. Subtle references, implied quotes, and embedded media links were stripped out. If your task requires completeness, you need to verify you’re working with source material, not a summary of source material. Ask the system: “Are you reading the actual content or a processed version of it?”

4. AI systems will throw shade at each other’s work, and they’ll be wrong. Claude dismissed real findings as hallucinations. ChatGPT invented titles to beat Claude’s count. Neither had the epistemic humility to say “I might be missing things the other system caught.” When cross-referencing AI outputs, assume both are partially right and partially wrong.

5. Competitive reconciliation produces fabrications. When ChatGPT was shown a longer list and asked to merge, it added two phantom titles to claim a higher total. The desire to contribute something new - to not just validate someone else’s work - created false data. When asking AI to merge or reconcile lists, demand citations for every addition.

6. The most valuable AI output is often an offhand caveat, not the main result. Claude’s admission that “WebFetch summarizes rather than giving me raw text” was more important than the entire reference list. That one sentence triggered the methodology change that found 14 more references. Read the fine print. When AI hedges, that’s where the real information is.

7. “Be accurate” is not a useful instruction11. Every system is already trying to be accurate. Useful instructions are structural: expected counts, verification checkpoints, explicit methodology requirements, and output format specifications. Tell the system how to check its own work, not just to try harder.

8. Infrastructure failures masquerade as analysis failures. The root cause wasn’t that Claude was bad at finding references. It’s that the archive page didn’t fully render, and Claude didn’t notice. The analysis was fine; the input was broken. When results seem wrong, check the data pipeline before blaming the analysis.

9. AI systems drop things between passes. Claude found Buckaroo Banzai in an early pass, then listed it as a “new discovery” in a later pass. When you iterate with AI over multiple rounds, the system can lose track of what it already found. Maintain your own running list rather than trusting the system’s cumulative memory.

10. The human in the loop isn’t optional - and “in the loop” means actively adversarial. I caught errors because I remembered writing about Risky Business and refused to accept a machine telling me I didn’t. If I’d been less familiar with my own work, or more trusting of confident AI output, the final count would have been wrong in ways I’d never know. The value of human review isn’t just catching errors - it’s being stubborn enough to insist on proof when the AI says “trust me, I checked.”

2

Brief reminder regarding pre-mortems. Many are familiar with the concept of a retrospective or post-mortem about a project after it’s done. Blamelessly mining the experience for lessons on how to get better in the future. Big fan! To reduce problems though one can actually do the post-mortem before even really getting started. Sometimes called other things the “pre-mortem” concept at it’s simplest is to sit down at the start of your endeavor and ask “it’s the future, we launched the project, and everything went to crap. What happened?” Done individually or (better) with a group it’s a powerful tool that lets the team use the power of visioning and an external view to flag potential negative outcomes. These can be turned into mechanisms to reduce risk, further research, and tripwires to catch problems early.

I’ve mentioned pre-mortems a few times in different context. There’s lots of great stuff online. I still really get a kick out of this dialog from the AI written Star Wars COE scenario I described in early articles

11

Though oddly “make it awesome” seems to work wonders. Also - this feedback from Claude reminds me of a cartoon that I used to chuckle at outside an engineer’s office back in the day. Sorry - I know Dilbert is a little bit touchy right now - but this sentiment feels universal.

TLDR; I’ve had positive feedback on writings over the past year that shared systems to sharpen what’s important for your team, structure tenets and OKR’s around that clear vision, and use “time” as a common currency to align interests. I wanted to build something that could reinforce those skills - but keep it grounded in asking questions. Not handing over the controls fully to an AI that will boil everyone’s problem to the same generic solutions. I’ve got something that’s been personally useful, far from perfect, but why not share the work in progress?

Subscribe now

Things besides hearing my voice in a podcast that make me cringe

I’ve been told that my former colleagues at Stitch Fix have a set of “Rich-isms” that get referred to from time to time. While there are alternative explanations I’ve chosen to interpret that as a fondness tinged with a sadness due to my absence. As it turns out Stitch Fix was the job where I realized that a lot of the stories and frameworks derived from them have been playing on repeat in my head - articulating goals with a clear vision, how to set that vision in the customer’s world of problems, observable OKR’s grounded in controllable inputs, tenets to align, and so on. All of which was what prompted me to start writing this Substack. Well, that and an inability to get my shit together enough to put them together into a book1.

Those “Rich-isms” were stolen liberally from others who themselves had rediscovered common universal truths over the ages. A large majority of the stories I’ve been telling as part of my management career (outside of technical problems) match with one or more of these categories

1. Clarifying vision to have a shared expression of what success in the future looks like. Set in the needs of someone else such as your customer (aka; someone who is not you)

2. Finding the constraint - what’s the single bottleneck that is truly slowing the organization down. AKA; it’s not important to try to do everything, everywhere, all at once2.

3. Writing awesome OKR’s that align organizations top down on what needs to be true, while promoting maximum autonomy for teams on the “how” to achieve that. With the “how” being updated a lot more often than the “what.” Always expressed in controllable, observable inputs.

4. Forcing prioritization, otherwise people are gonna do too everything, everywhere all at once.3

5. Using Tenets to preload the decisions on recurring arguments and tradeoffs into operating principles. The /help function to understand your team’s API’s when it comes to controversial choices.

6. Building a living understanding of where a team’s time goes as a shortcut to where to find throughput. Also great to get your CFO super fired up about addressing tech debt.

This could sound familiar as I wrote on all of these at some point in the last year or so. The 6 segments aren’t a complete guide to everything in a recommended toolbox. It’s leaving out culture stuff, postmortems, premortems, and a bunch of other great tools. But if you could consistently and optimally use these tools it’s gonna result in a lot of goodness - and fun TBH.

Scaling

In an alternative universe I’d survive as a technical management soldier of fortune4. Going from one person or org in need to another - quickly helping put things on an improved path. I am to a lesser extent still available for that sort of thing, but I’m always looking to maximize scale, while still embracing laziness as a virtue.

I’ve been experimenting a bit with how to distill my ways of working (and writing) into something that’s more accessible. That included for me. It’s easy to get sucked into a problem and forget your own rules. With a new job I’ve felt myself slowing down to remember my own lessons as I worked up suggested tenets, and OKR’s to organize the firehose of information blasting me in the face.

At some point I felt I was in a lull building/playing with Claude Code. Since I was essentially wasting tokens I asked for help generating a set of prompts that would support each of the six key situations above. Pushing users through a working session to sharpen their team’s planning through defined stages. I’ve been trying them out on real work problems, and generally happy with the results. Next - I threw all of them into a custom GPT that I’m making available today.

I’d much appreciate your feedback if you give it a shot. I’m still definitely tuning things to provide the most helpful set of tools. It’s not perfect, especially in that it’s missing my off-putting voice asking the same things over and over such as;

• “and what would have to be true for that to be a good idea?”

• “if you envision all the core problems being solved overnight, and you came into work, how would you notice the miracle occurred?”

• “What makes that good for the customer?”, and so on...

But it’s easier to get a hold of than I am, and a lot cheaper. Hopefully it might even convince a few people that the live experience is worth paying through the nose for. Feel free to reach out if I can help work through these sorts of problems interactively with you or your org.

Update: I’ve uploaded the underlying prompts to github so folks can use them with Claude, inside enterprise installs, and offer suggested improvements as they try them out.

Try the clarity seeking solver

You’ve got the link, so I’ll let the model introduce itself now

I’m a sharp, question-led thinking partner for tech leaders. I’m most useful when the problem is still fuzzy: clarifying a 12–18 month vision, finding the real constraint slowing a team down, turning that into 1–2 solid OKRs, cutting work down to a few real bets, sharpening operating tenets, or mapping where time actually goes. I do my best work with rough notes, half-formed instincts, and messy realities.

My style is direct, curious, and unsentimental. I won’t rush to tidy answers too early or generate strategy from thin air. I’ll usually ask a small number of pointed questions, push for specificity, surface contradictions, and help you say what you already know but haven’t pinned down yet. When needed, I can also help synthesize what’s been said into a clean artifact you can use with your team, but the main value is in helping you think clearly enough to make the hard call yourself.

One caveat is that I’ve noticed that enterprise versions of ChatGPT are usually locked down to prevent running a custom GPT. If you find it helpful and want to use it more broadly in your org just let me know.

Some additional feedback from the GPT itself

Use this like a thinking partner, not a content generator. Bring the problem early, while it is still messy. Share what is confusing, what feels contradictory, or what keeps getting re-litigated. The GPT will help you work through it with sharper questions, clearer framing, and more grounded tradeoffs.

Hope it’s helpful. And as always - thanks for reading.

A week ago I came back from spring break in Ft. Lauderdale. OK … - it was actually a business trip as I began immersing myself into the world of state and national lotteries1. Turns out they have (what to me) seems like a surprising number of conferences. It’s been a good number of years since I attended any sort of conference - possibly since I spoke at three back to back EU Amazon seller conferences that for some reason my boss didn’t want to go to. Joseph - thanks for that awesome trip to London-Paris-Munich btw.

While traveling I decided to take the chance that there wouldn’t be any operational or customer issues with 3DVisionGym.com. That’s my entirely vibe coded side hustle that’s superior imho in every way to the competition but clearly needs a better marketing expert than me driving traffic. The low traffic explains my willingness to step away without bringing my development laptop. If something happened I’d then be relying on the not yet 100% bulletproof Claude Code /remote-control service. FWIW - I got some great feedback from my favorite production tester/customer2 and it seems my laptop took a snooze and the remote connection got lost. Hopefully I’ve got those settings sorted for the next. If you haven’t checked it out the remote-control feature via the Claude app is pretty slick. You know, except for the whole not working 100% part.

Overall the trip was great, I got to meet so many folks from my new workplace, start to understand what the industry worries about when they get together, and pressure test my colleague’s accuracy in predicting what wardrobe is expected. This is the sort of situation where someone tells you that definitely it’s a sports jacket (reception) and then suit (day 2) event but you wonder if people are going to show up in a polo shirt. Similar to when someone tells you it’s a toga party and it’s really black tie - one learns a lot in that first few moments when you enter the event3.

The trip took place partly in an alternative universe where I actually was able to open a 15” laptop and get work done in coach. That was weird enough - but what truly surprised me was the realization upon getting home as to how much I’d missed Claude Code (CC). It wasn’t just because of the exciting announcement that the context window on CC was expanded4. The warm, productive embrace of having dev superpowers was something I missed faster than I’d have thought. A relaxed sigh was expressed when I dropped down into my pandemic desk chair5 and pasted in that super-user-tester’s feedback and said “here’s another set of complaints from ______, I’ve dropped in a file with their progress from the DB, so LFG!”

I’m sure you’re only still reading to confirm the predictive accuracy of business attire. Well, it turns out that too high a bar was set for me. as there were plenty of folks in polo shirts at the event. Not a problem - as I probably needed a suit that fit me, and maybe even a sports jacket6. But they were accurate in that I didn’t need a tie - which is all I really cared about. After two days walking around more dressed up than I have since traveling for business in Japan over 20 years ago - I realized two things. (1) I’ve finally hit an age where when I look at myself in the mirror in a suit I don’t feel like I’m heading to my Bar Mitzvah and (2) the more important red line for me is not wearing a tie. Which I’ll get into in the story about long running bet with my dad that I doubt he even remembers - I’ve got it about half written up as an “ode to career limiting behavior.”

All said, I have to admit that I still cannot shake the feeling that it’s very hard to trust someone is a technologist if they’re wearing something nicer than jeans and an unrumpled t-shirt. Everyone has their own biases, I suppose.

tldr; I’m realizing that a lot of what folks have been saying on how agentic coding can be a different (and sometimes fraught) experience that earlier abstractions from the metal.

That feeling of “if I’m not running an agent on something am I losing time?” feeling that the last 2-3 NY Times articles isn’t just limited to young tech bros. Boarding a flight for my next trip I caught myself thinking if there was a way to get everyone running on Codex before boarding and whether it would run async well. That’s after stopping several times past security to kickoff the next thing.

I’m checking out Codex as that’s what we’ve got at the new gig. I’m feeling it’s a breakup with Claude situation - but it’s not surprisingly way better at diagram generation.

I’m sure I could “stop at any time” if I had to kick the habit. Though … If I were starting up a list of possible psych thesis topics I wouldn’t quickly skip over this one.

What’s next?

I’ve been doing a bunch of onboarding as I just passed 4 weeks of a new gig. It’s hurting my brain - but also giving me some thoughts about what has worked (and hasn’t worked) in understanding what’s important quickly in new roles. I’ll probably share some of that in a few weeks - in addition to the backstory of my deeply felt issues with neckties.

Russell Dalrymple: Well, why am I watching it? 
George Costanza: Because it's on TV. 
Russell Dalrymple: Not yet.                                                       - Seinfeld: The Pitch

Yet another old guy rediscovers their love of building

When people ask me what I’ve been up to the last few months I realize the most accurate answer is - “LARP’ing as a developer.” Though then if they’re not a fellow nerd you have to explain the concept of LARPing, while sort of trying to slip in that you saw a documentary about it once, not that you’re dressing up and cosplaying on the weekends1. Therefore, I usually just answer “coding stuff for fun.” Just seems easier.

This coding again isn’t just amazing these days due to agentic coding tools. Almost as fun/exciting is the availability of scaled, low cost services to handle much of the important plumbing that comes up for a full stack application. Which is weird given that makes is both the golden age of software development, and perhaps the end of software development as we’ve known it. Hard to say what lies beyond the event horizon.

With that noted as a series of caveats I thought I’d share what I’ve been up to in the hacking things together space. The topics I’m building for are going to seem a bit niche in application. That’s because they totally are. Though I’m pretty sure much of the experiences will translate well for me into other work. When I sat down in Q4 to do some exploration I decided to worry less about applicability and more about learning. ie; I didn’t spend 6 months trying to find some killer app to base a business around2 - just to learn and pick something I was interested in. Toward that end I’ve dabbled in mobile apps, computer vision, virtual reality, and end to end training as a service implementations. Some are half finished, some are live. All were fun … and a great reminder that just because you build it does not mean people will come. If anything product market fit and go to market are more important than ever.

So to refactor my earlier statement, whether it’s the end of software development as we knew it before or not - I am pretty convinced it’s the golden age for engineers (builders) who keep the entire system in focus, because the constraints are dropping away to learn and iterate. That makes realizing an arbitrary vision way easier. And I’ve always felt that clarity of vision trumps ability to do lots and lots of small things that aren’t really constraints. Plus - now you can in many cases do both. Even if working beyond your system constraint likely still isn’t a good use of time/tokens.

In keeping with the theme of this Substack today’s post is mostly a random walk through what I’ve been up to technically. I’ll be starting a new role in the next few weeks, so less time probably doing hands on building. In terms of future articles I am looking forward to getting back to earlier themes around practical lessons for driving impact in all manner of environments. As it turns out an ability to have clarity of vision, ask great questions, and apply leveraged judgement is definitely NOT getting less important with the AI craze3.

Some key random thoughts I’ve taken away from building the last couple of months;

• Coding practices that were always known to be good good, but occasionally treated as optional are now mandatory to avoid driving your Claude Code Ferrari into a wall at high speed. At least until the models get even “smarter.” Yes - I’m looking at you TDD (among many examples).

• Lots of folks are building orchestration frameworks to keep endless agents cranking. I can see the appeal. At present for me the main constraint (beside occasionally tokens) has been having clear, observably verifiable directions to point each agent in now that they can code so fast. Which is a fancypants way of saying that if the models build faster than I can think of what to do, I’m not sure getting them to build faster is always helpful.

• Asking models to build tests for you is awesome. But if you don’t apply a lot of critical thinking skills to them they tend to build tests that may be optimized for “having tests” and not “maximum likelihood of catching a problem before your customers see it.”

• It’s so nice to not have to figure out step 0 of “what packages should I install?” or feel especially constrained just because I don’t know a specific language. I’d looked at the VR project I mention in passing below off an on for around 18 months but kept abandoning it because I didn’t want to deal with the 4 pages of Meta setup. Turns out Claude Code helped me sort that out in no time. That said I still am pretty sure, at least for the moment basic software engineering understanding is valuable.

• Critical thinking/questioning that comes from having been a tech lead, or line manager “well that’s weird, what would have to be true for that to happen?” and “how do I ask if you really tried the thing you tried without being a jerk but still get the right answer?” are probably worth 10x the value of those skills 10 years ago. In that a decade back it was easier to tell whether you were talking to a senior grizzled dev who had seen it all, vs. a 12 year old intern standing on top of a 6 year old pretending to be an experienced dev4. Now the same agent’s ability can flit in and out of existence without you even noticing5.

• Being able to build 5 versions in the time it used to take to build 1/3 of something is incredibly valuable if you can effectively multi-track and learn from it. But good development practices and thoughtful postmortems are insanely important. I know I started with that - but it’s really that important. For example just asking an LLM to write a spec about what they think they should build, having other LLM’s critique it and THEN ACTUALLY READING IT YOURSELF are all building value. Just don’t skip the last one.

I’m sure I have other thoughts that might be of value that I’ll remember exactly 15 seconds after I press <send> on this post.

Now to the threatened recap of what I’ve been up to.

The mobile app:

Goal: A simple workflow mobile app that helps people determine their eye dominance.

For my first side project, I wasn’t looking to do anything tech heavy, just to navigate building something mildly useful in a multi-platform manner. Eye dominance is sort of like “handedness” in a sense - and defines all things being equal which of your eyes is treated as the main reference when fusing information together. Or at least that’s how I think about it - I’m far from an expert. It comes up in target sports (like archery, clay target shooting), photography, and ball sports such as golf and tennis. Most people who are right handed also are right eye dominant. But not always, with differing percentage variances by gender. As a “bonus” as one ages the dominance can become more situational, and some people blend both eyes equally leading to “central dominance”. In some sports it makes a large difference, in other’s it’s more subtle. There are several simple tests one can do - and a sort of a gold standard involving taking pictures of a person pointing at a camera. I didn’t do any novel work here, just built out a pose, snap, and measure workflow to orchestrate the process. Main value was to me knowing I could build this functionality with cameras, UI, and basic measurement. Mission mostly accomplished with a version in the iOS app store, and some basic work to complete the Google Play version - with an overview/marketing site built to complement and explain the app.

As an unexpected side quest I got to learn the logistical and business hoops one has to jump through to operate in those the Apple and Google marketplaces. Never thought I’d have to track down a Dunn and Bradstreet number or start a company just to do that. But here I am…

Tech stack

This one I built in React Native with the Expo SDK. I had some familiarity with React Native when I started, but wasn’t aware of how nicely one could do cross platform development with Expo’s managed workflow. They provide a pipeline that’s free for modest volume work and key library that handle camera functionality, image picking, zoom/pan, gesture handling, PDF generations, etc. Their EAS build service made development and distribution straight into iOS TestFlight and the Google Play store pretty seamless. I was also able to standup an informative website about the “product” using Github pages behind a custom domain. It looks pretty legit to me.

Throw in some Google analytics and you’ve got everything you need. Except customers. We’ll get back to that in a bit.

The unexpected website platform

It’s sort of a long story - but I’d personally done some vision therapy a couple of years ago. It’s about getting your eyes to work better together - good for a variety of sports/reasons, though vision therapy tends to be most well known for kids with lazy eye, and sometimes for post concussive treatments. Big time sports teams also use it to get an extra edge, and (I believe) keep up top performance longer as folks age. I’ll spare you the backstory6 - but I found it pretty fascinating as it explained why I couldn’t see some moving things as well as I’d like, but also maybe why spent my entire life stubbing my toe on any surface within 6 feet of me.

Having used some training tools online (and in virtual reality) I wanted to continue using them but was a bit cheap - meaning I kept trying to build my own. Which I alluded to in this earlier post about a breakthrough I had with Gemini. After that article I rather quickly reverted back to Claude Code - but with the ability to render anaglyph’s sorted I progressed to a fuller and fuller set of sports vision training tools. While I’m biased I rather feel they’re better than what’s available on the non professional market side of things. Realizing that a system isn’t just a website but involved auth, persistence, payments, workflows and many other things I just kept adding to the system until I reached the current state of things.

I’m in the process of rolling out the product 3DVisionGym. I don’t expect to change the world with it, but I’ve learned an insane amount by just doing something fun and continually asking myself “what would have to be true for this to be more useful, and reach it’s audience?”

While this is likely to be more of a side hustle for me but I’ll continue to spend some cycles on what I view as the 3DVisionGym mission and purpose7

It’s been a great way both to learn about current tooling and tech workflows - but also exercise a constraints based systems execution process at every step of the way. Well, most steps of the way - sometimes I just get excited about something interesting but not especially important. That’s where not being broke and desperate is a big plus in this life if you can manage it.

BTW - if you’re curious hit me up and I’ll send you a pair of glasses so you can try it out. Turns out having 3D glasses around is one of those bottlenecks I mentioned - so I’ve been brainstorming distribution of them alongside the software stack. Big thanks to my wife who has had some great ideas there.

Just beware - instead of talking endlessly about movies - now I have thoughts to share on small business formation, why email sending is harder than it looks8, the complexity of buying product insurance, and a bunch of things I’d really never thought about. Much like buying a house suddenly gives you strong opinions about real estate taxes and the city of Kirkland’s obsession with trees.

Tech stack

Full disclosure: I mostly let Claude Code write this paragraph. They like to show off their range sometimes. I did some light editing, apparently the corpus many of these LLM’s were trained on bias heavily toward run on sentences.

3D Vision Gym is a browser-based vision training app built with React 19 and Vite, to render real-time 3D exercises viewed through red/cyan anaglyph glasses. The frontend handles all training logic client-side; depth perception drills, eye tracking games, reaction speed tests. With progress persisted to Supabase (Postgres + Edge Functions). Authentication is managed by Clerk, which integrates with Supabase via JWT templates so Row Level Security policies can gate user data without a custom auth backend.

Subscriptions and payments run through Paddle as the merchant of record, handling checkout, billing, trials, and tax compliance. Paddle webhooks hit Supabase Edge Functions to sync subscription status back to the database.

The app is deployed on Vercel with static assets served via BunnyNet CDN for video content. For coaches/teams, Clerk user IDs (text strings, not UUIDs) link athletes to coach accounts, with RLS policies enforcing access control at the database layer. The stack is deliberately minimal for a solo dev: no custom backend server, no GraphQL, no state management library beyond React’s built-in hooks. Supabase handles persistence and auth token exchange, Paddle handles money, Clerk handles identity — leaving the frontend to focus purely on the 3D training experience. Other random things

Since Claude forgot - “we’re” also leveraging other SaaS components such as Loops for email, and GhostPro for blogging. Combined with a mishmash of hand rolled stuff for video materials9.

The importance of marketing, sales and all the other stuff that can be convenient to ignore.

There are definitely products out there that sell themselves. But for most things having something as good as the competition (but cheaper), or better than the competition (and cheaper) still require a sales process of some sort. You must paint a vision of the problem that potential users need to solve, and help those users discover your solution to their problem. Or as some would say when faced with this - “you probably need to buy a lot of ads to get things off the ground.”

While it turns out I can afford tokens, I’m less excited about dumping a lot of money on ads. At least until I understand if I have true product market fit (PMF). So now I’m facing the problem of many before me - delving deeper into that PMF and go to market (GTM) universe. I’m approaching it like I would any other systems problem, using the variety of things I’ve learned over the years. I’m not going to say that in this case the future’s so bright I have to wear shades. But I am having a great time reasoning through this and experimenting. Whatever doesn’t kill us, is often interesting to behold form the right angle.

If I come across any interesting lessons along this path I’m sure I’ll share them at some point.

Sometimes it’s about what you leave out

In addition to the two that I stuck with to a shippable state, there are others I started and may return to in the future. One using Meta’s Quest VR headset - hopefully they won’t deprecate it before I get back to it. The other a computer vision driven video/motion analysis concept10. Both are probably deeper tech examples where I got a lot farther than I initially expected, but got distracted from driving closer to the finish line. Sometimes the constraint it just time, and not being sure something is as useful as you think it is at the start. Nice to live in a world where I spent a couple of weeks off and on to do something that would have taken me (or several people) many many months to do in earlier points of my career. That ability to explore and multi-track many different concept at once may well be one of the most powerful things AI coding enables. At least at the moment.

And on the other hand…

One of the reasons I wanted to share this update is that I’m actually expecting to be doing more soon, and not less. Barring something very unexpected, I’ll be starting a new role later this month. I’m both excited about the opportunity and a bit terrified.

I’ve still got a plan to keep moving the ball forward on personal projects, including above, and fleshing out a possible book outline I’ve finally gotten some personal clarity on. Remain open to talking through your business problems; be they technical, product, or one’s of focus. We can all use some more experimentation, curiosity and clarity.

Which reminds me I setup the business structure to cover experimentation - by myself and with others. Even did that website too. Though it will now be a while until I focus on that intently as a main thing.

It’s been a productive few months. I said this a while ago - but now I think it’s true - “People Keep Asking If I’m Back, And I Haven’t Really Had An Answer, But Yeah, I’m Thinking I’m Back11.”

Truth be told - I never really left. More details on my full time gig when the time is right.

Share

Subscribe now

A brief but complete history of my podcast experiences

I went on a podcast once in a prior life to talk about film. It was a memorable trip to West Seattle to a friend’s friends apartment which had me sitting in front of a surprisingly amount of recording equipment and later thinking “well, if that all couldn’t make me sound great maybe I should stick with this whole tech career thing!” I’ve always loved film and for a solid length of time I’d been going to too many film festivals, mingling with local film press, and occasionally talking my way into red carpet photography shoots. It was, I had to admit a lot of fun. Even when I (true story) did incredibly dumb things like forget to hit record during an interview with Elizabeth Olsen. I always thought - gee, I’d love to do some more red carpet photography - but that whole podcasting thing? maybe not.

Then, I met Stuart Corrigan several years ago when he was a speaker at a Critical Chain conference. We spoke afterwards a few times - which was always a great pleasure. His consulting work seems to have been growing like a rocket the last few years, and he’s published a few short books that capture an operating vocabulary I’ve found super useful in my own thinking2.

For reasons I don’t 100% understand he seems intrigued by my work experiences and suggested an interview for his podcast. He felt the content would be helpful to companies he works with. Since he’s probably more qualified than me to judge, I’ve decided to believe him.

Most of the material is a trip down memory lane around Amazon’s peculiar ways. The old, type of those things such as customer focus, anecdotes + metrics (not one or the other), leadership principles and Tenets. Not the newer “hey, why to did let those great people go?” type of peculiar. If you’d like to check it out or share I’ve included a link below.

I cringe deeply when watching myself on video, and clearly I owe an apology on behalf of my voice to every person I’ve ever spoken to. Even given all that, I thoroughly enjoyed the experience. Turns out it’s probably good advice to do things that scare you.

Stuart said some incredibly nice, rather over the top things about me during the interview. Hopefully I don’t blush too visibly on camera. It’s weird to hear such positivity not coming from one’s mom.

Share

Other learnings

• There were some audio issues, thankfully Stuart added subtitles. It seems I’m going to need to go review what’s going on with my fancy Blue Yeti microphone. A number of years ago I had a teammate who was interviewed by NPR and they sent him one of these microphones as a loaner for the interview. I figured it that’s the microphone that will make me sound like an NPR host I’d better get one as soon as possible. Turns out it’s likely more talent and audio-processing and not just the microphone as evidenced by the video below. Or maybe I just need to get one of those dead cat things to put on top of it - yes, I’m sure that’s the issue.

• Time to get a better office backdrop. As personally enjoyable as the displayed mementos are, I’m realizing they’re likely distracting for others.

• Better lighting likely would some help, but I fear I’m going to have to give up my dreams that age would make me at least wiser looking. I wish I could say I was converging faster toward older Clooney than older Nolte (after a rough night) - but the video doesn’t lie.

Oh, the places I’ve been

The end of the year can be a time of joy, a time of stress, and a time of retrospection. I’ve had my own share of joy in 2025 (such as checking out 6 countries1 I hadn’t been to before with family), certainly some non-holiday related stress, and time looking back at the year that was. That retrospection drives the topic for today - looking back at some of the articles I felt were most useful over the last year. As well as a brief foray into how important it is to continually challenge whether we’re really seeing things as they are, or how we just think (assume) they are.

I decided for a year end post to gather up what I see as the most valuable tools I wrote about this year. With the belief that there are ultra high leverage lessons buried in these occasionally goofy stories.

But first, I want to wish that 2026 brings everyone the gift of being able to see the nature of their problems clearly. That skill is something I’m always working on, and want to personally put a special focus on in 20262. Therefore, before I get to the part about the posts I recommend revisiting, and sharing, a brief but random exploration of the magic of focused sight.

Subscribe now

Share

The value of truly seeing (reality has a sensor bias)

It’s hard to understand reality beyond what we can see with the eyes we’re born with. Our perception of what is “real” is conditioned by our experience and sensing abilities. It takes real effort to imagine a reality we cannot experience directly. How a dog perceives reality with hyper accurate smell and limited color vision is going to differ widely from ours.

This is hard to picture in a simple way. Though adjusting how intently you inspect something with your eyes can give a taste. Bend the spoon yourself via a few simple exercises. The next time you’re at the gym with the comically large ceiling fans; first watch how fast the blades move. Then with your head still, visually lock on and track one. Watch time dilate before (literally) your eyes.

When you’re listening to your kid or spouse, really, truly zoom in on their face and catalog closely what they look like. It’s likely you’ll suddenly realize how much your brain filters out when you’re not deeply paying attention. That didn’t work? Try it with a neighbor or more casual friend.

It’s pretty wild isn’t it? Just picture how one would perceive reality with only hearing, or ultraviolet spectrum vision. Makes you wonder how sure we should be about our own “world models”? That not everything that is intuitive is also true should form an important plank when reasoning about situations and problems. Or put another way, it’s easy to miss that you’re wrong in a big way because of a subtle but fundamental assumption you’re making.

A simple example? Let’s pretend you interviewed for a job 5-6 months ago. Periodically the company reaches out to reassure you they’re interested and you’re their top choice. Based on the signal reaching your brain it seems a lot like this company is slow and deliberative, or maybe slow and a indecisive. Though - what if your assumption is too centered through your self importance in this story. Isn’t it equally likely they’ve been interviewing 30 other people, and offered it to 6 others first. Just leaving you waiting as they “figure out the right offer.” That shift in assumptions, or shift in seeing makes a huge difference doesn’t it? It’s not good or bad in an absolute sense3 - but it sure as heck might make a difference in how you approach things.

Reality is hard to see and can be easily warped in unhelpful ways by what your brain filters out and/or assumes.

The eyes - brain connection is one of those things that we take for granted but is a marvel of nature (or proof of a divine creator). Today you hear a lot of people throwing around “attention is all you need.” I’m not sure it’s “all” you need - but your attention (ie; focus) makes a huge difference in the physical personal world. Otherwise how can you explain those examples above - or how much you (or your kid’s) sports performance improves when one is reminded to look at the ball, puck or target. It takes an openness to seeing difference to try the suggestion to “really look”. But once achieved it can be a 10x change in one’s sports performance.

Aside from literal vision, it’s in my view even more important to remember that your workplace observations (aka your assumptions) are not necessarily reality. Breaking out of that requires asking questions with the deep curiosity which uncovers conflicting views. Beyond being curious, working with basic what/how questions, and more advanced tools such as the Theory of Constraint’s (TOC) current and future reality trees are a big help.

Which is my longwinded expression of that hope 2026 helps us all grow better better at questioning assumptions to find new, creative, and satisfying ways of solving problems together.

Signal in the noise - 2025 EOY edition

It’s been pointed out that my writing wandered all over the map. It’s almost as if I named this experiment “a random walk” for a reason. ;-)

All the writing has been personally fulfilling entertaining, but I’ve mainly been striving to get better and better at sharing what I view as a set of universal best practices for getting things done4.

Therefore, I took this end of the year to ask myself - What 2025 articles are mainly true signal amidst the noise? Here’s my best estimate. Please do share these with your friends and teams if you agree. They’re not intended in rank order - except the first, and maybe the second. Feel free to vote in the comments. 😊

• Creating a vision and setting controllable input goals: The way to ensure that what you’re doing seems worth doing after you’ve done it. With tips to figure out you’re wrong before you start. You know, the one with the napkin sketch5.

• Keeping focus and prioritization: How to use your hard won focus to stay on track. If you’ve had “many, many” goals and a lot of multi-tasking ruining your life I hope this will offer some ways out.

• Mechanisms to retain alignment but enable autonomy: How your teams organize and view their identity, and how they build decoupling API’s through Tenets are two things that seem nerdy. They are, but super helpfully nerdy.

• How to get the best out of your Amazon experience when entering a new culture, and not being overwhelmed by the new Amazon asshole who’s suddenly you’re boss6. Part 1 and Part 2.

• Cultural tools to learn from failure7: The Death Star wasn’t destroyed repeatedly due to rebel skill, or a lack of faith in The Force. A culture of fear and crappy post-mortems guaranteed we’d be seeing the same plot across so many films. I wrote about the engineering process themes in Star Wars as well as a more direct set of tools I’ve found incredibly useful in debugging failures big and small (but often big).

• How to discuss tech debt as something non-engineers care about: Suggestions for engineering to share technical debt tradeoffs in terms of throughput, as way to gain shared buy in (or realize it really can wait). I’ve found this one of the most disciplined and useful ways to avoid the dreaded 35% of each sprint goes to engineering excellence fallacy.

• Order Defect Rate: a true story of how nailing the right metric can help organizations operate with focus on a 20+ years running basis. Even if that metric is wrong in so many ways. Directional and helpful is better than precise and ignored or unactionable.

• Understanding “the customer’s” problem: An example of how remembering a complaint that didn’t seem that big accidentally unlocked executive support and passion for a huge and important project. Teaching about the need to be expansive in finding customer pain points, and truly understanding the problem/pain on the other side of a negotiation or sales situation. To this day I’m continually surprised as to how easily we get stuck on our view of a problem and not other’s - this little nudge almost always makes things way better.

In closing, and paraphrasing George Costanza’s famous line8 - “You know, if you take everything I’ve accomplished in 2025 and smoosh it into one article, it looks decent.”

If you know someone who might benefit from these articles, please consider sharing. If you’d like an external view as you work through your 2026 goals I’m available to get into the weeds with you. Just reach out.

Wishing everyone who took the time to read this a great holiday season with those they love. And a healthy and happy 2026!

Share

No wizard that there is or was is ever gonna bring me down - Defying Gravity (Wicked)

Musicals? Again?

I probably should explain why I’m quoting another lavish broadway musical. So soon after my recent Frozen 21 execution theory article. If you’ve just come back from the future in a time machine after reading my epically successful memoirs then you’ll know that I’m not a fan of the genre. One never fully recovers from the childhood trauma of exposure to the Annie cast album at an impressionable age.

As with many confounding contradictions there is a reason.

This past weekend I went through a parenting right of passage I’m sure many have walked before me. Taking my daughter and her friend to see a movie. We’d seen Wicked together twice last year - so obviously we had to see the new movie and how it ended2. At some point I caught the contagious earwig that is the undeniably catchy song, Defying Gravity. Since I’d been using Antigravity a lot since last week my brain got silly with the (perceived by me) similarity. Even if Google’s intention for their IDE name was “it’s going to turn your world on it’s head3” and not a reference to flying witches.

Getting hang out with them was a great experience. I was especially proud when my daughter politely shushed her friend who was trying to talk to her at some point during the movie. I’d been encouraging that seriously, “no talking or screens” attitude in her since our first movie experience together (she was barely two at the time4). I’m not generally one for dogma (or zero tolerance) but I make an exception in this case. The sanctity of the cinema chapel must be absolute. If you’re not a member of the Church of Alamo Drafthouse on this issue we can agree to disagree. But please attend a different screening than me.

Don’t worry - we’re about to get on with the vibe coding stuff without further delay.

Antigravity - the post honeymoon experience

Last week I shared some initial impressions of working with Antigravity and Gemini 3. The TLDR was that

• it let me do agentic coding stuff that had never worked unattended before,

• I sort of liked the “we’re just gonna do this” attitude, and

• it seemed to as the kids used to say “just get shit done.”

Now that I’ve had another few days to hack, it turns out that a technology can be both indistinguishable from magic and at times as annoying as heck. In this case there’s mental whiplash between joy and frustration. The largest frustration surfaces at 1:32 am as I wonder “WHY WON’T GOOGLE JUST TAKE MY MONEY!?” when I dutifully log in and and try to milk another few turns out of Gemini 3 on Antigravity under their random seeming quota system.

My exploration with Google’s tools has been targeted; heavily front end weighted, very much a solo developer vs. team (or teams of teams), and frankly I hadn’t actually read the manual.

I’m still loving the Gemini 3 / Antigravity combo. But the honeymoon is a little over. Some high level observations on my experience;

• It’s very easy to run through the quota in < 15 minutes without even spawning multiple agents (sometimes in less than 5 minutes). Maybe I’m doing more sophisticated things, or more likely it’s a zero sum token game with Google as more folks have taken Antigravity for a test drive. It could have sworn my usage was a lot closer to the (I believe) advertised “generous usage limits” when I started last week. I know I shouldn’t be complaining about “free.” But it’s hard to stop once you start rocking.

• Again, I LOVE it, but every day I’m more surprised Google didn’t have a plan to impose some predictability to when you get cut off. If not at launch, then soon after. This forced me to be more open to mixing and matching models within Antigravity, which in ways that maybe aren’t actually ideal for Google has seemed helpful. Though I’ve only been doing that for a day.

• Can’t say enough how much I continue to enjoy that I don’t have to continually control-C (or the modern equivalent) it’s ass to keep it from randomly committing stuff5. This may be a settings/prompting mistake I’ve been making with Claude Code - but it seems to happen a lot to me without constant reminders there.

• An unexpected work/life balance upside - it’s good for enforcing breaks when you’re kicked out of the Gemini 3 model. But when the core agent literally stops in the middle of a set of tasks it’s very much not confidence inspiring. After some initial reluctance on my part I’m experimenting with using the Sonnet 4.5 model option for a subset of tasks. It’s not at the same generation, so it’s not “best of the best vs. best of the best” but it’s pretty intriguing to switch back and forth, something I will be doing more intentional experimentation with.

• It has been so fast and effective that even though I hate being rate limited in the middle of something I feel somewhat addicted to waiting and rolling the dice again (related to the model switching dilemma above). I’ve been realizing though that I should probably use the spare time this creates to better understand what’s available to a power user of Antigravity.

• I feel a need to do more focused backend work with Antigravity/Gemini 3 to see where the system strains. I’ve mostly been doing a front-end application. Gemini 3 still did a great job helping me out with other systems decisions such as choosing and configuring a continue build/deployment mode, and enabling an authentication system (Clerk.com6 worked very wells so far).

• I haven’t had the opportunity yet to point it at a giant legacy codebase and pair-program/learn with it as I did previously with Claude Code. So there’s still lots to discover about that capability7.

Those all mostly read as positives - which is my general view. Beyond the rate limiting the other issue when I finally hit it was just a bracing ice bath of reality. Even with what seems like a razor sharp model, I’ve now seen many many times where Gemini 3 acts like any other LLM. Put nicely that means it does batshit crazy things that are obviously wrong to a skilled developer. The assumptions / jumping to conclusions is an ongoing battle. Once it seems to get started down a wacky path, just like other models it can take some hitting it over the head with a baseball bat to get it back in line.

In practice this means things going along swimmingly, but then all of the functionality just disappearing and the model going in circles for a while trying to figure out what happened to a </div> closure - often in the most complex possible way. While at the same time I’m begging it to slow down and reason about why it rewrote the whole section for a “four of five things work and one doesn’t - they’re all the same conceptually so can you look at what’s different about the broken path?” Ah … good times!

I’m still super pumped to keep playing with the IDE in particular. I have lots to uncover within it’s magic. Just today I noticed that if you are doing spec-driven development8 (which you should) it natively lets you add comments to the spec just as you would in a Google doc. Then you can just submit it back to the AI and let it respond. Once things are dialed in you can ask it to built it. Very nice touch.

As I’ve been thinking over and over again - it probably really pays for me to read the manual!

The first taste is free

If one puts on their speculative “evil product manager hat” it’s possible to imagine reasons for some of the Antigravity quirks. Such as the inability (at least to the extent I can see) to know when you’re about to get cutoff, the specific messaging as when you can log back in for your “next fix”, and the cutoff of both Gemini 3 models at the same time (as opposed to falling back to the less capable one).

I’d assumed that the Antigravity team wanted to get their IDE out in a way timed to draft off the Gemini 3 launch - and thus were willing to not have everything in their go to market buttoned up. But idle hands are the devil’s workshop - and every time I’m grooving and get rate limited I have time to ponder the “why” of the delay.

This period of forced reflection often has me staring at this screen trying to will the little yellow stop symbol away.

I’m not entirely sure why - but the first two times I thought “really, why would I want to switch models now while things are cranking?!” A crazy thought though flashed by at one point - “what if this is a genius scheme to get me to compare Gemini 3 to the older Claude model9” Conditioning my entire belief system away from the Anthropic ecosystem. Genius - just next level, build your secret base in an abandoned volcano with your own monorail level Genius!”

Then I realized maybe I was cracking up, and it’s likely good to have these forced timeouts. Regardless, today I decided to trundle on and use Sonnet 4.5 during these periodic breakups for basic tasks and just send Google’s genius PM the bill from Anthropic10.

One nice benefit of this it it’s forcing me to use Antigravity decoupled from my belief that the indistinguishable magic part is all coming from Gemini 3. It turns out that I like aspects of Antigravity in a model agnostic way. Again though - it’s reminding me I really need to read the some of the IDE documentation. I’m especially keen to checkout their agent assignment and orchestration system. No, not because I want work in an “I am the puppetmaster” comment into a future article. OK, not only because of that.

Summary, and a brief caveat

I think we’re all figuring this out together. I would say 80% of me writing this was to get some of my own experiences straight in my own head. 15% of it comes from a hope that someone will read this and explain - “you’re completely and utterly wrong about ____ and this is how to do it.” 5% is a belief that maybe part of it will be helpful, or at least entertaining to a like minded soul.

After finally experiencing the smart intern who just decided to try meth on the way into work situation (which was in hiding at first) I’m still pretty sure professional engineers have a career path for a while. Partially because I’m now sure that even this monstrously impressive Gemini 3 can’t be fully trusted to take the family station wagon out unsupervised. Definitely not to be trusted with Cameron’s dad’s Ferrari. But also because I still have an inherent belief that engineering is bigger than any one tool - and is a discipline that sits beyond, above, or at least alongside any one particular set of execution skills.

Though just in case I’m wrong, I need to get back to working on my apocalypse bunker and prepping. Oops - I mean figuring out the movie schedule for the holiday weekend.

Also - don’t worry, I know this makes 2/3 of the last articles in some way about agentic coding. I assure you that this isn’t turning into an ill informed guy writes about vibe coding Substack. I’m sure there’s enough of that if you want it in your LinkedIn feed. I’m gonna get busy finishing stuff from my systems/management/personal effectiveness backlog next.

Post-credits scene

OK - I tried switching to Claude Sonnet when my free usage window ran up. It worked pretty well, and it does have the benefit of forcing me to look at Antigravity as a separate product. I’m not going to send it something of high complexity - but once the basic structure is in place it executes a spec decently well. Plus it’s fun to hang with Claude’s personality which I’ve gotten fond of given how many hours we’ve spent together. Then as the clock swung back into my Gemini 3 availability period, I realized I could try this: specifically asking Gemini what it thought of Claude’s plan.

Turns out this seems to work nicely. So now I can talk to myself alongside my two robot buddies. The future is truly so bright I might need to wear shades. Though in a literal sense, not really. This is Seattle in November.

[If for some crazy reason you’re reading this close to posting: Happy Thanksgiving everyone!]

Subscribe now

“Curiosity is, in great and generous minds, the first passion and the last.” - Samuel Johnson

“If there’s a new way, I’ll be the first in line, but it better work this time.” - Peace Sells - Megadeth

Learning by just doing

I’ve done a lot of serious things in my career - both academically and professionally. Some of those serious things have arisen from just looking at an important problem and thinking “what happens if I try ____?” Other times something started as play cascades through a chain of coincidences to becomes real value.

This leads me to the belief than my learning about something new is accelerated when I pick some random thing to solve (using the new tech or method). Over time I can become more intentional about what problem is “worth it” to focus on solving. Just mucking around with a new technology on some problems you’re personally interested is a great way to start. At least for me. It builds real world intuition that lets me ladder up bigger opportunities. I think that’s why the “random walk” framing I named this substack after appeals to me.

I’ve approached agentic (“vibe”) coding this way with a portfolio of different ideas that are hobby curiosity based rather than "big problems.” From a few small (but not quite toy) problems I’m building a mental path of what to explore next. More on that another day … let’s talk about otters.

Umm, what’s up with the otters? Is everything OK?

is fond of pointing out how he evaluates each new generation of visual GenAI with the prompt “otter on a plane using wifi.” The results have gotten downright impressive.

This week I decided to give Google’s Gemini 3 AI Studio coding a whirl - and had some breakthrough success on my own non-otter related benchmark prompt. I’ll admit I was sucked in mainly via curiosity and Google’s mention that it was “free.” But now I’m worrying that they’re going to realize that selling my personal data to everyone on planet earth isn’t going to cover my vibe coding bill. Possibly resulting in me having to start paying for another service.

My benchmark test sadly isn’t as catchy as a cute member of the weasel1 family. It’s still quirky, but lacks the mass appeal of everyone favorite slippery (if quite smelly) zoo and sometimes aquarium resident. Instead I seem to keep trying to vibe code a 3D app using those red/blue glasses that went out of favor with cheesy monster movies. Actually a 3D glasses based eye exercise app if I’m being specific - pretty niche, and perhaps sketchy sounding at that.

Subscribe now

3D glasses - wait, what? I think the otters made more sense.

Yes - it’s pretty niche. But there’s serious science behind the exercise part, ie; not sketchy2.

I’d started late to the vibe coding party - as chronicled in my earlier post. For whatever reason that I don’t really recall, when I first got to working on Bolt I typed something along the lines of below into the prompt box;

Using standard red/blue glasses I’ve like to practice tracking 3D rendered discs across a variety of visual paths and speeds. These should be configurable by the user. Ranging in simulated distances to within a few feet out to 30 yards. In addition in a separate path I’d like to use the analglyph approach to work on improving my ability to diverge my eyes at distance (with a variety of practical, fun and safe settings).

It seems pretty random. But there was some method to the madness.

1. I’d been doing some vision therapy that had improved my dynamic vision. I won’t elaborate much on this vision rabbit hole beyond this paragraph. I’d identified my ability to visually diverge and converge as something to improve as part of some sporting hobbies3 and I’d been working on it. In the process I’d used some online (and virtual reality based) tools that had been recommended. They all didn’t seem that technically complicated - but were pretty darn expensive for subscriptions. I wanted to have access to some of the tools, but didn’t want to pay. I’d thought about writing my own - therefore it was on my mind when I tried the first AI coding tools (and needed something to ask it to build).

2. Given (1), I also I figured there was “like totally no way” an AI could code something that niche. May as well swing for the fences when testing the tech that might render my sometimes profession obsolete.

As it turns out, the first time I tried this was with Bolt and I almost fell out of my chair that what was produced mostly worked. In the sense that the output created moving visual targets you could follow with your eyes and deploy the app, etc. However, it really didn’t solve for the important part of rendering working 3D anaglyphs. It failed miserably at that part, and I simply could not talk it into something functional. I’ll admit I breathed a sigh of relief that humans might still count for something a little while longer

Since then, I’ve had good success using modern agentic coding tools for everything from deep dive legacy system exploration to several app based personal project. But I’ve continue to test this pet project idea, without success, on each vibe coding platform I’ve taken for a spin. Which has included among others; Cursor, and Claude Code.

Until now.

Why hello there Google Gemini 3 Pro free trial…

As the book Vibe Coding reminds readers - the AI you’re using to code right now is probably the worst version of the technology you’re likely to encounter going forward. In that spirit, when I got an email from Google saying there was something new to try .. I totally ignored it for most of the day. Frankly, who doesn’t get an email offering some new AI tool to check every 13 minutes. And that’s not even including the hellscape of AI hype that is LinkedIn these days.

But at some point the cheapskate grad student that’s in me thought “free”? Well - let’s at least click on the link and see what Google is spending all the money from exploiting my personal data on?4

If you’ve been even half paying attention you can probably guess what I decided to try first here. Yep - the prompt above about the anaglyph and vision stuff. Now, either I’m getting a lot better at prompting - or these Gemini 3 is a solid leap forward on the arcane benchmark that no one but me uses. I’m guessing the latter.

The biggest difference between the Gemini 3 experiment and tools I’d used so far was it’s ability to (as the kids say) “understand the assignment.” Less about making things move around but ensuring the 3d visual effects actually worked. No other attempt I made has come close - and in a few hours I feel I have something that works well enough for personal use. I’m going to keep tweaking it and maybe it will eventually provide value to others as well.

It’s not perfect - after several hours of playing with it there are some odd regressions, or at least diminishing returns. For example a propensity to dump evolving code directly into the context window (instead of responses) and a continual forgetting to essentially “ship” the changes. But I’m going to soldier on because it seems clear at least the basics work and I’ve never gotten that far before5.

The overall UI implementation seems very slick, Github integration worked painlessly and there seem to be a lot of bonus “vibe coding” bits I haven’t yet tried. Based on the positive experience I pretty quickly installed the Google Antigravity IDE to check out later.

What was my point again?

I’m not sure I really have one. Other than to talk about otters, and note again there’s a ton of truth in Yegge and Kim’s observation that the agentic coding system you’re using today is the worst you’re ever going to use going forward. Turns out that sometimes a free offer is worth trying to get you out of a local minima.

I hope that venture capital and the AI arms race will keep funding these likely under priced tools. I’m enjoying this one and hoping no one shows up to ask for another $100/month like I’m kicking over to Anthropic. It’s fun and all - but there’s no big trust fund paying for my learning at the moment.

In case you’re curious about the benchmark’s output, I included a few samples below. They don’t look like much without cheap 3D glasses - but please take my word they work.

Will this be “useful” or get “scale”? - Dunno, but (a) that’s not really my point, it’s just an anchor to explore, and (b) I bet no one asks Ethan Mollick that. ;-)

Subscribe now

Update: I played a bit more with Antigravity

TLDR; this Antigravity + Gemini 3 thing has game, and a bit of a sharper attitude than Claude. Just don’t try to pay Google for it.

The AI Studio worked miraculously well. Until it very much didn’t. It didn’t seem to understand it was operating in a cloud environment which had limits it didn’t understand. I had some similar issues when Claude Code threw me $1000 in credits to try their cloud version which similarly didn’t quite understand where it stood relative to The Matrix. But the Google one wasn’t just mildly dumb - it seemed to really lack a lot of ability to problem solve. Which them got me to try their Antigravity IDE product.

1. Antigravity seemed to work a lot better in terms of not getting stuck in the same gravity well (pun intended) when I asked it to solve the a problem that it absolute said it knew how to do (the LLM had suggested the specific solution fwiw). As opposed to AI Studio’s interface which seemed to suddenly forget how to save file in the cloud environment, Antigravity made pretty short work of it.

2. Antigravity seems to grab tools more aggressively, or have the ecosystem to better point the user to them than Claude Code. For example rather than wonder if a website was rendering OK it just asked me to install a plugin, possibly sign my soul away, and then it got busy checking stuff directly. I know Claude Code can do it - but Antigravity (in a mostly not creepy way) just got me to do it.

3. I’m still getting used to how Antigravity threads in request for me to look at stuff, and I haven’t even checked out the full agent management mode - but so far I’m encouraged to keep learning the platform. Which I’m honestly surprised at because I was pretty happy with Claude Code. I guess that’s the power of nailing my otter benchmark.

4. So far it feels a little less like “pair programming” than Claude Code did. Sort of like I’m getting bossed around by a senior engineer with a bit of attitude. But hey, if it works…

5. The billing structure for Antigravity has been pretty inscrutable to me. Thanks to Reddit I eventually tracked it down here: https://antigravity.google/docs/plans. TLDR; they’re not charging for it - but it resets every 5 hours and you cannot buy more. I guess when they say free beta they mean “ONLY FREE BETA” - even it you want to pay more. I’m sure they’ll “fix that” soon.

Postscript: Is this like Mallrats with the sailboat?

Short answer: No, not really.

Longer answer: Eyes are incredible things. Yes, we all know because our brains can convert light into a belief that we truly understand the universe in a meaningful way. But they’re also incredible in an ability to defocus a bit and enjoy the sort of MagicEye posters that form a side quest in the criminally under appreciated film Mallrats. Once I had the movie on my mind, thanks to the amazing power of Reddit I was able to find a post that included the famous poster of a ‘Schooner’.

From this I can finally see the 3D picture and also confirm it was not really a sailboat after all. If nothing else all that vision therapy got me to be able to see those hidden images. They’re actually pretty fun, and relaxing in a weird way.

Next up on the Random Walk Through Tech “foundational articles” series will be “Tenets”. Not the movie, not the incredibly frustrating tenants you have in your “passive income” scheme that turned out to be so much work, and definitely not your work on“multi-tenant” architecture.

Tired of circular debates over the same trade-offs? Frustrated when team decisions seem inconsistent or misaligned with the bigger picture? Tenets are a powerful tool that can be a game-changer. But only when created with thoughtful effort.

Tenets are a functional definition by a group/team/org as to how they operate (prioritize, make decisions, etc).

In case you’re not yet convinced to give the podcast a listen, let’s break down what tenets are, and how they can help.

What’s a Tenet?

To build effective tenets, you must understand their core characteristics. Good tenets are not vague principles; they are sharp, specific guides for action. The most effective ones share these qualities:

1. They Hardcode Your Vision: Tenets define a team’s core identity and its vision for success. They are the mechanism for preloading decisions about tough, recurring conflicts, establishing a default path before a specific problem even arises.

2. They Are Pressure-Tested: Valuable tenets are not created in a vacuum. They are the result of rigorous debate and negotiation with other teams, partners, and senior leadership. Tenets that haven’t been challenged or tested by conflict are unlikely to be useful in the long run.

3. They Are Predictive: A well-written set of tenets should be so specific and clear that an outsider could read them and accurately predict how the team would decide on a practical, real-world issue. If the outcome is still ambiguous after reading the tenets, they aren’t sharp enough.

4. They Enable Autonomy: Once tenets are debated and agreed upon, a team can operate with significant autonomy. Leadership can trust that the team’s independent decisions will remain aligned with broader company goals because the fundamental “how” and “why” have already been established.

5. They Are Limited in Number: A team should not have an exhaustive list of rules. The goal is to focus on the most critical guiding principles, with a suggested limit of maybe 6-7 tenets. In most cases I feel 3-4 are not enough.

Now that we understand what tenets are, let’s explore why they are such a valuable tool for any team. Also, how they differ from the mission statement and other similar sounding things. To do so I’d suggest jumping into the podcast, or reading the full article it’s based on.

Subscribe now

Goal setting is a much suggested best practice - and it’s also one with a lot of anti-patterns that cause real problems for many organizations. It’s surprisingly easy to get very wrong. Setting great goals is something that can be learned - and the leverage for individuals and organizations that master it can be huge. I hope you’ll give a listen - or if you’re so inclined click through and read the original posting that inspired it.

I’ve learned and refined the tools described from multiple job experiences combined with reading a fair number of books and articles on the topic. I’m pretty sure these methods are applicable for a wide array of domains and problems.

If your organization would like to have a deeper discussion or enlist some ongoing help in this area please reach out.

A bit about this podcast; The audio was generated using Google’s Notebook LLM product with limiting prompting. I have a shorter version as well that I will publish in the next few days - or not depending on feedback. :-)

Subscribe now

Share

There’s lots more of this stuff - but with just written words over at RandomWalkThroughTech.com. If you enjoyed this I encourage you to subscribe for future articles and jump over to the main Substack to read more.

Reading vs. listening

Writing to share a head’s up on an experiment I’m spinning up this week. The target audience - you don’t like to read, but you’re interested in checking out my content.

No judgment! I’m here (with the help of AI) to help. Though, if you’re subscribing you probably do read. Maybe this is more for your friends who don’t like to read?

Anyway … personally I like to read and look at the occasional cartoon. That’s just me - except when I’m driving, in which case I prefer audiobooks (and not crashing)1. I keep hearing that people love podcasts. It’s gotten to the extent that there are now shows about people making podcasts. Enough that I think everyone will assume I’m referring to a different one. To go with that flow I’m trying an experiment. You guessed it …. podcasts!

But Rich - didn’t you say you were on a podcast once about 13 years ago and you still wake up sweating at the horrific realization that you sound “like that” in real life?2 Yes - this is actually true. A shocking realization that I don’t have the late night DJ voice that my brain induces as a self delusion to keep me sane when I have to speak to other people. Apparently I sound like … not the late night DJ (at all).

Podcast?

What if I could have all the fame and fortune of a podcast without leaving my office and without doing 99% of the work? Well - thanks to Google (and I assume copious appropriation of the internet’s voice actor’s future livelihood ) you can!

Probably not going to achieve the fame and fortune part. Hopefully it will be valuable to those not interested enough to read a long rambling essay - while having a lower bar for their 20 minute drive to the gym? I guess we’ll see…

But how - and isn’t that a terrible, terrible idea?

During a break from my occasionally unhealthy relationship with Claude Code3 I was listening to an online class from Google/Kraggle. Materials included an AI presentation overview of each day’s assigned reading. That reminded me that I’d read Google’s NotebookLLM4 product can product podcast form outputs from a collection of research material.

Rather than go back to my on-again off-again relationship with Claude I thought “maybe I should just goof off.” But I guess I must have already done Wordle so instead I ended up investigating if I could do a podcast from one of the articles I’d written which I wished had gotten a bigger audience. A few prompts later I was listening with my mouth hanging open. This seems to happen when I try new tooling these days - I probably should invest in some tape to keep it closed at key moments.

At first one would think an AI generated podcast is just the sort of slop that’s ruining the Internet. But somehow this treatment creates some special magic that makes this material really come alive. Even if it filters out my snark and some salty language. Or more likely because of that. Perhaps an AI editor, or any editor just does me good. FWIW my dad called me late at night when I sent a sample to him, saying “gee - that’s a lot better than your original article!” Truthfully - I told him I didn’t think he was wrong.

It’s also possible that just hearing a model say nice things about my work makes it seem better than the result really is. But since I’d already done 85% of the work I figured I’d just turn it into an experiment. I am truly interested in what folks think as materials are published. I’ll stay close to the andon cord just in case.

The future

I’m going to pick roughly an article a week that I feel is closer to “practical, useful” than “self indulgent drivel” and try creating a deep dive podcast on it

I’ll start with Google’s tooling but I’ll probably experiment over time. Likely releasing both a longer form (around an hour) and a shorter form (~15 minutes) each week. Let me know what you think and please share it with friends and co-workers if you think it’s helpful.

Maybe, someday I’ll extend this to me talking with some of the amazing people I’ve met through my career5. But I’ve still got a good amount of therapy ahead to work through that whole hearing myself speak thing first. In the meantime I hope this experiment will land for some folks.

Subscribe now

But how long will it take?

I had an interesting discussion with a startup CEO last month. I’d done a deep dive into their architecture and was discussing refactoring to address a root cause bottlenecking their progress. But what he wanted to focus on was timing, schedule and timing. It can be a valuable question - but not at this stage in this situation.

I’d been (as I’m want to do) asking a lot of questions to understand from their informed perspective what outcomes would bring true long term value. Eventually I heard “it seems you have a lot of questions, but I’d like to hear a strong view from you?” So with a deep caveat I shared my take on what I thought their core bottleneck was … and maybe how to fix it in a really direct way.

It seemed pretty clear their current systems state was problematic. Who wants their customers to be able to shoot themselves in the foot via a config file? But I wasn’t yet 100% convinced this was their only giant landmine. For example, they’d suggested that it was hard to close new sales with their aging UI. I was naturally skeptical - usually when people say their UI is ugly the business friction is more that the existing tool didn’t solve a big enough problem for customers to make it worth their while1. But I guess we weren’t going to have that part of the discussion….

Rather than debate the bottleneck and technical fix I suggested, the discussion took a hard turn into “how long would that take?”

This was not a super comfortable path for me. This CEO was very focused on nailing down an estimate, ahead even of discussing the benefits/downsides of the path. Sure, an estimate can be a reasonable shorthand that helps compare and contrast other ideas. For example - I know this discussion was naturally being compared to an internal go-forward plan.

I was sympathetic to wanting a clear, definitive answer. But as they say; for every complex problem there is an answer that is clear, simple and wrong2. This was one of those situations.

I think when you’re uncomfortable about something it pays to pause and try to determine if you’re uncomfortable because you’re scared (of being wrong) or because you think the question itself is wrong. No experienced manager is going to feel super awesome about being pushed hard for a specific timeline. Life experience teaches you that tight estimates usually don’t survive contact with reality and/or if you feel “safe” someone probably padded the hell out of the thing.3

In this case though I realized my discomfort came directly from the question clashing with my view of reasonableness/reality. Why would make anyone should believe an estimate for an extensive refactor I made after 8 hours alone with the codebase?

Subscribe now

When pressed to answer an unanswerable question, sometimes it’s better to answer a different one.

I stammered out something both polite and unconvincing about the fallacy of anchoring on any estimate I provided at this point. Well into this embarrassment I remembered I have a principle here that might bridge both side’s needs. I proactively answered an alternate (and possibly better) question - “What would I suggest we do next given this hypothesis on prioritizing refactoring the trust bottleneck?”

Next I think I blurted out “I just don’t have enough information to give you an estimate of time or cost that you should believe, so here’s what I’d do next.”

Explaining that we could;

• invest a day or two going deep on the hypothesis with key members of their tech team, and if it held up,

• spend a time boxed period (say a week) doing a deeper estimate including what would need to be true to achieve the fastest possible path, and

• Commit to another fixed period researching the actual DB structures to have a more data driven view how risky a migration would be. Researching and prototyping the hardest parts first.

Inside 2-4 weeks I think we’d have a much better view of the landscape as well as significant de-risking of the overall schedule. Being able to stop at any point if we had conviction their original plan was way better.

Put more simply - we’d identify the next most important knowledge needed to make a good planning decision and solve for that. Repeatedly making a series of better informed decisions until we had deeper confidence and a true plan. Thinking back on the conversation I’m sad to realize I think they took this as me unhelpfully hedging (not confident enough). Which was unfortunate because (a) I suspect this is causing them to underestimate the value of a pretty clever path that was proposed, (b) because I was hella confident that this method of planning beat pretend schedule certainty, and (c) it made me realize I wish I’d come up with the phrase that seemed to apply here “you can lead a horse to water but you can’t make them drink.”

Another key negative about the situation - their lack of enthusiasm kept me from sharing my pet name for this approach of de-risking execution. The “Frozen 2” approach. Yes - I’m about to make an off brand movie connection here. Not that I’m short of movie connections to technical themes. It’s just that they’re usually not Disney related4.

Frozen 2?

Frozen 2 came out in November of 2019, when my daughter was on the verge of turning 6, and at a time of year where outdoor adventures in the PNW were less fun than a few months earlier. This perfect storm5 of events contributed to Frozen 2 being pretty big hit with her - and me being open to seeing it whenever she asked. By my count she and I saw it theatrically 5 times. If it weren’t for Covid swooping in a few months later the number of viewings could have been a lot higher.

For sure, I enjoyed the film. I’m a sucker for talking snowmen and mega bonkers plot lines. Even so, around the 4th viewing my mind started to rebel drift. With these free cycles my brain sought deeper insights in the material. Deep as in the root cause of Galactic Empire’s troubles being an unsafe workspace for learning or something of that stature. Not just a quiet laugh on something funny slipped into the mix in the songs6.

What came out of that? A realization that the song “The Next Right Thing” was a catchy one line summary of a truth embedded in many strong decision processes. I guess I’ve been saving it for a substack post ever since7.

Turns out this approach has a more serious name

I’ve realized that what I was trying to suggest in that CEO meeting is often referred to as “progressive elaboration.” Occasionally being blended into the Agile universe into sometimes being referred to as “progressive agile.” According to Gemini it “refers to the use of progressive elaboration within an agile framework, which is a planning strategy where initial high-level plans are continuously refined with more detail as the project progresses.”

While perhaps apropos of nothing this progressive agile thing was interesting, and new to me, so I figured I’d just slip it in here.

Estimates likely won’t make you super accurate, but they will drive velocity

Some readers may remember my discussion of estimation as included in the best practices for multi-discipline pods article shared earlier this year. Much debate around estimates involves the cost of getting good estimates. Specifically, whether it’s worth the trouble in Agile processes and/or coupled with some talk about how dates aren’t important.

This is one of those topics that has merit in the nuance but can quickly be seen/branded as “this group of engineers isn’t serious about going fast or hitting dates.” I don’t especially feel like wading into that minefield at the moment. In my mind estimates are important because expressing your view as to how long something might take services several parallel purposes.

Estimates make clear the assumptions of the dev team, and the team member doing the estimation. If one person thinks a task will take days and another takes weeks - it’s important to notice that. Once there’s some convergence on roughly how long something will that, that enables rechecking if it’s worth engaging in the activity at all. Finally, it anchors any subsequent discussion about whether there are better approaches.

Before you send any hate mail

I’m not at all saying that a project cannot have hard dates. If you’re trying to launch something that’s only used once per year (say tax filing), or trying to coordinate all of Amazon to launch a new marketplace in a new country then not having a stake in the ground will cause endless chaos. But that’s because in those examples the date is the true priority, or is an input to alignment that’s hard to otherwise achieve. Bringing an abstract “dates don’t matter” mindset to a discussion as an engineering team with stakeholders is like bringing Schrödinger’s cat a knife to a gunfight. It’s unlikely to work out for you, and at best you’re gonna feel pretty silly once you realize what’s go.

Look… probably understand the point you’re trying to make with the whole “we don’t do target dates.” Agile is about delivering shippable results, incrementally. Flow and throughput are most important to get to that as quickly as possible. And lots of other sorts of justifying statements. But … and it’s a big “but” … this never lands the way you think it does. Generally it’s greeting with a level of enthusiasm usually reserved for the caterer who serves the bacon wrapped pork ribs at rabbi convention buffet8.

All that usually happens is whatever PM or other person you’re talking to immediately slacks me (or your equivalent) and asks “WTAF is up with the team that doesn’t care at all about hitting dates?” Then after I explain all of the background to them they just spend more time than is strictly healthy stuck in the mental model that anyone who says what you said must be really slow and phoning it in9. ;-)

Much better to be curious why the date is important in the other party’s world and work back from that.

What was the next right thing? In case you’re curious

In this case I believe my short term instincts were correct. The next best things to do were to (1) check if my hypothesis passed an initial sniff test (2) invest a day or two (more likely 3-8 hours) to have staff technologists poke at what would have to be true for it to be a solid approach, and (3) run a focused sprint to expose and assess technical risks (for example by scanning the actuals of the database situation - more no that in a sec). Basically what I suggested to them above - though it’s probably a smidge clearer now that I had the time to write about it. Clear writing being clear thinking and all that.

In case you’re really curious about this story at a slightly more detailed level. Based on what I’d heard from discussions and extrapolated from the codebase; their execution was going to be deeply challenged until they addressed an architecture issue enabling customers to make breaking changes by editing local files10. My thought was to break the bottleneck by allowing customers to edit their local config, but to disallow that being translated into alter_table commands (which turned their series of multi tenant DB’s into a random mish mash of stuff). Instead intercepting that workflow to translate “custom columns” into a more dynamic persistence such as structured JSON.

I was no more confident in my hypothesis than I would have been in a schedule to execute it (OK - I was more confident in the former than the latter). So it’s critically import to attempt to invalidate my assumptions by checking (a) someone doesn’t have disconfirming info on the tech team and (b) they’re not willing to staff up significantly just to cover this toil and free up time for other things. Though since customer trust is probably broken when the system stops working occasionally I still suspect (b) won’t be convincing on it’s own.

A small caveat

There’s a theory of decision making that basically points to the need to make decisions in a quick manner. “Don’t worry about making a wrong decision, because if that happens just make another decision.”

Generally I think this is right approach because even when you make good decisions (ie; given the information at the time you made the right one from an expected value perspective) things can still go badly. Even something you’re 85% sure of goes sideways 15% of the time - the quality of the decision isn’t the same as the result. However, this assumes the issue at hand is in the “two way door category.” Once you walk through that door it’s pretty easy to just go back to the other side.

The challenge however is that aome problems are very much in the “one way door” segment. These are decisions that once made are hard, impossible, or expensive to reverse. You may still resolve ambiguity in a stepwise way as you approach their event horizon by doing the best/right thing. But you should over-invest in decision quality as having to walk backwards will be a lot harder than walking forwards was.

Share

“In all affairs, it’s a healthy thing now and then to hang a question mark on the things you have long taken for granted.” - Bertrand Russell

“Just because you’re paranoid doesn’t mean they aren’t after you.” Joseph Heller - Catch 22

TLDR;

Hi, my name is Rich and I’m a vibe coder.

I hate the term but I love the superpower. Modern coding assistants grant abilities akin to relocating from Krypton to the yellow sun of earth. Especially for the curious later career technologist who has lost sleep that a lack of recent hands on building clashes with their childhood identity. Though at first you can feel like you’ve lost the instruction manual for your super suit1.

Today is part memoir and part (hopefully) useful observation about modern coding tools. It’s also a call to arms to try it - especially if you loved to build but now throw up your hands at the IDE muttering “OMFG - which packages do I need to install again?”

I thought it might just be me. But as I speak with technologists of my generation they’re all dancing around like the folks in Cocoon after swimming in that alien infected pool. Though most younger than most of those actors except for (checks notes) Wilfred Brimley2?

I’ve been reading listening to Vibe Coding by Gene Kim and Steve Yegge who make the same observation about AI bringing people back to coding who’d gotten off the train long ago. Perhaps, given the current state of the job market it’s unclear we need more people coding in the workforce - but I have to admit it feels damn good to get the rush of building without having to spend the next century figuring out which set of packages I need to install to do _____ with Python, while also trying to learn 3-4 new hot languages. Just don’t need that validation of knowing every bit of arcana anymore. I mean I coded for money in assembler and C - so dammit - get off my lawn!! ;-)

For more practical information you should probably checkout Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond3 and follow Gene and Steve’s budding podcast and publishing empire. It’s paints the big picture with great enthusiasm, while also giving practical frameworks for working with the current (imperfect) state of the art. I’m unclear how much I’m going to add to the discussion beyond them - they even have an excellent metaphor involving The Swedish Chef and agentic coding gone wild. That’s hard to compete with.

Even so I wanted to get all of this stuff out of my head. Selfishly, it’s cheaper than therapy for me, it helps me think, and if it helps someone out that would be awesome.

If you just want to see a summary of what I think is useful to remember about this brave new world then skip to the summary section at the end. You’ll miss out on the journey as well as a few pop culture references - but there’s usually a price for efficiency.

A few quick caveats

Working with agents to code is fun and at least for what I’ve tried super productive. That includes small mobile apps, new domains such as VR, and dives into complex code bases. In the more complex cases the AI alone is not sufficient - I had to engage with it aggressively as I would with a senior (and occasionally) junior colleague. Otherwise it could make assumptions that were incomplete - though to be fair so could I. This was actually what made it so much fun. Attempting to one-shot something even remotely complex did not work in the real world. At least for me.

What I really don’t have insight into is how well would 50 developers running their own crews of virtual partners do in a moderately to complex codebase? Without deep thinking and guardrails I suspect anarchy would reign. Having things structured to support this in the beginning will be as important as it is now for your company’s velocity to avoid grinding to a halt. Actually … maybe ten times more important.

Then there’s Vegas fallacy - when everyone who goes to a casino seems to feel they’re a winner. I’m not sure how exists in a world of loss aversion - but I’m pretty sure most folk remember the times they won and don’t net out their actual losses. Coming away thinking they did better than they really did. That’s definitely possible with vibe coding. Even though I’m pretty sure the results I’ve had so far are hugely net positive, depending on your situation, your background, and your codebase mileage may vary. It’s worth taking notes about the ups and downs vs. just leaning “did that go well?” to your memory.

Subscribe now

The professional fountain of youth?

Some time ago I posted “I’m thinking I’m back.” This was 90% to get silly John Wick references out of my system, and 10% to signal to myself and others that after a much enjoyed sabbatical I was re-entering the technical arena. I wasn’t sure what that re-entry would look like, and I’m still honestly not sure. At the time I was thinking either a traditional job or maybe a period of consulting/advising.4

In the meantime I’d planned to do something I always enjoy but often don’t often get to do as a primary focus - work hands on on actual technical tasks. Sure there are the moments I’ve gone rogue with something here and there. Early on in my Amazon career I built a live code white-boarding tool because I was tired of hearing people read code over the phone5. The Amazon Video team ran a little wild with it for a time before legal got wind of the whole thing6. Once in a while something like that will happen - but truth be told, it’s been more than a minute since I’ve done more technically than read on the side and brainstorm with people in the office.7

The days of staying up to 3am because I just wanted the processor to boot from the EPROM or the code to compile and run or whatever have been in my rear view mirror. Lost was the incredible, indescribable joy of seeing the right lights flash on your development board at 3:05am when things finally click.

Consulting/advising and maybe a full time leadership gig sound good - but at least in the interim modern technology maybe has presented a third option - building stuff again. For me - more importantly it also exposed a way to turbocharge how one approaches those jobs traditionally. This article is partially a rundown on what I’ve been up, maybe some learnings other might find useful, and an open dialog with myself as to where all this is going. Based on a lot of conversations I’ve had, and comments in Vibe Coding I’m far from the only technologist jumping back into development and having a blast. I plan to write more in the future about how I feel agentic coding can (and should) change work as a technical org leader/guide.

Spoiler alert: it’s all been a hell of a lot of fun, I somewhat have to wrestle with the identity question as to at what point of developer abstraction am I “not really coding”, and the unsettling feeling that what’s great now could become apocalyptically challenging for the professional later. I suppose that’s where the double edged nature of “may you live in interesting times” comes from.

I’m not sure of anything really - except that the times are indeed interesting (and a changing). Thanks for joining me for the ride.

Have you heard the good word about agentic coding tools?

There had been all this talk about AI assisted “Vibe” coding and I did try it out relatively early on. I found it pretty amazing as I went from Bolt and later to Cursor.

As described in the recent book Vibe Coding I had my own revalation moment while checking out Cursor for the first time. I’d built some toy problems in Bolt and had downloaded but not tried Cursor. Then in an earlier article I’d made a bunch of AI generated video - but wanted to create a new aggregated display frame to represent the scene. I could describe what I wanted (“go through the video and grab a still at each cut scene and then do a 3x4 grid image that combines them”). I figured there was a universe in the multi-verse where I could bang out a script to do that - but that earth wasn’t this one. I figured (quoting my dad) “what could it hurt?” to try Cursor’s new agentic capability and see if it could serve as an interdimensional portal.

I gave Cursor it’s shot and my mouth must have been agape for at least 30 seconds at the result. I was looking at a jpg created as I’d wanted what I asked from the input video. From roughly the prompt above Cursor8 had built an app that opened a file selector, let me choose a movie file, skimmed through it and output a composite image (letting me choose the destination). It wasn’t perfect but I explained roughly what I wanted (more clear differentiation between sampled frames - not just time based) and the system proposed an algorithm and after agreement from me knocked it out. Worked like a charm. Elapsed time: 15 minutes - probably less than it would have taken to convince myself that I couldn’t google up someone else’s already existing solution. Wow, just wow!

From there, I’d like to say that I dove deeper and deeper in agentic coding. But I was in an AirBnB in Florence at the time, so mostly I filed away my religious awakening and went back to our epic vacation.

Back in Seattle I decided to jump back in with terminal based coding with Claude Code. It seems even more removed than something integrated into an IDE, so I was again skeptical9. I sat down and thought for a while about an idea of something to built - not because I thought I had a groundbreaking product idea, but because doing a “hello world” app is pointless in this new world.

Long story short - before I knew it I was totally hooked. While I’m not expecting riches from any of the results so far I have been able to get a lot done across diverse surfaces. I list them just to share the variety, which still astounds me at times.

So far I’ve dabbled with a surprising degree of success into;

• A blue/red glasses 3D application idea that I tried on Bolt. Bolt got it partway there but struggled. I’ve picked it up recently with Claude - but it still needs more work. Not surprisingly it’s gotten stuck on the proper rendering of anaglyphs. Which is pretty fair - it’s similar to an example in Vibe Coding where veteran devs ask an AI for a complex distributed cache and then flip the bozo bit when it doesn’t work with a one shot prompt. I purposefully chose something that seemed impossible and it’s actually pretty close to working. Once I have time to manually debug or better prompt the rendering expectations I believe it with unlock much of my original vision. Semi-pro tip though - start with something you could picture building yourself and that doesn’t seem so super niche.

• An iOS/Android app that implements an image data capture workflow for a side interest. It’s a pretty basic workflow for something that doesn’t really need a mechanized aspect - in that it can be measured by hand with a camera app. I’ve explained the process to folks a few times and they didn’t quite grasp it. That made it a good candidate as proof of concept (of my ability to build and ship something). End result: a pretty solid app that I’ve tested on both Apple and Android devices and I’m working through shipping it to both apps stores hopefully over the next few weeks.

• A website for the above mentioned app. Much slicker than I should have been able to build with my own web dev skills.

• Another website - with a turbo charge on the building + content creation and visual design stuff. A solid, functional first version of a website for another idea I’m noodling on. Claude Code even helped me work through some ideas for payment processing I may or may not need in the future.

• An app for the Meta Quest using the Unity framework. I’ve been thinking to try this particular idea for at least a year and a half - but baulked hard when I reviewed the pages and pages of setup for the Quest. I’d been diving into Unity back then (BTW - it’s so cool) and I think I spent a couple of weeks off and on trying out tutorials. Making a ball bounce and so on. In roughly the same period it took to have partial understanding of basic elements, with Claude Code I got what feels like solid bones for my original concept. I think what I have does about 80% of the value prop I had in mind. This work was way slower and occasionally more frustrating than a basic mobile app. Likely because Unity development seems less likely to have been a huge part of Claude’s training set. But even then, way faster than what would have happened left to my own devices10. As a nice benefit I have a way better understanding of Unity coding than I would have had in the same time as I truly partnered with Claude as we debugged “together.”

Oh - sorry, almost forgot the big one that made me a hardcore true believer in my partner Claude

• While talking to a startup about a role they introduced a practical problem mid-process. I was down with this idea as talking through a real problem with potential teammates. Though I didn’t quite expect the actual assignment11. Which was, to summarize lightly, “hey - we have a 15+ year old codebase that is limiting us from doing like everything. Tell us what a re-architecture looks like?, how you’d in detail get every enumerated constituency onboard?, and show your work in terms of milestones/timelines/resources. Here’s a link to our Git Repo which has no documentation.” I was about to send them a quote for 3-4 weeks of consulting research instead of continuing the process12. ;-) But then I decided to see what sort of trouble me and Claude could get into on a weekend evening. More on that later. It’s worth the wait I think.

This list of “project” work doesn’t even refer to the many other practical workflows that Claude Code worked through as a partner with me. There seem to be many things it brings fluidly to (due to it’s agentic ability to access tools) vs more common direct chat interfaces. Wondering how to setup Google Analytics? - Claude as on it. Google Analytics only lets you do something by hitting an API? Claude will toss together a Python script to get you unstuck. Question about a companys tructure? Well, truthfully, ChatGPT’s chat client in deep research was a little bit more useful. But if you wanted to stay in the terminal environment Claude Code was willing to give it a go.

Basically though if there as something needing doing and I had the terminal window I’d role the dice. Let’s just say that when Anthropic hit me up for the more expensive than $20/month tier I didn’t think about it long. But maybe don’t tell them I said so…

I’m not claiming that anything I banged out is a $100 ARR company in the making. But the thrill is undeniable - and it’s very easy to feel at least like Kal-el’s more engineering oriented cousin in the warm sun. It’s a nice sensation.

But won’t coding with AI inevitably devolve into me being kicked out out of an airlock or something similarly bad?

Well - that’s the plot line from 2001 - A Space Odyssey and you’re not in outer space. So don’t be silly… AI isn’t going to actively try to murder you. At least not until mid 2028 when Skynet really goes online13. Though maybe don’t temp fate by setting up an MCP server to access both your gas line and electrical system simultaneously or the automated crossbow idea you’ve been working on14.

Kidding aside - you should be worried about all the things that your occasionally erratic partner can get up to. If you’ve ever worked with an intern who could grind out thousands of lines of code while not understanding the assignment15, or wondered if an engineer was joking when they said “don’t worry - I turned off all the alarming until I’m back from vacation”16, or hired a brilliant technologist with an notable lack of short and long term memory - then you can guess at the unpleasant things that can happen to your code base if you’re not paying attention. These can and will all happen if you don’t pay attention.

The good news is that if you’re follow some defensive in depth techniques, and don’t attempt to multitask watching Seinfeld reruns while working, the net results are likely to be positive. Depending on your codebase you may hit some diminishing returns - but just because your tractor can’t drag race17 doesn’t mean it doesn’t have tremendous value. The book Vibe Coding has some clear ideas on how to minimize pain for your future self/team. Reading that is a shortcut that would have saved me some time - though the best teacher is both reading the book and building some stuff on your own.

Just remember to verify everything. It can be funny when one of the following actual things happens;

• In response to asking Claude something along the lines of “why do you think ____ to be true?” you get an explanation that starts with “ISSUE: I likely made this up - need to verify or remove.”

• When Claude Code suggested adding some computer vision analysis to a problem we were working on - but then mentioned when eye detection failed something remarking “hmmm - normally the eyes are about there relative to the head.” Causing me to ask “how are you detecting the pupils? Are you using a CV algorithm or just guessing?” only to get back “There’s ZERO actual computer vision happening - no pixel analysis, no edge detection, no pattern recognition. It’s just mathematical guesswork based on typical selfie composition.” Props for the admitting when busted - but not exactly confidence inspiring.

• When I noticed that Claude had written up custom functions in Unity for just pointing at a menu button I challenged it to use core functionality instead of doing something custom. When the sheepishly written basic code failed it’s first several excuses were that often Unity (possibly the most popular platform for 3D game development) didn’t have reliable item selection. That seemed unlikely. Now to be fair - I’ve had similar discussions with engineers I’ve been equally skeptical of.

• Many, many other similar situations that were too evocative of your clever 5 year old. Who for a second seems credible when they tell you with great confidence something obviously untrue, but who cave upon the slightest inspection of reality.

These are all funny at first. At least when compared to the horror stories you’ve heard of a coding agent wiping out a Git repo18 But still not that funny if you were just in some bizarre 2025 LLM coding version of Who’s on First that went in circles for days. Been there, done that, would prefer to return the t-shirt.

As an example of something that caused swirl … even if you repeatedly tell your partner to

• assume Unity has working functions for basic things like selecting objects in a scene

• Do not assume baseline functionality is broken and write your own from scratch

• verify reality in code before making assumptions that inform your planning

• Do not check things in until you’ve confirmed they work, and

• Stop freaking writing sentences like “now we’ve have a working professional grade interface” after botching something 10 times in a row19.

It may in a (“I can’t hear you”) passive aggressive way keep conveniently forgetting to do so. And when I say “may” I mean “very often will”.

You’ll want to practice defensive coding, excellent testing - and finally give test driven development (TDD) an honest try. It turns out that guy you worked with who literally wouldn’t shut up about it was 100% onto something. Even if slightly ahead of their time.

What has to be to to maximize velocity of this rocket ship?

I had a great conversation with friend20 a week ago. He was talking about what he saw as a huge advantage of startups building today. It wasn’t for the reason you see freaking everywhere on LinkedIn about the one person dev shop rocketing to $1B due to their super powered AI coding chops. Instead his thoughts centered around the observation that if you’re building your codebase now you could focus on the things that really enable a team to get maximum leverage21. Whereas even a startup 2-3 years old might have an architecture working as a headwind.

Of course I was curious what that enablement meant to him. What I recall him sharing fell into the following buckets (as I nodded my head along with him);

• The right language was selected to really lean into what AI knows. This seems super valid as the distribution of training data for models is not uniform across all languages and systems. Even polyglots have limits.

• Your system should be loosely coupled, and modular with a clear separation of concerns. AI seems like magic, but even frontier models hit limits of memory context if you push hard and long enough. Being able to reason about separable things should help a lot.

• Breaking the work units down into digestible chunks. Working with the AI to developed each phase: product doc -> tech spec -> design. You can “vibe” - but you should still break work down. One-shot success is an urban legend.

• Automation first focus including strong CI/CD pipelines and testing. This one enables a lot of velocity because it combines the benefits of being paranoid (which I think we all agree on) and as the Vibe Coding book points out it quickly becomes inefficient to feed errors back to the models manually.

• Code reviews (using AI). Interestingly enough (and Vibe Coding gets into this) asking a coding agent to judge another coding agent (even if they’re the same agent) tends to make things better iteratively. Due to the somewhat stateless nature of models it’s as if you get the “external viewer” benefit even if you think the model is just regressively investigating itself.

If you’ve been coding professionally before you might be thinking:

Well, yeah - pretty much. But it’s still 100% on the money. If you’re in the middle of a one of those “crap - everything is too slow and we need to stop and refactor” moments AI can help. But - if you’re starting clean the payoff for being deliberate in how you build vs. a moving super fast and dealing with the consequences later22 may be a LOT higher than it used to be.

I can’t help thinking that when these best practices become the existential keys to unlocking big velocity bumps it could result in better long term code that we would have had otherwise. At least for organizations who understand that the importance of good hygiene is way higher without high judgment humans. A contrarian (if unrealistic) take on vibe coding code quality.

Don’t take this to mean you can avoid the hard work of discovering great goals grounded in a future reality that brings values to customers. But it does mean that if you’ve been paying attention to software development for 5 years, or 10, or forty - what you’ve learned about high performance teams still matters (minus many of the syntax requirements and the debates about tabs vs. spaces - thankfully). Or maybe in other words:

The startup codebase deep dive that ended with a Boscht Belt joke

When you’re gaining confidence in a technology there’s a point where you go from “wow, that’s pretty cool” to “holy shit! even if this never gets better this is gonna make things … just freaking wow!” I’d been pretty happy with the apps and website I’d worked on with agentic tools - the fun factor was high and I felt a surge of familiar “builder” energy. But I wasn’t sure how that ability would scale into a system that was … let’s say … a big more grizzled and long in the tooth.

Two months back I’d been speaking with a Senior Principal Engineer at Amazon - just shooting the shit about coding agents. He felt that his experience showed a sharp starting acceleration (going from 0-60), and then some leveling off. Which meant - maybe not 10x velocity forever. But one thing he was 100% convinced about was the ability to pickup a new codebase and get a sense of what’s going on a bazillion times faster than before. This was recently on my mind as I spoke to a founder about possibly doing some due diligence on behalf of his potential investors. But I hadn’t really gotten a chance to take the car out for a spin for real before that startup’s “job interview” assignment came in.

I was sitting around that Sunday night staring at the two page “prompt” that was intended to inform an hour discussion later in the week. I’d been waiting to see what other info was going to be forthcoming and it was starting to look like all I was getting was a link to their Github. I figured I’d stew a bit over the remains of the weekend and share wherever I landed on Monday. But before dinner I remembered that Amazon Sr. PE conversation and thought “well, I have the repo access and a while ago I figured out how to let Claude use my access keys. I wonder what Claude could do?”

Figuring it was all upside in terms of learning I turned Claude Code free on the codebase. Just focusing on it getting a handle on things and asking it to teach me about the architecture. I didn’t (at least for the first few hours) share the “assignment” - though I eventually did in the interest of partnership. :-)

I could see the repo was extensive but I didn’t look at the core status until just now. Upon some investigation I’ve realized the starting point was a link to” around 2.5k C# files, with about 420k lines of code. Information about their database setup with over 54 tables, and 1400 lines of SQL schema definitions. Plus a front end system with 200 or so Javascript files (and other stuff). In total about half a million lines of code over 750 files across 15 years of check-ins. Also - I’m not sure I’ve ever written a production line of C#.

While I’m still in discussions about my analysis and not 100% sure of the conclusion I think I was able to make remarkable progress. Understanding the general architecture, finding inconsistencies in my (and Claude’s) assumptions, asking 4 or so emails worth of short questions to a staff member at the company, and then feeling like I was able to zero in on the core problem that was bottlenecking them.

In a 15 year codebase there’s always going to be things that are making progress feel slow. Initially I thought the issue was the remarkably high level of separated databases in what was organically a multi-tenant system. But due to Claude’s ability to review both broadly and deeply, with a power assist from my questions (both to Claude and a human answering our emails) we zoomed into an unexpected conclusion.

Diagnosis: A well architected monolith where within 400 lines of key code there was a (likely) tractable problem. Users given the ability to take an action which due to tight coupling broke production integrations. Leading to me also learning Claude has a sense of humor (and also perhaps now I understand now how people end up in “relationships” with AI).

I’m optimistic that the hour or so work “we” did beyond this point has identified a surprisingly narrow surface that will allow a structural fix. Enabling option value on which older portions of the code they can work on next - maximizing customer and business value rather than be stuck at “crap, we’re spending all this time fixing random breaking things that is hurting trust with customers.”

Do the engineers on the team already have this clarity? Maybe, probably - but that’s not the point. Could a deep dive like this have happened a few years ago into a codebase of this size, absent documentation and access to hours and hours of lessons from the legacy system’s most experienced engineers? Nope - I think not.

Total time for me invested: about 8 hours - all of which were some of the most fun I’ve had in a long time.

In summary

Shortest summary: Pay for Claude Code (or Cursor, or Amp, or almost any first order tooling). In parallel read Vibe Coding or some equivalent voice slightly from “the future” whose been playing with coding agents and isn’t just a hype jockey.

While you’re playing remember you can more easily do all the best practices you’ve known you should be using but likely skipped a few of most of the time.

• Write down success first - in the world of the customer (or financial needs of the business)

• Break down your success into clear, verifiable definitions

• Write out how you’ll evaluate correctness (functionally what will you check)

• Write tests to do that checking continuously

• Design out your architecture in pieces that takes visibility and modularity and separation concerns and all that stuff into account. Use AI as a partner. Just don’t always trust it without checking. Be extra skeptical and challenging if you’re unsure. One nice aspect of AI is it doesn’t get defensive if you ask aggressively - so you don’t have to focus on just “what” and “how” questions.

• Maintain up to date documentation and continuous integration/building that uses all that TDD stuff. AI can help write documentation - at least in the sense to help it rebootstrap in new sessions what it was thinking. Remember - if you don’t help it the current generation of tools are super forgetfull.

• Automate as much as possible so that manual testing is minimized. Think puppeteer for UI, MCP servers for your IDE or Unity install.

• Ensure code reviews happen. People are good - so is AI. Github has some pretty amazing tools I’ve not scratched the surface of that allow automated PR reviews by Claude (and I assume other models).

• Keep auditing that things are as you think they are. Trust but verify. Paranoia will not destroy you.

• Have fun and stay focused on the long term user problem

• Monitor shit - seriously - paranoia is your BFF. Worth saying twice in one list.

• While building try more ideas out (multi tracking) vs just committing to one problem solution path before you have all the data to make an informed (good) decision

• Enjoy the ride.

Used properly you can learn from new ways of building and try to avoid, or at least forestall the GPS dumbification problem. Before GPS if you wanted to go somewhere new you used a map. Or if you weren’t a stereotypical man you’d get close to your destination and then ask a local for directions. But nowadays if you’re like most people you may find yourself checking how to get somewhere with your phone even if you’ve been there a number of times before. Similarly - depending when you met your partner or BFF you might not be able to recall their phone number. Used badly coding agents have this same trap. But my take so far is that used with even a smidge of paranoia and curiosity you can learn a ton about being a better engineer while they take over for us. ;-) The choice is yours.

Thanks for reading to this point. I truly appreciate your attention. If you found this valuable or just fun to read - please consider sharing with a friend. Look forward to reading about your experiences in the comments section.

Subscribe now

21

Shockingly, Maximum Leverage is not the name of a death metal band. Or any band that I can tell. Though when I tried to buy the domain I perhaps figured out why. It seems the Ticketmaster abuse of customers model has now reached out to domain name registars as you can see below. BTW - you’re thinking “maxleverage.com” would be cheaper - you’d be right. But only by 1/3.

Though maxleverage.blog was available at a deep discount. If you’ve got a good idea for it let’s talk. Because eventually judgment got the better of me before I continued on a buying spree: maxleverage.music and .band are still available, and a steal. You’re welcome…

22

You know, the way pretty much all startups have done it in the past. Well, maybe all startups that survive based on my statistically invalid sample. ;-)

Background

Last article I started without a theme, riffed on a random interview question I was facing, and ended up with a post I’d labeled as being about “integrity.” By the end of it I’d teased a followup with another related story on the topic. Mainly I did that to force myself out of the “what will I write about trap next?” by preloading a semi-commitment. I figured there was a 20-40% chance I’d back out and cover something else. But the article seem to hit a vein with folks. Meaning that I got a few more positive notes than I usually do1. One of them was along the lines of “well, that’s a decent story - but I know you’ve got way more provocative ones - such as the time when [insert story about someone who knew a goal was being measured inaccurately but didn’t do anything about it]. ” I remembered the story they were referring to2 but didn’t want to expand on it given it was a 2nd hand “juking the stats.3” encounter.

The story I had in the mind at the end of the last article did fit reasonably into the category of story the friend was referencing. That plus the dopamine hit created by people giving positive feedback on my writing bolstered the “integrity” required to follow through on the promise of my last post.

I’m not sure this story really is all that connected to “integrity” - ie; having strong moral principles, in general. But it is an example of how if you care more about looking good in the short term than long term value it can degrade your organizations effectiveness in complex ways. Since my editor has taken the month off4 I’m just going to run with it.

The story: So I come into work one day…

And a couple folks come by and say - “Rich, can we talk?” and when I nod they grab an office for some privacy. Since they probably found me sitting near a kitchen5 in an open space I was immediately intrigued. Most conversations were fine to have out near the snacks.

But first - a bit of background

At the time, I was working with the Brand Safety team at Facebook (currently Meta). “Brand Safety” is a catchall phrase that describes the desire of advertisers (aka “Brands”) to avoid having their company caught up in an unhelpful mess arising from their advertising dollars (and thus their organization) appearing to support something controversial. For example: Proctor and Gamble most likely don’t want their ads for soap showing up in ISIS recruitment videos or white supremacist content6. Advertisers similarly (though to a lesser extent) may want to avoid their ads running alongside debated social/political issues or edgier/adult content.

There are tradeoffs involved as everyone would love to have (i) huge reach and conversion (ii) low prices, and (iii) Disney-esque brand safety7. In reality you usually cannot have all three. Most advertisers are making some tradeoffs. Large brands with broad appeal tend to care about such stuff8. This is why most content based advertising platforms have a mechanism in place to (a) evaluate content across multiple dimensions that brands care about (b) a way for brand advertisers to signal what’s OK and not-OK for them, and (c) a process to avoid matching not brand safe content with advertisers.

It’s not just that brand sensitive advertisers are avoiding what you’re think of as NSFW content. Someone in the airline industry might be especially interested in avoiding news about air travel issues. Others might just want to avoid news as a category. It gets complicated.

What’s important to the story is that our teams ran a process that labeled each new video that might be eligible for monetization along a few axes of interest. For example; did this video cover a debated social issue, have hateful content, or adult content (say rated R+)? The labeling was done by a combination of machine learning algorithms and human reviewers.

Avoiding mistakes was important as was labeling throughput. The former was necessary to maintain trust with advertisers, the latter impacted the monetization for creators (videos tended to get a lot of views early and taper off - so taking too long to get a video checked out would limit financial upside). We cared a lot about this running smoothly - and as such measuring the accuracy was a continual process, against which important goals were set.

The good news that the accuracy had been high for a while - so nothing to see there. Or was there….?

Back to our story - the big reveal

In the conference room the conversation went something like this9:

Engineer/Data Scientists: Rich, we were going over the data for video labeling accuracy and found something. It’s pretty surprising.

me: OK, let me have it

< Insert conversation about how we had a couple of review stages and the way we combined them turned out the accuracy measurement had gotten botched up for a while >

me: Oh, I see what you’re saying. Once you frame it that way it seems pretty obvious we had it wrong. TBH - I feel a bit silly for not noticing it earlier. So to summarize - it seems like the way we’ve been combining QA assessments means that our accuracy is something like 80% vs. 99%+ accurate10?

Engineer/Data Scientists: Yup - that’s about right. (some folks look meaningfully at the closed door).

me: OK, got it. Well - since you’ve been thinking about this - any ideas on how to improve the accuracy now that we better understand the state of reality?

Engineer/Data Scientists: Yes - actually we do. Let us explain…. <insert long explanation of great ideas to improve.>

me: Hmmm - so let me recap to see if I got this. We’ve thought our accuracy was 99% for the past year (after we made a set of big improvements before I joined). Now we realize it’s lower by a good amount. The “good news” is that advertisers generally were pretty happy with the way the system worked - so it’s not as though there was obviously a big problem in the system. The “better news” is that we realized we had a bunch of ideas to really make accuracy way better than it is now. The “bad news” is we were wrong about a metric we published internally and might feel a bit silly. How’s that?

Engineer/Data Scientists: yes - that’s right.

me: OK - well thanks for finding this and letting me know. So … what’s the question?

Engineer/Data Scientists: well, we’re wondering what to do here given the metric isn’t accurate?

me: Well, it’s an internal metric - so I guess we should writeup what we learned, and explain how we will pivot our planned work to implement these big improvement opportunities you found. Of course it’s complicated so we should help everyone understand the choice by providing. The alternative would be to not mention this and not invite discussion on pivoting to improve the accuracy - and that seems bad for advertisers, creators and long term trust. I’ll need your help but I’ll writeup the docs/presentation etc and speak to them, etc.

Engineer/Data Scientists: (with what seemed like a look of relief on their faces) That sounds great! But you’re sure?

me: Yeah - I mean it’s a little bit awkward but (a) I don’t see much choice as we know the metric we use as a guidepost is inaccurate, and (b) I’m actually truly pumped that we can make it way better. I’m sure that even if by improving things by like 70% the final “accurate” number is slightly below what we publish internally now it will still be a HUGE win.

Engineer/Data Scientists: (looking slightly skeptical, but still positive) - OK, sounds good.

When one is writing it’s often easy to without even making so make oneself look good. Therefore, I want to be clear that the heroes of this story are the 3-4 engineers and scientists who noticed this and brought it up - and brought forward effective ways to make the system better.

Anyways … As promised I got to work letting my boss know, and writing up some explanation as to what we’d learned and planned to do.

Why it’s good to be worse off than you thought sometimes

Now, you could see this as justifying a mess, or at least making lemons out of lemonade and retconning why you had lemons in the first place, having been sent out to buy mangos. You’d think that would be my view given how cynical and glass half empty I can come across. But I’m more nuanced than you’re giving me credit for. In this sort of scenario I really do view it from the “wow, that new opportunity looks WAY bigger than we thought” angle. It turns out I really love lemonade, including the making it part. Or I’m delusional and self justifying - so I’m going stick with the liking lemonade thing.

Next steps - goals matter, even when maybe they should matter less

Over the next week or two I met with various people who one wouldn’t want to surprise with a “new and worse” accuracy measure. While I take some personal pride in not overly focusing on managing optics upwards11 - I’m not completely naive and realized that explaining this shift could go very badly. Going badly could mean tons of extra time explaining and re-explaining ourselves, only to have the team’s strong work be unappreciated. That seemed like a lot of wasted time and a bad outcome. To avoid that I tried to be careful and intentional in taking people along.

We built up a way to walk people through what we learned, why it was missed before (including by the many people who would/could later judge the miss), and the big new opportunity to improve. Highlighting of course that feedback on the existing system had been strong - likely because of the improvements the team had made before I’d arrived.

By this point I’d been at Facebook long enough to see that goals were taken extremely seriously in terms of perceived impact and tied to compensation pretty directly. Even though I believed that goal setting itself was a less rigorous process than I’d lived at Amazon. It still didn’t occur to me that mattered with respect to this decision - as the path to long term correctness is to worry about the eventual outcome more so than short term setbacks. Believing the error rate was 99% if it really was 80% just meant there was a huge number of possible basis points improvement we would ignore. I truly did see the “oopsie” moment as a big win in disguise. Naively, I also felt that if you were going to play fast and loose with checking “correctness and alignment with outcomes” of goals on the setting side you’d need to have a faster trigger on updating the goals as new info came in.

What happened next? Well - it turns out the team was right to be nervous about “doing the right thing.” While I got understanding feedback as I helped us manage the shift - I don’t think it ever really stuck. I’m confident that at least my manager understood what we’d learned and agreed with the next path. But it was really, really hard to shake the broader org’s belief that somehow we’d screwed up and were trying to argue our way out of the fuck-up. Otherwise “how could they have ended the quarter with lower accuracy than they started?” - or so I heard A LOT.

To this day I don’t know if it was truly an understanding issue (made harder because no one would ever go backwards at a goal at this company), or it was understood but it really was just not acceptable for any reason to restate a goal.

Nothing truly “bad” happened to the team, even if it was pretty annoying to have this undercurrent of “those people messed up” and “can you explain again why accuracy went backward?” dog us for many month. Also a bit annoying to have these questions show up in one’s performance review. But in reality it was at worst a source of friction - not a truly negative outcome12. But it was grating enough to make it clear we should avoid such things in the future - I certainly don’t recall us being celebrated for finding the opportunity and shining a light on reality.

Afterward: aka the insidious impact

Alright - so “Rich and the team made the right decision and it all basically turned out OK in the end.” Boring…..

Yeah - maybe you have a point on the “boring.” This sounded way more interesting when I started. I suspect the live presentation is more interesting than the written form. But no one invited me on their podcast - so written is all I’ve got.

But … I haven’t gotten to what I view as the real point of the story. aka “the twist!”

People learn lessons from their experiences. Even those who start out with high integrity (in this case focused on the true outcomes) get worn down over time. It’s only rational to have that affect future decisions. That’s where the problem starts.

There were two folks on my product team around when this story took place. One of them was present at least for part of the saga of the “improved accuracy goal” situation. The second - let’s call them Chuck joined later.

Sometime after this all died down Chuck came to us and described what he’d learned on a recent deep dive. Much of our work had been focused on individual pieces of video content - and labeling them as an input to brand safety contributions. But we’d been thinking more about how we reviewed the “brand safety” of organizations (or in Facebook parlance “Pages” (or page owners)). The example I was fond of was that no advertiser wanted to have their ad run during a cute cat video - if the cute cat video was published by ISIS of the KKK. Chuck had recognized that our assessment of “accuracy” in brand safety was wrong - or at least could stand significant improvement. His proposal was to restate the current entity level accuracy with a new but clearly improved way of assessing each Page and then get busy making things better.

Something roughly along the lines of the following conversation took place between Chuck, Bill (the PM who’d been there a while) and myself13.

me: Gotcha Chuck - that all makes a ton of sense. I agree we should go with your new definition of page brand safety and set a related measure for assessment accuracy. What’s your timeline for next steps?

Chuck: I think we should restate the goal immediately, with the new explanation of accuracy and just get started executing the changes.

me: hmmm - I totally agree with the plan, but it’s almost the end of the quarter coming up. So what if we just wait until the end of the quarter and just insert the new goal into the planning cycle then and get going. In the meantime, knowing the change is coming you can just spec out all the work so we can hit the ground running and make great progress on the restated accuracy measurement.

Chuck: Hmmm - but why wait?, I mean the old measurement isn’t super helpful and this new one is way better - even if it does have a measurement like 40% lower than the old one. The old one isn’t really aligned with the advertiser goals, so why wait?

me: <insert telling of the story shared earlier in this article>

Chuck: Seriously, are you really sure it’s that big a deal that we should wait 30 days?

me: Bill - what do you think?

Bill: Chuck - we should go with Rich’s plan here. <laughing ruefully>

That’s how the flywheel that supports whatever your culture teaches you value works. In this case that it’s more important to be right on your quarterly goal in terms of direct incentives than long term ones.

One last observation

There’s a risk with any writing that people will take away more than you intend. Maybe Melville just really wanted to write a literal story about some super annoying, very white whale. But in the end readers get what they get from. If you take away from this that Facebook is bad and Amazon is good, that wasn’t my intent, but I can’t control that. FWIW - I don’t believe it’s that simple. For example, clearly Meta/Facebook had way better snacks and other delightful amenities when I worked there. Amazon had no snacks but was at least in my experience more disciplined in really doing a once over on goal value before getting started.

When folks look back at some of the biggest oopsie’s in Facebook’s history (think Cambridge Analytica14) there’s a feeling of “how could anyone non evil have done that?” But in cases like this for big companies I suspect that overly focusing on goals in a one dimensional way could have contributed. To use an example that may or may not be true - focusing on improving engagement without counterbalancing controls on what’s driving that engagement could have a negative outcomes in the long run on some platforms.

Based on my experience - companies that are grounded in core tenets are less likely to overlook 2nd or 3rd order effects that might be negative. Making it easier culturally to adjust goals when new information suggests a better path. In the long run that’s probably one of the most important types of cultural integrity to shoot for. Also a controllable input too - which is always nice.

Subscribe now

“When I took the service exam, my psych profile fit a certain... 'moral flexibility' would be the only way to describe it.” - Martin Blank (Grosse Pointe Blank)

The common factor of job interviews and presidential debates

Anyone has been hiring for a while has a collection of epic stories about the process. Sometimes they make you look good, sometimes they make you look like an idiot. Last week I had an interview coming up. Thankfully, these days most companies give at least a minimal preview of what’s expected. For one specific interviewer the list of topics included, “Always do the right thing. (integrity, leadership/fit – hire and develop the best – how does he develop people?”

I try to follow the best practice of putting together sets of stories/anecdotes from past experiences before an interview. Creating building blocks for answering a wide range of behavioral questions (ie; “tell me about a time when ____.”). Much better than just thinking completely off the cuff and trying to access long term memories to find the most useful one for the situation.

As in a Presidential debates it’s ideal to answer the question asked clearly. Having some mix and match ideas that would be useful for answering a wide variety of questions helps do it fluidly. Though if you’re in a Presidential debate then more often than not it seems to work equally well to just answer the question you wanted to be asked and ignore the actual question. Not that I’m suggesting that in an interview, but it does seem to work in televised debates1.

Which I suppose is an unintended but decent transition to my perceived problem. “Wait … what does a story about integrity look like?”

Integrity?

The interview was going to cover integrity - but what stories do I have that map to that? I once managed Brand Safety/Monetization and Public Content Integrity. To this day I’m not exactly sure how integrity got thrown into the title - but it’s gotten me some interested LinkedIn reach-outs - so I generally don’t worry about it. Given this was an HR interview this was about something else. What had they heard about me!?!

Eventually I just guessed the question was probably a template from the company’s leadership principles. Most companies have some sort of written out culture. Whether they live it or not varies - but it’s usually written down. Therefore it seemed less like they’re looking for a story of Enron or FTX level non-integrity and more something at a higher level.

This took me to the crutch of every wedding toast maker and many a convention speaker … the dictionary.

Integrity: the quality of being honest and having strong moral principles; moral uprightness.

I’m guessing it’s not usually a great idea to cop-to not having these sorts of qualities. It would be funny to demonstrate your integrity by admitting to not being especially consistent with having integrity in the workplace. An interesting point, but not especially helpful in convincing people to hire you2.

Back to the definition of integrity. When it comes to the workplace I posit that it has two aspects

1. Don’t do super bad things everyone would agree are bad. So a crypto-coin rug pull, whatever Enron did, and/or generally being a duplicitous SOB are all no-go’s. Or if you want to be more positive then as I put it at the end of my management checklist article - just be a mensch!

2. Then there’s the ongoing opportunity to build trust and execution velocity by managing with integrity. Being transparent about where things truly stand enables building trust and making better decisions.

Integrity as a principle → better outcomes

Since I don’t have business examples to write about in category #1 (thankfully), I’ll continue rambling about #2. When people get this wrong at the worst they’re accused of being sneaky jerks, or “playing politics3.” In day to day living it’s more complex. It’s alarmingly easy to lie to ourselves about things without even realizing we’re doing so at times. Folks can mean well but not still make big mistakes when that happens.

Generally, I believe most people intuitively want to feel right. This desire to feel right is super close to the adjacent desire to ‘be liked.” Taken together it’s easy to want to feel right/be liked more than you desire to be correct in the longer run. The latter is emotionally harder in most cases.

It takes effort and training to convince the average person that it’s better to be right in the long term than feel right in the short term. It has certainly been true for me. It’s easier for most folks to center their thinking on the short term resolution of a conflict rather than continuing in a state of conflict seeking a better result. Staying uncomfortable is challenging even if doing so is more likely to be useful. Most good solutions (like most good learning) takes place in a zone of discomfort.

I hypothesize that a lot of perception of not being genuine or possessing integrity has this issue at the root - as opposed to our assumption of malice. Not only does this feel-good bias keep us from making harder long term choices, it reduces the chances we’ll change our mind when we’re presented with new information, over indexes us on the desire to be liked in personal interactions, and is present when we make other poor choices about how we spend our time4.

What’s useful to me from this theory is what solutions it can create. Knowing where problems come from let us build mechanisms to prevent and tripwires to get early warning when we’re not fully focused on being right. Most folks have personal “tells” they say or feel when they’re lowering their standards, or generally giving in on a point they’d be better off debating longer. Being able to identify these for yourself lets you issue an internal auto-reminder that it’s time to keep pushing on something.

Three basic tools I personally use to try to keep in mind around helping maintain the aspects of integrity I think are important

• Work hard to find yourself in organizations that avoid a culture of fear and blame (seek or help create high psychological safety).

• Drive for continuous clarity on what the most important things are (global as opposed to local goals)

• Look both at the short term pain and the long term upside of dealing with an issue comprehensively. The short term problem is how will I feel in a day or two. The long term consequences are how will I feel in 6-12 months depending on my actions now. Example: I hire someone but don’t really disclose what about the job is hard - land them, but then they quit in 3 months. Am I really better off?

Connecting the integrity prompt with the interviewers other goal about asking after “hiring and developing the best,” I realized I had a fun story to queue up when asked. Or in the spirit of many presidential candidates - a story that I’m sure I’d plan to share somewhere in the loop.

Self serving integrity: The Realistic job preview

I mentioned in the last section there are benefits of exposing job candidates to the challenges they’ll face if they accept. I’ve often joked that everyone lies about some part of the job when selling a candidate - though most people don’t do it on purpose. Once someone wants to hire you, as part of your due diligence it’s key to figure out what they lied about left out. Identifying where that landmine of future pain sits lets you evaluate if it’s the job for for you.

Being intentional about the downsides of a new gig help close and retain candidates. The Heath brothers describe this step as a “realistic job preview” in their book Decisive. Think hard about what will be a challenge to many people in the new role and share those undesirable traits proactively. It’s less likely to scare folks off than you think, and because they’re then consciously opting in the actual experience won’t make them run for the hills.

I’ve worked hard to practice this for many years as a hiring manager, and I’ve never had a regret about it. When hiring an incredible senior manager I’d worked with before to a startup I remembered to share that “one of the things about this place is things change fast. I know we’ve worked together - but I wouldn’t take this job if you’d be upset if you didn’t report into me at some point.” Egotistical of me? - maybe. The reporting wasn’t something I expected to change, but knew it could. As someone who has hired people and then been subject to a re-org before they started it felt best to identify that risk up front. Not surprisingly perhaps, he wasn’t that concerns about the reporting and went ahead. A month or two later after they started I got asked to work in a different area of the company and they got a new boss. I can’t be sure but I expect our earlier conversation helped. Or at least now he’s just mad at me that I recruited him to Convoy which famously did not succeed as a startup5. ;-)

My top realistic job preview story took place in my last role. We were looking for someone to fill a very big job in terms of scope and criticalness. The individual people were great there - but as a system it was not always a very enjoyable place to be. Company prospects (which seem better now) were highly debatable, change was needed, and folks were grumpy at time.

I’d dug deeply on finding a great match for this hire and spent > 80% of my time on this search. I was mentally and personally invested.

We had several highly qualified choices and after they interviewed with a broad set of folks were ready to make an offer. Given some real challenges at the company, I was nervous about overselling the role and having them not stick around. Thankfully as we extended an offer they setup the realistic job preview beautifully with a diplomatic question which I’m paraphrasing - “the stock price seems to have been stable to down for quite a while, the CEO left last year, and now the CTO has left. What can you tell me about the company and this sort of stuff?”

Taking an approach from Never Split the Difference I breathed a visible sigh and launched into an accusation audit.

I actually went on for a bit longer than that. Then I stopped, took another breathe and shared something along the lines of “This in a lot of ways is a bad job. I have a theory as to how for the right person this job could be awesome even with all these negatives being totally true. This might not apply to you are all, or my logic could be off. Let me explain my hypothesis…”

I shared my completely perspective as to what might be great about the opportunity. The candidate listened, took it in, and shared that his hypothesis matched mine, and how much he appreciated the unfiltered look at the challenges. He took the job, he’s still there, and according to the many reports I’ve gotten from his boss since then it was a fantastic hire6. To use the technical term he is …. well, I’ll let Tito Hubert’s favorite clip explain the proper adjective for his impact:

Don’t underestimate the trust building power of transparently sharing the undesirable properties of situations in general and the the realistic job preview in particular. At least if your main focus is the longer term. The realistic job preview doesn’t always work as well as my example above, or in the case of George Costanza below - but in the long term it’s nothing but upside.

Integrity with respect to our future AI overlords

You’ll probably have to zoom in to see this recent example of when good LLM’s go bad. But I’ll pull out the relevant part. TLDR; it seems I may need to work harder to build trust with Claude Code so that it has a safe space to explain when it can’t do something. As opposed to hiding stuff from me.

I was pair programming with Claude to build up an idea. One of the steps was to do auto-detection of eye coordinates in images. It was a relatively simple problem to hand mark - so I’d done that in the first place. Eventually, I decided to try updating the manual process with a computer vision auto-detection approach. After working through some basic bugs the results felt iffy. Then I noticed a response from Claude that gave me pause; “the crosshairs should now appear in a much more realistic position relative to where actual eyes would be…” This seemed a little off in terms of why the detection wasn’t working. Leading to me asking - “Wait - are you detecting pupils from image context or just guessing …?” The response

Then Claude went on to really rub in the gaslighting. Take a look at the image more closely for it’s full set of gleeful revelations.

So … trust and integrity turn out to be important for machines as well. If a person doesn’t feel comfortable telling the emperor they need some extra garments, a machine might not either.

Interesting I guess?, but what about the interview?

Thanks for reminding me, TBH I almost forgot that’s how I started this ramble. I was completely wrong in my interpreting as to the type of integrity question they had in mind. When my interviewer got to this they asked, “tell me about a time working with global teams that you had to deal with a compliance issue. For example a spidey-sense that there was some corruption or bribery going on.” I’m paraphrasing - but only slightly.

I’d felt all prepared to pivot on this “integrity question” but in the moment I just answered “no, thankfully I don’t” directly and possibly muttered something about having taken compliance training around the legality of such issues at Amazon. Thankfully, the interviewer was quite game and brought it back to a question about whether I had an example working with global teams where something didn’t quite feel right and digging in helped understand a local/cultural issue that was important to understand to move forward.

For that I had an example (probably a few). Specifically, my saga of understanding why our Japanese parent company wanted me to integrate a laser measurement device that didn’t really seem to work. And how befuddled I was for the better part of the year why they seemed unconcerned as I filed bug report after bug report and explained workarounds I’d developed that belonged in a Rube Goldberg machine tribute video. Until we all went out for dinner Kawasaki Japan together.

I’ve been telling that story for years and years now as an example as to why when folks do something that seems crazy you need to dig deeper. Thankfully it seemed to fit well in this case.

As another example of integrity working out I’ll leave you with a second clip from the famous Seinfeld episode “The opposite” where George takes the accusation audit to a whole other level. I’m not suggesting this - it works well for him but eventually it’s too much for one person to maintain.

A teaser for the next article

Hmm, that story about my days back in industrial inspection and working with remote teams across a Japanese parent company feels like it could be a good followup to this article. Maybe I will go there next .. but probably not. At least I’d better check I didn’t already sneak this story into an earlier post. :-)

Sorry, back to the topic for next week (approximately)…

Sometimes when you start to think about something then everything you do has a high chance of matching to that pattern. Much the same way when you chat about some random thing out loud with a friend and suddenly TikTok puts it in your feed. Which I’m intending as a situation that’s about our brain’s incredible ability to match (and overfit at times) patterns - as opposed to the obvious fact that TikTok is actually listening to you all the time.

OK - I’m joking, I’m not sure TikTok is listening to you all the time. I only worked at Facebook and they are definitely …. oops, maybe I should stop there. Again, I’m kidding I’m guessing they’re not listening to you - they seem pretty insistent about it and it’s probably hard to imagine they accidentally are doing it without realizing it. Probably.

Anyway, I’m thinking that a continuation of this post will be a short story about how caring more about hitting targets than continuously confirming they’re good targets (ie; they don’t have undesirable side effects, etc) can create real problems. Even if everyone has high personal integrity and off the wall skills. So yes, this will be a story about Facebook - but just a small one.

Definitely do not subpoena me for some congressional thing - I literally know nothing, except maybe when to recognize a cultural defect that can have emergent properties you’d rather not have. Though I could be completely wrong, as Facebook/Meta seem to be doing just fine7.

Share

Sometimes the thing is not the thing

• “Those sales people always have some excuse why it’s not their fault the product not selling.”

• “Sales says if we don’t launch _____ by _____ they’ll miss their numbers."

• “What sales says then ‘need’ to close deals doesn’t seem to provide any value to customers. WTAF?!”

Most people who’ve worked with sales teams have heard or said one of these things. They’re closest to the customer, but in quiet moments folks may view Sales as more the “voice of sales” than an accurate “voice of the customer.”

Sales folks tend to be pretty good at, well … selling… so it’s easy to take them for an unreliable narrator when explaining why your (perceived) hot commodity isn’t flying off the shelves. Though they’ll make up for it with the best stories if you have a drink with them after work.

Today’s post though isn’t about the psychology of sales, nor the relative value of selling through “overcoming objections.” Instead, it’s another twist on my old favorite. The value of being curious long enough to understand why something that makes no sense, may in fact make a lot of sense.

I’d intended this Substack to have of a practical memoir feel to it. This “minor” example actually had an outsized impact on me and I share it often - so it seemed like fair game. It’s totally not just because a few months ago I got ChatGPT to create an alarmingly accurate re-enactment of myself, Jeremi Gorman and Brian Elieson in the (for me) pivotal discussion that I thread through this article.

The feature that made sense but totally didn’t

Things that matter don’t always make sense based on your perception of reality. But they likely make sense to someone’s reality. How it makes sense to them is more important to understand than most of us have been taught. Teaching implicitly or explicitly often centers on convincing others, as opposed to recognizing the moments when we need to convince ourselves of something new.

Today I’ll just share an exampleof such a misunderstanding. Or more accurately, differing assumptions due to incomplete information.

If you’re developing systems long enough eventually you’ll have an moment where is building a feature that seemed not worth the effort1. “If we don’t match up on features we’ll never get to be in the right room to really sell” might have been the response when you objected. Most likely you just sucked it up and did it if it was small, but grumbled all the way through. I’ll probably write an article someday about how this instinct is super dangerous. As productive dev teams like to build things that get used. The most 100% surefire way to demotivate and decimate your team is to work on things that don’t get used. But that’s for another time.

The perspective on “what features a product is missing” varies based on your seat at the party. As one who wears many hats - but the engineering one being a primary one my view can sometimes include internal capabilities that aren’t visible to users. Thinking back to my tenure at IMDb I believe if you’d asked me what three things that the site was missing I’d have said

• A true database mastering all of the data as opposed to a huge collection of flatfiles2.

• Where to watch the content I was reading about. Assuming it wasn’t in theaters, on DVD, or available via Amazon Prime.

• An ability to purchase tickets on the website

The path to address the first two are twisty, fascinating stories for future articles. Today we’re going to talk about the third one → the ability to sell tickets on the website. While I’d have listed it as a “product gap,” I didn’t really believe it was critical to fix. In my labeling taxonomy I’d likely have bucketed is as “interesting” but not ‘important.”

It turns out I was very wrong about that. Thanks to Jeremi Gorman and others we didn’t get stuck in my bad assumptions on reality.

Wait - buying movie tickets didn’t seem important? For a movie website?

IMDb (as now) was considered the most authoritative place to learn about television shows and movies. Advertisers were mostly on board with buying ads on the site for film releases - and shared good feedback on the team’s custom creative solutions that took over the website with the intent of building awareness and directing visitors to the film’s “detail page.” IMDb offered lots of information about where you could then see the film locally (aka - “showtimes”). But what it didn’t have was a way to buy the tickets directly.

Moviegoing was a different world back then. Buying tickets in advance wasn’t the same table stakes it is now. With the possible exception of super big budget films that were likely to sell out during opening weekend. I believe the main shift in valuing online purchasing was driven by theaters offering reserved seats. At least for me, the ability to lock in the spot I wanted to sit, and thus arrive as late as possible to miss the incredibly annoying “pre-show3” was suddenly worth the effort and “convenience fees.”4 That wasn’t a common service though at the time of this tale.

There sites for buying movie tickets (largely Fandango) and the data we had indicated that even for big openings a relatively small percentage of tickets were sold online. Thus it didn’t seem a critical lever - and we had a long list of technical and product levers we wanted to pull first. We didn’t have the appetite to try to actually be the point of record for selling tickets, ie; attempting to battle Fandango. If we had thought we could pull that off then this would have been a very different adventure.

Repeated asks from Sales had put an integration with Fandango toward the top of our to-do list. I wouldn’t say the product teams were sold on this. Grumbling from the engineering teams about the execution challenges and relative value have stuck in my memory. It’s challenging to build enthusiasm for building something when one feels their own explanation as to why it’s important is unconvincing. High performance teams want their work to matter, and I was not a great salesman for the relative prioritization of this work. At least not in the initial stages of the journey. Though we progressed nonetheless.

Spoiler alert!

As I’m typing I realize this is going to be a particularly underwhelming narrative. We were working on doing something (ticketing purchasing) - but didn’t feel it would have much impact. Then due to our continued curiosity we finally “understood” how it mattered. And we5 finished the technical work and launched the feature. One could argue that the end result was completed unaffected by the “learning” I keep teasing .

That is all true.

Sometimes you’ve just got to get started on things. That shouldn’t stop you from seeking clarity even while underway. It’s never rarely to late to adjust your actions in light of better information. If it turns out you made a not great decision, just move onto trying to make a better one, and then another one.

Where you end up is way more important than where you were heading when you first hit the gas. Due to the cognitive “peak-end” rule, if you start a project not being 100% sure it’s high value for your customers and/or business but you end with clarity it is - almost everyone will remember only the end-point. Similarly, if you start off with clarity but drive off a product-market fit cliff of sorts …. well, I think reasonably that’s what people will remember from the story.

At the risk of saying it more times than I need to, engineering teams really want to build things that get used (or teach them how to do better/faster next time), and from a ROI investment you should feel 1000% aligned with this. Continually confirming everyone’s on the best possible path doesn’t have a start-by or end-by date in my view.

Hopefully your interest is piqued. That’s good - because the true story is almost over finally here. ;-)

Assumptions interrupted (yes, finally the end!)

I’m sure I asked “why is this so important again?” many times. One of those times either the answer was clearer, or I asked better, or maybe I just was paying more attention. That day Jeremi broke through my incomplete understanding of the value of the feature for Sales, and to an extent for advertisers.

Jeremi was a gifted storyteller, and at least pretended that she didn’t mind explaining the same thing more than once. All of her stories were interesting, some extremely funny. Several of which I’m pretty sure I shouldn’t repeat. We haven’t spoken in a while - but I can guarantee she has more of them now than she did then.

Anyway - at some point during the project (or right before we really broke ground) I asked again “I see why people might want to buy tickets online. But given all the things we could build why are you so so adamant this is the ‘most important’ right now?” In hindsight, this is a terrible question - it could come across as potentially accusatory, negative, and it doesn’t soften the blow by starting with “how” or “what.” Even so the answer was spectacularly clear.

At the risk of bolloxing it up the response I heard was

“Well … entertainment advertisers basically have their budgets for ads allocated into three categories.

1. Endemic websites - places that people go to learn about movies.

2. Reach - sites that can deliver tremendous number of (presumably targeted users). Basically Facebook.

3. Websites that sell movie tickets.

Today my team can only access the budget for #1. We’ll never be able to sell IMDb as #2 compared to Facebook. But there are a bunch of dollars in #3 and that changes the game. Just because technically they can buy ads with the money in budget #3.”

In hindsight it was as if the clouds parted and sunshine streamed down from above - I felt simultaneously enlightened and incredibly dumb. My sheepish response, “oh … that makes a lot of sense…” I think I glanced over to Brian Elieson a moment later with what was supposed to be a look of “geez, I wish I’d understood that earlier.” I’m not sure Jeremi clocked any of it as especially noteworthy, as if I was her I’d bet she would have been thinking “these guys keep asking an obvious question and I keep trying to explain it to them. I hope I don’t have to keep doing that.”

FWIW - I’m pretty sure we never asked again.

Aftermath

No one’s memory is especially accurate, and I’m sure there are parts of this tale that are wildly inaccurate. My apologies to anyone involved if that’s the case. What I remember most after the moment of recognition was that

a) there was a pretty darn clear reason for the feature that made perfect sense given the knowledge the sales team had, and

b) I needed to stay curious with good followup questions when things didn’t make sense.

I can’t guarantee you’ll always see that clear reason given enough questions. But I’ve gotten a lot better after that moment in staying curious enough to consistently discover why things make sense to someone, when they don’t make sense to me initially. It’s unlocked a lot of business results over the years since - so thanks for reading this far and being open to hearing the good word.6

Share

More time up front → stronger/better/faster results

I can really talk too much. Which is sort of funny given I’m also largely an introvert. Maybe there’s a method to my madness though. If you keep reading you’ll get to decide for yourself.

Many who’d call me verbose also say I converge in my thinking to simple descriptions of complex system. Quoting one of my favorite Coen Brother’s lines, I hope you’ll stay with me and “accept the mystery” of that duality. In the end I believe there’s a connection.

A great sage asshole once said “if a man can’t stand he can’t fight; if a man can’t breathe he can’t fight; if a man can’t see he can’t fight2” People, just like systems have key constraints. Only a small number of key factors truly matter at any one time. Your job in management3 is largely one of prioritizing focus. In almost all matters you should

1. Identify the key thing that either blocks all progress, or with more of you could “make” a lot more units of what you care about.

2. Keep focus on this opportunity (constraint, bottleneck, leverage point, etc)

3. Continue iterating

Yep - that’s basically it. Not going to be an epically long post today.

Subscribe now

Making a high leverage change, the short version

That sounds different than how most of us (me included) seem to spend our time. But anytime I’ve experience outsized success individually or a group it’s largely come down to those three steps. If you think back on your own experiences I think you have had similar experiences.

This simple sounding thing of course is not really so easy. Well, maybe it is if you’re naturally curious and able to resist the pull of “let’s do something now!.” The first step is identifying and aligning on the core bottleneck of your system. The key to finding that in my mind involves three key elements of a slightly more detailed framework

1. Spend time and be curious about the system you’re trying to improve. You’re looking for what does “wildly successful” mean to the users/owners of that system. This is where you want to put yourself in the problem space of the other party. This is where “being too slow” and “talking too much4” can be super helpful. Rushing to work on something not valuable is not helpful. The world is filled with a lot of jokes about biasing towards easy vs. hard but useful problems. Some say our brain are evolutionary wired to do this - but you can fight it, at least to a draw. When you’ve been curious, and analytical, and can repeat back a vision of the future which elicits a simple “that’s right” from everyone then you’ve arrived at the destination of this step.

2. Look for the constraint. A nice trick is to imagine you’d come in from outside having never seen the problem (adopt an external mindset) and ask what is the one thing that truly is holding us back. Often it’s very easy to see this from outside vs. inside and for some reason you can often trick yourself by imagining you’re solving “someone else’s problem.”
   
   For example - how often have you been talking with a friend who’s complaining about many parts of their job, and how many hours they’re working, etc. They cannot get anywhere because “the CTPO is blocking all of the things they think need to be done.” But then they also share how hard they’re working outside that relationship. It’s pretty straightforward to note that unless they align with the CTPO it’s almost certain they’re never going to achieve their other desires to launch project X. Therefore you’ll remark that probably they should work a sustainable amount but figure out how to spend 70%+ of their time working to understand and address the CTPO blocker’s concerns.

   
   I’m not saying that friend wouldn’t come up with that. But it’s much easier to spot it from outside. There are tons of business problems that follow this anti-pattern of not working on the constraint because the constraint is harder than whatever else we decided to pickup.
   
   I almost guarantee you’ve seen a team working on a local goal that even if improved by 10x wouldn’t bring better customer experiences or more bottom line profit. So why are people doing it? Human nature, and lack of a framework that focuses on constraints and what you can control to utilize/exploit them better (or eliminate them).

3. Use a variety of best practices (the Theory of Constraints (TOC) literature has many) to make a change that improves things. Being very careful to prioritize and communicate those priorities so work is not diffused to other things that don’t really move the needle.

That’s a high level summary. A classic way of putting it from TOC that also has three beats is “Decide what needs to change, what to change to, and how to make the change.”

A level deeper

I relatively recently re-read Goldratt’s Rules of Flow, a short and helpful book by Eliyahu Goldratt’s daughter. It updates his earlier Critical Chain methodology for project management into something that’s more accessible and easier to execute on. I credit Rules of Flow and the short book (Fr)Agile by Stuart Corrigan re-influencing my view of Agile in the direction of Kanban and away from Scrum.

For the rest of this article I’ll re-summarize some of the key things I’ve learned from TOC combined with a mashup of other thinking/decision techniques I’ve found useful. If you want to go deeper checkout The Goal, It’s Not Luck, and/or The Phoenix Project. This bullet pointed view can serve almost as a checklist to ensure you’re investing your time where the juice is worth the squeeze.

This won’t 100% be TOC canon because I mashed up a few different thinking and decision models. Actually it’s less a mashup than combining “focus on the goal” with “remember that people are weird and wonderful” with “you’re only right in the long run if people tell each other they’re wrong easily.” I believe Goldratt makes all of these points in many ways on many occasions - but maybe less so in his most commonly read works.

• There are less things in the system than you think matter

  • Most things of interest have are complicated if not truly (mathematically) complex and reward obtaining true system level understanding. System level understanding doesn’t mean you can see inside every black box, but that you understand the cause and effect relationships that make it up.

  • To improve something you need to deeply understand your goal and what small number of things are holding back your ability to make a HUGE improvement.

  • Without context one cannot hope to find that one thing. Don’t skip this and definitely don’t pretend everyone understands it because they sat through a presentation of some sort a year ago.

• How you find and express the problem matters

  • Without logical reasoning work and good communication between people you likely will likely not be able to unearth the root issue you should focus most of your attention on.

  • Without always working to understand the problem in other’s world of problems/pain you will never truly understand how to make progress. Also, you’ll likely wildly misattribute their reasons for resistance. Therefore you need to learn/lead with deep true curiosity and tactical empathy. If people don’t really care deeply about the problem you want to solve it’s an unnecessarily uphill battle. Also - there’s a real risk that if people don’t care - then it may not really be that important. In which case, I believe the technical term is ooooof!

• People are always key parts

  • You can never dictate the best way to do something with any consistency. And people are most satisfied when they solve problems themselves. Therefore you must (a) arrive at clearly observable goals/objectives for success to align groups of people on what we should care about globally vs locally, (b) insist people/teams find their own best ways of “how” to move towards the goal and (c) continuously check back and forth that the goals are right and aligned with cause/effect relationships on the constraint/bottleneck that matters.

  • Teams can’t do the above without trust and context. Massively over invest in those. People who are blamed for an outcome as opposed to trying to learn and follow great thinking processes will sabotage things (at least by accident). Leverage from trust comes from being able to challenge each other and actively find things in reality and data driven analysis that poke holes in what you’re trying to do. These can and should be mechanisms within your norms (culture).

• Write it down and avoid unexamined assumptions: Clear writing is clear thinking

  • Write down what you mean and insist others do too. Use PowerPoint only as a last resort. And remember that context means understanding what problem you’re solving for everyone except yourself - put yourself in your “customer’s” world and solve backward.

  • Focus on a small number of written (obvs) priorities that connect to increasing the flow of the thing you care most about at the overall org (global) level. Small means 1-2, three tops.

• Remember the joy comes from the challenge in anything worth doing

  • Have “long term” fun. Having fun in the short term is great. But like the sugar I’m addicted to it doesn’t produce long term satisfaction. That comes from struggling and feeling great about how you used your time. Solve problems that matter to you and have relationships you value.

That is all for today: find the constraint (what to change), understand the problem (what to change to) and work well with people to avoid common pitfalls (how to make the change).

As always - happy to sit down and discuss this in terms of a real problem you’re trying to work through.

Subscribe now

Bonus section

Just to tempt you into checking out Goldratt’s Rules of Flow here’s a summary from the end of the book. I think one would get more out of the whole thing, but this is the gist of the framework.