Skip to content

Series

The Engineering Tax

A book in progress about what complexity really costs a growing software company, with published articles exploring the ideas as the book takes shape.

6 of 29 published

Every growing software company pays costs that are there all along but go unrecognized and therefore unmeasured. They show up inside engineering estimates, inside the standups that exist only to keep two systems agreeing with each other, inside the coordination friction that grows with every feature shipped. Nobody sends an invoice for them, so nobody fights to lower them. It’s like an object right in front of you that you miss until you start thinking about it; once you do, you see it everywhere. The Engineering Tax is the book I’m writing about that whole family of costs, and what they’re doing to the margin that was supposed to fund growth.

The articles in this series are published as I develop the ideas behind the book. Each one takes a single idea and develops it fully. They stand on their own, but they build on the same framework. Read them in order, or start with whatever matches the decision in front of you. The outline below lists all twenty-nine articles; published articles are linked, the rest are on the way.

The book will draw on these published articles, organized as a reference you can return to. If the articles earn your time, the book will be worth your money.

Table of contents

  1. Article 1

    The Sync Tax

    Capital before demand doesn't fund a business, it subsidizes the illusion of one. This piece traces how premature funding detaches companies from their market, how the unrecognized cost of keeping systems in sync multiplies with every feature shipped, and why the moment after product-market fit demands subtraction rather than addition.

  2. Article 2

    The Architecture Of Independence

    A modular interface isn't a technical artifact. It's the treaty that lets two teams operate as separate companies, shipping in parallel. The Rule of the Bolt keeps them intact with immutable identifiers, and shows why engineering shortcuts become a permanent tax.

  3. Article 3

    You Don't Automate the Levers of the Past

    Automating a broken process does not fix it. It just makes the broken process faster, and most of the bills labeled "automation" in the last decade were really subsidies paid to preserve the inefficiency underneath. The next article argues that efficiency has to come first, not as a slogan, but as a precondition, because the candlemaker lost his job the day electric light arrived, not the day someone optimized his wick. We pull the Paradox of Automation apart to show why the more efficient the system gets, the more valuable the human inside it becomes, and the more expensive it becomes to keep scaling with sync tax still lodged in the codebase. If you have ever seen a team "automate" their way into a bigger mess, this is the argument you wish they had read first.

  4. Article 4

    The Hardest Part of Scaling a Software Company Isn't Technical

    The cheapest way to destroy a software company is to let Business, Product, and Tech speak different languages until nobody can tell a real constraint from a political maneuver. The next article replaces that ambiguity with a hard protocol, one that forces every department to translate its needs into location and cost, the only terms a CEO can act on. It explains why story points survive despite generating distrust every time they appear on a roadmap. And it introduces the dignity threshold, the boundary that separates an expert advisor from a yes-man paid to nod at bad decisions.

  5. Article 5

    When the Game Changes After Product-Market Fit

    We talked about sync tax, architectural embezzlement, and organizational protocol so far. Useful vocabulary for pointing at the mess. But there's a limit to what vocabulary can do in a board meeting. What changes in the next article is the instrument itself. The Total Cost of Complexity is the first formula introduced in The Engineering Tax, turning unmeasured dependencies, coordination meetings, and tangled maintenance into a single dollar figure. Only with that dollar figure does a strangler extraction become the only exit the math allows.

  6. Article 6

    Treat Every Module Like an Outside Company

    The next article treats every module like an outside company, not a department you can rifle through when a deadline is tight. It lays out the Autonomous Cooperation Protocol: self-contained requests, hard ownership at the interface, and the economic case for refusing the "just in case" field that looks free today and bills forever. It also names the speed trap that starts in the C-suite and ends with engineers taking shortcuts, then shows why throwing more headcount at a tangled system is the mark of a manager who misread the bottleneck. If you've ever watched a clean boundary die so one ticket could ship this sprint, this is the discipline that would have stopped it.

  7. Article 7

    Up next

    Decisions That Look Good Today and Hurt the Company Tomorrow

    A feature greenlit to close a deal can look like revenue today and still compress the margin long after the ink is dry. The next article closes that strategy-to-engineering gap without turning the CEO into an engineer. It covers the culture that lets experts speak without fear, the repayment contract on every quick-and-dirty path, and the estimation gap that exposes yes-men when culture alone won't. When the CEO is the single point of failure for whether truth reaches the decision, tomorrow's options hang on those conditions.

  8. Article 8

    Recruitment Is a Strategy Decision, Not an HR Task

    Coming soon

  9. Article 9

    The Setup That Turns a 20-Hour Feature Into an 80-Hour One

    Coming soon

  10. Article 10

    Your Sprint Report Tells the Truth but Hides Everything That Matters

    Coming soon

  11. Article 11

    The Cost of Not Understanding the Technology You're Building On

    Coming soon

  12. Article 12

    The Way Teams Talk Shapes the Software They Build

    Coming soon

  13. Article 13

    When Your Software Choices Stop Making Economic Sense

    Coming soon

  14. Article 14

    There Are No Natural Boundaries Waiting Inside Your Monolith

    Coming soon

  15. Article 15

    Every Piece of the Product Needs a Single Human Owner

    Coming soon

  16. Article 16

    The Pursuit of Flexible Interfaces Is Modularity's Silent Killer

    Coming soon

  17. Article 17

    Automating a Broken Process Gives You a Faster Broken Process

    Coming soon

  18. Article 18

    Every Change to Your System Breaks Something That Was Working

    Coming soon

  19. Article 19

    What Started as an Extraction Plan Became a Permanent Trap

    Coming soon

  20. Article 20

    Coupling Isn't a Binary Switch, and Every Level Has a Price

    Coming soon

  21. Article 21

    You Can't Steer When You Only See the Destination

    Coming soon

  22. Article 22

    The Architecture That Found Product-Market Fit Becomes Why You Can't Scale

    Coming soon

  23. Article 23

    The Cost of the Shortcut Compounds Non-Linearly, and Nobody Sees It

    Coming soon

  24. Article 24

    Nobody Gets Promoted for Preventing the Failure That Never Happened

    Coming soon

  25. Article 25

    The Middle Manager Is the Early Warning System Nobody Listens To

    Coming soon

  26. Article 26

    He Was Indispensable Until the Company Killed the Duplicate Work

    Coming soon

  27. Article 27

    Software Has Three Dimensions of Interface Design, and Teams Use One

    Coming soon

  28. Article 28

    The Build Is a Down Payment on a Liability Nobody Budgets For

    Coming soon

  29. Article 29

    The AI Boom Is a Broken Signal Distorting the Software Market

    Coming soon

Follow the series

Subscribe to get an email when a new article in this series is published. These articles explore the ideas behindThe Engineering Tax, the book I'm writing.