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.

Today’s topic

A while ago I wrote an article about treating tech debt less as a moral failing, nor a “debt” issue, but instead as a throughput one. Some folks reached out to share the framework had been useful to them.

I also know the original article it was a bit long for some folks. Today I wanted to pull out a functional piece of that post for those with shorter attention spans. I’m not judging, I’m meeting you where you are. 😉

This article will zero in on making the work of your engineering team visible, and to an extent countable. Yeah - I’m aware of the DORA approach which has some great measures of inputs to velocity. But when you’re wondering “what are the types of work we do?” and “how much are we doing of each?” - this is the post for you.

I nice side benefit is that the non-engineering executives you work with are always wondering about this even if they aren’t asking. Trust me - I’m pretty sure. Proactively having even a swag at this on a regular basis is likely to make your resourcing conversations go much smoother.

Subscribe now

What is slowing us down is what we’re doing - so what is that?

At the root cause level what tends to slow things down are likely in one of these three buckets;

• Lack of clarity/vision (impacting motivation and focus) - ie; you’re not only working on this thing that drives outsized customer/business value. It’s hard to make great progress without this. I have a primer to start with from a few moons ago.

• Lots of multitasking. Read Goldratt’s Rules of Flow and checkout my prior post to ensure your Agile-like process is helping and not hurting. If you don’t want to read these check if you’ve got 6 devs in a sprint and 8 things going on, plus a “product owner” that wants to get every drop of juice out of every sprint. If you’re wondering how I knew that then go read the other two things. Please.

• Significant amounts of time that isn’t on either new customer value or being able to build faster. Maybe people are a bit vague about this - or often list things like “dependency updates” in what’s a drag on velocity. This is the throughput point I’ll hone in on below.

A types of work histogram

At a tactical level, most teams can build a histogram of where time goes using the following buckets

• Broken stuff: Things you were interrupted by because they broke - or people thought they might be broken (think questions about the prices from your pricing system).

• KTLO (Keeping the lights on activity) - Time you had to take just to keep things running (package/dependency updates, compliance updates, answering questions about your poorly documented API etc) - also could include those pesky pricing questions depending on how you bucket things.

• Dealing with coupling: Time spent on dependency discussions (how you organize people, systems). An example: if you cannot change your database because you’ll break other people’s stuff downstream, then you spend an inordinate amount of time discussing boring but critical changes to your tightly coupled schema. Don’t laugh - this still happens all the time.

• Time spent on building new things that are slow because of your current systems/architecture. This is the roughest one to estimate - it’s more of a swag. If say you out of 10 devs spend roughly 6 of their time building, but you feel you could go 30% faster with some changes then capture that as a bucket for improvement. It’s not perfect given the next bucket - but I’m just looking for a way to highlight typical problems and opportunities.

• Time invested so we can go faster or be safer in the future (better monitoring/alarming, extensibility of current architecture, toolset, CD, testing, etc).

• Time building new product features

The first four bullets are drags on throughput (building new things that drive customer and business value - now and in the future), the last two are positive throughput, or increase throughput. Once you’ve refined the histogram segments with group discussion, then I recommend measuring just enough to scope the size of each bucket.

Now we’ve gone a rough sense of the types of work and time in each. So what?

At this stage you’ve found how much time is spent outside the two last categories (going faster in the future, building stuff we want now). Evaluate if there’s enough drag to care about changing right now. There may not be - or it may make more sense for any number of reasons to work on them later. If you’ve made that call at this stage you likely built enough shared context and trust for everyone to understand the decision, and feel heard.

If you do decide that there’s benefit in reducing the drag on throughput - then congrats - you’re about to pay down some technical debt! Focus on finding the biggest constraint on your throughput and what things that you control can be changed to make it better. Most systems have key constraints to throughput that once identified allow you to have disproportionate benefits. This is often referred to as the Pareto principle that suggests there exists 20% of work that can drive 80% of improvement.

If you take only one thing away from this:

There’s no magic formula. Figuring out what investment to bet on requires getting into the weeds. If you do something a lot and it sucks then fixing it will have a lot of yield. If things break all the time and trust/customers are hemorrhaging then you probably don’t need to overthink whether you fix stuff. Tech debt costs time later (and integrates), not making customers thrilled now can make a recovery harder or impossible, and fearless/joyful building lets us win in the longer term. Thinking in a truly 360 degree manner like most things requires accepting complexity and getting people to share the same context.

Want to go a step deeper in how to use these measurements - just checkout the longer form version of this post.

“In the land of the frugal, the team with the free snack closet reigns supreme.” - Tito Hubert

Silly Story Trigger warning

Likely this will come across as a very silly story. Though, a small contingent of folks I’ve worked with claim that my actions at the end of this tale were my strongest contribution to Amazon’s ad-tech juggernaut (with at most 60% sarcasm). Though now that I think of it, since in that period we put up an incremental three commas on the scoreboard maybe they’re just trolling me.

I still think it’s a fun story with value. Throughout my career I’ve worked on how to affect change when I don’t agree with something. I’ve learned over time that framing a problem in others worlds’, asking open ended questions, and using both to build vision helps a lot. It also hurts a lot less than banging my head into the wall.

This is a time where asking a single ended question worked a thousand times better than saying what initially popped into my head. '‘Well that’s the dumbest freaking thing I think I’ve ever heard. Why would we do that?”

But first, an overly long setup... 😉

Snack wealth is not distributed uniformly in big tech

Amazon is famous for Frugality as one of the official leadership principles. There’s of course a longer story about doing more with less that completely makes sense. But it also gets translated in practice into choices on where to spend as little money as possible. One can judge - but if you went through some existential crises early in your formative years, drove a low margin retail business, and believed in lower prices as part of a growth flywheel … then you might behave in the same way. This isn’t really a story about judging the leadership principle. But to understand the tale having a sense of what this frugality meant is helpful.

Most places of business have at least a break room for employees. At other places I’d worked more not often there was some low value perk around. Maybe saltines, maybe junk food from Costco and/or soda sold at cost. As big tech grew, a perk of having a mini-kitchen stocked with more became pretty common. Whether it was drinks + cereal + hard boiled eggs/cheese as a baseline, or the full deluxe version at the Facebook’s of the world, companies seemed to feel the expenses were worth it.

Amazon … not so much. There was free drip coffee available1 and at some point a public facing free banana stand2. If you wanted fancier coffee or a snack, there was usually a marked up concession in the building to take your hard earned money. Free though - nope.

Smart folks brought in some snacks to avoid being fleeced, and some teams had their own quirky approaches to dealing with coding induced munchies - most famously (to my knowledge) one with a breakfast cereal “bar.”3

Subscribe now

Always be closing, with snacks

Sometime in my last two years of Amazon our VP had an inspired idea. Spend some portion of the budget and buy snacks for the team. It seems pretty obvious I’m sure - but it truly was pretty unusual at the time. This was in the ads group which was just minting money - so maybe there was a little bit more discretionary money in the budget. Not sure how she pulled it off TBH. But always appreciated it.

This was Amazon - where leftovers in the kitchen would be consumed instantly - as if we only hired staff who were part hyenas. Therefore, the snacks had to be secured in one of those locking cabinets that you use for high value items like staplers or extra ammunition or whatever. The EA team was tasked with keeping it stocked and they did an impressive job - even if I’m not sure if anyone every really ate the Kale chips. There always seemed to be a lot of Kale chips4.

BTW - we realized and informed our VP that the snack closet was a huge recruiting secret weapon5. Back then before today’s dark days getting a new developer to join your team was not easy. Mass poaching recruiting from other Amazon teams was the norm. You’d get together with folks for a chat over coffee6 and try to wow them with the cool people and work they could be doing. They were going to make the same money regardless of which team - so the marketplace was one of enjoyability and coolness.7

