This morning I was watching a BBC News segment on the trial Meta is currently facing, and it stopped me cold. The numbers being discussed aren’t hundreds of millions, or even a few billion — plaintiffs are pursuing damages that could run into the hundreds of billions, potentially over a trillion dollars. Twenty-nine state attorneys general, led by California, Colorado, Kentucky, and New Jersey, are arguing in federal court in Oakland that Meta built Facebook and Instagram to be addictive to kids, knew it, and hid what it knew. The case centers on internal decisions — infinite scroll, notification design, algorithmic feeds tuned for engagement — and on emails going back to at least 2016 that reportedly show the company tracking “teen time spent” as a growth metric. Mark Zuckerberg himself is expected to testify before the trial wraps in about six weeks. It follows an earlier bellwether verdict this spring that already found Meta liable for contributing to a young woman’s mental health injuries.

Whatever the outcome, the trial is a landmark moment. And watching it unfold, I found myself thinking less about Meta specifically and more about the pattern it represents — a pattern I’ve had a front-row seat to for forty years in this business.

Forty years of product meetings, and the question nobody asks

I’ve sat in a great many product design meetings over my career. I can tell you, without exaggeration, that in not one of them has there been a representative in the room, or even a passing discussion, about the potential social harm of the feature being introduced. The conversation is always, one hundred percent, about growth and engagement. How do we get more people to install this? How do we get them to open it every day? How do we keep them here longer?

That wasn’t always the industry’s center of gravity. When I started out, we were selling packaged software to businesses. In the 90s, that same business-to-business model migrated onto the web. The earliest consumer-facing uses of the internet were mundane and useful — companies putting up web forms so you could book a flight, sign up for a service, or check your bank balance. Nothing addictive about any of that.

Then, in the mid-2000s, social networks arrived, and something changed. Facebook emerged from a crowded field — MySpace and others — and the engagement numbers it was showing potential investors were unlike anything anyone had seen. That triggered a genuine panic among investors to get in early, and from that point on, the entire industry’s definition of success shifted. Hypergrowth in the consumer base became the barometer. How fast could you scale? Monetization was often an afterthought — the real question was what features would get people to install the app, keep it installed, and open it daily. That is, I think, the moment that set the current reckoning in motion. And more recently, tech has gone a step further: in many corners of this industry, the explicit definition of success isn’t just growth — it’s attaining a monopolistic position outright.

The problem with how we regulate harm

Here’s what strikes me about the Meta trial, and about the wave of similar litigation before it: our legal system is built to respond to harm only after it has already happened. A civil tort trial requires proof of damages — you have to show that real harm occurred before a court will even hear the case. So the sequence is always the same. A company starts up, grows to enormous scale, some social harm becomes impossible to ignore, and only then do we end up in a courtroom arguing over money.

But by the time a trillion-dollar verdict is even on the table, the damage is done. The growth that built the company happened at the expense of actual people — people whose lives have been upended, who’ve gone through serious financial hardship, who’ve developed real health and mental health problems, and in the worst cases, people who have died, directly or by their own hand. A settlement or judgment, however large, doesn’t undo any of that. It’s the market’s after-the-fact way of correcting itself, and it’s a genuinely terrible way to protect people, because it only works once the harm is already irreversible.

I want to be clear that I don’t think the answer is heavy-handed regulation of every startup from day one. Silicon Valley’s traditional argument — that overregulating how businesses get started and enter markets would stifle the innovation that gave us things like Facebook, Uber, and DoorDash — is a fair point, and largely a correct one. I’ll grant one exception: Uber’s early growth involved knowingly bending and breaking local taxi and livery laws, and that’s a genuinely different case. But in general, we do want young companies to be free to build, experiment, and take risks.

A social contract for founders

So here’s what I’ve been thinking, and it’s an idea I’d like to see taught at business schools, in ethics classes, right alongside the standard startup playbook.

Start your business. Grow your business. Do what you need to do to succeed. But go in aware of a social contract: once your company crosses a certain threshold — and reasonable people can debate exactly where that line is, whether it’s the number of people affected, or the percentage of the population your product touches — you take on a new obligation. At that point, your company becomes subject to regulation, and it’s on you to help shape what that regulation looks like, rather than waiting for it to be imposed on you after something has gone wrong.

Think of it as an analogue to the S-1 process. When a company prepares to go public, it doesn’t wait until the IPO is imminent to get its financial house in order — venture-backed companies build the processes and controls appropriate to a public company from a very early stage, often almost from the get-go, because they know that day is coming. I’d propose something similar here: once a company reaches meaningful scale, it should be expected to prepare a statement — essentially its own regulatory S-1 — laying out how its business should be regulated, and to work with government to actively craft rules that prevent social harm, or mitigate it if some has already occurred. The goal is to never end up in a courtroom facing a trillion-dollar judgment because harm went unaddressed for a decade.

I actually think this could benefit companies, not just the public. If a founding team knows from day one that regulatory scrutiny is coming once they hit scale, that knowledge changes the conversation inside the company from the very beginning. It means someone in that product meeting finally has to ask the question I never heard asked in forty years: what harm could this cause? What regulations might we eventually be subject to, and how do we get ahead of them? That conversation, happening early and often, is worth infinitely more than a class-action settlement negotiated after the harm has already been done, and after real people have already paid the price for someone else’s growth chart.

Sources on the current Meta trial:

• Meta faces federal trial demanding $1.4 trillion for alleged teen harms – Washington Post

• ‘Profits won.’ The child safety trial against Meta kicks off in federal court – NPR

• Meta is on trial – again. Here’s what to know about the case brought by dozens of states – PBS NewsHour

• Meta Stares Down Trillion-Dollar Threat as Landmark Social Media Trial Begins – Bloomberg

See task progress for longer tasks.

meta-lawsuit-social-contract.md

Connectors

Web Search

Over the course of more than 30 years as an engineering manager, I’ve interviewed hundreds---possibly even thousands---of software engineers. At my previous company alone, I conducted a few hundred interviews while helping build out the engineering organization.

We had a structured interview process, and I always explained it carefully to candidates. After a recruiter qualified someone, I conducted the first interview as the hiring manager. I made it clear that I wasn’t going to review their resume or ask technical questions. Instead, I wanted to understand their previous experiences---particularly how they worked with managers, peers, and, in some cases, engineers they had led.

Our interviews followed a consistent format. We used a scorecard in our applicant tracking system with a standard set of questions, so I became very familiar with asking the same questions in the same order. While every candidate brought different experiences, we were generally hiring for the same role: a senior software engineer with strong technical leadership skills.

We were looking for someone who could take ownership of a feature from beginning to end, collaborate effectively with product management, coordinate with other engineers, and help guide technical decisions. Throughout the interview, I paced the conversation carefully so there would always be about ten minutes at the end for the candidate to ask questions.

Most candidates did ask questions. Typically they wanted to know about the team, the engineering organization, the company culture, or the technology stack. If they asked technical questions, I usually deferred them since dedicated technical interviews would come later.

But there was one question that almost nobody asked, even though I had made it clear that I was their prospective manager.

The question is remarkably simple:

“What do you need me to do?”

Or, more personally:

“How can I make you successful?”

There are many ways to ask the same thing:

• What do you expect from the person in this role?

• What problem are you hoping this person will solve?

• What isn’t getting done today that you need someone to own?

• What would success look like after six or twelve months?

A thoughtful hiring manager should have clear answers. They should know what they’re hiring for, the problems they need solved, and why your background caught their attention in the first place. Perhaps there is something on your resume that aligns with a challenge they’re facing. Discovering that early gives you valuable information.

That information helps in several ways.

First, it helps you throughout the rest of the interview process. If you know which of your skills the hiring manager values most, you can emphasize those experiences in your subsequent interviews.

Second, the question demonstrates initiative. It shows that you don’t simply wait to be told what to do---you actively seek to understand where you can have the greatest impact.

Finally, it communicates something subtle but important: you understand that your role is to make your manager successful. People rarely phrase it that way, but in almost every organization, part of your job is to help your manager achieve their goals. Candidates who recognize that tend to think more like leaders than individual contributors.

At my last company, the manager interview was followed by a detailed review of the candidate’s resume. Understanding what the hiring manager cared about made it much easier for candidates to highlight the experiences that mattered most.

The next time you’re interviewing with a hiring manager, try asking some version of:

“What do you need me to accomplish?”

You may be surprised by how much you learn---and by how few other candidates think to ask.

00:00:00,480 --> 00:00:13,900 Intro — showing the short rib meat, bought from Ranch 99.

Hey Liam. Today I’m gonna show you how dad makes a homemade cheesesteak sandwich. This is some short rib that I bought from Ranch 99 yesterday. You can use any kind of thinly sliced meat.

00:00:14,940 --> 00:00:28,320 Weighing the meat (6 oz) and prepping the bolillo roll.

I’ve already weighed out six ounces of it, and you can see that’s how much this is. And then this is a Bolillo roll that I bought from Safeway yesterday, and I’ve already cut it in half, longitudinally, with this bread knife right here.

00:00:29,420 --> 00:01:37,720 Setting up at the stove, heating the grill, toasting the rolls, and searing the meat with salt.

Okay, we’re at the stove and we’re ready to cook. I’ve got my bolillo rolls and some provolone cheese right here. I’ve got the six ounces of meat like before, and I’ve got my favorite spatula for cooking. And then I’ve got a pair of tongs as well, standing by in case I need that to load up the sandwich. So we’re gonna turn the stove on high, and we’re gonna wait for it to heat up. All right, the stove is heating up. I’ve got my thermometer on there, it’s almost up to 400 degrees. You can hear the background noise because the vent is on. I start by just putting these rolls down on the edge of the grill. It’s gonna warm them up a little bit and hopefully increase the flavor. And then this is gonna go on the grill and you can hear right away that sizzle. That sizzle means that the grill was hot enough. Can I add one more thing that I haven’t shown before — I’m just gonna put a little salt on top of this to add some flavor. You gotta remember that the bolillo rolls are a little more bland, so you wanna salt the meat to get a little bit more flavor on it. So while this is cooking, I’m just gonna kinda

00:01:38,960 --> 00:02:09,179 No oil needed thanks to the fat in the short ribs; first flip of the meat.

move it around a little bit. With this cast iron grill and short ribs, you don’t need to add — you’ll notice I didn’t put any oil on the grill because short ribs have a lot of fat in them, and they’re gonna cook up just fine. So I’m gonna leave that go for a minute and we’ll come back when it’s right. This has been cooking for like 10 or 20 seconds, and you can see if you sort of turn this over, that the other side of the meat is already starting to turn a different color. So I’m just gonna grab this up, flip it over.

00:02:10,259 --> 00:02:11,520 Checking the flipped meat.

And there you go. You can see

00:02:12,680 --> 00:02:13,660 Confirming it’s cooking well.

it’s cooking just fine.

00:02:16,400 --> 00:02:17,160 Brief check-in on the cooking process.

Got that going.

00:02:19,820 --> 00:02:26,860 Explaining the meat only needs one flip.

And I’m really not gonna turn this meat multiple times because it really doesn’t need it. It’s gonna cook up,

00:02:28,040 --> 00:02:38,860 Packing the meat to roll size and adding provolone cheese.

just from one side to the other. So what I’m gonna do is pack it together a little bit, to get a little bit closer to the size of the bolillo roll. I’m gonna throw the provolone right on top here,

00:02:40,220 --> 00:02:56,960 Cheese melts and helps hold the sandwich together; making just one sandwich today.

and then that’s gonna start to melt. But the other thing it’s gonna do is keep the sandwich together, and you’re gonna see that when I try to take this off, that’s important. I’m not gonna make a bunch of sandwiches today — I’m only gonna do this as one cut. So,

00:02:58,220 --> 00:03:05,260 Preparing to assemble the sandwich with the spatula.

[laughs] I’m probably gonna mess this up when I try to flip the sandwich together, but I’m gonna do it with the spatula

00:03:06,340 --> 00:03:30,240 Turning off the heat (residual heat is enough) and assembling the sandwich.

and not with the tongs. So the first thing I’m gonna do is turn the heat off, because with the cast iron grill, you’ve got plenty of residual heat and there’s no reason to keep it on this long. So here I go, trying to make the sandwich — hopefully I don’t mess this up. I’m gonna grab all this meat up and flip it onto the top right there,

