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

Subscribe now

Something interesting happened to me recently during a staff meeting. It was a strategic discussion among senior engineering leaders, including my boss and several colleagues. We were talking about a new product development initiative—an area where the company had previously invested effort, but ultimately canceled the earlier project. I was part of that original effort, so I have some history with both the domain and the engineering team that worked on it.1

Given my background, I offered my thoughts on how we might want to approach the internal conversations surrounding this new initiative. I emphasized the importance of involving and aligning with the broader organization as we move forward.

Then a newer colleague responded. His reaction made it clear that he didn’t agree with my take. In fact, he offered an alternative approach with a tone that came across as a bit dismissive and somewhat self-important. You know the kind: someone hears your perspective and immediately offers what sounds like a more “enlightened” way to handle the situation—something higher-minded, more strategic, more polished.

In the past, I would’ve felt the need to respond. To correct him. To clarify that I had considered that approach, or to explain why it might not be as straightforward as he seemed to think. I would have wanted to make sure I didn’t look like I missed something—or worse, let him have the last word.

But this time, I didn’t.

Instead, I sat with it. I let it pass.

Partly because I’m learning that in more political environments, timing and discretion matter. But mostly because I realized something deeper: I don’t need to correct every misunderstanding. I don’t need to defend every nuance of my thinking. And I certainly don’t need to prove that I’m the smartest person in the room.

If my colleague chooses to jump to conclusions about my perspective—if he assumes that my brief comment was the extent of my insight—that’s on him. If he decides not to engage further with someone who has experience and context he doesn’t yet have, that’s his mistake to make.

And I don’t need to stop him from making it.

Instead, I can take note. I can proceed accordingly. I can save my energy for when it matters most—and trust that the value I bring speaks for itself over time.

There’s power in restraint. In letting someone else have the last word—not because you lost the argument, but because you’ve already won something more important: perspective.

I've been writing code now for more than 40 years and been a professional engineer for more than 30 years, most of that time in startup companies. I’ve been an individual contributor, manager, Vice President, CTO, every technical position you can hold within a startup company, I've done it. I've managed hundreds of engineers, across hundreds of releases and I have worked with my teams against many, many deadlines.

At this late stage in my career, I am managing a team of engineers again, at a startup company, working with younger engineers on many releases. One thing I hear over and over again, and when I think about it I've been hearing it for some time, for decades, from these engineers is this idea of a made up date. To many engineers it seems that releases often get defined before engineers get involved, and that deliverables, milestones, deadlines are dictated in a top down fashion. Therefore, they seem made up, not based in reality by anyone within the engineering organization.

If you zoom out on startup companies, you've got this idea of an entrepreneur, the somewhat mythological figure that starts businesses. What that person is trying to do, a highly simplified version of what a startup company is, is they’ve identified a need in a market. They believe that need can be met with a product that has value to certain people, therefore those people will pay for that value, or you can find a way to monetize the value. So they have a way to make money but of course they need that product.

Most of the time, especially in modern software startup companies, you need money to realize that vision, you need money to execute on your plan starting usually with developing the product. So the entrepreneur has to go out and convince other people of their vision for the business in order to get the money they need. Those people you convince will become your investors.

One of the key things that needs to be added to your vision of the product and the value is going to be timing. Investors will start asking you, when is this going to happen? When are you going to deliver this product? When are you going to start realizing this value you are describing? As an entrepreneur, one of the first things that you will have to do is to come up with a date. This is an essential part not only of bringing your product to market but of explaining to investors when they will start to see returns from the company. You have to look out into the future and think about what your capabilities are, what you're trying to do and you have to come up with a date.

As I was saying earlier, you have to make up a date.

As an entrepreneur you have to pick a date practically out of thin air and say, yes, this is the date on which all this is going to happen. Then you have to set about making that a reality within your company. You begin a planning process from the top down and usually this goes through the product management organization and turns into milestones and deliverables that ultimately land in front of your engineers. That's when engineering says, whoa, whoa, these dates are totally made up.

In a later post, I will talk about what can be done about this but for now let me point out how important it is what has just happened. As the saying goes this is not a bug it’s a feature. The entrepreneur, the person who believes that they can solve a problem in the market, this person has decided when this needs to happen. This one thing, maybe more than anything else, is the fundamental thing about being an entrepreneur. You have to be willing to say when this will happen.

Think about that. You may have just started your company, you may not have written a single line of code yet and yet you have to decide on the future of the company. Not just any future: a definitive point in time when something is going to happen which has never happened before. If you are not capable of doing that, then you're not an entrepreneur. You are not somebody who should be starting a company. If you want to go to work for a start up company and therefore be entrepreneurial yourself you have to accept that this is a vital part of your decision.

I recently joined a new engineering team and was given my first coding assignment. I was told that time was of the essence in this case and so did a rather hasty implementation in Ruby and opened a PR fully expecting to get some interesting suggestions and even some of the dreaded “change requests”

I got some legitimate questions and concerns about the code, in particular related to getting the tests to run in our CI system.

There were two types of comments that I took issue with.

The first was “not idiomatic” which I have heard before, especially from Ruby engineers. All modern languages have their cool language features and their eccentricities and learning those things is part of the fun. Knowing a particular language well - be it Javascript, Ruby, Go, Rust, Haskell, whatever - is a real accomplishment and people should be proud of doing so. But they should not use that pride and knowledge to belittle people who write code “with an accent”.

In my case, I have written production code in perhaps 20 different languages over my 30+ years in this business and still actively code in 3 or 4 at any given time. When I haven’t used a particular language heavily in a few months it takes me a while to get caught up and fluent again. I have learned a lot in the past from PR comments and suggestions and I have no problem incorporating these into my code going forward.

The refrain I often hear from the “idiomatic” perspective is “your code is too hard for me to read”. I find this a weak argument with elitist implications. In this development team, as is almost always the case in the year 2022, we have a few engineers who speak English with an accent. On our Standup calls with these engineers, we don’t interrupt them and say “I can’t understand you because of your accent, can you please speak more like a native”. If we don’t understand someone, we politely ask them to perhaps try another explanation or maybe write out their ideas. We take it upon ourselves to help understand them, we don’t put that burden completely on them.

I once worked with a very talented and sharp Ruby engineer, someone I admire and learned a great deal from. This engineer spoke Spanish and English fluently but had a significant speech impediment. Not once when I worked with him did I stop him and say “can you please not stutter when you speak, I can’t understand you”. Instead I waited patiently for him to work through his stutter and I appreciated the enormous effort that he made to communicate.

The other comment I received which bears some examination is “no reason”. As in “there is no reason to do it this way”. This is a breathtakingly arrogant thing to say to another person regardless of the context. When I hear someone say this I mentally convert their statement into “I can’t think of a reason” or perhaps “I am too lazy/dumb/narrow-minded to think of a reason”. Younger people who may be reading this, take some advice from a middle aged professional who used to be as narrow-minded and arrogant as anyone: there is always a reason why people do what they do. Just because you don’t understand their reason, or disagree with it does not mean they didn’t have one.

A younger, less experienced version of me would have been insulted by these types of comments. Lucky for me, I am not that engineer anymore. I am well-seasoned: salty and spicy.