I can’t recall who figured this out first - but it became apparent that walking a candidate past the open snack closet and causally mentioning it was free increased candidate conversion. Much as in the kingdom of the blind the one eyed man is king - if no one has any snacks then the team with any snacks appears special. Dare I say enlightened.

To be fair - having some basic nibbles so that engineers don’t have to break flow often could be argued just on the financial merits. But I suspect that most engineers who saw the cornucopia took it as a sign that this org cared about people more than most.

Either way - that closet was our top closer. Other orgs might bring in some fancy SVP to convince the new engineer how much they were wanted/needed. But we saw the results between big shots flybys and our Snickers collections - and we liked our odds.8

SHTF - Snacks Hit the Fan

One day our entire org received a horrifying email. An email day that might have lived in infamy. The much discussed “allowable snack use case email”!!!!!

Now this is an email that I wish I had saved. It would be fun to have. And I’d also be able to check how much I’m blowing the email out of proportion. I loved the EA team that sent it - and I fully understand the reasons for it. Sometimes when there’s a lot going on, and you don’t have 100% of the information of the value of something (such as our closing rate for hiring) things look different. That said - at the time the notice landed with my dev teams with a dull thud. As if the heaviest stone you could find was wrapped up with Dilbert cartoons featuring the pointy haired manager gone amock9.

Since I don’t have the email I’ll try to recap the main points. This might not really be what it said precisely - but the interpretation is pretty accurate in how it was perceived broadly;

• We are glad you liked the snack closet.

• People are eating too many snacks.

• Please do not eat a snack under the basic circumstances of “I am hungry and want a snack.”

• Only take snacks if you are truly hungry, have no time to go buy your own snack, and meet one or more of these other key snack eligibility criteria.

• Take only one regardless.

• Have a nice day10.

I’m pretty sure that the day this email arrived was not our most productive. I’m not sure what the kids would say today11 - but back then we might have said “folks were steamed.”

Update: The internet has found the Snack Closet Email!

Thanks to the diligent detective work kicked off by Tito Hubert and a digital packrat that I believe wishes to remain anonymous, the original email has been located.

I think FWIW my summary was reasonably accurate for so many years ago. 😉

Breathe … the benefit of ignoring that first instinct

It probably isn’t a surprise that I thought this was a pretty hair brained idea. One would have to be completely nuts to send this email! What kind of idiots would ask folks earning 6 figures to take slightly less snacks at the cost of productivity in one of the biggest cash machines in Amazon’s history!

Even worse - who would first get these people hooked on the snacks and then pull them away. Clearly someone who thought that whole speech by Bane in The Dark Night Rises was supposed to be inspirational. Also .. dammit! how am I going to hire anyone! And do I have to go back to selling stock low to pay for my Snickers!!!

Yeah - I might have been over invested in the situation. But for whatever reason I took a deep breath and thought what a useful response was.

A useful response was clearly to try to understand the constraint that was complicating our beloved snack closet. Label the conflict, and see if we could find a solution. Therefore to followup with true curiosity

me: “Hey, saw your note. Sounds like there was a problem with the snack closet?”

response: “Yeah, we had a budget from ____ for snacks and we shot through it in the first week or two of the quarter?”

me: “Oh, that’s a bummer. Seems like people love the snacks. But I see how that’s a problem.”

response: “yeah, we felt bad having to come up with a way to make the snacks last longer, fairly.”

me: “Hmmm. What do you think would happen if we just asked _____ for more money for the snacks? And just buy more snacks if it was OK.”

response: “good point - we’ll try that.”12

What happened next? I believe that curiosity was continued on the part of the EA team back toward our VP, an email in the spirit of Emily Littella was sent and great rejoicing followed. The new approach of “when we run out of snacks we buy more snacks” heralded a return to our golden age of recruiting.

Wait, what!!?

I know it all sounds a bit trivial. But there are a few really notable moments where I felt I had impact not because I was smarter or cleverer. But instead because I was curious, and asked questions to build vision. It’s a framework that works, even though this story is probably not quite the home run example I shared earlier about the Buyer Seller Messaging Service.

Though truth be told - there are worse things to be known for than someone who helped restock a beloved engineering institution helping drive up Amazon’s stock price.

Postscript

After working on this team I left Amazon and ended up for a minute at Facebook13. I got to witness a perfect example as to how a company with cash to burn that was willing to spend it in any way that increased tech focus. Our floor basically staffed two different teams. The other group had a weekly friday happy hour catered by Din Tai Fung. The EA I worked with covered both organizations and at some point she told me they’d run out of food because folks who were likely not clear whose happy hour it was came by and messed up the count. So I asked how she was going to handle it? She looked at me sort of like I had a third head and laughed - “well, I’m just going to buy more food.”

‘nuff said.

I used to think anything Agile was awesome, and different strokes were just equally good but for different folks. But now I do not think that, at all. The TLDR hits my main point, but I’ve bunched up a number of stories to support some common Scrum anti-patterns, culminating in a suggestion that Kanban can fix the most scary structural one. I hope you’ll read on - the issues may seem subtle but with the benefit of hindsight I think they’re the drivers of much of the “but I thought we’d get more done” pondering I’ve seen over the years.

A special thanks to Stuart Corrigan’s short, free e-book (Fr)Agile which I learned about at a Critical Chain project management conference. It sort of red-pilled me on this subject. I feel I added onto it along the way, but the what he wrote helped me to see reality more clearly.

This one pulls together a lot of the operating concepts I’ve been preaching - along with stories of Scrum gone wild. Then I try to tie it all back together on what I think should be true about a throughput based Agile approach. Which Kanban more or less satisfies given the (almost) tenets of the TLDR below.

Without further delay LFG!

TLDR;

1. Make sure you have great OKR’s so you truly know what’s important. Use my guide or any of the more famous ones.

2. Read “Goldratt’s rules of flow” and make sure you understand how critical having everything ready for a task (full kit) and how bad multitasking truly is within agile processes

3. Switch to Kanban so you can really visualize and reduce WIP

4. Avoid Scrum because the perceived upside “we let the product owner fill in the capacity for a period so they leave us alone” has a fatal flaw of “the product owner has a huge incentive to use all the capacity.” Using all the capacity sounds fantastic. But … that’s a case study of focusing on local efficiency (utilization) vs. global throughput. Spoiler: you care a LOT more about throughput.

5. Make sure your entire management focus is on the prioritized release of work and unblocking people so they don’t multitask and/or wait on blockers.

6. Another recommendation to read the damn software flow book I keep bringing up. It probably is just like 2 hours of your time. But of course read the rest of this first.

You’re welcome. ;-)

Subscribe now

Longer version: Throughput > Efficiency

This is the section where I suggest that several things that we think are great about Agile processes are totally wrong and should be abolished. Unless you don’t care about velocity and achieving highly leveraged business results.

No … I’m not going to argue for Waterfall, per se. Even if I believed in the merits of some of it (actually, I do) - I don’t quite feel like being burned at the stake. But I am going to argue that a few things in Scrum tend to get abused, and there’s basically an unalterable flaw in the system that leads me to believe you’re better off not using it the way most of us have been using it.

Apologies this section does expect some prior knowledge in Agile/Scrum and some of the associated lingo. But I’ll try my best to not make things require total nerddom in the topic. I’ll start with some context…

A biased history of the amazing shift that is Agile.
The tablets come down from the mountaintop