00:03:31,540 --> 00:03:35,580 Meat stays together; adding the bottom roll.

and you can see it all stays kind of nicely together. I’m gonna add the bottom,

00:03:37,000 --> 00:03:42,859 Final flip and reveal of the finished sandwich.

flip this back over, and there is your dad-style cheesesteak sandwich.

When I started my new job a couple of months ago, my desk came with the usual gear: monitor, mouse, charging cable plus a small stack of books management clearly hoped we’d read and live by. One of them was about Netflix’s engineering culture.

I’d already heard the mythology. Netflix went from mailing DVDs to running one of the largest streaming operations on earth, and somewhere in that leap, the story goes, they overhauled their engineering org: they kept only the “far exceeds expectations” performers and let everyone else go. Productivity went up. Netflix became a giant. The end.

I’ve heard versions of this story more than once in my own performance review cycles, usually from someone in management asking, half-joking and half-not, why we don’t just do what Netflix did. Why carry anyone who merely “meets expectations”? Just cut them.

That question always leads somewhere useful: a conversation about whether your own bar is genuinely high, and whether you’ve actually told your engineers, clearly, what’s expected of them. But it also skips the part of Netflix’s culture that matters more than the bar itself.

Netflix’s real bet wasn’t the bar. It was the trade.

The half of the story that gets dropped is that Netflix engineers are also unusually autonomous. Product managers don’t direct the work or prescribe how a feature gets built, they collaborate. The engineer is expected to own the business outcome of what they ship. Netflix’s own culture memo puts a name to this: “context, not control” — managers give teams the information and clarity to make good decisions themselves, instead of making the decisions for them. For big calls, they name one “informed captain” accountable for the judgment, then let different teams, each with their own captain, execute independently “highly aligned and loosely coupled.” Decisions get argued over (”farming for dissent”), and once made, everyone, including the people who disagreed, is expected to “disagree, then commit.”

That’s the part I keep coming back to. You cannot ask someone to own an outcome they didn’t get to shape. I’ve worked places where a product manager specifies not just what to build but how, waves off real pushback from the engineers building it, and then still expects those same engineers to be accountable for how it performs. That’s not accountability, it’s someone else’s decision wearing your name.

Netflix’s near-zero rulebook only makes sense in that context. Vacation policy: “Take vacation.” Expense policy: “Act in Netflix’s best interests.” Those aren’t quirky perks, they’re what you get when the company has already decided its people should be trusted with judgment calls, so it stops writing rules for people who don’t need them.

Worth saying plainly: this isn’t a purely happy story. Netflix has acknowledged, including in its own updated culture memo, that the freedom got abused: an assistant expensing $30,000 with no rule technically broken is the go-to example. Their fix, notably, wasn’t to add more control. It was to reinforce the responsibility half; hence “People Over Process” now sitting where “Freedom and Responsibility” used to.

Which is really the point. Freedom and accountability aren’t two separate policies you can mix and match. They’re one system, and it only works as a pair. A high performance bar without real decision-making authority isn’t Netflix’s culture, it’s just a harsher review cycle bolted onto the same old command structure. You’ve kept the consequence and cut the deal that made the consequence fair.

So when the question comes up — why don’t we just get rid of anyone who isn’t “far exceeds?” The honest answer is: you can, but only after you’ve given your engineers what Netflix gave theirs first. Real context. Real ownership. Real say in how the work gets done. Skip that part and copy only the bar, and you haven’t adopted Netflix’s culture. You’ve adopted half of it and half of a good idea is a bad idea.

I wanted to share some thoughts on AI in the workplace from the perspective of someone who has spent nearly four decades building software. I’m 58 years old, and next year I’ll celebrate forty years as a professional software engineer. I started at nineteen while I was still studying at UC Irvine, and over those four decades I’ve worked as both a software engineer and an engineering manager across companies ranging from startups to large enterprises. During that time I’ve seen the industry reinvent itself several times, from the rise of the web, to mobile computing, to cloud services. AI feels different—not because it’s replacing software engineering, but because it’s changing who can effectively contribute to every other part of building a business.

I recently joined a software company where AI isn’t simply another tool in the toolbox; it’s part of the company’s culture. During a recent company retreat, our CEO published a collection of AI skills that employees use throughout the organization. People use them to review specifications, documentation, engineering tickets, product proposals, and other internal documents to ensure they are clear, consistent, and aligned with the company’s goals. Working in this environment has reinforced something I’ve suspected for a long time: AI is most valuable when it amplifies human expertise rather than attempting to replace it.

The Communication Gap

To explain why I believe that, it’s helpful to describe something I’ve observed throughout my career. Being an excellent engineer and being an excellent communicator are two very different skill sets. Some engineers possess both, but many do not. I’ve worked with brilliant people who could solve incredibly difficult technical problems yet struggled to explain those solutions to anyone outside engineering. As a result, engineering organizations often become isolated from the rest of the company. Product managers translate customer requirements into engineering work. Marketing translates technical capabilities into customer value. Sales translates product features into business outcomes. Every layer adds value, but every layer also introduces another opportunity for misunderstanding or loss of nuance.

For much of my career I’ve naturally gravitated toward that boundary between engineering and product management. I’ve enjoyed helping bridge the gap between technical implementation and business requirements, and I think I’ve been reasonably successful at it. Even so, I discovered that communicating my own ideas beyond my immediate team was surprisingly difficult. I could often see an opportunity, understand the technology required to pursue it, and even build a prototype, but I struggled to package those ideas into something investors, customers, or even colleagues could immediately understand.

The Companies I Never Built

I can think of at least two occasions where that limitation probably prevented me from building a successful company.

The first occurred in the early 2000s while I was consulting for several Fortune 500 companies. They all seemed to struggle with a common problem: they possessed enormous amounts of business information but lacked effective ways to present it to decision makers. I recognized there was an opportunity, but I couldn’t identify the right market, define the right feature set, or clearly articulate the value proposition. I spent months exploring the idea and even spoke with a few venture capitalists I knew, but eventually abandoned the project because I couldn’t explain what I was trying to build.

Looking back with twenty years of hindsight, I now realize I was describing what eventually became known as web-based business intelligence. The market was there; I simply couldn’t frame the opportunity clearly enough to pursue it.

A few years later, as smartphones and social media began transforming the technology landscape, I found myself working on another idea. I was fascinated by the relationship between people, places, and social connections, and I built a mobile application that allowed you to choose a location, tell your friends you planned to be there, and let members of your social circle discover where their friends were gathering. Like many early mobile applications, it suffered from technical limitations—GPS accuracy wasn’t particularly reliable at the time—but that wasn’t the real problem. The larger issue was that I still didn’t know how to describe the business. I couldn’t clearly explain who the customers were, how the company would grow, or why investors should care.

Someone else eventually solved that problem. The company was called Foursquare.

What AI Actually Changes

Those experiences have shaped how I think about AI today. I often hear people speculate that AI will eventually create entire companies from scratch, independently discovering markets, inventing products, and building successful businesses. Perhaps that day will come, but I haven’t seen convincing evidence of it yet.

What I have seen is something that, in many ways, is more immediately valuable.

If I had those same ideas today, I have little doubt I could build a company around them. Not because AI would generate the ideas, but because it would help me develop them. It would help me identify potential markets, evaluate competitors, refine the messaging, prepare financial projections, challenge my assumptions, develop a business plan, and produce investor presentations. None of those activities replace creativity; they allow creativity to reach people who can act on it.

I think that’s the real revolution. AI isn’t replacing expertise—it is removing many of the barriers that prevented expertise from being translated into products, businesses, and ideas that other people can understand.

AI Isn’t the Source of “Slop”

This leads to another criticism I hear frequently—that AI is flooding the internet with low-quality content, or what many people call “AI slop.” There is certainly some truth to that. The internet is already filling up with generic articles, marketing copy, presentations, and documentation generated with very little thought or care.

But I think that criticism misunderstands the technology.

AI doesn’t inherently produce poor content; it reflects the quality of the thinking behind the prompt. Ask a vague question and you’ll receive a vague answer. Ask for generic marketing copy and you’ll receive generic marketing copy. In many cases, what people call AI slop is simply human slop produced more efficiently.

Over forty years in software engineering, I’ve learned that the difficult part of communication isn’t writing sentences. The difficult part is organizing your thoughts, understanding your audience, deciding what matters, and explaining complicated ideas without oversimplifying them. Those are still fundamentally human skills.

When I use AI, I’m rarely asking it to write something for me. I’m asking it to help me think. I provide context, explain my goals, describe my audience, ask it to challenge my assumptions, and iterate on the results. Sometimes I reject everything it produces. Other times it helps me discover a clearer explanation or a stronger structure than I would have found on my own.

The value isn’t that AI is doing my thinking.

The value is that it helps me communicate my thinking.

Why I’m Optimistic

As engineers, we’ve always understood that tools amplify the quality of the person using them. A compiler doesn’t magically produce good software because someone typed code into it, and a database doesn’t produce valuable business insights simply because someone executed a query. The quality of the output depends on the quality of the design, the quality of the inputs, and the judgment of the person using the tool.

AI is no different.

In fact, I think it does something even more interesting: it increases the return on expertise. Forty years of engineering experience still matter. If anything, they matter more than ever because AI allows me to apply that experience in areas where I was never formally trained—product strategy, marketing, business planning, technical writing, and communication.

Looking back, I don’t think AI would have given my younger self better ideas. I think it would have given those ideas a much better chance of succeeding by helping me explain them, test them, challenge them, and communicate them to investors, customers, and teammates. The ideas were always there; what was missing was the ability to translate them into something the rest of the world could understand.

As I near the end of my career, I find that realization surprisingly energizing. I could retire today—and probably could have retired several years ago—but instead I find myself more excited about software engineering than I have been in a very long time.

Simply put, AI has made this job fun again.

Not because it has replaced what I’ve learned over the last forty years, but because, for the first time in my career, I feel like those forty years of experience can finally reach farther than they ever could before.

I want to talk a little bit about keeping yourself mentally and physically fit as an older person. Let’s be honest: the body starts failing you, and there isn’t a lot of time on your hands. That’s not because you’re lazy — it’s because of everything else pulling at you. Work. Extended family. A spouse, kids, maybe even grandchildren. Fitness, in both senses, has to compete for whatever time is left.

Staying mentally fit

For me, mental fitness has always come down to one thing: going deeper into whatever subject grabs me. There’s a touch of ADHD in my family — something we only figured out later in life — and once I understood that a little better, a lot of my own habits made more sense. I don’t think of it as a disorder. It’s just how I’m wired. I get interested in something, or even a little frightened by it, and I want to know.

My mom likes to tell the family that she got so tired of fielding questions from me and my brother that she bought us an encyclopedia — and I read every volume, cover to cover, over the course of my childhood.

So when the internet came along and information exploded, I was in my element. We all know what happened next, too — a flood of disinformation and content deliberately designed to mislead. It got harder to tell what was true. But it also got easier to strip away the noise and find sources worth trusting, if you knew what to look for.

More recently, AI has become a genuinely interesting tool for me — both as someone who’s just curious about the world, and in my day job as a software engineer. That deserves its own post, so I’ll leave it there for now.

Staying physically fit

Now for the harder half. One of the biggest challenges as we get older is that we simply can’t work out the way we used to — our bodies can’t take the punishment, and recovery takes a lot longer. I think that’s the real reason competitive athletes eventually have to walk away from their sport: not that they’ve lost the skill, but that they can’t put in the preparation anymore.

Over time I’ve developed one trick that’s actually made a real difference, and it connects back to that same attention-span issue I mentioned earlier. I’ll also admit something else here: I’ve struggled with anxiety, with “future-tripping,” and with catastrophizing things before they’ve even happened. Applied to exercise, that means when I think about working out, my mind jumps straight to all the effort I’m about to have to put in. I lose touch with the payoff — the part that actually feels good.

For most of my life I’ve studied rhetorical devices and logical fallacies, both formal and informal. I’ve talked to my son, who’s 18 now, about how important it is to understand how people construct arguments — and how people try to manipulate each other with them.

Here’s the twist: it turns out you can manipulate yourself with a logical fallacy, on purpose, for your own good. The one I use is the sunk cost fallacy.

If you’re not familiar with it, the sunk cost fallacy is a common error in reasoning where, instead of judging a decision on its actual future value, you let yourself be swayed by how much you’ve already invested — time, money, effort — in getting to this point. You keep going not because it still makes sense, but because you’ve already put so much in.