There was a time believe it or not when Agile was controversial1. Folks were saying things like “what are those newfangled whippersnappers up to?” and screaming “get off my lawn!” with some regularity. Maybe a slight exaggeration. But there was real skepticism for the practice, though that was also still an age where some devs would feel they didn’t need any kind of source control systems. It was sort of the wild west now that I come to think about it.

To my recollection, back then “Agile” more or less meant “Scrum.” I’ve certainly heard lots of different views of why Scrum is awesome - and lots of them around breaking work down into continuous delivery, having milestones that are verified (and celebrated) during team demos make a ton of sense. Of course I’ve always loved the continuous learning mechanism of the team retro.

Though when I read the early Agile manifesto one thing jumped out at me as the true reason for the approach - the backlog and the sprint planning meetings. Specifically the process of having a team estimate units of work and the forcing function of the product owner selecting only what will fit in the next sprint. And THEN LEAVING THE TEAM ALONE WITHOUT CHANGING THEIR MIND FOR 2-4 WEEKS.

To this day, admittedly without any evidence, I remain convinced that the reason that Scrum spread like wildfire at a let’s spill gasoline and play with matches convention is because it was impossible to not read the idea and think “OMG - I can get to actually code for 2-4 weeks without someone changing their flipping mind on the requirements.” Even with the predictable problem that folks would feel they didn’t need to really think through the requirements anymore2, the tradeoff on focus seemed like the deal of the century.

Undesirable effects - rise of the heretic

Over time I thought I’d begun to feel there were some cracks in the armor of execution perfection promised by Scrum. This wasn’t super obvious in the best, smaller teams. Those where the various folks required for something to come together were in perfect sync. As work became complicated, getting a project done starts to require input from product managers, scientists, engineers, designers, operational teams, etc. All things have weak points. Scrum provided flexibility but if one didn’t address the potential pitfalls intentionally plenty of undesirable things could happen.

Before I get back to my main thesis, I’m just going to riff a bit on undesirable aspects of Scrum I’ve noticed over time in the next few sections. This isn’t intended to be a guide to “how to do Scrum well.” Therefore things like ensuring you have a definition of “done”, a well groomed backlog, and how to run an effective retrospective are being left out for now. Feel free to checkout this article for what I think some important things you’ll want to make sure are true for any Agile implementation.

Low rigor in defining “what we want to accomplish” (the requirements)

With Scrum It’s a bit too easy to not have a high bar on rigor around “what we are building?” In the (not entirely so) good old days folks would be tasked with creating a requirements document that detailed everything to solve the problem at hand. Shockingly this one and done document didn’t always work out and epic stories of changing requirements were common. Scrum’s sprint cadence provides a natural way to buffer the shocks of such changes by explicitly allowing the product owner to learn and pivot every few weeks.

For those readers who’ve worked with humans before the likely undesirable effect is probably obvious. While a requirements document may be written, it’s all too easy to either skip the step entirely or just not apply a high bar on the documents. Much as people in media production joke that when a terrible mess happens that they’ll just “fix it in post” (production) this under investment in up front analysis is rationalized that it can be fixed in a later sprint. This is true but with a but that Sir Mix-a-Lot would love. You don’t want to come up with the requirements as you go for the same reason you want to be crystal clear when setting goals what the problem is you’re trying to solve and why that’s important. Otherwise you’re just going to be lurching from idea to idea - which itself is almost always a sign that you don’t really know what the most important thing for your customers is.

Here's a suggestion for those looking for a fast test to assess whether your product team has nailed the requirements at the 80%+ level. Does the product manager feel they need to attend the team’s daily standup? Or worse - does the dev team feel they need the PM there at the daily standup? If so, then it’s likely more proactive thinking around the requirements (and likely your OKR’s) needs doing.

I get pushback almost every time I make this point. But “We love having Mary attend the standup, we work better when everyone is in sync and she often has great insights!” Or the PM says “If I don’t go to stand-up then how will I know what the team is doing?” While often at the same time each side is complaining that the product manager is behind on some other thing that they probably should be thinking ahead on (ironically, often the next stage of requirements).

My advice at this stage (whether you buy my argument or not) is to be curious and ask - “what specifically will go wrong if Mary isn’t at the standup for this sprint at all?” Of course, pushing deeper for anything that’s nonspecific in the answer. I suspect in a meaningful number of cases you’ll hear something that reduces to “if they’re not there I won’t know what to do next” or “if I guess at what to do next there’s a good chance I’ll be wrong because the requirement/user-story/napkin isn’t clear enough.” Bingo! This is the point I’m trying to make. As if you go back to the Scrum origin story - the entire point of the exercise is that the team enters the Sprint with clear information on what they are expected to do. Whether this is a user story, API definitions, or just adequate context to understand “done” the intent is for the execution team to be able to execute.

If the product manager (PM) is needed to handhold so consistently that they’re always meeting with the devs then they’re either (a) not specifying what successful completion of the Sprint components are (b) doing some important aspect of the Engineering lead/manager’s job, or (c) changing their mind as they go. All of these are bad - and often it’s a combination of these.

I’m not saying anyone should ban the PM from hanging with the dev team. But I am saying it should be a “want” and not a “need.” Also, you should be very suspicious that the PM has so much time to hang out with the devs in this way. If so there’s a good chance they’re then underinvesting in the incredibly hard and complex job of thinking through the longer term execution aligned with the core problem the business needs solving. This harder work gets put behind the easier dopamine thrill of hanging out with the developers and feeling like you’re contributing to the coding part of things.

Throughput is your goal, not self organizing autonomy

One of the things that also gets a lot of positive attention is how Scrum supports a working team autonomously self organizing their work by how they choose elements from the backlog. In theory everything going into a Sprint has passed through the “Sprint Planning Meeting.” During which the product owner (often the PM) sits down with the team and reviews the “groomed backlog.” This is a list of things that the group wants to do - including both product features, important bug fixes, and other work that improves the team’s ability to build now and in the future (ie; infrastructure/platforming projects). In theory, using a well defined prioritization rubric the product owner selects what items from this backlog should go into the plan for the next sprint. The team, having provided the input estimates, then reviews and “commits” that they will work over the Sprint cycle to complete everything chosen.

There are a few things that tend to go a bit wrong here. The product owner being highly incentivized to include as much as they can in the next sprint, leaving not enough slack/buffer for things that go sideways. Additionally, there is often a long simmering battle between investments the team feels are technically valuable that the PM doesn’t want to do now. Typically this is because the devs are want to have a simpler codebase allowing them to go faster, and the PM feels they only get measured on what’s shipped (without much risk of being blamed if things break after launch). These are both big issues - but they’re not the problem I now refer to as the core Steve problem of Scrum.

To understand what I’m referring to it’s important to recount how Scrum teams typically organize the doing of work within the Sprint (2-4 week period). Going back to my recollection of the manifesto writings, the commitment of the team is to complete the work agreed to in the planning meeting - but no agreement is made on the ordering of work. This is intentional, because one of the issues with people changing their minds (keeping the product owner from poking their nose into the spring) is that they tend to try to get teams to deliver specific things in specific order within the sprint. This violates the separation of focus concerns and autonomy of the team. Which is viewed as bad. For the record I’m extremely in favor of teams being able to operate with high autonomy. As mentioned in my writings on OKR’s, a huge benefit of that process is the ability to ensure high alignment (through objectives and context setting) while also providing high autonomy. These are often seen as in conflict - but they’re not, and you need both for a high achieving organization in the long term.

The problem comes from the simple fact that no plan survives contact with reality. With the corollary that almost no Sprint finishes all the work committed to. Given that the commitment is only to complete the work for the sprint, and not in any order - most teams default to a work assignment model that is “pull driven and interest based.” Meaning that while maybe there is team discussion, in some way the individual devs select which item they will work on next. This often means that only one dev will work on each item, and more often than not when a dev gets blocked in some way they select a new item from the Sprint’s backlog while they try to figure out how to complete the last item.