Here’s how I use that against my own resistance to exercise. Instead of confronting the decision “should I work out today?” as one big, effort-loaded question, I break it down into its smallest, most concrete steps. Get out of bed. Take off the pajamas. Put on workout clothes. Walk to the gym, or step outside. Each one of those is small and undemanding on its own — nobody dreads putting on socks. But once I’ve done two or three of them, I’ve already sunk cost into the process. Quitting now would mean the getting-dressed part was for nothing, and that’s usually enough to carry me the rest of the way into an actual workout.

It’s a small trick, but it works because it sidesteps the part of my brain that wants to catastrophize the whole effort up front. By the time that part of my brain notices what’s happening, I’m already at the gym.

If you’ve got a mind that likes to future-trip the way mine does, it might be worth trying on yourself too.

I’ve been reading about how companies raising the tens (and in some cases hundreds) of billions of dollars needed to build AI data centers have landed on a financing strategy that gets described as clever: borrow the money, then bundle that debt and sell it off to institutional investors in pieces.

It isn’t clever. It’s a rerun.

We’ve seen this movie before

That exact pattern — pooling a large number of loans and slicing them into tranches to sell to institutional investors — is what caused the 2008 mortgage crisis. Banks bundled home loans, marketed them as high-quality debt, and sold them off. The flaw was simple: the whole scheme assumed housing prices in different regions wouldn’t all fall at once. They did. Supposedly nobody saw it coming. Everybody saw it coming.

The data center version isn’t hypothetical or something I’m speculating might start — it’s already well underway. Data center loans are increasingly being securitized through commercial mortgage-backed securities (CMBS) and asset-backed securities (ABS), the same structures used for mortgage bonds. JPMorgan projects annual data center securitization issuance could reach $30 billion to $40 billion in both 2026 and 2027, representing 7% to 10% of combined CMBS and ABS issuance in those years, up from about $27 billion in 2025.[1] That’s on top of a much larger wave of AI-related corporate debt and private credit — AI-related companies and projects tapped debt markets for at least $200 billion in 2025 alone, and Morgan Stanley expects $250 billion to $300 billion of issuance in 2026 from hyperscalers like Microsoft and Meta.[1]

It’s not just journalists and bloggers drawing the 2008 comparison. The Bank for International Settlements warned in its annual report that an AI investment bust could hit credit markets with disruption comparable to the 2008 financial crisis, specifically flagging what it called “circular financing” — chipmakers and hyperscalers taking equity stakes in AI labs or neocloud providers who in turn commit to multi-year purchases of chips or computing power from those same investors, with deal terms that are typically poorly disclosed.[4] Lawyers who worked structured-finance litigation after 2008 are using the same word to describe what they’re seeing now: one attorney who worked on housing-crisis litigation said tracking developments in AI data center financing feels like “deja vu,” noting we’re talking about trillions of dollars with almost no transparency about the financing structures.[3]

The scale is the scary part

In 2008, the underlying problem wasn’t just that some mortgages were bad — it was how enormous the mortgage market was, and how much of it had been securitized and distributed into “safe” institutional portfolios. Data center financing is being talked about in the same order of magnitude. Global data center spending could reach $7 trillion by 2030 according to McKinsey estimates,[3] and that money increasingly can’t come just from hyperscalers writing checks out of cash flow — it’s being raised through corporate bonds, private credit, and securitization, layered on top of each other in ways that are hard for any single investor to fully see through.

Will the demand actually be there?

The 2008 crisis depended on a bet that home prices could never fall everywhere at once. The AI data center bet depends on demand for AI compute continuing to grow at something close to its current pace, forever, to justify the debt taken on to build it.

I’ll admit the data here is messier than I expected going in. Per-token prices for AI models have actually been falling sharply, not rising, thanks to competition and efficiency gains — and so far that hasn’t suppressed demand; if anything, usage has grown even faster than prices have dropped. Anthropic’s annualized first-quarter 2026 revenue rose fivefold to $45 billion, and token consumption is forecast to keep climbing even as chipmakers lower annual token costs by 60% to 70%.[5] So the simple story of “prices are rising, so demand must be cooling” doesn’t hold up cleanly.

But that doesn’t mean the underlying concern is wrong — it just points at a different pressure point. The real open question is whether AI usage translates into revenue that can service all this debt. Enterprises are already pushing back on cost, with many companies reporting minimal measurable profit from generative AI pilots,[5] and Goldman Sachs Research has found that gains from the AI buildout have concentrated heavily in infrastructure stocks — semiconductors, hyperscalers, data center operators — with equity gains far outpacing growth in actual forward earnings, a gap that has made analysts more cautious about how long capital spending can run ahead of visible monetization.[6] If growth in paying, profitable AI usage doesn’t keep outrunning the buildout — whether because adoption plateaus, competition erodes pricing power faster than volume grows, or the ROI just isn’t there for enough customers — you get a glut of very expensive, purpose-built infrastructure with no way to pay off the debt behind it. And these facilities aren’t easily repurposed: they’re built around GPU racks, power density, and cooling systems tailored to one job.

There’s also a real question, separate from the financing mechanics, about what all this compute is actually for. It’s not always clear whether the buildout is meant for bigger models, more inference to serve existing demand, or a more speculative bet that enough compute gets you a qualitative leap toward general intelligence. It’s probably some mix of all three. But the dollar figures being thrown around are what make the uncertainty concerning — you don’t want to find out after the fact which bet you were actually financing.

Nobody is stepping in

In 2008, the mortgage crisis eventually forced a regulatory response, but not before triggering a global financial crisis. What’s needed now is the thing the U.S. is generally bad at: getting ahead of it. That means regulators actually looking at how these data center financing deals are structured and passing rules that prevent debt from being oversubscribed or repackaged past the point where anyone can trace the real risk.

There are early signs some people in government are paying attention. Four U.S. senators sent a letter this year calling on the government to investigate how Big Tech is turning to complex and opaque debt markets to borrow staggering sums of cash, warning that massive debt loads could cause destabilizing losses for financial institutions and trigger a broader financial crisis.[3] Whether that turns into actual legislation before something breaks is another matter.

To be fair, there are real differences from 2008 worth naming. Data center tenants are predominantly investment-grade hyperscalers with enormous cash reserves, the underlying demand for AI compute is demonstrably real and growing, and the physical assets have genuine utility that residential mortgage-backed securities lacked when housing demand collapsed.[2] That’s a meaningfully different starting point than subprime borrowers with no ability to pay. But “the borrowers are richer this time” was also roughly the argument made about corporate debt before plenty of past blowups, and it doesn’t address the structural issue: opaque, layered securitization that lets risk pile up in places nobody’s really pricing correctly, at a scale — trillions of dollars — that rhymes uncomfortably with the last time this went wrong.

A side note on Andrew Yang’s tax-AI argument

Andrew Yang has been making a related but distinct case: that the U.S. should tax AI itself rather than labor, on the theory that AI is going to displace workers at scale, and the tax code shouldn’t keep penalizing employers for hiring humans while automation goes untaxed.[7] His argument is built on the same underlying number that worries me here — the trillion-plus dollars going into AI infrastructure — but he uses it to argue corporations need to generate enough revenue from AI to justify those valuations, and that revenue has to come from somewhere, likely payroll.

Taxing the construction and operation of data centers directly could be another route to some of what Yang wants, even if it’s not exactly what he’s proposed. A tax on data center capex or on-site power draw would land squarely on the physical infrastructure driving both the job-displacement story and the financing bubble described above, and it would generate revenue precisely at the moment resources are being committed — rather than waiting to tax AI revenue or job losses after the fact, when the money may already be spoken for by debt service. It also sidesteps some of the “where does AI stop and the human interpretation start” line-drawing problems that critics of a compute or automation tax raise, since a data center is a discrete, physical, easy-to-measure thing to tax. Whether that’s better or worse policy than taxing compute or automation directly is a separate question, but it’s worth having on the table alongside whatever regulatory response eventually comes to the financing side.

Sources

1. The $3 Trillion AI Data Center Build-Out Becomes All-Consuming For Debt Markets — EnergyNow, Feb. 2026

2. AI Data Center Financing Hits $200B: CRE Impact 2026 — The AI Consulting Network, Apr. 2026

3. AI data center boom ‘stress tests’ insurers as private capital floods in — CNBC, Apr. 2026

4. The BIS warns an AI bust could hit credit markets as hard as the 2008 financial crisis — The Next Web, June 2026

5. The AI Bubble Is Stable As A Price War Forces A New Reality — Forbes, June 2026

6. How AI Token Supply Shapes Prices and Investor Returns — The AI Insider, July 2026

7. Tax AI, Not Humans, Again — Andrew Yang, June 2026

This is going to be a short post, in the spirit of some messages I want to leave for my son. I’ve said this to him before, and I say it to myself a lot.

The topic is confrontation — or really any situation where two people have to come to an agreement. Like a lot of things in life, some people are just naturally good at it. I had to learn, and I’ll describe how.

The formula I came up with is simple. I call it the three reasonables: if you make a reasonable request, to a reasonable person, in a reasonable way, you will usually get what you want.

But you have to be honest about all three. Is what you’re asking for actually reasonable? Depending on the situation, it may or may not be. Are you dealing with a reasonable person? This matters especially in heightened situations — even ones where things might turn physical. You have to be clear-eyed about who you’re dealing with. And finally, are you making the request in a reasonable way? If you’re both shouting, neither of you is.

That’s why I think it’s so important to learn to control your emotions — anger and fear especially. They make people behave unreasonably. And honestly, that third reasonable was the hardest one for me. I’d get emotionally triggered, fear would follow, and fear would turn to anger. Anger, as neuroscience tells us, puts blinders on you. It cuts off the part of your brain that’s actually equipped to handle the situation. And then you’re no longer reasonable.

That’s my thought on confrontation — on situations where you have to hold your own

There’s a conversation I’ve been meaning to have with my son — not about any single decision, but about the ones you make every single day without even thinking about them.

Aristotle got there first: “We are what we repeatedly do. Excellence, then, is not an act but a habit.” He wasn’t being poetic. He was describing a mechanism.

The small things aren’t small

When you wake up and reach for your phone before your feet hit the floor, that’s a choice. When you skip the workout because you’re tired, that’s a choice. When you sit down and do the hard thing before the easy one — that’s a choice too. None of these feel significant in the moment. But they compound.

Science backs this up in ways that should give you pause. Research from University College London found it takes an average of 66 days — not the mythical 21 — for a new behavior to become automatic. Some habits take up to a year to truly set. The point isn’t to discourage you. The point is that the person you are becoming right now is being built slowly, quietly, by what you do every morning before the world starts asking things of you.

Identity follows action

Most people think it works the other way — that you decide who you want to be, and then you act accordingly. But watch how it actually unfolds. You don’t become disciplined and then start showing up. You show up, imperfectly, repeatedly, and one day you look back and realize: that’s who I am now.

James Clear put it well: “Every action you take is a vote for the person you wish to become.”

You’re casting those votes constantly. The question is whether you’re doing it consciously.

What I’ve learned

Lao Tzu traced the whole arc: “Watch your thoughts, they become your words; watch your words, they become your actions; watch your actions, they become your habits; watch your habits, they become your character; watch your character, it becomes your destiny.”

That’s not philosophy. That’s a warning.

Your daily routine isn’t just how you spend your time. It’s how you spend your self. The morning you protect to think clearly. The hour you put toward something that matters. The discipline to finish what you start even when the enthusiasm has worn off — especially then.

What I want you to remember

You will not be remembered for the things you intended to do. You will be shaped — thoroughly, permanently — by the things you actually did, day after day, when no one was watching and nothing was forcing you.

Build your days with that in mind.

The secret of your life is hidden in your daily routine. Guard it accordingly.

As I get closer to the end of my career, I’m finding it more and more important to break down some of the experiences I’ve had as a professional software engineer over almost 40 years — to share them, and to try to help the next generation of engineers deal with some of the problems I’ve had to deal with.

So here’s one. When you get into a situation where somebody tries to screw you over — or actually does screw you over — the last thing they expect is for you to patiently wait for the right opportunity to fix the situation, whatever that may be.

Let me give you an example from my own career.

A few years ago now, before the Pandemic, I accepted a relatively small consulting engagement with a very, very early-stage startup. They hadn’t built any product yet — not a single line of code. They needed somebody to come in and architect the system for them, and work with another engineer to build a prototype.

So I put a contract in place. A very important provision in any contract you sign as a professional engineer is the Acceptance Criteria: under what circumstances has the customer accepted the work you’ve done, and therefore owes you payment? A very common provision — one I always add — is that if the customer uses your software for any commercial purpose, they have accepted the software.

The situation was that I went to work for this very early-stage startup. It was about a $27,000 engagement over the course of, I’d say, six weeks or so, with three milestones, each carrying its own milestone payment. The company originally told me they only wanted to pay $18,000 for the engagement, but I sent them some estimates and said, well, I think it’s really going to take more like $27,000. That was the very first tell. Looking back, I realize it was the first sign there might be problems.

They wanted me to use my own computer, but even though I was a contractor, they insisted I come into their office every day. It was actually a WeWork in downtown San Francisco. And despite the fact that asking a consultant to show up at nine in the morning and work until five in the evening sort of automatically makes you not a consultant, I agreed to that as well, because I thought it was an interesting thing to work on.

So I went into the office and was introduced to the other engineer on the project. He was a front-end engineer, I was a back-end engineer, and we were going to be working together to build this prototype. I very quickly realized that this was literally his first job out of college. He had zero experience working in a professional environment. So in addition to building the back end of the system, I was immediately put in the position of having to mentor him, coach him, and help him with his work.

We trundled along through the first milestone. I submitted my invoice and got paid $9,000. Then we trundled along through the second milestone, and I submitted another invoice and got paid again. After a couple more weeks of work, I was getting ready to deliver the final milestone. We had a demoable system — one that showed potential investors what the product was ultimately going to be able to do, and what the value proposition of the company was.

But along the way, a couple of other red flags started to pop up.

I got into a very serious back-and-forth with the CEO about HIPAA compliance. This company was intending to launch a technology product in the healthcare space, and since we were going to be storing patient data, we had to be — in my view — HIPAA compliant. At that time we were running our system on Heroku, which is a very convenient platform to launch startup ideas on. But Heroku is not HIPAA compliant. You cannot launch a HIPAA-compliant product on Heroku.

So I made the CEO aware of this and put some options in front of him that would eventually lead to HIPAA compliance. And I got immediate pushback. It was too much cost, too much effort, way too many problems. At the same time, there was a conversation going on about launching a limited pilot with real patients.

That’s where my concern lay. It became clear to me that the CEO was not going to take HIPAA compliance seriously. In fact, I found out he met with a consultant at one point who told him that companies can self-certify for HIPAA compliance. I pointed out to the CEO that self-certification was for companies like Johnson & Johnson or Procter & Gamble — companies with big internal IT organizations that could actually check all the boxes for true HIPAA compliance.

So I ended up sending the CEO an email basically saying: I’ve done all this work, but I won’t put this system into production for you. I won’t be involved in making this system available to real patients in any capacity, because of the lack of HIPAA compliance.

And with that, I submitted my final invoice and went on vacation with my family.

We went to England. I was sitting in Wembley Stadium with my son and my wife, watching The Pretenders open for Fleetwood Mac — that was the concert we went to at Wembley — and I was thoroughly enjoying myself when my phone suddenly blew up.

Two things were happening at the exact same time. On one hand, the young engineer was texting me, because the CEO was getting ready to demo our product to a potential investor, and he had lots of questions about how to set up the back end and get everything working correctly. So I was helping him with that, sending him instructions for how to do it.

At the same time, I got a message from the CEO and his co-founder telling me they were not accepting the work I had done. They were not going to make the final milestone payment. And in fact, the system was so unacceptable, they said, that they were planning to sue me to get back the $18,000 they had already paid me.

It was at that point that all the red flags came together — and there were other red flags I don’t care to get into here. I realized that for these guys, $18,000 was all they ever had. That’s all they ever intended to pay me. They had essentially been stringing me along to get as much work out of me as possible.

So I sent them back a notice saying: listen, I know you’re about to do a demo for a potential investor. In my view, that constitutes a commercial use of the system I built. So you have accepted this product, and you do in fact owe me the last $9,000.

I can’t remember what they wrote back, because frankly, I was on vacation enjoying myself with my family. So I just filed it away and didn’t think much about it for several years.

The Pandemic happened, and we all got through that. I just waited patiently. Every once in a while I would check in with this company to see what was going on. They were in the telemedicine business, so like a lot of other companies during the Pandemic, they did extremely well. They got funding, they launched, they signed up a lot of patients, and by all accounts were doing extremely well.

Sometime toward the end of the Pandemic — or maybe after — I decided to check in with them again. One of the first things I did was check my laptop, because it turned out I still had a couple of artifacts on my machine from the work I’d done for them. I had the code, because there was no reason for me to delete it. And I also had some AWS keys that I had originally used to set up parts of the system.

Almost on a whim, I tried to access Amazon. I won’t say exactly which services I tried to access, but I just sort of probed. And I discovered that the Amazon keys I had issued to myself years earlier were still valid.

In other words, this company had not done even the most superficial, cursory security cleanup when they let me go — a consultant they had basically stiff-armed and never paid. They hadn’t changed those keys. I immediately shut down what I was doing and went no further, because at one point I was actually looking at patient data. And I was like, okay, this is not good.

So then I checked their website, found out the name of their venture capital firm, and found out the name of the partner who sat on their board. I sent that gentleman a very nicely worded, very helpful, but also very serious message. I laid out the whole thing for him. It was sort of a “did you know about this?” You have these security holes. You obviously don’t have a culture around security. I doubt you’re HIPAA compliant. And — can I please get paid for the work I did, so we can put this all behind us?

And lo and behold, I got paid within three or four days.

Remember, this was years after the initial fallout. I had waited patiently for this point, because that’s the best thing to do. At the point they actually owed me the money years ago, there was no use trying — I wouldn’t have gotten paid. But several years later, after they had raised quite a bit of money, the potential liability was a very serious issue for them. So I got paid right away.

In fact, they asked me to sign a mutual non-disparagement and non-disclosure agreement around these issues, which I did. In retrospect, I probably should have asked for more money to sign it. But I didn’t. I just put the whole thing behind me.

Several years after that, I came to find out that this company, after its initial success, basically imploded — because it turned out they were sending confidential patient data to a third party. I still don’t know what ultimately happened to their business, because at this point I don’t care.

But the point is this: in your professional career, you will run across all sorts of people. And unfortunately, what I’ve seen in my almost 40 years in this business is that the caliber and integrity of a lot of people in our industry has degraded significantly. This is not the only story I have about a startup founder who not only bent the rules but blatantly broke them — broke laws, even — in order to be successful, thinking the rules don’t apply to them. And they do.

So when you run into a situation like this in your career, be thoughtful and be patient. Wait for your opportunity to make things right.

You’ve probably noticed it, even if you don’t have a name for it. The washing machine that doesn’t last as long as the one your parents had. The software you now rent instead of own. The Starbucks that seems perpetually understaffed. The streaming service where you’ve “purchased” dozens of movies you’ll lose the moment you cancel your subscription.

There’s a word for this. It’s called enshittification — the gradual, deliberate decrease in the quality of any product or service over time. The term was coined by the author and journalist Cory Doctorow, who originally used it to describe a specific pattern in tech platforms: the way a platform attracts users with good service, then degrades that service to extract more value for advertisers, then degrades it further to extract more value for shareholders, until there’s almost nothing left for the people who originally showed up. I want to use it more broadly here, because the pattern Doctorow identified in platforms turns out to describe nearly everything. And I want to draw a through line that I don’t think gets enough attention: the legal and political conditions that made enshittification not just possible, but almost inevitable.

How We Got Here: The Legal Foundation

To understand enshittification, you have to go back over a century, to a 1919 Michigan Supreme Court case called Dodge v. Ford Motor Company.

The Dodge brothers — yes, those Dodges, the ones who would go on to found the rival car company — were minority shareholders in Ford. Henry Ford had decided he wanted to stop paying large special dividends and instead reinvest profits into the company, expand production, and raise worker wages. The Dodge brothers sued. And they won. The Michigan Supreme Court ruled that Ford had to pay the dividends, writing that “a business corporation is organized and carried on primarily for the profit of the stockholders.” Not for its workers. Not for its customers. Not even for the long-term health of the enterprise itself. For shareholders. First, last, and primarily.

That principle — shareholder primacy — became the foundational legal logic of American corporate governance. (Dodge v. Ford Motor Company, 204 Mich. 459, Michigan Supreme Court, 1919.)

The intellectual machinery came later. In 1970, the economist Milton Friedman published a famous essay in the New York Times Magazine titled “The Social Responsibility of Business Is to Make Money.” His argument was blunt: corporate executives who voluntarily spend shareholder money on social goods — cleaner factories, better wages, community investment — are, in effect, imposing an unauthorized tax. The only legitimate obligation of a business is to increase profits within the rules of the game. Friedman’s essay gave academic cover to a doctrine that had been humming along in the courts for half a century, and it became enormously influential in business schools throughout the 1970s and 1980s.

Then came the political dimension. To understand how shareholder primacy moved from legal doctrine to cultural operating system, you have to read a document called the Powell Memo.

In August 1971, a corporate attorney named Lewis Powell wrote a confidential memo to the U.S. Chamber of Commerce titled “Attack on American Free Enterprise System.” His argument was that American corporations were under coordinated assault — from the political left, from academia, from consumer advocates like Ralph Nader, from the press — and that business had been far too passive in its own defense. His prescription was systematic and well-funded: corporations needed to staff and fund think tanks, shape what was being taught in universities, cultivate relationships with media, and lobby government with far greater aggression and coordination than they had before. He was, in effect, writing the blueprint for the modern corporate political infrastructure — institutions like the Heritage Foundation and the American Enterprise Institute trace significant parts of their origin and funding to exactly this moment.

Two months after writing the memo, Lewis Powell was nominated to the Supreme Court by President Nixon. He was confirmed in December 1971. And in 1978, he wrote the majority opinion in First National Bank of Boston v. Bellotti — the decision that gave corporations First Amendment rights to spend money on political referendums. The man who wrote the corporate mobilization playbook handed corporations one of their most powerful legal weapons from the bench.

Over a period of roughly a century, American courts steadily expanded the legal rights of corporations until they resembled, in many respects, the constitutional rights of individual citizens. The arc is worth tracing briefly: in 1886, Santa Clara County v. Southern Pacific Railroad (118 U.S. 394) was cited — through a contested court reporter’s headnote, not the actual ruling — as establishing that corporations are “persons” entitled to equal protection under the Fourteenth Amendment. In 1978, the U.S. Supreme Court’s First National Bank of Boston v. Bellotti (435 U.S. 765) gave corporations First Amendment rights to spend money on political referendums. And in 2010, Citizens United v. FEC (558 U.S. 310) completed the circuit, ruling that corporations could spend unlimited sums on political speech. Along the way, the Supreme Court’s 5-4 ruling in Burwell v. Hobby Lobby Stores, Inc. (573 U.S. 682, 2014) held that closely held, for-profit corporations could claim religious exemptions under the Religious Freedom Restoration Act (RFRA) — a statutory rather than constitutional ruling, which means Congress retains the power to amend RFRA and close that door.

The practical consequence is that corporations gained the political and legal standing of persons without the moral accountability of persons. They can speak. They can lobby. They can donate. But they cannot go to jail.

Put all of this together — the shareholder primacy doctrine of Dodge v. Ford, the intellectual legitimization of Friedman’s essay, the decades of expanding corporate rights — and you’ve built a legal and cultural environment in which corporations believe, sometimes rightly and sometimes wrongly, that their only real obligation is to maximize returns for shareholders, even at the cost of the general public, their own employees, and ultimately their own products.

That belief is the engine of enshittification.

The Evidence Is Overwhelming

If you want proof that shareholder primacy has taken hold as an operational doctrine — not just a legal theory, but a genuine guide to corporate behavior — the evidence is not hard to find.

Start with stock buybacks. In 2018, companies in the S&P 500 collectively spent more than $800 billion buying back their own stock, directly inflating share prices. That same year, they spent less than $600 billion on research and development. The math tells you everything: returning money to shareholders was a higher priority than investing in the future of the business.