This is possibly the most important point so I’m going to write it out again in a super annoying way.

Ok, now that I’m done shouting I’m going to share a real life example of how this sort of happens. I’d call it the Tao of Steve except I’m pretty sure I saw a movie with that title something like 25 years ago.

The Steve parable - start something and finish it, don’t just do lots of work in parallel.

So let me stop and share the story of Steve and his team when I was at IMDb. Before I get started it’s worth me being explicit that Steve was (and likely still is) an incredibly gifted and trustworthy engineer. This was a strong team, with an excellent manager - this was 100% NOT a team that had performance issues. They were responsible for a key middleware layer that enabled our collection of mobile apps to function, and powered the app teams to build quickly without having to understand all the nuances of the larger IMDb ecosystem. Key stuff, staffed by good and conscientious people.

One of the projects they had on the backlog was switching over the authentication mechanism we used for IMDb logins. Logged in users were important in the long run. Without a logged in experience the site was valuable, but just not as sticky. Ensuring there was low login friction was a key controllable3 input.

The team took on this project with enthusiasm, and clear requirement. But month after month as we reviewed their sprint outcomes the project wasn’t completed - likely it “just needed another sprint or so.” While we hadn’t drawn a line in the sand for when it MUST be completed - it was exceeding the estimated investment, and we wanted the business benefits. Even though I was not the direct manager, nor the manager’s direct manager I started to be super curious what was going on with these delays (relative to repeated sprint commitments).

Probably a few sprints had gone by this way this way with me hearing about it it indirectly. Most likely the narrative was around unexpected (and detailed) technical issues, folks being out of office, or other specifics. Not something systemic in how work was being done. Eventually, and admittedly too late, I sat down with the team to deepen my own understanding.

What I eventually learned would both haunt me, and inform my views for years to come. While there were 6 people on the team, it slowly dawned on me that only Steve was working on this problem each sprint. Being one of the most senior folks on the team, Steve also had other responsibilities - such as jumping in to help teammates, helping prep other estimates for new work, and so on. Because it was “Steve’s project” and others were pulling tasks of interest there wasn’t a bias to jump the other way to help Steve out. Eventually by being curious about everyone’s assumptions I realized the key mental model of the team was “we do work in parallel in order to go fast and preserve individual autonomy. and interests4” It was a lightning bolt moment of feeling stupid for me. We (and by “we” that means “I”) had not communicated the context on the relative importance of the authentication work to the team. Letting them make this series of decisions based on the otherwise reasonable believe that everything was equally important.

Discussing it more as a group, we made a larger fundamental change. The mental model became “don’t do things in parallel” but instead that everyone should work together to complete the next big thing (the authentication work), rather than trying to do everything all at once. Once we reset this expectation for the team, things got done a lot faster. It also shouldn’t surprise students of flow that more also got done5.

This concept of “swarming” isn’t new and I know it’s often been described as a best practice - well before I had this epiphany. Outside of software development, operational processes have famously sought to streamline the number of things going on at ones - epitomized by the goal of single piece flow from the Toyota system. Even so, this Scrum tendency is worth keeping an eye out for because at almost every place I went to after this story I observed teams proudly working on 8 “things” in a sprint with 6 people. So the idea of focusing and minimizing the number of workstreams with only one person on it is not a solved problem in the wild.

But … taking this further, this story points to the fundamental flaw in the scrum methodology if you’re seeking to maximize flow (aka velocity) in your development process.

Share

Kanban - what is it good for?

For many years I’d heard about and even worked with teams using the Kanban approach to Agile6. I knew a few basic things about it. First, that it was based upon a system pioneered at Toyota that was designed to control work in process across stations in a factory - using a visible card to signal when it was time to do the next piece of production work. Second, when people explained it to me that “it was like scrum, but instead of designing a sprint ‘we just pull the next thing to do off a list’ and do it, oh - and we have a cool board too!”.

I’d ask “Tell me about this board” and be told that each “story” was on a notecard/sticky and that the team tracked all work by placing the cards on the proper place of a highly visible physical board. Where the board’s layout consisted of the following columns:

My main thought each of these times was along the lines of “this seems sort of cool, but I don’t really see why it’s better?” Plus this “pick any piece of work you want seems to violate the forced structure of carefully ordering work by product value/priority.”

I WAS WRONG. Full stop.

Clue #1: The one time I walked into a team room lead by a manager named Patrick I saw the spark of difference. He’s the one who initially made me sure I was missing something, even if it took me years to realize what exactly7. The thing was that when walked into that team room there was a sense of clarity that the team knew exactly what they were doing in which order and why. I just couldn’t put my finger on the reason for it.

Clue #2: Much, much later I think I figured it out - aided by a mini book by a Stuart Corrigan8 and some self introspection after reading Goldratt’s Rules of Flow and attending a Critical Chain virtual conference.

If you’re just having people pull whatever type of work they want next from the backlog then Kanaban is nice, but not really unique in the Agile universe. An approach that addresses the undesirable effects of Scrum without introducing some negative second order outcome is what’s needed. Therefore you want a method that

• Ensures that team members are working on the most important work as defined by your objectives and key results.

• Retain a high degree of team9 autonomy for how the team builds and organizes ways of working.

• Control work in progress (WIP)10 from a top down so as to enable high rates of flow focus on global needs

• Visually highlights constraints to flow such as bad multitasking or too much WIP