Look at executive compensation. In 1965, the average CEO of a large American company earned roughly 20 times what the median worker at that company earned. By the early 2020s, that ratio had climbed above 300 to 1 in many industries. The primary driver of executive pay is stock price performance. CEOs are, structurally, optimized to make one number go up — not to build great products, retain talented employees, or serve customers well. If those things happen to make the stock go up, fine. If they don’t, they’re expenses to be cut.

Even the corporate establishment has quietly acknowledged the problem. In 1997, the Business Roundtable — the lobbying organization that represents CEOs of America’s largest corporations — published a statement declaring that corporations exist principally to serve their shareholders. In 2019, to some fanfare, they reversed themselves, issuing a new statement signed by nearly 200 CEOs pledging that corporations should serve all stakeholders: employees, customers, suppliers, communities, and shareholders. It was treated as a landmark moment.

And then, largely, those same companies continued doing what they had always done. Harvard Law School professors Lucian Bebchuk and Roberto Tallarita examined what actually happened after the signing in a paper titled “The Illusory Promise of Stakeholder Governance” (Cornell Law Review, 2021) and found that virtually none of the signatory companies had updated their corporate governance bylaws — the actual documents that boards use to make decisions — to reflect the new stakeholder commitments. The pledge had never been operationalized. It was, in their words, an “illusory promise.” The statement was, in the end, a press release. The incentive structure hadn’t changed, because nobody in the boardroom had been asked to change it.

The Cheapening of Everything

The most obvious form of enshittification is straightforward: make the product with cheaper inputs and hope the customer doesn’t notice.

The American washing machine is an instructive example. Compare the durability and construction of an appliance made in 2022 to one made thirty or forty years ago. There’s simply no comparison. Corporations have spent decades finding ways to use cheaper materials, less expensive manufacturing techniques, and lower-grade components — while keeping the product looking, on the surface, roughly the same. The goal isn’t to deceive customers, exactly. The goal is to preserve the perception of value while steadily eroding the actual value. The machine still washes your clothes. It just won’t do so for as long.

Stretch this logic across nearly every consumer product category and the pattern holds. Furniture. Appliances. Tools. Clothing. The things we buy today are, in most cases, designed to need replacement sooner than their predecessors. This is sometimes called planned obsolescence, but that framing lets corporations off the hook too easily. It’s not just planning for obsolescence — it’s engineering it.

The Rise of Monthly Recurring Revenue

There is a second, arguably more corrosive form of enshittification: the shift from products you own to services you license.

Corporations have become infatuated with what the business world calls MRR — monthly recurring revenue. The logic is seductive from an investor’s perspective. If you sell someone a product once, and it’s a genuinely excellent product that lasts a lifetime, you’ve made one sale. The customer is satisfied. They may even recommend you to others. But you’ll never make another dollar from them directly. Under the old model, building the best possible product was, at minimum, defensible as a business strategy.

Under the MRR model, that math inverts. A product so good it never needs replacing is a liability. What you want instead is something the customer pays for every month, every year, indefinitely.

The tech industry offers the clearest illustration of this shift. I spent part of my career at Lotus Development Corp, which made — among other things — a word processor and a spreadsheet called Lotus 1-2-3. These were dominant products. Then Microsoft entered the market, bundled competing products with the operating systems businesses were already buying, and priced Lotus out of existence. That move effectively eliminated a major competitor and consolidated enormous power in Microsoft’s hands.

But here’s the part that deserves more attention. Once Microsoft had that market dominance, it shifted its entire business model. You used to walk into a store and buy a box: Microsoft Word, Microsoft Excel, a one-time purchase. That model is essentially gone. Today, you license those products. You pay every month, or every year, forever. The software is never truly yours.

And that shift created a problem that Microsoft solved in a particularly telling way: how do you justify charging customers every year for a product they already know how to use? The answer is features. Constant, relentless, often unnecessary features. I watched this from inside the industry and found myself wondering: who is this for? Menus grew more complex. Interfaces became cluttered. At one point, Microsoft had to roll back years of accumulated complexity by redesigning its menus from scratch — an implicit admission that the product had grown unwieldy. But the underlying dynamic never changed, because it couldn’t. The business model demands it.

One consequence of this feature race that I don’t think gets discussed enough: in their rush to add new capabilities to justify ongoing subscriptions, Microsoft embedded a scripting language — VBA, Visual Basic for Applications — directly into Word and Excel. The intention was to give power users more flexibility. The result was a massive, long-lived security vulnerability. Every Excel file, every Word document, became a potential vector for malicious code. A feature nobody asked for, built to satisfy investor expectations, ended up making millions of computers less safe for years.

You Don’t Own Your Movies, Either

The same dynamic has reshaped entertainment. With the rise of streaming, the notion of “buying” a movie has become something of a legal fiction. When Amazon Prime offers you the option to purchase a film, what you’re purchasing is a license to view that film on Amazon’s platform, subject to Amazon’s terms of service. If you ever cancel Prime, those “purchases” go with it. The fine print in Amazon’s terms of service makes this explicit — those licenses are non-transferable. You cannot take them to another platform. You cannot bequeath them. You cannot resell them.

You are, in effect, paying for the privilege of being locked in. Monthly recurring revenue, applied to culture.

Understaffing as a Business Strategy

Move from products to services, and enshittification takes a somewhat different form — but the logic is identical.

Walk into a Starbucks today, or sit in a hospital emergency room, or call a customer service line for almost any large corporation, and you are experiencing the results of a decision made in a conference room somewhere: how few people can we employ without meaningfully hurting sales? Not “how many people do we need to serve our customers well?” Not “what staffing level would prevent our employees from burning out?” The question is almost always about the floor, not the ceiling.

Labor is typically the largest single operating expense a service business carries. Private equity firms in particular have become skilled at identifying businesses where staffing can be reduced — the logic being that customers, out of inertia or lack of alternatives, will tolerate a degraded experience rather than leave. And often, they’re right. At least in the short term.

The results are visible everywhere, if you’re paying attention. The Starbucks line that takes twenty-five minutes when it used to take five, because there are two people working a shift that used to have four. The customer service hold time that runs forty-five minutes, then an hour, because the company has decided that the cost of hiring enough agents to answer the phone promptly is higher than the cost of your frustration. These aren’t accidents or isolated failures. They are the output of a deliberate calculation, made in a spreadsheet, that your time has no value on their balance sheet. You will wait because you have no real choice — and because the people making that calculation know you’ll probably stay anyway.

What makes this particular form of enshittification especially corrosive is that it also falls hardest on the people doing the work. The barista who has to apologize to an irritated customer for a wait that isn’t her fault. The support agent handling a queue no reasonable person could manage. The ER nurse running between too many patients at once. The degradation of the product and the degradation of the job are the same event, experienced from two different sides of the counter.

You Don’t Own Your Tractor, Either

The software licensing logic doesn’t stay neatly inside the tech industry. It has migrated into the physical world, with consequences that are, in some cases, a matter of life and livelihood.

John Deere is the dominant manufacturer of agricultural equipment in the United States. It also sells some of the most software-dependent machinery ever put in a farmer’s hands — modern tractors packed with sensors, GPS systems, and onboard computers that would have seemed like science fiction a generation ago. When that equipment breaks down, the software that runs it is locked. Farmers cannot access the diagnostic tools required to identify the problem, let alone fix it. That access is reserved for authorized John Deere dealers.

The practical consequence is that a farmer whose tractor fails in the middle of harvest — a window that may last only a few days before crops are lost — cannot simply fix the machine they own and go back to work. They have to wait for a dealer technician, who may be days away. The tractor sitting in the field is theirs. They paid for it. In every practical sense, however, they do not own it. They own the hardware. The software that makes the hardware run belongs to John Deere, and John Deere has decided that software is not transferable with the sale.

The argument John Deere makes will sound familiar: you aren’t purchasing the software, you’re licensing it. The same logic that turned your Microsoft Office subscription into a monthly fee and your Amazon movie “purchase” into a revocable license has now been applied to a $500,000 piece of farm equipment. A farmer in Iowa and a software developer in Seattle are, legally speaking, in the same position: they paid for the use of something they will never truly own.

John Deere, facing mounting pressure from farmers and legislators, signed a voluntary memorandum of understanding with the American Farm Bureau Federation in 2023, promising expanded access to repair tools. Voluntary. Unenforceable. Sound familiar?

What To Do About It

The through line in everything described above is not bad luck or market failure. It is the predictable output of a system that was deliberately constructed — through case law, through intellectual frameworks, through coordinated political organizing — to place shareholder returns above every other consideration. That system didn’t build itself, which means it can be dismantled. Here is where to start.

Right to repair. The most direct intervention. Legislation requiring manufacturers to provide customers, and independent repair shops, with the tools, parts, and documentation needed to fix what they own. The European Union has moved aggressively in this direction; the United States has lagged, though more than two dozen states have introduced right-to-repair bills in recent years, and Colorado passed agricultural right-to-repair legislation in 2023. The fight is winnable, but it requires sustained pressure on state and federal legislators who will face well-funded opposition from manufacturers whose dealer service networks are a significant profit center.

Antitrust enforcement. Many of the worst enshittification dynamics are downstream of monopoly or near-monopoly power. Microsoft’s ability to price Lotus out of existence and then lock customers into subscriptions depended on its dominance of the operating system market. Amazon’s ability to sell you a movie license you can’t transfer depends on its dominance of streaming infrastructure. John Deere controls roughly half the U.S. market for large agricultural equipment. When companies don’t have real competition, they don’t need to treat you well. Antitrust enforcement — actually breaking up dominant players, or blocking mergers that would create them — is not a radical idea. It is, historically, how democratic societies have kept market power from concentrating to the point of abuse.

Open source and cooperative models. Not every solution is legislative. The open-source software movement has, for decades, produced tools — Linux, Firefox, LibreOffice, countless others — that are genuinely owned by their users and deliberately designed not to be enshittified, because no shareholder is waiting to extract value from them. Agricultural cooperatives give farmers collective bargaining power against equipment manufacturers and input suppliers. Credit unions exist as direct structural alternatives to shareholder-owned banks. These models don’t scale to replace every corporate product, but they demonstrate that the shareholder-primacy model is not the only way to organize the production of things people need.

A constitutional amendment. This one is a long shot, and I say that without apology — long shots are sometimes the only honest answer to a deeply structural problem. The accumulated power of corporate personhood doctrine was not handed down from nature. It was constructed, case by case, over more than a century, by courts interpreting a Constitution that says nothing about corporations at all. What courts have built, a constitutional amendment could clarify: that corporations are not natural persons, that they hold no inherent constitutional rights, and that whatever legal standing they enjoy exists only because democratic governments choose to grant it — and can choose to limit it. Corporations are legal fictions. They are instruments created by society to organize economic activity. They were never meant to have a bill of rights.

There are already organized efforts pushing in this direction. The Move to Amend coalition has been working toward a “We the People Amendment” that would do exactly this: establish in the Constitution that constitutional rights belong to human beings, not to corporations, and that money is not speech. Whether or not such an amendment ever passes, the argument behind it is correct. A corporation cannot suffer. It cannot be imprisoned. It cannot die. The idea that it should enjoy the same First Amendment protections as a person — that its capacity to spend unlimited money on politics is constitutionally equivalent to your right to speak your mind — is a legal fiction built on top of another legal fiction, and it has had consequences that the drafters of the Fourteenth Amendment could not have imagined and would not have endorsed.

The economists and lawyers who built the legal infrastructure of shareholder primacy spent decades doing it deliberately and patiently. Dodge v. Ford was 1919. The Friedman essay was 1970. The Powell Memo was 1971. Citizens United was 2010. This was not an accident. It was a project. Reversing it will require the same persistence — which starts with being clear about what actually happened, and why your washing machine doesn’t last as long as your parents’ did.

When you’re trying to live a goal-oriented life, you’re trying to be constantly improving yourself. That gets harder as you creep toward middle age, because now there are honest-to-god bucket list items you either haven’t started or just aren’t making any progress on. They sit there. They mock you a little.

I’ve been an engineering manager for more than 30 years, and the way I’ve started thinking about this is that, just like at a company, the projects I’ve taken on for myself are a backlog. I’m a blue belt in jiu-jitsu — I’d love to get to purple someday. I’m trying to claw back my Spanish after letting it rust for 30 years. There’s general fitness and health, which gets harder, not easier — you can’t just flop into bed at the end of the night and pop up eight hours later like you could in your 20s. Now it’s a struggle to get to sleep, a struggle to stay asleep. Oh, and I’m trying to write three books. Not one. Three.

If you’ve ever worked in software, you know what this looks like: a pile of open Linear tickets that have been sitting there for years. The tasks have subtasks. The subtasks have subtasks. Every time you look at the board, you feel further behind than the last time.

The cycle that eats your life

Here’s where it gets ugly. You put all these expectations on yourself, you fail to live up to most of them, and then you beat yourself up about it. The self-criticism kicks the anxiety up a notch. Anxiety scrambles your emotional state. And when you’re not in a good emotional state, it’s really difficult to get any work done. It’s actually painful.

I think this is one of the reasons people distract themselves so much. When you’re staring at what feels like an insurmountable list — a list you put on yourself, by the way — your brain reaches for the cheapest available dopamine. Phone. TikTok. Instagram. “Just five minutes.” Two hours later, you’ve done nothing, and the list is still right there waiting for you. The cycle is: overwhelm → distract → still overwhelmed, but now also two hours behind. It’s maddening.

Manage yourself like an engineer

I know how to manage engineers. I’ve spent decades doing it. So I figured: maybe I should start managing myself like an engineer.

Here’s the thing about that. In my work life, I’ve gotten pretty practiced at staring down product managers and telling them — politely, but firmly — to put everything in priority order. Product managers are great people, but their literal job is to ask engineering for things. And if you’re not careful, a well-meaning PM will overwhelm you with “must-haves,” because to them, it’s all must-haves.

So I push back. I say: there is no must-have line. Everything goes in priority order. Top to bottom. Because every single day, every engineer on the team is making decisions about what to put their attention on, and they need to be able to look at the list and just start at the top.

The same thing applies to your personal life. The problem is that you are both the product manager and the engineer. You’re the one piling on the requests, and you’re also the one who has to do them. And you, the PM-version-of-you, can absolutely overwhelm you, the engineer-version-of-you, with very well-meaning requests.

Build a bomb-proof priority list

What you need is a bomb-proof list of priorities, in the actual order they’re important to you in your life. Not aspirational order. Not “what would sound good on a podcast” order. The real order.

When you have that, then on the days when you’re overwhelmed and can’t even figure out where to put your attention next, you don’t have to figure it out. You just go to the top of the list and ask: am I making progress here? Am I falling behind?

For most people, health probably belongs at or near the top. It’s also the easiest thing to fall behind on. By health I mean the boring, well-known stuff: drinking enough water, eating real food regularly, getting enough sleep, exercising. We all know we should do these things. That’s not the hard part. The hard part is the motivation, and the motivation gets a lot easier when health isn’t competing for attention with eight other things you also told yourself were “must-haves.”

Stop blaming the people around you

One more thing, and this one is uncomfortable.

When you put too many expectations on yourself, there’s a real tendency to look around at the people in your life and start blaming them. They’re asking too much of you. They’re not helping enough. They’re getting in your way.

Be careful with that. In most cases, you’re the one asking too much of you. You are the product manager of your own life. You are the business manager of your own life. If you’ve put so many expectations on yourself that you can’t possibly do it alone — that’s fine. Get help. But look in the right places for help, and don’t reflexively blame the people around you for not solving a problem you created.

I tell engineers this. I tell my son this. It is totally okay to need help. But you are the one who has to ask for it. You have to figure out who, and how, and in what way to ask. Sometimes the most useful help isn’t even someone else doing a thing for you — sometimes it’s just a person looking at your list with you and saying, “Yeah, you don’t actually have to do that one.”

TL;DR

You are the product manager. You are the engineer. The PM-you can overwhelm the engineer-you, and when it does, the engineer-you starts scrolling TikTok at 11 p.m. instead of sleeping.

So manage yourself the way you’d want to be managed. Make the list. Put it in real priority order, top to bottom, no must-have line. Start at the top. Ask for help when you need it. And every once in a while, give yourself permission to look at a ticket that’s been open for two years and just close it.

Not every goal deserves to be on the board.

It’s an easy mistake to make, and an intuitive one. You’re building a command that does a few things: call Stripe a couple of times, get back payment objects, and write the results to the database. You want the whole thing to be atomic — if anything fails, nothing should be persisted. So you wrap everything in a transaction. Done, right?

Not quite. This pattern — third-party API calls inside database transactions — is one of those things that looks correct on paper but causes real pain in production. I’ve seen it take down services at exactly the wrong times. Let me explain why, and what to do instead.

The Intuitive Approach

Imagine you’re scheduling a payment. The operation requires three calls to Stripe: create a customer, attach a payment method, and schedule a charge. After each call you get back an object and you want to persist it. Something like this:

def call
  ActiveRecord::Base.transaction do
    customer = Stripe::Customer.create(email: user.email)
    db_customer = StripeCustomer.create!(stripe_id: customer.id, user: user)

    payment_method = Stripe::PaymentMethod.attach(
      payment_method_id,
      customer: customer.id
    )
    db_payment_method = StripePaymentMethod.create!(
      stripe_id: payment_method.id,
      stripe_customer: db_customer
    )

    charge = Stripe::PaymentIntent.create(
      amount: amount_in_cents,
      currency: 'usd',
      customer: customer.id,
      payment_method: payment_method.id
    )
    StripeCharge.create!(stripe_id: charge.id, stripe_payment_method: db_payment_method)
  end
end

The appeal here is obvious. If the third Stripe::PaymentIntent.create call blows up, the transaction rolls back and none of those partial records land in the database. Clean and atomic.

The problem is what you’re doing to your database in the meantime.

The Latency Mismatch Problem

A database transaction is not a free operation. Depending on your isolation level, it holds locks — at minimum on the rows it has written to, potentially on the pages or tables those rows live in. Those locks are held for the duration of the transaction.

On a well-provisioned system — say, two services on the same AWS availability zone — a straightforward database operation (a simple SELECT, INSERT, or UPDATE) should complete in well under 10 milliseconds. A batch of several such operations inside a single transaction? Still probably under 10ms total.

Stripe API calls, on the other hand, regularly take 500–700ms. Sometimes more. There’s no amount of infrastructure tuning you can do on your end to change that. You’re at the mercy of Stripe’s servers and the public internet.

So what you’ve actually built is a transaction that holds database locks for the better part of a second, per call, times however many Stripe calls you need to make. Three Stripe calls? You’re looking at a transaction that holds locks for potentially 2 seconds or more. And if you have any concurrency at all — multiple workers, background jobs, web requests — those locks start competing.

What This Looks Like in Production

At Mudflap, we had a background job that ran every morning to update fuel prices and validate a large number of cached objects. This job made multiple third-party API calls and also needed to commit a significant number of database updates. At some point, someone had wired this up with the API calls living inside transactions.

During the morning run, we started seeing cascading database performance issues. Connections were getting held. Queries were backing up. The combination of high-concurrency writes and long-running transactions caused severe lock contention — and the morning price update, which customers depend on at the start of their day, was the worst possible time for it.

The fix was straightforward once we diagnosed the problem: pull the API calls out of the transactions entirely.

The Pre-Transaction Pattern

The solution is to restructure your command object so that all third-party API calls happen in a dedicated pre-transaction step. The results are stored as instance variables on the command object. Then, in a separate step, you open the transaction and do nothing inside it except write to the database.

Here’s what that looks like:

class SchedulePaymentCommand
  def call
    fetch_stripe_objects   # pre-transaction step: all API calls happen here
    persist_to_database    # transaction step: DB writes only, no network I/O
  end

  private

  def fetch_stripe_objects
    @stripe_customer = Stripe::Customer.create(email: user.email)

    @stripe_payment_method = Stripe::PaymentMethod.attach(
      payment_method_id,
      customer: @stripe_customer.id
    )

    @stripe_charge = Stripe::PaymentIntent.create(
      amount: amount_in_cents,
      currency: 'usd',
      customer: @stripe_customer.id,
      payment_method: @stripe_payment_method.id
    )
  end

  def persist_to_database
    ActiveRecord::Base.transaction do
      db_customer = StripeCustomer.create!(
        stripe_id: @stripe_customer.id,
        user: user
      )

      db_payment_method = StripePaymentMethod.create!(
        stripe_id: @stripe_payment_method.id,
        stripe_customer: db_customer
      )

      StripeCharge.create!(
        stripe_id: @stripe_charge.id,
        stripe_payment_method: db_payment_method
      )
    end
  end
end

The transaction is now doing only what it should: coordinating a set of fast, local database writes. Lock hold time drops from ~1.5 seconds to under 10ms.

“But What About Atomicity?”

This is the obvious objection. In the original pattern, if anything fails, the transaction rolls back. With the pre-transaction pattern, what happens if the API calls all succeed but then the database write fails?

It’s a fair concern, but it’s also fully solvable — and handling it explicitly is actually better than relying on a transaction rollback, because a rollback doesn’t undo what already happened on Stripe’s end anyway. If you made three Stripe API calls before the DB write failed, rolling back your database changes leaves you with orphaned Stripe objects. The transaction gives you a false sense of safety.

The right pattern is a structured error handling routine on the command object — something that has a specific job: clean up whatever API-side state was created if the overall operation fails. Since the Stripe responses are stored in instance variables, the error handler still has access to them:

class SchedulePaymentCommand
  def call
    fetch_stripe_objects
    persist_to_database
  rescue => e
    handle_error(e)
    raise
  end

  private

  def fetch_stripe_objects
    @stripe_customer = Stripe::Customer.create(email: user.email)

    @stripe_payment_method = Stripe::PaymentMethod.attach(
      payment_method_id,
      customer: @stripe_customer.id
    )

    @stripe_charge = Stripe::PaymentIntent.create(
      amount: amount_in_cents,
      currency: 'usd',
      customer: @stripe_customer.id,
      payment_method: @stripe_payment_method.id
    )
  end

  def persist_to_database
    ActiveRecord::Base.transaction do
      db_customer = StripeCustomer.create!(
        stripe_id: @stripe_customer.id,
        user: user
      )
      db_payment_method = StripePaymentMethod.create!(
        stripe_id: @stripe_payment_method.id,
        stripe_customer: db_customer
      )
      StripeCharge.create!(
        stripe_id: @stripe_charge.id,
        stripe_payment_method: db_payment_method
      )
    end
  end

  def handle_error(error)
    # Cancel whatever was created on Stripe's end, if anything
    Stripe::PaymentIntent.cancel(@stripe_charge.id) if @stripe_charge
    Stripe::PaymentMethod.detach(@stripe_payment_method.id) if @stripe_payment_method
    Stripe::Customer.delete(@stripe_customer.id) if @stripe_customer

    Rails.logger.error("SchedulePaymentCommand failed: #{error.message}")
  end
end

The key insight: handle_error is a method designed to be overridden in subclasses. It’s not a catch-all — it’s the specific, intentional cleanup routine for this command. Each command knows what it created and knows how to undo it. That’s a cleaner contract than hoping a database rollback somehow undoes side effects that already happened in an external system.

The Container Shutdown Problem

There’s a harder failure mode that doesn’t get talked about as much, and I want to be upfront: it’s a problem with the pre-transaction pattern specifically, but it’s also a problem with the original wrapped-transaction pattern. Moving the API calls outside the transaction doesn’t introduce it — it already existed. It just becomes more visible when you start thinking carefully about the pre-transaction step in isolation.

Here’s the scenario. You have a container running in production. A deploy kicks off, the orchestrator sends a SIGTERM, and the container is supposed to drain in-flight requests before shutting down. Supposed to. In practice, containers sometimes get killed before they finish draining — either because the shutdown grace period is too short, the orchestrator loses patience, or the drain logic itself has a bug.

Now imagine that kill signal arrives at exactly the wrong moment: after a Stripe call has been dispatched from the pre-transaction step, but before the response has been received and written to the database. The HTTP request is already in flight to Stripe’s servers. From Stripe’s perspective, the operation completes successfully — the customer, payment method, or charge now exists in their system. From your system’s perspective, the process is dead. The response never arrived. Nothing was committed to the database. The operation simply didn’t happen as far as your records are concerned.

This is sometimes called a “ghost” operation: a real side effect in an external system with no corresponding record in yours.

What happens next depends on how your retry logic works. If the job is re-enqueued on restart and the operation runs again without any memory of what the previous attempt created, you make the same Stripe API calls again. Without idempotency keys, Stripe treats each of these as a new, independent request. In the case of Stripe::PaymentIntent.create, that means two separate charges get created for the same order. The customer gets billed twice.