It turns out Kanban addresses all of these as long as you; ensure that there is coordination on release of work (starting new development units, the release of work is according to a very simple prioritization rubric aligned with OKR’s, and your team doesn’t just pick up new work when blocked on something11.

Isn’t coordinating work anti-Agile in some way?

The coordination of release of work may run counter to a lot of Agile talk in the past - and could be seen as “non-empowering.” But my view is that we want to empower teams to maximize impact. Impact is throughput aligned against true goals - what you’ve written your OKR’s again, taking into account your unique system bottlenecks. Even if this assignment in the short run occasionally runs counter to what would be most personally interesting for a team member

I’m not saying that personal development and other interests shouldn’t be balanced. But we all mostly have a tendency to want to do things that give us a sense of accomplishment, and often that’s at the expense of doing the harder, but more critical things first. Therefore, this shouldn’t be 100% left up to any one person’s feelings at the moment. Unless that’s one of the very few priorities we’ve decided to use as our decision rubric.

Step 1 is to release work for development (as tracked on your Kanban board) in the order it is needed, ie; aligned with your prioritization rubric12. Step 2 is that once released the work must be completed before moving onto something else. People get stuck/blocked all the time - one should expect that to happen. But once someone is blocked, then it’s important that the team react with the belief that unblocking that person is the most important thing that can happen. If a manager for example sees a team member is blocked, then the manager’s top job at that moment is restoring the flow (aka - helping break the blockage).

If someone on the team (including the dev) has to wait a bit without doing “productive work” then that’s perfectly OK. Because we are maximizing the flow - NOT maximizing the “efficiency” of that developer. This is pretty different than what normally happens in my experience whereas you get blocked, so you switch over to something else while you wait for whatever is blocking you. I do this too - unless I use a structured tool to avoid it - it’s very very easy to just think multi-tasking is the right call. It’s not, sorry.

Likely as a maanger (or a PM) you hear “I’m blocked waiting for ____ so I pulled another task” pretty regularly without it triggering you to spring into action to resolve the issue. But if we care about flow that’s what must happen. What’s great about Kanban is that that board provides an ongoing visual perspective as to whether people are blocked and WIP is piling up. Creating a hard to miss feedback loop that if used with these simple expectations should cause an ongoing focus on maximizing throughput.

Conclusion

That’s it - that’s like 80% of the magic, and why I strongly recommend ditching Scrum in favor of Kanban. If you can avoid the anti-patterns I called out your throughput will likely rise, and with it overall internal and external satisfaction. You cannot do it without

• great OKR’s set in your customer’s world,

• tenets to preload decisions,

• simple prioritization rubrics that focus attention,

• treating tech-debt as a throughput and not moral problem, and

• strong blameless culture that supports psychological safety.

But if you combine these things (and a few others) with WIP control and a zeal to stamp out bad multi-tasking magic can happen.

If you’re new to the Substack I encourage you to read through my prior ramblings.As a set the whole may be worth more than the sum of the parts.

The name’s the thing

I’ve been writing this here substack for a few months. It’s struck me as overly serious at times, and with summer here I thought I’d cover something fun and fluffy.

Sorry, I’m totally, 100% kidding - I’m going to cover one of the hardest problems known to computer science. As stated by Phil Karlton, and boosted in popularity by Martin Fowler1

Over a lifetime in tech I’ve realized it’s sort of true, and not limited to computer science. Choosing a name well in any domain is valuable; whether you’re trying to protect your progeny from an unfortunately obvious (in hindsight) rhyming taunt, avoid your restaurant invoking images of gastrointestinal distress, or just avoiding tempting a universe with a dark sense of humor2.

TLDR;

Try to avoid names that…

• Embarrass because of the implied “type” who would choose that name (see Twilight related names below for an example).

• Feel silly in retrospect if something goes wrong. ie; maybe don’t tempt fates with the “Bulletproof Server”. If you can picture a future review of your movie or software where the critic makes reference to the name of your company/title/system with snarky, undisguised glee - think a bit longer.

• Check the acronym for unintended meaning. Then ask some friends just to be sure.

• Consider just using a name that’s descriptive vs. being too clever. For example, at one place I worked critical incident postmortems were auto-named with two random words. This mashup might have worked for Pride and Prejudice and Zombies but it just left everyone constantly confused about which incident we were talking about.3

• Consider ignoring all these advice if you just know you’ve got a winner even if it violates some of the rules. In the cinematic universe I’m looking at you Sharknado!

• Get back to work on more important things. ;-) But if you insist there’s a whole article below if you insist.

It’s not just a computer science issue

I was originally going to just cover naming tech teams and systems. Because if I’m being honest that’s what I know the most about. But then I realized, why stop myself from pontificating on something just because I don’t really know anything about it4?Instead, let’s just start with kids’s names. Harder than it looks.

First off, there’s just the luck factor. I worked with a super nice engineer named Tom Brady a number of years ago. Very sharp guy, hard worker, introduced me to the marvel of mid-level work kitchen free snacks hackery which is peanut butter + yogurt5. I never asked him, but I strongly suspect he could have gone another lifetime without remarking “no, not that one” nor sharing his views on football inflation levels.

Then there’s the unconscious factors that could set you up for something more on trend than planned. I’m betting that the parents of all the Bellas born in 2009 onward didn’t 100% consider this choice branding them as Twihards for life as surely as if they’d gotten a “Team Jacob” back tattoo6. I’d like to think that most people give some defensive thought to possible baby names. Though I’m not sure what excuses the elders of the world’s “Lesters” have to say for themselves in the inevitable blameless postmortem? Another example where the “premortem”, in this case using your schoolyard rhyming skills, is a valuable practice.

I probably shouldn’t be casting stones in the child naming space. While I’m 99+% happy with our selection of “Hana”, I didn’t realize it was a lifetime sentence of our daughter explaining her correct pronunciation to people. We instilled the “explain the right way to say it quickly” and by probably 3-4 she’d blurt out the correct pronunciation before becoming embarrassed to say anything. Actually, I probably did know this because I had a friend named Kari - who taught me how bad it gets when an executive has been mispronouncing your name for years and you didn’t catch it early.

Some people have entire frameworks for the best way to choose a name. HB Siegel who is definitely one of the most creative thinkers I’ve known suggested one. From what I recall he viewed the best approach is to choose a pretty common/vanilla first name and a more unusual middle name so that the child can choose either one at different life stages. When he said it I immediately regretted not taking up my brother’s suggestion making Hana’s middle name “Peligrosa” so she could choose to share that danger is literally her middle name.

I think HB’s system combined with the whole rhyming pre-mortem is the way to go. Just accept nothing is perfect - we knew Hana sort of rhymed with Banana but we had good reasons for the name so we didn’t let perfect stand in the way of pretty darn good.

Thinking about names in tech

But I didn’t set out to write a guide to how to pre-mortem the choice of your child’s name7. I just had some funny names and no topic in mind this week. Oops! - I mean the intent was intended to focus on naming practices on internal codebases and team. The stuff you and I name at work. Not the sort of public facing names like Pentium which eat up millions in market research8.

I’m going to just zip through some of what I feel are the common naming schemes teams come up with and some fun examples I’ve run across. Please share your favorites in the comments. I’m sure I’ve forgotten some good ones. Another reason in hindsight for keeping a journals. Learn from my mistakes.

Let’s jump in. I love fun names, and I am frustrated by “fun” names when I cannot recall what does what in a system. So while this may have the snark dialed up in places, it comes from a true place of love.

Simple naming taxonomy

System/component/team names seem to fall into one of these not mutually exclusive categories

• Non-explanatory - ie; given the name you are unlikely to be able to guess the function of the service/system. You may though be able to guess some architectural characteristic it’s referencing in some cases. Example: Boss Hogg (likely something big), or Pandora (some kind of wrapper/box)

  • Source: Often beloved childhood references that make the assigner of the name smile but has little to do with the functionality. It can support (or at least signal) quirky/culture insider status. But it’s rarely conducive to deciphering what is going on. Not that that’s always a big deal.

• Explanatory - given the name you can pretty reasonably guess what the service/system does. Though sometimes things stray from the original purpose - in the sense that you rarely name your system ‘giant spaghetti code copy-pasta monolith’ yet sometimes that’s what it became. Example: disbursement control service - probably controls disbursements to something.

• Acronyms - these are usually subsets of predictive names, but need to be pre-checked a bit due to unique but sometimes amusing (to others) failure modes.

For the rest of the article I’ll just share a few examples of

Non explanatory categories

Random words that have no association with anything

Yeah, I don’t know why people do this, but they sometimes do. ‘nuff said

Let’s move on.

Nostalgia (Geeky) naming schemes - aka “Fun” names

This is where you choose some fandom and name things after/within it. Sometimes you’ve built a system where the components have a connection to the fandom sub-names, but often not. Folks that were part of the original team tend to really enjoy the feeling of connection/solidarity that comes from being in on joke (or moment of conception).

There’s a reasonable argument that this approach lacks something in terms of explainability. I get it - but I’m not especially dogmatic about it myself. If you’re doing a basic startup and have a handful of systems then people will figure out the names. If your startup becomes Amazon then it may get a little hairy. Now I know someone is going to point out that Amazon is so huge it’s a bad example and needs some sort of service directory to function (and also has some randomly named system). That’s true, but I think the point still holds.

I tried to think back on real world examples I’ve run across

• Pac-man - It doesn’t always all start from Pacman, but this list does. I’d played a lot of Pacman over the years (OK, some very specific years) but I still cannot remember all the names of the ghosts that made up a specific Supply Chain system.