Idempotency keys are the standard mitigation here, and Stripe supports them well. The idea is to generate a stable, deterministic key for each logical operation — typically derived from something like the order ID and the operation type — and pass it to Stripe on every call. If Stripe receives two requests with the same idempotency key within a 24-hour window, it returns the result of the first request instead of processing a new one.

def fetch_stripe_objects
  idempotency_key = "schedule_payment_#{order.id}"

  @stripe_customer = Stripe::Customer.create(
    { email: user.email },
    { idempotency_key: "#{idempotency_key}_customer" }
  )

  @stripe_payment_method = Stripe::PaymentMethod.attach(
    payment_method_id,
    { customer: @stripe_customer.id },
    { idempotency_key: "#{idempotency_key}_payment_method" }
  )

  @stripe_charge = Stripe::PaymentIntent.create(
    {
      amount: amount_in_cents,
      currency: 'usd',
      customer: @stripe_customer.id,
      payment_method: @stripe_payment_method.id
    },
    { idempotency_key: "#{idempotency_key}_charge" }
  )
end

With idempotency keys in place, a retry after a botched shutdown is safe: Stripe deduplicates the calls and returns the original response objects. Your retry can then persist those results to the database as if the first attempt had never been interrupted.

But idempotency keys don’t fully solve the problem. They protect you from creating duplicate objects in Stripe, but they don’t help you recover the original response after a container death. When the retried job runs, it still calls Stripe fresh and gets a response — it just happens to be the same response as before. The window between “API call succeeded” and “result written to the database” is still a gap where a process death causes silent data loss. And depending on how you structure retries, you may not even know the first attempt ever started.

At the time of writing, we’re still working on a robust solution to this. The approaches worth exploring involve making the pre-transaction step itself more durable — writing an intent record to the database before making the API call, so that a retry can detect partially completed operations and reconcile them. That’s a more involved pattern, and it deserves its own writeup.

The Rule

Here’s how I think about it now: a database transaction should contain only database operations. Any call that goes over a network — to Stripe, to a payment processor, to any external service — should live outside the transaction. Make all your external calls first, validate that the results look sane, then commit everything to the database in a fast, tight transaction. Handle failures explicitly with cleanup logic that knows what it actually needs to undo.

Transactions are a powerful primitive. They’re designed for coordinating local, fast, reliable operations. Stretching them to cover slow, unreliable network calls doesn’t make your system more correct — it just makes it slower and more fragile at the same time.

The cracks appear later. Some part of the database is straining under load you could have predicted. A shared library has three incompatible versions living in three different pods. Nobody owns the work needed to fix it, because nobody was ever asked to.

The problem isn’t the pod structure — that part works. The problem is a missing team.

How the pod model is set up

The typical structure is elegant in its simplicity. You have five or six product managers, each paired with a pod of engineers — say, five or six people, led by a tech lead. A layer of engineering management sits across those pods. Engineers report up through management but work day-to-day with their product manager.

This creates something genuinely valuable: tight product-engineering alignment at the team level. Engineers understand the “why” behind what they’re building. Product managers develop technical intuition. The pod is largely autonomous, with few dependencies on other teams.

Product orgEng. managementPM 1GrowthPM 2PlatformPM 3Core productPod 15–6 engineersPod 25–6 engineersPod 35–6 engineersSolid = product directionDashed = reporting line

The standard pod structure — effective for product velocity, but silent on cross-pod technical work

At 40–50 engineers across six pods, this is a formidable product machine. But notice what’s missing from the diagram above: there’s no regular forum where the engineers in those pods talk to each other as a technical community.

The asymmetry nobody talks about

Here’s a tension baked into the pod model. The product organization is small — six people who meet regularly, coordinate roadmaps, and share context. They function as a team. The engineering organization is five or six times larger, and typically meets in fragments: each pod runs its own standups and planning, but the 40-person engineering org rarely convenes as a whole.

This isn’t a failure of management. A weekly all-hands with 40 engineers is genuinely unwieldy. But the practical consequence is that nobody is holding the cross-cutting technical picture.

Where it breaks down: Shared architectural components that two pods both touch. Technical debt that doesn’t belong to any PM’s roadmap. Infrastructure that needs re-architecture to support the growth the product team has already planned for — but hasn’t told engineering about yet.

The product team has visibility into what’s coming. The pod teams have deep visibility into their own corner. No one has the full technical view. That’s the gap.

The tech lead council

The fix is a standing team of tech leads — one from each pod — meeting on the same cadence as the rest of the organization. Call it a tech lead council, an architecture forum, whatever fits your culture. The name matters less than the habit.

This team does something specific: it holds the technical picture that no individual pod can hold on its own.

In practice that means: comparing implementation approaches across pods before work diverges, identifying opportunities for shared components, surfacing technical work that needs to happen for business reasons no PM has yet named, and developing a 6–12 month technical roadmap that runs alongside the product roadmap.

Product roadmapPM team, quarterlyTech roadmapLead council, quarterlyShared planningRisk, priority, sequencingLead, pod 1Arch, debt, shared codeLead, pod 2Arch, debt, shared codeLead, pod 3Arch, debt, shared code

The tech lead council bridges pod-level execution and org-level planning

The goal is that this team’s outputs — architectural recommendations, decisions to adopt new tooling, proposals to allocate sprint capacity to debt retirement — are treated with the same weight as product requirements. That takes time to earn. The team earns it by being right consistently, by communicating their reasoning clearly, and by building a track record the rest of the organization learns to trust.

“At the same time you’re developing a vision of what the product will look like a year from now, you need a group of people meeting regularly to discuss what the future of your technical stack looks like.”

In more mature organizations, this function often migrates toward staff engineers or a principal engineering group. The exact structure depends on where the company is. What shouldn’t vary is the underlying principle: technical planning must be ongoing, structured, and given organizational standing.

Team-ness at every level

There’s a broader pattern here, one that applies not just to tech leads but to every layer of the organization. The most effective teams aren’t collections of individuals each reporting to a shared manager. They’re actual teams — people with shared goals who work together on the business of their level, not just up and down their individual reporting lines.

One CEO put it well to his executive team: “You’re not six people who each report to me. You’re a team, and I’m the lead of that team.” The consequence was that most decisions got made and executed by the team, without the CEO needing to be in the room. Issues came to the weekly meeting; only the things that required a tiebreaker or an especially consequential call escalated further.

The same logic applies at the tech lead level. If those leads see themselves as a team — not just representatives of their respective pods attending a meeting — they’ll make better architectural decisions, resolve cross-pod tensions more quickly, and present a more coherent technical direction to the rest of the organization.

Putting it into practice

None of this requires a reorg. It requires one standing meeting, a clear mandate, and leadership willing to treat the outputs as real inputs to planning. Start with the tech leads meeting biweekly. Give them a simple agenda: what architectural work is each pod planning this sprint, is any of it shared, and what technical work needs to happen in the next six months that isn’t on any PM’s roadmap yet.

The meeting will feel unfocused at first. Give it three months. By then, the leads will have developed shared context, a working vocabulary, and a sense of what they can resolve themselves versus what needs to escalate. That’s when the value shows up — not in a single decision, but in a dozen small ones that don’t require a VP to broker.

The pod model gives you product velocity. The tech lead council gives you the architectural coherence to sustain it. You need both.

I’ve been a professional software developer for almost 40 years. I’ve spent more than 30 of those years as an engineering manager and executive — CTO, VP of Engineering — watching the industry evolve through multiple generations of technology.

I started in the era of packaged software. We put programs on disks, sealed them in boxes, and sold them in stores. Then came client-server development. Then the web. Then mobile. Then social media. And now AI.

Across all of those waves, Silicon Valley — and American technology companies more broadly — have led the world in innovation. We’ve built new categories of products, created massive global businesses, and changed how people live and work.

But over the last 10 to 20 years, as companies have grown bigger, richer, and more powerful, I’ve watched the same tragic pattern repeat itself over and over again.

We invent something world-changing — and then we immediately chain it to the quarterly result.

The Moment Innovation Gets Constrained

The cycle is predictable.

A company builds a new technology. It proves itself commercially viable. Customers love it. The product begins to change the world in real, meaningful ways.

And almost immediately, the organization clamps down on it to satisfy Wall Street expectations.

The long-term vision that drove the innovation — the idea that we were building something transformative — starts to narrow. The horizon shrinks. Instead of asking what the technology could become in five or ten years, leadership becomes focused on how it performs next quarter.

The spirit of innovation doesn’t disappear. Engineers and product teams still believe in the big ideas. But structurally, the company shifts from exploration to extraction.

Shipping Too Early: The First Self-Inflicted Wound

One of the worst mistakes a company can make is bringing a product to market before it is ready.

I’ve seen this happen many times. A promising idea gets rushed out the door because leadership wants momentum, headlines, or revenue sooner rather than later. The result is predictable: customers become frustrated, trust erodes, and the original promise of the product gets overshadowed by early negative experiences.

Good ideas have been ruined this way.

There is a difference between iterating quickly and shipping prematurely. Healthy iteration builds confidence and improves quality. Premature release creates a reputation that can follow a product for years, even after it improves.

The pressure to meet quarterly expectations often accelerates this mistake. When timelines are driven by financial cycles rather than product maturity, teams lose the space needed to refine and stabilize what they’re building.

When Entire Technologies Get Distorted

There’s an even more dangerous version of this pattern: trying to extract too much value from a new technology before it has fully matured.

In those cases, it’s not just customer frustration that’s at risk — the entire category of technology can become warped by premature monetization and short-term incentives.

Social media is a powerful example.

Many early platforms carried a genuine promise: connecting people across distance, fostering conversation, and creating new forms of community. There was a sense that these systems could become forums for constructive discourse and shared understanding.

But once the pressure to maximize engagement and revenue intensified, the incentives changed. Feeds filled with ads. Algorithms optimized for attention rather than well-being. Doom scrolling replaced meaningful interaction. Online trolling and bullying became amplified rather than mitigated.

The technology itself wasn’t inherently flawed. The way value was extracted from it — too early, too aggressively, and too narrowly focused on growth metrics — reshaped the category into something far different from its original vision.

Heads Down, Eyes Off the Horizon

Once a company ties its identity to quarterly performance, something subtle changes in how decisions get made.

Roadmaps compress. Risk tolerance drops. Long-term investments become harder to justify. Teams spend more time optimizing metrics than imagining possibilities.

I’ve seen organizations put blinders on — not because people stopped caring about innovation, but because the system incentivized short-term predictability over long-term transformation.

Every year, plans are built around hitting numbers. Miss the numbers, and the market punishes you. The stock price drops. Investors look for a new CEO who promises tighter execution and faster results.

Over time, this creates a culture where innovation is tolerated only if it can be forecasted on a spreadsheet.

The Long Game vs. The Quarter

It’s impossible to ignore the global context. Over the course of my career, China has emerged as a technology powerhouse.

Yes, some technologies originated here in the United States. Some were copied or adapted. But what stands out to me is not just what was built — it’s how long-term strategy was applied.

Chinese companies, from my perspective, have often played a longer game. They invest in infrastructure, ecosystems, and platforms with a time horizon that extends beyond the next earnings call.

That doesn’t mean they ignore financial performance — every business has to survive economically. But there is a visible willingness to think in decades rather than quarters.

Meanwhile, American companies frequently limit themselves with what is, in many ways, a self-imposed constraint: the belief that innovation must immediately translate into quarterly revenue growth.

A Made-Up Constraint

The quarterly cycle is not a law of physics. It’s a financial construct — one that has grown powerful enough to shape how entire industries behave.

And I’ve watched it hobble companies that were once bold.

As soon as a technology begins to succeed, it becomes less about building the future and more about protecting the number. Engineering decisions shift. Product strategy shifts. Risk appetite narrows. The organization becomes less willing to invest in ideas that might not pay off immediately.

Over decades, that pattern has had a real impact on how technology evolves, especially inside successful companies that should have the most freedom to take long bets.

What Gets Lost

What’s frustrating is that the innovative spirit never fully disappears. The engineers are still there. The ideas are still there. The ambition is still there.

But the structure around them changes.

Instead of asking, “How big could this become?” the question becomes, “How does this help us hit next quarter?”

And that’s where the real loss happens — not in talent or creativity, but in time horizon.

After nearly four decades in software, I don’t believe the challenge is a lack of innovation in the United States. We are still extraordinarily good at inventing the future.

The challenge is that we often stop ourselves from fully realizing it.

We build something transformative — and then we shrink our vision to fit inside a quarterly report.

I’ve been a professional software engineer for almost 30 years. Over that time I’ve served as a manager, engineering leader, VP of Engineering, and CTO across organizations ranging from small startups to companies the size of IBM. Watching engineering organizations grow from small teams into large, complex systems has given me a long view into how culture and incentives evolve — and sometimes break.

One of the most destructive tendencies I’ve seen develop over time is surprisingly subtle: engineers begin to believe that the only way to advance their careers is to work on the most visible, most successful products inside the company.

At first glance, that seems reasonable. Of course people want to work on the products that generate revenue, attract executive attention, and shape the company’s public identity. But inside a modern software organization, that instinct can quietly undermine the long-term health of the entire engineering system.

Visibility Bias Inside Engineering Organizations

Even in companies that technically have a single product — especially SaaS organizations — different parts of the system receive vastly different levels of visibility. The UI, the client experience, and customer-facing features are seen by marketing, sales, executives, and customers every day. Those parts of the system become the center of attention.

Engineers naturally gravitate toward that visibility. It feels like the place where careers are made.

But modern software systems are far larger than what users see. Reliability engineering, infrastructure, fraud mitigation, security, risk management, customer support tooling — these areas operate behind the scenes. They are less glamorous, less visible, and often harder to explain to non-technical stakeholders. Yet they are just as critical to a company’s success as the features that generate revenue.

When incentives drift toward visibility instead of system health, organizations slowly become unbalanced.

From Boxed Software to Web Systems: A Cultural Shift

Early in my career, I worked on packaged desktop software — the kind that shipped in boxes on store shelves. In those environments, nearly every engineer worked on the same deliverable. The entire team focused on what would go into the box.

As the industry shifted toward web-based systems, and later toward mobile and distributed architectures, that unity disappeared. Engineering work fragmented into layers: front-end, mobile, APIs, infrastructure, data systems, security, and operational tooling.

The engineers working on the visible layers received more attention from across the company. Sales teams, marketing teams, and executives could see the UI. They could interact with it directly. Naturally, conversations gravitated there.

Meanwhile, the backend systems grew larger, more complex, and more essential — but less visible.

That imbalance created a cultural gravity well.

The Executive Table and the Hidden Work

When I moved into leadership roles and eventually sat at executive tables, I saw this bias amplified. Entire executive teams would discuss what the product looked like, how it behaved for customers, and which features were driving growth. Those conversations were important — but someone had to worry about how the system actually ran.

More often than not, that responsibility fell to the engineering leader alone.

Over time, I found myself investing more attention in infrastructure, reliability, and backend architecture — not because it was more interesting, but because it was necessary. The health of the company depended on systems that most people in the room couldn’t see.

This is where many organizations struggle: how do you convince engineers to invest their careers in parts of the system that receive less external recognition?

Why the “Best Product” Mentality Is Dangerous

When engineers believe promotions come from working on the most visible product areas, several problems emerge:

– Critical infrastructure roles become harder to staff.
– Reliability and security work become reactive instead of proactive.
– Organizational knowledge becomes skewed toward features rather than systems.
– Long-term risk accumulates quietly beneath short-term success.

Modern architectures make this especially dangerous. Backend systems are no longer simple servers running behind a UI. They include distributed services, data pipelines, observability platforms, and compliance layers that grow more complex every year.

Ignoring these areas doesn’t make them less important — it makes them fragile.

Engineering Leadership as Incentive Design

The challenge for engineering leaders has always been incentive alignment.

You cannot promote engineers faster or compensate them more simply because they work on the UI or on the product areas that executives see most often. If the incentive structure favors visibility over impact, engineers will optimize for visibility every time.

Instead, organizations need to reward outcomes that reflect true system health:

– System uptime and reliability
– Backend performance and scalability
– Risk mitigation and fraud prevention
– Operational excellence and maintainability

These achievements are harder to measure and often less glamorous, but they are the foundation that allows visible products to succeed.

In my own leadership journey, I tried to make infrastructure and backend work a first-class path to growth. That meant recognizing engineers publicly for reliability improvements, tying performance reviews to system outcomes rather than feature count, and ensuring that compensation and promotion paths reflected the value of invisible work.

Aligning Culture With Reality

The deeper lesson is simple: culture follows incentives.

If engineering organizations reward visibility, engineers will chase visibility. If they reward stability, collaboration, and long-term system health, engineers will invest in those areas instead.

The goal is not to diminish UI or product innovation — those are essential to any company’s success. But a sustainable engineering culture recognizes that the parts of the system no one sees are often the ones that determine whether the company survives.

After three decades in engineering, one truth has become clear to me: the strongest organizations are not the ones where everyone wants to work on the most successful product.

They are the ones where engineers understand that success comes from building — and valuing — the entire system.

But the debt only looks impossible in isolation.

When you place it next to where American wealth actually resides, a very different picture appears. Not a simple solution—but a real one, with real tradeoffs.

The Scale of the Problem (and the Wealth)

As of late 2025, total U.S. federal debt stands at roughly $38 trillion. Of that amount, about $31 trillion is debt held by the public—Treasury securities owned by investors, institutions, and foreign governments. This is the portion economists usually focus on, because it represents external obligations.

Now compare that with Baby Boomer wealth.

Americans born between 1946 and 1964 collectively hold about $83 trillion in net wealth—more than half of all U.S. household wealth.

This comparison changes the framing. The United States is not “broke.” The money exists. It is simply concentrated and lightly taxed at the point of transfer.

Average vs. Median: Why This Matters

Wealth among Boomers is highly uneven:

• Average (mean) net worth: roughly $1.2–$1.7 million

• Median net worth: roughly $200,000–$400,000

This distinction matters because estate taxes apply only to the top of the distribution. Most Americans—and most Boomers—are nowhere near today’s exemption thresholds.

How the Estate Tax Works Today

• Top federal estate tax rate: 40%

• Estate tax exemption: ~$14–15 million per individual

• Share of estates that pay: fewer than 0.2%

Despite an unprecedented intergenerational wealth transfer already underway, the estate tax raises relatively little revenue.

A Simple Thought Experiment

To understand scale—not to propose a literal policy—consider a simplified model:

Assumptions (for illustration only):

• Total Boomer wealth: ~$83T

• Estate tax rate: 40%

• Wealth above an exemption is taxed once, over time

• Ignore avoidance, deductions, timing, and behavior

This is not how policy works. It is a measuring tool.

Could Boomer Wealth Retire the National Debt?

• Total gross debt (~$38T):
  Even taxing all Boomer wealth at 40% raises only ~$33T → not enough.

• Debt held by the public (~$31T):
  Mathematically achievable at a 40% rate with a very low exemption.

The math shows capacity. But math alone is not policy.

The Overlooked Question: Would This Be Deflationary?

Yes—by default, retiring all or most of the national debt would be deflationary.

This is where many “just pay it off” arguments quietly collapse.

Paying down federal debt removes financial assets from the private sector. Treasury securities are not just liabilities—they are core infrastructure of the financial system.

How Fast Matters More Than Whether

The economic risk depends almost entirely on speed.

What this chart shows:

• A slow payoff (~0.5T/year) creates manageable drag

• A moderate payoff (~1T/year) is meaningfully contractionary

• A fast payoff (~2T/year) risks recession and financial stress

Three Payoff Paths

1. Fast Payoff (High Risk)

Aggressive estate taxation and rapid debt retirement.

Likely outcome:
Strong deflationary pressure, tighter credit, recession risk.

2. Phased Payoff With Offsets

Gradual debt reduction over decades, paired with:

• Public investment

• Tax cuts elsewhere

• Monetary accommodation

Likely outcome:
Debt declines without choking demand.

3. Partial Payoff (Most Stable Option)

Reduce debt relative to GDP, not to zero, while preserving a deep Treasury market.

Likely outcome:
Lower long-term fiscal risk without destabilizing the system.

The Deeper Insight

The national debt is not like household debt.

From a macroeconomic perspective, it represents the net financial assets of the private sector. Eliminating it entirely would mean fewer safe assets, tighter credit, and less financial flexibility.

The goal should not be zero debt, but the right amount of debt, sensibly balanced against private inherited wealth.

Final Thought

Over the coming decades, Baby Boomers will pass on more than $80 trillion in wealth.

We will choose:

• To fund the future through inheritance, or

• To fund it through debt

Lowering the estate tax exemption would not magically solve everything. But it would force an honest reckoning with how wealth, risk, and responsibility are shared across generations.

The debt exists.
The wealth exists.
What remains is deciding which one we want to pass on.

Carina is a 20 something broke, exhausted professional living alone in a tiny one room mid-Manhattan apartment. Her apartment is so small and cramped that her parrot Bart has more room in his cage than Carina does.

For someone so young and seemingly successful, Carina has never figured out how to correctly use an alarm clock to get herself to her subway train by 9:00am. She’s tried every conceivable trick over the years but nothing has worked and now she is still in bed asleep at 8:55am.

The sun is shining through the partially opened curtains and a narrow beam of sunlight pokes through into the room. The sunlight falls on Carina’s face, she yawns, stretch herself gently while the memory of a pleasant dream rolls around her head until her eyes snap open suddenly.

She casts her eyes around the apartment, she can’t even be sure where she put her alarm clock but she is certain that she is late again. Carina screws her eyes shut for a moment, she wants so much to go back to sleep and pretend this isn’t happening again.

She has been late so many times she is sure this time she will lose her job. She jumps out of bed, dashing across the room to her closet to get dressed but trips and falls over the only appliance in her place, a little refrigerator.

“You could have just asked me to wake you up Carina”, says Bart. Bart has never spoken before. Carina is so stunned she lays on the floor for a few moments before opening the fridge and giving Bart the only thing she finds in there: an old carrot.

It’s a rather lovely morning in the city Carina thinks when she reaches the street via the back stairwell. She has a second to check her looks in the reflection of the subway car window before she jumps aboard.

I recently revisited Isaac Asimov’s short story The Last Question. Without spoiling too much, it explores the fate of the universe and humanity’s place in it. The story traces the arc of human civilization: from living alongside artificial intelligence, to merging with it, to eventually spreading among the stars and populating entire galaxies.

Running through the narrative is a powerful theme: human survival. Asimov asks whether, given humanity’s relentless expansion, there will always be enough resources to sustain us — no matter what form we take.

At one point, Asimov describes a future where humans have achieved a kind of immortality. Consciousness is separated from the body, the body is perfectly preserved, and death is no longer possible. This liberation of consciousness allows humanity to exist and act indefinitely.

That idea made me think of Liu Cixin’s The Dark Forest, the second book in his Three-Body Problem trilogy. Its “dark forest theory” offers one of the most chilling answers to the Fermi Paradox — the question of why, in such a vast and ancient universe, we have never encountered alien life.

The dark forest theory suggests that the universe is teeming with intelligent civilizations, but that every civilization is both a potential threat and a potential target. Because resources are finite, any species that expands unchecked could one day endanger others. As a result, the safest strategy for any intelligent lifeform is to eliminate other civilizations as soon as they detect them.

The metaphor is that the universe is a dark forest. Every civilization is a hunter, moving silently through the woods. The moment one becomes aware of another, its survival instincts demand that it attack before it is attacked.

But Asimov’s vision raises an interesting challenge to this grim worldview. If a civilization achieves immortality — true immortality — does it still need to reproduce and expand? Reproduction is, in a way, a biological strategy for achieving immortality by passing on DNA. But if individuals never die, reproduction becomes unnecessary.

A species that no longer needs to reproduce would also no longer expand at the same rate, and its resource needs could eventually stabilize. In that scenario, such a civilization might no longer feel compelled to destroy potential competitors.

Of course, there’s another possibility: immortal civilizations might still feel threatened by species that are reproducing and expanding, and thus act as the “hunters” in the dark forest — wiping out younger species before they grow too large.

This interplay between immortality, reproduction, and survival opens up fascinating philosophical questions. Is endless expansion inevitable? Or could the path to universal peace lie in transcending the need to reproduce at all?

I highly recommend reading both Asimov’s The Last Question and Liu Cixin’s The Dark Forest. Together, they offer two very different but deeply thought-provoking visions of humanity’s future — and the universe we inhabit.1