• mythological stuff and LoTR - TBH I can’t actually remember any systems with either of these. But I’m pretty sure I must have worked in systems for both. Seems like just a law of large number things for our Tribe. ;-)

• Comic book characters - Now, I’m going to admit this is another area where my memory is shaky. I hazily recall a job where the system/subsystem names sounded very familiar, and a few were superheroes. My recollection is that the theme was comic book characters. But while I’m maybe 45% sure about that taxonomy9. Oddly, I’m like 75% sure it then lead to the later systems names which followed which were…

• Independent comic book characters. Presumably when it was pointed out that the original characters were all unrealistically busty and perhaps not the greatest choice. Which had the downside of being especially hard to remember because the closest I’ve been to truly independent comics was watching Chasing Amy.

• Dukes of Hazard characters - you kids may need to look this up. It was a wildly popular TV show about two white “good old boys” from the south who drove a car called the General Lee (with a big confederate flag on the hood), who got up into hijinks that constantly irritated the incompetent sheriff and the town administrator (or something) named Boss Hogg. For extra memorability, Boss Hogg dressed from the same Big and Tall mens shop that the Kingpin did (ie; all white suits). The Dukes had had some sort of trouble with the law and thus I gathered were unable to possess firearms. This then led to them shooting various things with bows and arrows a lot. At least that’s what I remember about this show, well that and their sister who never had shorts that seemed especially comfortable to wear10. I may have hallucinated all of this in a fever dream. But probably not because when I got to IMDb our amazing principal engineer from the UK had chosen this naming system. I cannot imagine what UK audiences thought of the show.

Adjacent to the fandom approach is naming things that hint at some architectural feature (wrappers, orchestration, mythological heroes who were fast, etc). This often balances the “fun” and “descriptive” name axis.

I’m superstitious - so if the reference could have clearly negative (or overly positive) connotations I’d try to avoid it. I recall feeling a bit silly asking a team how they chose the name Pandora for a recent system. I knew it wasn’t for the charm bracelet place in the mall, nor a reference to Avatar11. Mainly I remember the end of the conversation where Dmitry, who I’m sure was annoyed or at least befuddled by the conversation reminded me “but Hope was remaining in the box.” To which I laughed and suggested that’s sort of a consolation prize if you’ve just released all the world’s evils.

Boring, but usefully descriptive names

I think this is probably the most functionally useful approach - just naming the thing in a way that a reader reasonably versed in your system can guess whether it’s close enough to what they’re looking for to look more closely. Yeah, yeah - I know service directories are a thing and you can embed meta content in other ways. These names are less fun and (mostly) don’t lead to me making fun of them in this article. But sometimes life needs a little spice - I’m not judging.

I’m guessing everyone knows what I’m referring to here - but some examples for the heck of it. Mainly to just stretch my own recall a bit a few real world examples

• Order Management Service (OMS) - of Amazon fame (I have no involvement)

• Watchlist service (assumes you know what we meant in the business domain by watchlist but if you did then you were golden)

• Disbursement Control service - covered this earlier

• SellerFeedback Service - most likely for capturing feedback on sellers.

• Pricing service - if you’re pricing a lot of different things you might consider being more specific, but a good bet this system component deals with pricing. Alternatively you can name the same service TheFed and leave everyone a bit confused because you’re nerding out on economist jokes12

• and so on…

There’s one caveat I can think to share about “boring names.” Don’t make them so boring they’re confusable. Beware of descriptive names you mix up at the worst possible time (say deploying code at 2pm. Specifically, don’t have a SellerFeedbackService and a SellerServiceFeedback service. Ask me how I know. Actually, I’m still a bit traumatized by that - so it’s OK if you don’t ask.

The acronym trap

The danger of not running your acronym13 by the more cynical and snarky bunch of your friend group can be lasting. Once folks come out with a name, especially for a team they tend to stick with it. Maybe that’s why three out of the four examples here are team names and only one is a system name.

Funnily, all three of the team names were from one job - an embarrassment of riches with respect to slightly embarrassing names. All staffed by great people though. So, as the opening quote of this article points out - the name really doesn’t matter that much.

• CLAP - I can’t quite recall what this was an acronym for. But when I joined Convoy this was an active team name. When I asked one of the managers whose role included this group why that name I got a hilarious answer. “Well … there’s basically two types of people in the world. Those who see CLAP and picture happy, positive folks applauding something in support. And then there’s everybody else.” If you’re in the former then I seriously applaud your positive, there’s only good in the world attitude. Though I’m not 100% sure I’m as impressed with your school’s health-ed curriculum.

• SAG - Yes, I realize this is the same acronym of the extremely prestigious screen actor’s guild. For them I’m sure this is just fine because it’s probably the most athletically fit and winning bunch of humans collected in a single organization. But if you’re an operating team, it’s hard to see how anything sagging is gonna feel positive.

• Shipment Success - this is a sneaky one. On the surface it’s a fantastic team name. It’s short and direct, and sounds likely to be evocative of the team’s core mission. The only problem was when people who maybe didn’t ace typing in junior high decide “Shipper Services” is too much work and start abbreviating it as “SS.” As one of my even more snarky than me colleagues pointed out, if could have been worse. As he related a fictional conversation in which they “found a really cool lightening emoji” leading to using two lightening bolts instead of SS. It’s a sort of dark joke, but I absolutely cracked up because for a while I kept wanting to say “hey, maybe this SS abbreviation isn’t such a great idea” and the lighting bolt joke made it clear I wasn’t the only one thinking that.14

• Buyer seller messaging system (the BS messaging service - BSMS) - this is a lighter version of the SS group (yeah, sounds so bad doesn’t it). I’m mostly including it because I feel like a jerk writing this story without contributing at least one personal oopsey. I’d shared the story of this super impactful service I’d gotten to be part of the inception of at Amazon. I still remember vividly our SVP just silently writing out the acronym for this project and looking pensive. Then people laughing. We were in hindsight too lazy to act on updating the name. So twenty years later I suppose folks can laugh at that bullshit messaging service we built.

The acronym approach has another sneaky failure mode. Occasionally folks choose an acronym that’s been in use for year by a more wildly popular system. If “in-circuit emulators” has been a thing electrical engineers called “ICE” for like 40+ years than when you call your system ICE15 don’t be surprised if some folks are confused. Similarly if CTR is known as “click through rate” for like the entire internet industry then naming your new freight related metric CTR is gonna confused the newbs.

It’s worth googling your new beloved acronym. You don’t want to be like the new kid in school named Bella truthfully explaining her parents had seriously never ever read or seen Twilight!

A positive acronym example

Here’s an exception that proves the rule. For many, many, shockingly many years Amazon’s entire recruiting operations ran on top of a tool called MRT. Which at the time I was told stood for “Matt Round’s Tool16” but a search of the internet has Matt Round himself referring to it as “Matt’s Recruiting Tool” - which somewhat makes more sense. It is sort of descriptive - Matt’s … tool was a very effective bit of kit for managing interviews at Amazon. Someone I’m sure has amazing stories of the 2-3 times major efforts were taken to build something “better” only to be kicked to the curb. I don’t know much about the BTS stuff there - only that MRT survived at least one or two major attempts to dethrone it. It didn’t do everything but it did enough and sometimes that’s what needs doing. Also this story is making me think about Greenhouse’s applicant tracking thing, and creating a login for each role you apply for, and just using it as a hiring manager, and GETTING SO MAD!!!!

Let’s move on before I realize I can’t turn into the hulk and I’m just raising my blood pressure for no good reason.

Why it’s all worth it

Naming choices can make you feel silly later. Getting a name right is hard. I still understand why taking some risk is worth it, and how quickly one can get enamored by swinging for the fences with a clever name. If the system takes off your 12 year old brain will take great pleasure in slipping one by the squares (or whatever the kids say nowadays). I’ve certainly done it. If you can pull it off it might make you smile every single time you see the project mentioned internally.

I’ll send everyone off to the comments section to share their favorite system and/or team names by sharing a couple of my own not entirely successful attempts to anchor an in-joke name. I’m sure there are a few more that will come to me as soon as I hit publish - but for now I’ll stop here to protect the guilty.

• Superfly - One of my favorite pre-Amazon work experiences was getting to work on a project that increased the throughput of some measurement equipment we were making 5x for basically $0 in extra costs. This came about via one of our team members making several very clever observations about both the nature of our systems constraints and the newer hardware stack we’d been experimenting with for other reasons. It’s a story I look forward to sharing (I love these sort of assumption hacking on constraints), but today is just about names.
  
  After we’d built a proof of concept to wow our corporate overlords a name was required for the system. I don’t remember how long I actually spend on that - but I took on presenter’s prerogative to call the system Superfly. Obviously because it was very fast, but more obviously because when I thought of the system for some reason professional wrestler Jimmy “superfly” Snuka popped into my head.
  
  Perhaps thankfully for everyone involved by the time the project got successfully released it had been renamed the Stream model of our equipment series. Referring to it’s need to not stop before measuring as opposed to the earlier, slower approach. Though losing sales from classic wrestling fans I’m sure.
  
  Still a great win, and likely a better name in the end. But stung a bit.

• Double Secret Probation - When I was working on Trust and Safety (TRMS17) at Amazon we’d build a number of performance management systems. The first being a “Watchlist” system that put sellers into a somewhat gray zone/purgatory of continuing to be active on the platform but slowing their funds disbursement schedule to contain financial risk. At some point we were discussing how to address increased risk profile within this group - and I believe build some heightened monitoring and action taking on this population. I’m embarrassed to admit that I don’t really remember the technical or business details. But I do remember suggesting we name the system Double Secret Probation. Team members either seemed to like that, or was just an example of “highest title in the room” halo effect.
  
  Eventually, I realized most of the engineers had never seen Animal House, or in other words had been better supervised as an 11 year old at their Uncle’s house with his new HBO installation than I had been. Thus I bought a copy of the Double Secret Probation Edition DVD for the team in order to provide cultural mentorship. Which almost immediately seemed like a bad idea. Hopefully the whole statute of limitations is up on that one.

OK - that’s all for today. So please head to the comments and share your most entertaining naming stories. Epic flops encouraged. I’m sure the Clap team would appreciate your candor.

I want you to be nice, until it’s time not to be nice. - Dalton (Roadhouse)

TLDR;

• Being nice is pleasant, but being nice != getting stuff done. Ironically, too much being nice (in the wrong ways) makes people and teams miserable.

• When teams are in conflict they are often seeing different realities. Dealing directly with these varied vantage points is the best path forward.

• Stay curiously engaged with the disagreement until you’ve surfaced everyone’s underlying assumptions. Doing so increases the chance you’ll find a great solution. As a bonus, people are more likely to be happy with a decision in which they were deeply heard out on. Even if something they’d disagreed with is ultimately done.

• Avoiding compromise results in better decisions with higher leverage. Compromise paths rarely are optimal for your global (read important) needs. More often they try to give everyone a little bit towards some local goal - which rarely adds up to something important to the overall enterprise.

• If you really mine the disagreement down to the underlying assumptions level it’s common to find great solutions based on ideas no one had at the start of the conflict.

• When you’re stuck use two simple tools

  • Ask everyone - “what would have to be true for each idea to be the best choice?

  • Still stuck? Get an external view sooner rather than later. AKA the dreaded “escalation” in corp-speak.

• You’re welcome. ;-)

Subscribe now

The downsides of premature agreement

I’ll eventually make a half hearted attempt to write a framework of some sort out on the topic of this article. Serious people seem to love frameworks. But really, my main goal here is to

• encourage you to say no when you aren’t sure you agree with a plan,

• encourage everyone around you to do the same,

• do the hard work of constructively unearthing the assumptions underlying disagreement.

• Finally, without compromise, look for what would have to be true to resolve the conflicts you’ve identified.

Even more than frameworks, statistics prove I feel everyone seems to love a story from the billionaire who’s slightly less controversial than Elon (residents of Venice excepted of course). So let’s go with that…

Jeff Bezos famously worried about social cohesion at the expense of truth. One of my favorite talking points from my Amazon years was how much the culture expected the speaking of truth to power. To disagree and not say anything was not cool, and constructive disagreement was celebrated1. That’s a culture with a higher interest in making the best possible decision than any of these other possible “goals”

• Finishing a discussion quickly

• being right

• feeling smart

• getting along with others

• being see as “nice” or “flexible” by compromising

Of course there are more and less jerky ways of accomplishing this. But at it’s core it struck me from the beginning that this was a very “engineering culture” way of approaching reality. You could also argue it’s the scientific method way as well.1

Dr. Eliyahu Goldratt shares a wonderful illustration of why compromise is unhelpful. Coming from a physics based background, he argues that when people disagree about something, their views of reality differ based on assumptions they are making. Only by examining those assumptions can one untangle how they can view the same actual state of reality and believe different things. In physics the idea of compromising, splitting the difference etc. is laughable - even to the non scientist2.

Everyone laughs at the idea that compromising on the height of a building is a good plan. But I’ve still seen tons of folks splitting the difference in order to get along with another team or person’s view of the world. If you’re haggling with a vendor on the price of a t-shirt then you’ll survive if you ignore the excellent advice in never split the difference. But if you’re a company that’s encouraging people to be “nice” without training on principal based negotiation/reasoning skills then those series of compromises are almost guaranteed to degrade the outputs you care about. Ironically they’ll also leave everyone less satisfied then they would be in a culture of constructive, even aggressively constructive disagreement3.

Before I recognized this problem I’d already lived an endless series of examples. Two teams are in conflict - say about whether the auction function in an adtech system should include some weighting parameter as opposed to filtering out some ads upstream, or whether a price prediction should be used unchanged from team A - or modified with some local information by team B4. They argued and argued5 but didn’t make progress. Or worse, they announced they broke the logjam by some compromise. You can usually tell this happened because they say things are resolved, but look pretty miserable when the topic comes up6.

In each of the cases I’ve seen a better choice would be to (a) agree they are stuck, (b) get some help on resolving the conflict, and (c) make their underlying disagreement more visible and then work together on a framework for how to decide on how to make a decision.

Oh … I owe you a billionaire story don’t I? I’ve got a great movie discussion one about Prometheus, but … I’ll hold that for now and share one on topic.

I was lucky enough to be in the room on an occasion when Jeff B entertained a meeting with reflections on the risks of social cohesion. A pretty notable blunder had occurred recently, and he was reflecting about his own contribution. It’s the sort of thing that felt off the cuff but I suspect may have been repeated in meetings throughout the period to organically cascade a point.7 He was chastising himself for giving in to social cohesion when he went along with a plan he suspected had a downside. It was especially interesting to me because he identified a personal “tell” that he knew he used when he was suspicious about agreeing with something but was tempted to play nice.8

Jeff also told a parable he’d recently come across where a family ends up at a restaurant that literally no one in the family wants to be at because they all assumed something about the others and didn’t want to contradict anyone. I wish I could recall the exact structure of the story as it was a great example - both funny but also something we could all relate to. Sorry! Definitely my bad. This is why one should journal consistently to benefit your future memoir.

In a previous post I was joking not-joking that people thing of Amazonians as jerks7. This is not in my view inevitable if you get people to disagree when they should and avoid compromise. Better to deal with that though than have everyone skip happily holding hands towards a giant sinkhole that one of the “nice” people knows is right there. This probably doesn’t mean everyone has to be great at disagreeing - but you need some critical mass, and probably a practice of actively seeking out the disagreement.

As the parable suggests, it’s best is someone points points out the emperor’s naked. OK class - just stop giggling now please…

Share

But disagreeing all the time is exhausting..

Amazon balances the everyone disagreeing all the time rabbit hole with their Disagree and Commit leadership principle. Focus often falls on the “disagree” side when this principle is discussed. People often also talk about Amazon as a purely top-down culture where everyone “commits.” But when this principle works it’s because of the balance.

Employees are expected to have backbone and share when they don’t agree with something. Once everyone has been heard and a decision taking all the views into account then there are moments where it’s more productive to do something than to keep arguing. That’s the “commit” part. It is very useful, especially if teams couple it with a “tripwire” (not a common Amazon term) identifying under what circumstances they’ll revisit a decision.

The principle in practice can be seen as having three parts in my view

1. Expecting disagreement to make better decisions even when it’s uncomfortable

2. Expecting people to run with decisions that have been made

3. Operationally yet sets tripwires to pre-identify when to revisit choices.

I don’t have the science to back up that these are all necessary and sufficient conditions for it to work, but it passes my biased experiential test for correctness.

Different cultures get jammed up in different spots when dealing with how much to disagree and how to resolve conflict. A friend ones shared a story from a team-building event at an archery range that balances a few large tech companies. Maybe it’s apocryphal but I found it pretty funny nonetheless.

At the start of the event the range staff gave a standard safety briefing. All seemed to go fine. Afterward one of the instructors asked her where the team was from - as they were so different from some other recently hosted events. They described the experiences roughly as

• Amazon: They sat through the briefing, asked some basic questions and accepted the rules as useful to prevent being injured. Then got on with things.

• Microsoft: OK, I’ll admit I totally forgot what they said about those teams’ quirks were. In my defense, it wasn’t as funny as Google, and Microsoft hadn’t yet hit their second run at taking over the world.

• Google: They could barely get to the actual archery because the engineers questioned and then attempted to change/improve every process step. Questioning all the way down to the basic assumptions that are typical for all shooting sports. Largely one would presume due to the physics of not being in front of projectiles at any time.

I’m sure this is unfair of me8 - though Googlers have laughed at this story in the past. But it seems like a simple example as why you do need a culture that can both argue and decide. I’m just writing all this because “compromise” as a decision framework seems more prevalent than argue all the way down culture from what I’ve observed. Also - when folks fight too much it’s usually obvious. Compromise is insidious in that teams can appear to be super highly functioning but not have the high leverage results you expect due to not making principled decisions based on global business goals.

Disagreeing constructively

Hopefully it goes without saying that it’s definitely possible to get this benefit of constructive conflict without being a jerk in how you disagree. Some tips for how to do that are explored in my article on mind reading. In short, the best way to understand another’s problems is by asking - preferably with “what” and “how” lead questions.

The reality is that none of the above came (or comes) easily to me. I’m an introverted person most of the time, and when I’m being honest also a recovering people pleaser. It requires focus and some mental hacks to be able to use my own advice.

• Learn how to say No effectively, and as part of principled decision making. This book is an especially good primer on the topic. Lots of folks tell me they don’t like the intro - so feel free to skip it.

• For two-way doors (decisions that can be reversed) endless arguing may be a bad way to approach things. A great way to deal with disagreement can be to commit to going forward with idea X but agreeing jointly on tripwires that would cause you to stop and re-examine the situation. If folks things that the new design is awesome but agree that higher bounce rates after two weeks would make them question the original plan then set higher bounce rates as a tripwire.

• When you’re thinking about how you don’t agree with something but are hesitant to speak up consider these mental hacks to have better discussions

  • Say something to get the ball rolling quickly - don’t sit and ruminate on exactly what to say. I read that this is a good tip to making conversation with someone you don’t really know and it seems to work here. The longer you wait to object the harder it gets.9

  • If you’re still debating whether it’s worth disagreeing - try some time travel. It’s a few months later and whatever you’re worried about has gone wrong. How much is your stress then relative to the immediate stress you’re worried about from saying something now? Sometimes this will show it’s better to have conflict now vs. a lot of drama later. Almost as often you’ll see it’s not a big deal either way. People aren’t likely to really be that upset, the decision will likely be better, and if you realize you’re wrong you at least increased everyone’s confidence.

  • Ask some questions to build vision in the other party about what specifically they view as risky or undesirable about the solution you don’t agree with. The more curious the questions the better this works. A similar approach is to suggest a pre-mortem before you all really commit.

  • If it’s not so much about failure of an idea and more about choosing the “the best one” then it can be time to trot out the “what would have to be true” experience. Ask everyone to list out all the ideas on the table and get everyone to contribute their take on “what would have to be true for idea #3 to be the best.” Then sit back and look for opportunities in everyone’s not explicit assumptions.

• Focus less on the decision details but more on what would be true about a great decision. Basically construct a quick, high level decision framework to see if there’s agreement on that first. Conflict often comes from differing assumptions, but a subset of this is differing goals. Some really big disagreements are caused because depending on where you sit relative to a problem the goals may be wildly different. Talking about the goals sounds “process heavy” but can cut through a lot of baggage faster than you could read 1/2 of this article.

• If teams are really stuck you can ask the parties to argue the other side’s position. It’s a really interesting approach intellectually - and my intuition is it has value. But it’s a smidge theoretical one for me - a very smart coworker effectively pitched this to me once upon a time. If you’ve used it successfully I’d really like to learn more from you.

• Try the bonus idea in the conclusion section :-)

• DON’T BE A JERK. I’d use stronger language but I think everyone once in a while my dad forwards this to my mom. I’m sure there are cases where being a jerk makes things better, but that feels very much like an edge case.

Conclusion

Hopefully you’ve read through this and found lots of useful suggestions. Or maybe you feel it’s all pretty obvious but someone you know would benefit from it being shared with them. Or maybe you just have a soft spot for the Beastie Boys and/or Patrick Swayze’s best role. I mean you could hate this stuff but have read all the way through anyway. In that case - Thanks Dad!

Rather than recap what you’ve already read I’ll include one thing I don’t believe I mentioned10. When you get stuck - just escalate. If you’ve been disagreeing with a team (or a person) and have tried your best it’s time to get help. Most healthy orgs would prefer you get an external view to help the team decide rather than just bang your excessively well paid heads against a wall.

A short example; when I worked in Ads at Amazon there was a constant battle royale disagreement between the team that put ads at the top of search, and the team that controlled search results. Something about the purity and value of relevance vs. the debasing view of money effing everything up. The search relevance team was always looking out for our ad-loving eternally damned souls - doing lots of research to help out and explain to us find the right answer. But, as often happens in such cases we could not sort through this disagreement. Both teams excelled at not-compromising.

Ultimately, the situation needed Jeff B to truly help. From his external view came a few well placed questions about the max damage of an ill chosen ad to the search team. Given the answer he quickly calculated how often the ads would have to truly suck to be long term negative. That presented a working framework that avoided compromise and got teams unstuck. We left with a new clarity and the teams went on to operate to tremendous gains. If you’re wondering how Amazon maintains their flywheel of low customer pricing this story is part of that .

Long story short - Jeff’s departing comment was how happy he was when something this important was quickly brought to someone who could help with an external view. That stuck with me, because people often think the only options of conflict are to compromise, or argue until resolution. Sometimes one just needs a little help from a friend external viewpoint.