DEV Community: David Vartanian

When the Game Changes After Product-Market Fit

David Vartanian — Wed, 29 Jul 2026 12:41:02 +0000

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.

Transitioning from Integrated Performance to Modular Scale

Every product company eventually passes through a moment Professor Christensen calls the Decouple Point, a term I learned in his Disruptive Strategy course at Harvard Business School. In his framework, it marks the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture, a transition he develops in The Innovator's Solution. I extend it here to mean the moment when architecture, strategy, and demand all signal the same transition at once. Before it, the company is in learning mode, moving fast, breaking things, finding out what the customer actually wants. After product-market fit, the job changes. The current product got the company to a successful state, but it's tangled, costly, and slow to change if the exact same product works at scale. Remaking it for the next phase is mostly a job of removing what's in the way, not adding more on top.

This article is about that second job: making the same product work for many more people at a much lower cost per customer, without giving up the speed to keep improving it.

A quick clarification before we start. When we say "performance" in this article, we mean business performance: whether the product satisfies the Job to be Done, whether customers are happy with the outcome. Alright, with that out of the way, let's go.

1. Two Phases: Performance, Then Efficiency

Following Professor Christensen's framework in The Innovator's Solution, a product's evolution splits into two distinct phases:

Integrated Performance: Before the product is "good enough" in the eyes of the customer, the company stays tightly integrated. Every team, every decision, every line of code serves a single goal: reaching the business performance required to satisfy the Job to be Done. Interdependence is a feature at this stage, because it lets the company iterate fast until the product clicks with the market.
The Efficiency Threshold: Once business performance is "good enough," the basis of competition shifts. Customers stop paying for raw performance and start demanding flexibility, speed, and convenience. This is the typical sustained market tier, where modular products already compete on efficiency and on how fast they ship. To survive the shift, the company must move to efficiency, offering the same product to exponentially more people without exponentially increasing costs.

2. Phone vs. Battery: A Diagnostic for CEOs

To distinguish between dangerous technical debt and healthy modularity, we use the phone hardware comparison. Everyone has a phone, and every phone needs a charger. Both the charger and the battery are moving parts. What separates them is the quality of their interface.

The Module (The Charger): A moving part with a clean, well-defined, and standardized interface (eg: USB). It is swappable, carries zero risk to the main device, and requires no specialized tools to manipulate. You plug it in, it works. You replace it with another one, it still works. This is the goal.
The Tangled Component (The Battery): A moving part with an internal, ad-hoc, and undocumented interface. Manipulating it requires specialized tools and deep knowledge, and any change carries the risk of breaking something else. One mistake can brick the entire device. This is the reality of a tangled system.

A moving part is just a point of failure, and every moving part is a point where the cost of change goes up and the risk of breakage goes up with it. The fewer moving parts, the better. The trick is making the moving parts you maintain look like chargers, not batteries.

3. Putting a Number on the Interdependence Bill

It is the sum of the cost of updating dependent modules, the cost of human coordination, and the cost of maintenance and infrastructure overhead that a lean, modular system would not require. Then the total is multiplied by the risk of something else breaking every time a change is made.

The rest of this section walks through the formula piece by piece, in the order that makes most sense.

Baseline: what the work would cost in a clean system

Before measuring how bad the cost is today, the formula needs a baseline: how much would this change cost if the system were perfectly modular, with no unrecognized dependencies and no coordination overhead? We call that baseline the Vacuum Effort, written as $E_{v}$ .

Imagine a developer needs to add a new field to a customer profile module. In a perfectly modular system, it touches one file, one test, one deployment. That is $E_{v}$ : the time the change should take measured in hours. You'll see below that the final formula measures how far reality has drifted from the vacuum effort.

$E_{v}$ is multiplied by $R$ , the blended hourly rate (developer, QA, ops, all in), to convert time into a currency value. Therefore, the dollar version (or your preferred currency) of the vacuum effort is $E_{v} \cdot R$ .

First drag: the cost of unrecognized dependencies

In a tangled system, changing one module breaks others, because the modules are connascent: they share dependencies that haven't been recognized and considered so far. When module A changes, modules B, C, and D also have to change, even if no one planned it that way. The number of other modules that must be touched because of a single change is the Connascence Degree, which we'll define as $C_{d}$ .

Meilir Page-Jones introduced connascence, formalizing the concept in the 1990s, and Ford, Parsons, and Kua built on it in Building Evolutionary Architectures. The takeaway is that $C_{d}$ counts how many unrelated modules get dragged into a single change.

But not every connascent module adds the same amount of work. Some are tightly coupled and require extensive rework; others need only a small adjustment. The Interdependence Factor, defined as $k$ in this article, captures the average share of extra effort that each extra module adds. A reasonable starting point is $k = 0.5$ : each connascent module adds half of the vacuum effort in extra work. Calibrate $k$ from past tasks by dividing the total extra module effort by $C_{d} \cdot E_{v}$ .

Now the dollar cost of hidden dependencies, the Connascence Degree Cost $C D C$ , becomes:

C D C = C_{d} \cdot k \cdot E_{v} \cdot R

Read it left to right: count the connascent modules ( $C_{d}$ ), multiply by the average extra effort per module ( $k \cdot E_{v}$ ), and convert to your monetary currency ( $R$ ).

Second drag: the cost of human coordination

Unrecognized technical dependencies aren't the only drag. Tangled systems also force people to coordinate. Adding that new customer field might require a meeting with the billing team, a Slack thread with the search team, and a code review with someone who built the original schema years ago. All of that cost might show up in the calendar, but not in any engineering budget.

The Coordination Overhead, defined as $C_{coord}$ , is the total number of hours the team spends in meetings, threads, calls, and reviews that exist only because the system is tangled. In a modular system, those hours wouldn't exist because teams managing different modules wouldn't need to talk at all. It's hard to calculate the amount of hours spent in coordination per engineer. However, at least an approximation of the dollar cost, the Coordination-Overhead Cost $COC$ , can be represented as:

COC = C_{coord} \cdot R

Third drag: maintenance and infrastructure cost

A tangled system forces the company to do maintenance work and run infrastructure that a clean system wouldn't need. This work exists only because the system is tangled, not because the customer is asking for new things.

What it looks like in practice

Picture a customer updating the email address on his account. In a clean system, the change touches one record in one place, and the change is done. In a tangled system, the customer's email lives in three different systems, because at some point each part of the product stored its own copy. Updating the email means updating all three. If one update fails, the customer gets a login error the next time he tries to sign in. The support team gets a ticket. The engineering team has to figure out which of the three systems failed and reconcile them by hand.

That is a small example. Multiply it by every change the company makes, every month, for as long as the system stays tangled. The work piles up.

Maintenance: engineering hours consumed by the tangle

The maintenance part, written as $M$ , is the engineering time the company pays for work that exists only because the system is tangled. It doesn't include building new features the customer demands. It is the work of:

Patching a piece of the product because another piece changed.
Migrating data from one place to another because the same record is now stored in two systems.
Writing small pieces of code that exist only to translate between two systems that shouldn't need to talk.
Reconciling records that drifted apart because two systems were supposed to stay in sync but didn't.

Track $M$ by asking the engineering lead one question: of the engineering hours last quarter, how many went into work that exists only because the system is tangled, not into building new things? The answer, in hours, is $M_{hours}$ .

Infrastructure: operations and cloud cost the tangle demands

The infrastructure part, defined as $I_{c}$ , is the operations and cloud cost the company pays to keep the tangled system running. In a clean system, you run one copy of each piece of data on one set of servers. In a tangled system, you run:

Duplicate copies of the same data in different systems.
Servers running the same logic in multiple places to keep things in sync.
Monitoring dashboards and alerts that exist only to watch for drift between tangled parts.
Backup and recovery procedures that exist only because the data is split across systems that could fail independently.

Track $I_{c}$ by asking the operations lead: of the cloud bill and the ops workload last quarter, how much exists only because the system is tangled? Convert that to engineering hours equivalent (a rough rule: a fully loaded engineer's month of work is about 160 hours, so divide the dollar cost of that work by $R$ to get hours). The answer, in hours, is $I_{c, hours}$ .

The dollar formula

Add the two components together and convert to dollars with the blended hourly rate $R$ :

E C = (M_{hours} + I_{c, hours}) \cdot R

The result, in dollars, is what we call the Excess Complexity Cost (ECC): the money the company is paying each quarter (or the period corresponding to the entered amount of hours) to keep the tangled system functional, on top of what the clean system would cost.

Why it grows over time

Here is the part that makes the third drag harder to ignore than the other two. Unrecognized interdependencies, expressed as the Connascence Degree Cost (CDC), and coordination overhead, expressed as the Coordination-Overhead Cost (COC), scale with the size of the change. Maintenance and infrastructure cost scale with the age of the system. Every quarter the tangled system stays tangled, another layer of patches, migrations, sync jobs, and monitoring gets added. None of it goes away. A clean system doesn't accumulate this overhead. A tangled system does, and the accumulation shows up in the operations budget long before it shows up in a feature delay.

Assembling the cost of complexity

The three drags together form what we call the cost of complexity, before any risk adjustment:

C = C D C + COC + E C

This is an approximation of what the company pays today, in dollars, just to keep a tangled system running before anything breaks. A high cost of complexity is the mathematical proof that the system is expensive to live with.

Risk multiplier: when changes break unrelated things

The cost of complexity isn't the full picture yet, because every change in a tangled system carries a risk of breaking something else. The cost of complexity is what the company pays when nothing goes wrong. The risk multiplier is what gets added on top when something does go wrong.

The Regression Rate, defined as $R_{t}$ , is the frequency with which a single change breaks an unrelated part of the system. Measure it from historical data: count the regressions in the last quarter, divide by the number of changes shipped. A modular system has $R_{t}$ near zero; a tangled system has $R_{t}$ climbing as the system ages.

The Incident Cost, defined as $C_{f}$ , is the total cost of a single regression: engineering time to fix it, plus the business impact (downtime, lost transactions, customer churn during the incident).

The Failure Risk Multiplier $R_{m}$ captures the expected additional cost from the risk of breakage:

R_{m} = 1 + \frac{R _{t} \cdot C _{f}}{C _{base}}

The "+1" at the front keeps $R_{m}$ from collapsing to zero when risk is low. When $R_{t}$ is zero (a modular system where changes never break unrelated things), $R_{m} = 1$ and the multiplier is a no-op. When $R_{t}$ is high, $R_{m}$ inflates the cost of complexity proportionally to the expected damage. Article 18 on the Failure Risk Multiplier will develop the full derivation, including how to handle correlated risks across many changes.

In a tangled system, $R_{m}$ applies to the totality of the cost of complexity, because a regression in one part of the system can break anything else. In a modular system, the risk stays isolated to the module being changed, which is exactly why the multiplier is gentler in modular systems.

Full TCC

Finally, now we can estimate a total dollar amount:

T C = C \cdot R_{m}

The total complexity cost (TCC) is the all-in dollar cost of running a tangled system today, including the expected cost of the next breakage. A high TCC is the mathematical proof that the tangled system is more expensive to operate than a clean one, and the gap widens with every change.
Hopefully, this will help to understand why an interdependent system cannot be scaled as it is.

4. Cutting the Old System Out, Piece by Piece

To escape the interdependent software system without doubling investment or losing current customers, the tech department runs a strangler extraction. This is a gradual replacement process where a new, clean module grows around the old system until the old system can be removed.

Form the Team: Create a "Module Team" from existing employees (no new hiring). The team and its leadership need to adopt an entrepreneurial mindset, because they are building a small product, not patching or simply replacing a monolith.
Define the USB Socket: Identify a module interface compatible with the legacy interdependent system. The interface is the contract the rest of the system will rely on.
Standalone Build: Implement the module as a standalone sub-product with no inter-dependencies. It must be sovereign, ruling itself and remaining independent from the rest of the system, receiving all the data it needs in the request and returning the expected value.
Routing Interface: Implement a proxy in the interdependent system to route requests to the new module.
Cut: Remove the old interdependent code, making the old interdependent system smaller until it can be killed completely.

A critical rule: cut domains, not functions. If the slices are too small, the new pieces end up talking to each other constantly, which is a "chatty interdependence," and the result is worse than the original monolith. The right cut is vertical: a piece of the business that can stand on its own, not a horizontal layer shared by every other piece.

5. How Independent Is the Module?

A module is a self-contained piece of software that delivers one specific value to the main product, the kind of thing an outside customer or an internal team can "demand" because of the value it produces. For example, in a shipping module, the unit of value is a printed label or a calculated delivery date. Its health is measured by its Independence Score:

I_{s} = \frac{V _{e}}{V _{t}}

Where:

$V_{e}$ (External Value): Requests handled entirely by the module's internal logic.
$V_{t}$ (Total Interactions): The total number of times the module must reach into any external system (including the legacy system, third-party APIs, or other modules) to fulfill its job.

The goal is to push $V_{e}$ as close to 1 as possible. A score of 1 means the module runs completely on its own. Anything below 1 means the module is at least partially a remote-controlled part of something else. Autonomy matters because a module that depends on the rest of the system can never outgrow the cost structure of the rest of the system.

6. Building a Team That Wants Change

The transition requires a shift in human alignment. Alignment is more valuable than motivation, because things will keep changing. The old monolith or any other legacy piece is just the first wave; every module will keep evolving after that. So the right principle to run on is: there are no "maintainers" in a modular organization. Every contributor is an innovator, and three operational rules follow.

Ownership Protocol: A module owner must claim every unowned piece of code found in the interdependent system. The team and the team lead become accountable for that code's future.
Hiring for Change: HR must be involved in recruiting people who are energized by change, not people who prefer to live in the past. People who want to maintain a legacy system until it dies aren't the right fit. Every part moved to modules has an innovator owner.

The experts use shared contract templates to capture the requirements, and the team uses OpenAPI as an automated contract verifier. It checks that the technical interface implemented by the team matches the organizational interface (the teams, the departments, the responsibilities) defined in the contract docs. The CEO's job is to make sure only qualified people sit at the table, because a bad contract is worse than no contract.

7. A Trend Line Worth Watching

The CEO watches Revenue per Engineering Hour as a trend line, not as a single number. The metric will fluctuate quarter to quarter, and fluctuation doesn't mean the company is dying. The point of tracking it is to spot the moment when the trend bends down as the company scales, which is the mathematical proof that the sync tax is outgrowing the business. There is no arbitrary red-alert threshold, only the direction the line is moving.

Conclusion

This was a long and dense article, most likely hard to digest. The math is there so the cost of a messy product stops living only in engineering folklore and shows up in the same units the business already uses for everything else. A customer pays for the value he believes the product delivers on the Job to be Done, not for unrecognized dependencies, coordination overhead, excess maintenance, or the chance the next change breaks something unrelated.

When the product gets bloated and tangled, that internal cost structure drifts away from the value the market still assigns to the outcome. The two stop lining up: the company spends more to deliver the same job, while willingness to pay stays anchored to the performance the customer can feel.

Scaling that product is a bad idea because volume multiplies the misalignment. More customers means more load on the same interdependence, more total complexity cost per unit of delivered value, and a revenue per engineering hour trend that bends down as the company grows the cost of change faster than the value customers will fund.

References

Christensen, C. M. & Raynor, M. E. (2003). The Innovator's Solution: Creating and Sustaining Successful Growth. Harvard Business School Press. Ch. 8: Managing the Strategy Development Process
Christensen, C. M. Disruptive Strategy. Harvard Business School Online course. The term "Decouple Point" as used in this article was learned in this course, where it marks the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture. The extension to strategy and demand timing is the author's own.
Christensen, C. M., Musso, C. S., & Anthony, S. D. (2004). Maximizing the Returns from Research. Research-Technology Management, 47(4), 12--18. DOI: 10.1080/08956308.2004.11671636. The origin of the "Decouple Point" concept: the position in the value chain at which an innovator can deliver a modular product or service.
Page-Jones, M. (1992). Comparing Techniques by Means of Encapsulation and Connascence. Communications of the ACM, 35(9). Expanded in What Every Programmer Should Know About Object-Oriented Design (1995, Dorset House Publishing). Connascence overview.
Ford, N., Parsons, R., & Kua, P. (2017, 2nd ed. 2022). Building Evolutionary Architectures: Automated Software Governance. O'Reilly Media. Ch. 5: Evolutionary Architecture Topologies.
Fowler, M. (2004). Strangler Fig Application. martinfowler.com. The original description of the incremental legacy system replacement pattern.

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

David Vartanian — Tue, 28 Jul 2026 10:10:21 +0000

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.

Interface of Trust and the Language of Reality

Human teams don't speak the way software does. Software has clean interfaces, contracts, and well-defined inputs and outputs. People have ego, incentives, career anxiety, and a habit of mistaking jargon for competence. The hardest part of building a scalable software company is not technical. It is making Business, Product, and Tech understand each other well enough to make decisions that don't destroy the business.

The protocol below is the language and the accountability structure that makes that possible.

1. Inter-Departmental Interface

Human organizational interfaces must connect three distinct areas of expertise: Business, Product, and Tech. The work is harder than fixing a code module because humans follow incentives, status games, and the fear of looking stupid in front of the CEO.

The goal is not to ask technical teams to "explain complexity" to a CEO. Complexity, parsed as a technical term, becomes a technical excuse, and the CEO is right to tune it out. What works is forcing the expert to communicate two things: location and cost. Where is the complexity? What does it cost in cash, time, margin, risk, competitiveness, or growth?

The expert's job is to run simulations of implementation choices and present them to leadership in the language the business actually speaks.

"Cheap" Sync Simulation: Shows short-term speed but reveals how much cash the project will burn through increased maintenance and the inflated cost of all future features.
Modular Path Simulation: Projects the total system state after implementation, demonstrating a sustainable maintenance bill and lower costs for subsequent innovations.

If the expert cannot show those two numbers, the expert does not yet have the right to recommend a path. The C-suite pays for outcomes, not for a feeling.

2. Killing the False Currencies

Story Points Are for Losers

To understand why story points are still around, you have to look at how the engineering labor market broke. Engineers became scarce and expensive, so management started treating them like fragile assets. Wrap the job in cotton, strip out every friction, remove any accountability that might bruise someone's feelings. Story points were born from that instinct: a way to measure output without ever confronting the engineer with a hard deadline, a real number, or a cost the business had to swallow.

We are all adults. Jobs come with parts we don't enjoy, and as adult professionals we should stop designing roles that pretend otherwise.

That is also exactly why story points are destructive. This removes accountability from whoever needs to get the job done. Deadlines vanish. Engineers become disconnected from the rest of the company, where every other role is measured in shipped outcomes, signed contracts, paid invoices, or closed revenue. The engineer used to be one of the most respected roles in any industry, on par with lawyers, doctors, and architects. Now software engineering has been rebranded as the job of a fragile loser that managers need to handle like a disabled toddler. Story points are a load-bearing piece of that rebrand.

Strip the politeness away and the technical case is the same as the cultural one. Story Points are a non-convertible currency with no standard exchange rate, subjective to specific teams and dependent on individual seniority, project knowledge, and personal history. Every team interprets a "5" as something different, which is why they generate more distrust on the business side, not less. If a metric cannot be converted into a unit the CEO is accountable for, it is noise. Story points are noise.

Communication must move from subjective "points" to objective business metrics. Tech and Product must present data that reflects time, budget, margin, risk, and growth, the variables the CEO is actually responsible for.

3. The Expert's Fiduciary Duty and the Dignity Clause

Hiring the Expert, Not the Yes-Man

The relationship between the CEO and the expert (CTO/CPO) is governed by the following Steve Jobs principle: "We don't hire professionals to tell them what to do, we hire them to tell us what to do".

This protocol requires:

The Hiring Agreement: It must be established on Day 1 that the expert is expected to disagree with the CEO if an initiative is a bad idea based on their experience. The CEO is still the leader, but in specific areas, experts give the advice and propose the next course of action.
Speaking the Dialect of Growth: The expert must adapt their message to the CEO's current optimization goal, usually gross margin or growth. They need to explain in that language why the idea is not good right now.
Lose the Fear of Getting Fired: The worst corporate mistakes trace back to a smart person who saw the problem and stayed quiet to keep the paycheck. Once an expert has put the data on the table, there is nothing left to fear. It is uncomfortable, yes, but it is not the end of the world. In fact, it is the start of a new career stage better than the previous one, because the work stays clean and the reputation stays intact.
Dignity Threshold: An expert who nods and executes a "cheap" solution they know to be destructive is making a shitty choice that becomes part of their own shitty career. If a CEO persists in ignoring data-backed arguments in favor of ego-driven decisions, the professional protocol is to withdraw one's talent immediately. Professionals with integrity and dignity protect the quality of their work, and they join companies that value reality-based experts over submissive "yes-men."

4. The Inverse Conway Maneuver

By establishing clear, independent organizational interfaces, where experts are trusted to propose the next course of action in their fields, the business naturally forces its software architecture toward modularity via the Inverse Conway Maneuver. The maneuver is the counterpart of Conway's Law, which says organizations end up designing systems that mirror their communication structure. When human communication is structured through independent accountability and clear protocols, the "Cheap Sync" becomes socially and professionally unacceptable at the leadership level, preventing it from ever reaching the codebase.

5. Middle Management: The Bi-Directional Bridge

Middle management plays a vital role that has nothing to do with relaying memos. Their job is to lead in both directions:

Upward Leadership: Managing the expectations of upper management and translating technical and product realities into actionable insights for the C-suite.
Downward Leadership: Directing their teams to execute the deliberate strategy (the part of the plan leadership has actually committed to, as opposed to the emergent strategy that shows up in the field). And protecting them from top-down initiatives that would result in architectural embezzlement (trading the system's long-term health for a short-term feature).

A middle manager who only forwards messages from the top is functioning as a mailman. The actual job is leading people with more authority than you, leading in both directions at once, and doing the work that actually moves the company.

6. Presenting the Unsustainable Path

To overcome C-suite blindness, leadership must be presented with the ramifications of their decisions through hard data. Ramifications matter here, not just the first consequence but the consequence of the consequence.

In legacy environments, this usually means showing how incident growth correlates exponentially with user data and technical complexity. A common shape of this is a single business event fanning out into multiple redundant layers, where every new event has to be written in two or three places, and every new feature has to remember all of them. Each one looks cheap on its own. Together they form a compounding cost on the business, where incidents climb with user growth and feature cost climbs with incidents, until the company is paying for the complexity more than what's paying for the product. When the CEO parses "Incidents" as a survival threat rather than a technical detail, the mandate to cut the redundant dependencies and modularize becomes a radical business necessity rather than a technical preference.

Anywhere a single business event fans out into multiple code paths that must stay in lockstep, complexity compounds with traffic.

References

Schwantes, Marcel. "This 32-Year-Old Steve Jobs Quote May Be His Best Leadership Lesson Ever." Inc., 2024. https://www.inc.com/marcel-schwantes/this-32-year-old-steve-jobs-quote-may-be-his-best-leadership-lesson-ever/90986760
Conway, Melvin E. "How Do Committees Invent?" Datamation, vol. 14, no. 4, April 1968, pp. 28-31. https://www.melconway.com/Home/Committees_Paper.html
Fowler, Martin. "Conway's Law." martinfowler.com, October 2022. https://martinfowler.com/bliki/ConwaysLaw.html
LeRoy, Jonny, and Matt Simons. "Dealing with Creaky Legacy Platforms." Cutter IT Journal, December 2010. https://jonnyleroy.com/2011/02/03/dealing-with-creaky-legacy-platforms/
"Story Point." Wikipedia. https://en.wikipedia.org/wiki/Story_point

You Don't Automate the Levers of the Past

David Vartanian — Tue, 28 Jul 2026 10:06:30 +0000

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.

What scale, automation, and creative destruction actually do to a business

1. Automation as Systemic Transformation

Elevator Logic

Automation demands transforming the entire workflow. The historical example of the elevator operator makes it obvious. When the profession disappeared, nobody built a robot to sit in the chair and move the manual lever, and nobody built a voice recognition system so passengers could tell a machine which floor they wanted. Both would have been expensive ways to preserve the inefficiency of the old system instead of replacing it. The lever became a button, the manual circuit became an integrated electronic system, and the components changed because the system changed. The lesson generalizes. An automated system can't stay the same and just become "automatic." It must evolve, or the industry's progress will destroy it. You don't automate the levers of the past, you redesign the system so those levers are obsolete. The workflow, the components, and the interface all change together, or the attempt at automation is just a dressed-up version of the old process running on more expensive hardware.

What the elevator pattern really shows

The loudest debates around automation treat it as a self-contained phenomenon, as if a single technology causes a single class of job loss. The reality is wider and older. People who used to make candles lost their livelihood to the spread of electric light. Telephone operators who spent their days connecting cables for callers were replaced by an electronic switching system that worked around the clock without a salary Bell Labs deployed the first electronic switching exchange, the 1ESS, in Succasunna, New Jersey in 1965. Did these people just disappear? No. Some suffered through the awkward years of unemployment. Most of them adapted, willing or not, because the world around them kept pushing forward and they had to keep up with it. That pressure is the general pressure of creative destruction, not a side effect of automation alone. Joseph Schumpeter used the term in Capitalism, Socialism and Democracy (1942) to describe how capitalism constantly displaces the old with the new. The old gives way to the new, not because anyone planned it that way, but because evolution doesn't consult the people it displaces.

Automation is one of the more visible faces of this process, not the process itself. A profession disappears because the underlying activity stops being demanded, and a machine often shows up simply because it's the cheaper way to serve whatever demand is left. Framing job loss as "caused by automation" misses the structural driver and tends to produce bad policy and bad business decisions built on a misdiagnosis.

2. The Trap of Premature Capital

Capital needs a critical distinction. VC money isn't inherently "bad money." But VC money used too early, before a company has proven its customer demand, enables a dangerous detachment from reality. That premature injection of capital encourages management to scale an inefficient business model. The real threat is scaling an inefficient system, not automating it. When you scale a system loaded with sync tax, the cost of running it doesn't grow linearly, it grows exponentially, and the whole operation bloats as a result. It demands more meetings, more coordinators, more human glue, more tooling just to keep the pieces from falling on top of each other.

The talent side of this trap is brutal. The company recruits skilled professionals with tempting offers to keep the scaling machine fed. Those professionals walk in expecting to do meaningful work and quickly discover that most of their day goes to meetings, status updates, and hand-offs between teams that can't talk to each other on their own. The job experience gets devalued. The talent stagnates. The company pays a fortune for it, both in infrastructure and in the silent cost of people who are slowly checking out while still drawing a salary. The Sync Tax doesn't just eat profit. It eats the professional lives of the employees.

When the "just leave" answer fails

A common objection at this point is whether automation "frees" the humans trapped in such a system. In practice, that question misses the structural constraint. People are not slaves. Nobody is legally forced to keep showing up to a job that is slowly hollowing them out. The freedom to leave exists in principle, and in many labor markets it exists in practice too. The real damage is the loss of a meaningful job experience, not the loss of liberty. Sync tax devalues what people do all day, and the people who stay either accept the slow decay or suffer through it as if they had no choice.

The caveat matters, though, because the freedom to leave isn't equal everywhere. In countries with strong protections against firing, the same laws that make it hard to let someone go also make it harder to get hired somewhere else. The cost of changing jobs rises, the duration of unemployment stretches, and the practical freedom to walk away from a toxic workplace shrinks. So the question of "why don't they just leave" deserves an honest answer. In some regulatory environments, they can't leave easily, and pretending otherwise ignores the structural cost those policies impose on the very workers they are meant to protect. Either way, the right move is to remove the sync tax that turned the job into a devalued experience in the first place, not to make staying in a devalued job more comfortable.

3. What Humans Still Have to Do

As deterministic data processing and repetitive mechanical tasks get delegated to machines, the essence of human work concentrates into two high-value jobs that, in their nature, have to stay human: creativity and leadership.

Creativity: the ability to invent the machines and design the interfaces (or anything else) that move the world forward.
Leadership: the ability to set the vision, inspire, and guide the transition from learning what works to executing it at scale.

Repetitive and mechanical work is still needed. The work was always meant for delegation, not destruction. Freeing that contribution up is the whole point.

What machines can and can't do

In practice, machines don't lead humans. They can coordinate, schedule, route, and even simulate authority, but the act of leading other humans through uncertainty, conviction, and responsibility isn't a process you can encode. A machine follows its objective function, a human can change the objective function, and that distinction is the entire difference between management and administration.

The creativity claim needs more care because AI today sounds creative to many listeners. It can produce a poem, a logo, a strategy memo, a working piece of code, and any of those outputs can feel new to the person reading them. The output, though, is recombined from training data that already existed. The machine didn't invent anything in the strict sense. A human looked at the world, noticed something nobody had noticed, and wrote a paper, painted a canvas, designed a product, or started a company that didn't exist the day before. Only humans invent the way humans invent. AI emulates the surface of that process well enough to fool a lot of people, sometimes for a long time, but it's still working from something that already exists. Anyone building a business on the assumption that the machine is the source of novelty is building on borrowed ground.

When the role itself is the problem

A company that successfully removes sync tax will discover, often with surprise, that a meaningful slice of its workforce was only there to manage the meetings, the handoffs, and the manual reconciliation work the new system no longer requires. The instinct in some leadership circles is to keep those people employed out of a vague sense of fairness. That instinct is wrong, and the reason is economic. There is no demand for the coordination work those roles were doing, because the new system does it for them. The whole point of The Sync Tax and The Architecture of Independence is that you don't pay for things nobody needs. Keeping a useless role alive to spare someone's feelings costs the company money it could spend satisfying actual demand. This equals less profit, which equals jeopardy. It also traps the person in a job that is being hollowed out from the inside, which is exactly the devalued experience the redesign was supposed to end.

The honest version of the message is simple. When a role is no longer demanded, the right move is to let it go. The person in that role gets freed to find work that is actually valued, even if it's unpleasant and uncomfortable for some time, and the company gets freed to pay for work that customers are actually paying for. Demand rules, and that pattern repeats across product decisions, hiring, and org design, and actually everything related to humans. The job of a leader in a post-sync-tax organization is to make those calls quickly and humanely, not to pretend the work was never the problem.

Middle management is the structural layer that makes creativity and leadership possible at scale, not a layer of waste. The only honest distinction to hold onto is between middle managers who do real coordination work and the layer of coordinators who only existed because the underlying system couldn't coordinate itself. The first one is demanded, and the second one is the one the previous paragraph is about.

Who decides what to build next

The same logic applies to who decides what the company should do next. A healthy company hires expert professionals and asks them what to do, not the other way around. If a CEO dictates every product project from above, the best product manager in the world has a single rational move, which is to quit that toxic workplace and find a company that will actually use his brain.

Any entrepreneurial venture starts in learning mode. The team investigates, tests, adapts, and chases the right problem to solve (the JTBD, the Jobs to be Done framework from Clayton Christensen's The Innovator's Solution) and the right solution that customers will actually pay for. That phase is emergent strategy, because nobody up front knows the answer. Once the demand is proven and the solution is working, the strategy becomes deliberate. The company now knows what to do, and execution takes over from learning. That is the natural transition.

The CEO also has a parallel duty, and it's the one most often missed. He has to keep scanning for changes in the market that the deliberate strategy is no longer catching. As companies grow, the CEO loses direct contact with demand. The product department owns that scanning work, and the tech department owns the implementation. In a small company the same person can do all of it, but the moment the organization scales, the role splits. The product manager is looking at the present, at what customers are asking for right now and what the next quarter's roadmap should look like. The CEO is looking at the future, at where the market is moving, which adjacent demand is about to open up, and which part of the current business model is going to be obsolete in a couple of years. Both jobs are real. Neither replaces the other, and the practical question of how a company should actually structure that split's the kind of thing that gets decided badly in many growing companies, often by accident rather than by design. The principle, though, comes back to the one introduced in The Sync Tax. Demand rules, and the people closest to demand should be the ones deciding what to build.

For anyone who hears all of this and fears for their own job, the reality of creative destruction is simple. At least in the short term, AI won't replace you, someone who uses AI will replace you (a saying that gained traction in early 2023, with no single clear origin). The replacement is a verdict on the value of doing the work the old way when a new way exists, not a verdict on you as a person.

4. How Modular Systems Take Over

Modularity is a pattern that shows up everywhere once you look for it, and it doesn't belong to any company or any framework. Nature doesn't evolve by making a single organism live forever. It evolves through newborns, each one more efficient and more resistant to threats than the last, while the old generation dies off. A company that wants to survive has to follow the same pattern in its own structure. A biblical metaphor captures the same point. You can't put new wine in old wineskins Matthew 9:17; Mark 2:22; Luke 5:37-38. The new wine ferments, expands, and bursts the old container. Trying to force a new, agile business model into an integrated, interdependent architecture destroys both. A company that wants to live has to be willing to kill its interdependent business model, not just the software monolith, and replace it with a modular, efficient one.

As Clayton Christensen described in his work on disruptive innovation and modular architecture The Innovator's Dilemma, 1997, integrated systems are optimized for performance during the early phase, when the components are still small and being tuned to deliver a working product. Modular systems are optimized for efficiency during the sustaining phase, when the priority shifts from making it work to making it cheap to maintain and evolve. Old machines are replaced by new ones because keeping the old ones around costs more than the value they still produce. The same logic shows up in genetics, in industries, and in software, because the underlying constraint is the same in each case.

5. Deregulation, with Enforcement

The C-suite often accepts high complexity costs as "normal" because they lack technical understanding or because the leadership below them is too submissive to push back. The answer is to give the system more freedom and more accountability at the same time. The historical precedent is clear. The economies that flourished after periods of shock therapy the term associated with Jeffrey Sachs and the Balcerowicz Plan in Poland (1990) did so through aggressive deregulation of the private sector, paired with strict enforcement of the law against abuse, and both halves were required. Deregulation without enforcement is just chaos with a marketing slogan, while enforcement without deregulation produces a system so over-regulated that nothing can move. The countries that got it right gave businesses room to operate, and then made sure that anyone who exploited that room faced serious consequences.

Applied to a company, the same logic holds. Independent modules get the freedom to innovate on their own side of the boundary, and the agreement between them (the interface, with its rules of who owes what to whom and in what format) is enforced strictly enough that nobody has an excuse for breaching it. If two departments or two modules need constant meetings to coordinate, the diagnosis points to a bad interface, not a need for more meetings. The time those humans are spending in meetings should be invested in redesigning the interface until the meetings are no longer needed. Constant meetings between two modules are a signal of over-regulation inside the company, a sign that the architecture is forcing humans to do the work that an interface should be doing for free. Once the interface is fixed, the internal economy deregulates itself, and the company's ability to actually ship and adapt comes back.

The same principle explains the cost of C-suite blindness in a way the balance sheet never quite captures. A CEO who has learned how to raise large rounds and pick his CTOs will keep operating as long as the runway lasts, even when the technical debt is compounding. If the CTOs he picks share his blind spots, or simply lack the standing to disagree with him, nobody in the building has both the information and the authority to bring the consequences to light. The fix isn't a louder dashboard but giving the people closest to the technical impact the freedom and the obligation to challenge the high-level decisions that are creating the cost. The CTO stopped going to the sync meeting he was never supposed to need.

References

Schumpeter, J. (1942). Capitalism, Socialism and Democracy. Harper & Brothers. Wikipedia
Bell Labs. (1965). First Electronic Switching System (1ESS) deployed in Succasunna, NJ. Wikipedia
Christensen, C. (2003). The Innovator's Solution. Harvard Business Review Press. Wikipedia
Christensen, C. (1997). The Innovator's Dilemma. Harvard Business Review Press. Wikipedia
The Holy Bible. Matthew 9:17; Mark 2:22; Luke 5:37-38 (NIV). Bible Gateway
Shock therapy economics. Jeffrey Sachs and the Balcerowicz Plan, Poland (1990). Wikipedia

The Architecture Of Independence

David Vartanian — Tue, 28 Jul 2026 10:02:07 +0000

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.

Establishing the Grammar of Modularity and the Rule of the Bolt

1. Interface as an Organizational Treaty

A modularization interface is an organizational contract that establishes how a specific business unit or module will interact with the rest of the system. A well-designed interface is what allows teams to operate as entirely separate companies, autonomous and independent, as long as they honor the contract. Interfaces define the boundary of responsibility, and that boundary is what makes a modular system economically viable.

The economic logic behind this approach was formalized before software teams started talking about microservices. As Prof. Clayton Christensen of Harvard Business School explained, every operating business is governed by a "profit formula" that dictates which investments and projects receive priority (Johnson, Christensen & Kagermann, "Reinventing Your Business Model," HBR 2008). When that formula treats the company as a single unified entity, every project competes for the same scarce resources, and the same lens decides the priority of one module-level investment. This creates the conditions for incompatibilities between business, product, and tech, because the model forces linear prioritization over what should be independent, parallel work. The profit formula is what determines whether the business is structurally modular or structurally monolithic. No amount of refactoring at the code level will change that.

Carliss Baldwin and Kim Clark, in Design Rules, Volume 1: The Power of Modularity (MIT Press, 2000), argued that modularity is the most powerful force in the modern economy precisely because stable interfaces allow decentralized innovation. Their "six modular operators" (splitting, substituting, augmenting, excluding, inverting, and porting) describe how splitting a system into modules with clean interfaces unleashes parallel work. The deeper insight is what they call option value: when a module can be replaced cheaply because the interface holds, the organization can experiment with multiple versions in parallel. The one that wins is kept, and the rest are discarded. This is the source of the speed that high-performing modular companies demonstrate. The discipline is to maintain a clear boundary between visible information (the interface) and hidden information (the module interior), a distinction Baldwin and Clark also formalized in their working paper on the option value of modularity. As long as the interface is honored, the interior can be a masterpiece or a mess. The rest of the system does not care, and does not need to.

A common question in interface design: minimal or extensible? The temptation is to make the interface open-ended so it can absorb any future need. This is how interfaces become bloated, and bloated interfaces become coupled to the modules they were meant to decouple. A better discipline is to bound the interface by what the module is expected to do, not by what the consumer might want from it. Over time, this implies that engineers should classify or categorize interfaces by purpose, so the contract reflects the function rather than the consumer's appetite.

Let's illustrate the discipline with a practical example. Consider a company running a single monolith, with checkout, fraud, and settlement logic all interleaved. The first refactor splits out the payment processing concern. Naming the module is not arbitrary. The module is PaymentsProcessor, and the interface it exposes is PaymentProcessing. Every other team codes against that interface. Whether the underlying implementation is a single function, a queue, a distributed system, or even an external service stays hidden behind the interface. Other teams pass a payment_id and receive confirmation. They stay unaware of the database schema or the queue topology inside PaymentsProcessor. If the team later replaces the entire implementation, no other team has to change a line of code. That is the entire economic value of a well-defined interface.

A frequent objection is to point at an OpenAPI specification and ask why that is not enough. OpenAPI documents a different kind of interface. It describes the technical contract between a client and a service, typically at the request-response level. That is useful for engineers wiring two endpoints together. The right question is whether the product can be broken into independent, replaceable, business-aligned modules. Modularity at that level concerns business structure, team topology, and the technical architecture, all sharing the same interface principles Christensen describes in his work on interdependence vs. modularization (Christensen & Raynor, The Innovator's Solution, 2003; HBS Module Note 420-016, 2019).

2. The Rule of the Bolt: Immutable Identifiers

The stability of a modular system depends on the predictability of its interfaces. The Rule of the Bolt defines the discipline for maintaining true domain responsibility and independence:

The Identification Joint: The only valid physical connection between independent modules is the Immutable Identifier (The Bolt).
Responsibility Limits: Interfaces must exchange IDs, such as a User ID, not complex, state-heavy objects.
Encapsulation: As long as the data type of the Bolt remains unchanged, the internal properties, constraints, or metadata of the module can evolve daily without disrupting the composite system.
Independence: Cross-module function calls and shared internal types are welded joints that prevent a system from being broken into truly separate modules; independence requires that modules communicate only through their declared interfaces.

3. Timing: The Good Enough Pivot

Modularization is a capital allocation decision rather than a default.

Early Stage: Prioritize raw performance, feature delivery, and finding product-market fit. Modularization during this phase can create unnecessary overhead and detract from the core focus on performance.
Sustaining Market: Once the product reaches good enough performance and serves demanding customers in a competitive tier, the competence shifts from performance to flexibility and speed. Modularization at this stage is a critical requirement to avoid the Sync Tax and ensure future innovation speed. Christensen and Raynor make the same pivot explicit in The Innovator's Solution: once a product overshoots what customers can use, the basis of competition moves to convenience, customization, and speed, which demands modular architecture.

4. Measuring the Human Cost of Architecture

Traditional metrics miss the human cost of poor architecture. Two simple views of the codebase tell the story.

The first view plots the number of releases a team ships against the total man-hours the team spends in meetings with other teams during that same period. In a well-modularized system, these two numbers move in opposite directions. Feature work scales, release count grows, and meeting hours stay flat or fall, because each team codes against stable interfaces and rarely needs to negotiate with anyone. When feature work and meeting hours both climb at the same time, the architecture is broken no matter how clean the code looks. A team that needs three meetings to ship a small change is paying for somebody else's shortcut.

The second view compares two kinds of complexity over time. Business model complexity counts the number of unique logic paths the product has to support. These are the distinct conditions a customer can fall into that change how the system behaves: different jurisdictions, account tiers, edge cases in pricing, refund rules, fraud signals. Technical complexity counts the corresponding load on the codebase, the branches, integrations, exceptions, and special cases the engineering team has to maintain. In a healthy modular system, the two lines grow together. New business rules add new logic paths, and the codebase absorbs them at roughly the same rate, one module at a time. When the technical line starts climbing faster than the business line, the architecture is leaking. A small new rule, a new country, a new customer tier, should require a proportional change in the code, not a step change. When the code explodes for a small business change, the Sync Tax is already eating the margin.

When the code explodes for a small business change, the Sync Tax is already eating the margin.

Both views gain their full meaning with the right economic framing. The Sync Tax is called a tax because it behaves like one. Taxes, in any economy, are regressive. They shrink the productive base without ever growing it, taking a disproportionate share from the most constrained resource and returning nothing. That is precisely what the Sync Tax does to a software business. It consumes the engineering hours the team should reinvest in new features, and it returns only friction.

Some of these syncs came into the codebase as "temporary" measures. They were a quick fix to keep a feature moving when the architecture would not allow it. The team that introduced them intended to come back and clean them up. They never did. The pattern is identical to what any government does when it adds a "temporary" tax to fund an emergency. They never had the intention of removing it because they love other people's wealth, while in the case of a product, upper management might never have the intention to approve time to cleanup the product architecture. Milton Friedman captured the dynamic in Tyranny of the Status Quo (1984, p. 115): "Nothing is so permanent as a temporary government program." The political class that benefits from the tax has no incentive to remove it. Their power depends on the tax base. So they lie when they call it temporary. By the time a generation has passed, the "temporary" tax is permanent, the original emergency fades from memory, and anyone who tries to remove it gets labelled a radical. The Sync Tax follows the same logic. Each "temporary" sync compounds with the next, and the architecture teams originally intended as transitional becomes the only architecture anyone remembers.

Nothing is so permanent as a temporary government program.

5. Where to Start Decoupling

For legacy systems with heavy interdependence, leadership must deliberately remove the Sync Tax. The principle is the same as paying off debt, a metaphor Ward Cunningham introduced in his OOPSLA '92 experience report on the WyCash portfolio system. Rank every coupling by how much pain it causes, and pay down the worst ones first. Start with the syncs that trigger the most incidents and consume the most meeting hours. Cheaper, less painful couplings can wait.

The longer-term direction is to move away from rigid, predefined contracts between modules. A module should be able to ask the rest of the system what it needs and get a usable answer, instead of depending on a fixed schema that breaks the moment someone adds a field. Modules that can negotiate their interactions on the fly are far more resilient to change than modules bound to strict, brittle contracts, and they let teams ship updates without coordinating a meeting.

6. The Crime of Architectural Embezzlement

Management must be vigilant against Architectural Embezzlement. This occurs when engineers or managers implement "cheap" solutions, such as reaching into a foreign domain to grab data, to satisfy immediate pressure. The result is the technical equivalent of a politician printing money to pay for today's subsidies. It creates 'architectural inflation' that nobody recognizes as tech debt, debasing the value of every future engineering hour. By the time the bill arrives, the perpetrators have often moved on. What can leadership do? Surface these practices and frame them as a breach of trust and long-term organizational health.

The rule is simple. An engineer should never need to read data from another domain. Where the interface does not expose it, the engineer codes around the gap rather than breaking the contract. Enforcing this rule is a management responsibility. Even with perfect interfaces, the architecture erodes if leadership tolerates shortcuts under pressure.

References

Johnson, Mark W., Clayton M. Christensen, and Henning Kagermann. "Reinventing Your Business Model." Harvard Business Review, December 2008. https://hbr.org/2008/12/reinventing-your-business-model
Christensen, Clayton M., and Michael E. Raynor. The Innovator's Solution: Creating and Sustaining Successful Growth. Harvard Business School Press, 2003. https://www.hbs.edu/faculty/Pages/item.aspx?num=15473
Christensen, Clayton M. "Interdependence vs. Modularity: Getting the Scope of the Business Right." Harvard Business School Module Note 420-016, July 2019. https://www.hbs.edu/faculty/Pages/item.aspx?num=56504
Baldwin, Carliss Y., and Kim B. Clark. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. ISBN 0-262-02466-7. https://mitpress.mit.edu/9780262538206/design-rules-volume-1/
Baldwin, Carliss Y., and Kim B. Clark. "The Option Value of Modularity in Design." Harvard NOM Working Paper No. 02-13, 2002. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=312404
OpenAPI Initiative. OpenAPI Specification. Linux Foundation. Accessed June 26, 2026. https://www.openapis.org/
Friedman, Milton, and Rose D. Friedman. Tyranny of the Status Quo. Harcourt Brace Jovanovich, 1984, p. 115. https://miltonfriedman.hoover.org/objects/57553/tyranny-of-the-status-quo
Cunningham, Ward. "The WyCash Portfolio Management System." OOPSLA '92 Experience Report, 1992. http://c2.com/doc/oopsla92.html

The Sync Tax

David Vartanian — Wed, 24 Jun 2026 13:23:12 +0000

Capital, Complexity, and the Cost of Ignoring Demand

1. Funding Mirage and the Subsidy Trap

For a successful startup, there's a moment where capital becomes a sedative. When a company raises significant funds before its business model is demand-driven, it enters a state of reality detachment. This capital acts like a government subsidy.

In national economics, a subsidy allows an inefficient entity to survive without being "chosen" by the market. The entity stays alive not because customers want what it sells, but because someone else is paying the bill. In business, "Bad Money", as Clayton Christensen defines it in The Innovator's Solution, Ch. 9, does the same thing. It allows a company to hire talent and increase valuation while ignoring that product development has stalled. Instead of building what customers demand, the company begins building what it wants, funded by investors who have money but no actual demand for the product.

Christensen drew a sharp distinction between good and bad money. While a company nurtures emergent ideas during nascent years, money must be patient for growth but impatient for profits. When winning strategies become clear and deliberate ideas need execution, money should be impatient for growth but patient for profit. The problem is the type of money companies receive. VC funding before product-market fit encourages reality detachment. Managers start using it to increase company valuation or hire talent. They're busy, feeling good, but they're not investing in what they should. Getting paid for your job and getting subsidized by the government are very different things, even if the amount is the same. If money comes from demand, that's good. If it comes from a subsidy, the government took that money from people in taxes and it has nothing to do with demand. As soon as the money runs out, a business that customers never truly validated dies. It was artificially alive.

2. How the Inefficiency Parasite Multiplies Cost

Complexity has a price companies rarely calculate on a balance sheet: I call it the Sync Tax. Companies pay this tax when they maintain an interdependent product architecture while trying to scale. As the product grows, the gradual increment in complexity creates a wasteful system where every new feature or modification results in higher coordination friction: code, data, and human alignment beyond meetings.

I saw this firsthand. I joined a company where the product had found its market. The original system was a monolith, and the company had started building a new service alongside it. Data had to stay in sync between both systems. Not a huge deal at first. But as the domain became more relevant, a third system entered the picture. Now there were three systems we had to keep in sync. Every "temporary" solution, every rushed feature, added another layer of coordination overhead. A new feature that should have taken a week required two months of a four-person team, not because the feature was hard, but because keeping three systems aligned consumed most of the effort. That's the Sync Tax in practice. It drains value the way a parasite drains its host.

Mises showed that capital invested against consumer demand is malinvestment, capital squandered (Human Action, Ch. XX §9). The same logic applies inside a company. Every dollar spent maintaining complexity that customers never asked for is internal malinvestment. In a clean system, $1 of effort generates multiple units of value as it flows through the organization. That's an efficiency multiplier: capital compounds when complexity stays low. When complexity grows unchecked, the multiplier reverses. Each dollar circulates less, feeds more overhead, and returns less value to the customer who was supposed to justify it in the first place.

The business pays for the feature plus the cost of feeding the parasite of its own inefficiency. The natural reaction is to automate the mess, but automating an inefficient system just makes it more inefficient. Automation makes sense for repetitive tasks that don't require human judgment. You wouldn't pay an elevator operator to press buttons for you, and that job disappeared because a button and an electronic system does it better. But automation doesn't fix structural problems. The fix is removing the inefficiencies first, then letting automation amplify what works.

3. The Factor of Time in Strategy

Deliberate Strategy (top-down) gets a bad reputation. Emergent Strategy (bottom-up) gets treated as inherently better. The distinction originates with Mintzberg & Waters (1985), and Christensen applied it to innovation strategy in The Innovator's Solution, Ch. 8. In reality, strategy shifts over time, and timing is everything.

The CEO must constantly steer between experimentation and discipline. There are periods where strategy must be pragmatic (Emergent), experimenting, researching, and listening to the "front line" (engineers and middle managers) who are the first to detect shifts in customer demand. There are other periods where strategy must be dogmatic (Deliberate), consolidating those discoveries into a winning strategy the organization must execute with discipline.

The factor of time is the one leaders consistently overlook. What works today might not work six months from now, and what failed last year might be exactly right for the current moment. The world keeps evolving, and strategy must evolve with it. Emergent strategy brings solid knowledge that can become dogma for a while. But learning never stops because the market doesn't stop changing. The person in charge is responsible for deciding when to dedicate more resources to experimentation and when to keep delivering what's already proven.

The "Sync Tax" is what happens when a company stays dogmatic for too long. Because the system is too complex to change easily, the company ignores the warnings from the front line and insists on top-down features that no customer wants, simply because they have the "bad money" to pay for them. By the time the company realizes the strategy is wrong, it's also too far from the customer to know what right looks like at the moment.

4. Playing the Political Game of Refactoring

Escaping this trap demands both technical and political skill. Because the business side knows little about technology, they view the tech department as an expensive "black box" and respond with micromanagement and reports. The business side wants higher margins. The tech side wants better metrics and convince the business that those metrics mean the company is doing well. Neither side speaks the same language, and the cost of that disconnect lands on the customer.

This lack of trust creates a bureaucratic loop that makes refactoring nearly impossible. In the triple sync story, I had to propose stopping all new feature work to remove the syncs that were strangling the product. Nobody liked the idea. The business saw an expensive department asking to slow down, and the tech department hadn't been transparent about the mess it was maintaining. We were heading straight for failure if we continued on that path, but getting budget approval to stop building and start fixing required fighting through layers of bureaucracy that existed precisely because trust had eroded.

To break free, you must play the "political game": stopping the production of new, unwanted features to remove the unjustified complexity that is smothering the business. You can't scale an inefficient system; you must first remove the inefficiencies to allow the money to accelerate growth rather than accelerate loss. The business side needs to understand this in their language, which is dollars and timelines, not technical jargon. If the tech department can't translate the cost of complexity into numbers the business feels, nothing changes.

5. The Decoupling Point

After product-market fit, all product companies pass through a moment I call the Decoupling Point, a term I learned in Prof. Christensen's Disruptive Strategy course at Harvard Business School. Christensen used it to mark the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture. I extend it here to mean something broader: the moment when architecture, strategy, and demand all signal the same transition at once.

The strategy must shift from learning what customers want to preparing the product to handle much larger demand. This is the first time in the lifetime of the company that the strategy needs to change. Until this moment, the company was in learning mode, making quick changes, trying to understand the customer, until they did it and that's what product-market fit is about. But now, they need to prepare to handle a much bigger demand.

The current product isn't scalable. It's an original product with lots of modifications and patches, far from ideal. That same product can't scale essentially because to get there, the company had accumulated a lot of complexity, which means higher cost and slow changes.

This is time for deliberate strategy. Now the C-suite learned what to do and can take that knowledge and apply it properly. But here's the confusion. The job now is to stop adding features and scaling the same product, and instead make the product work at low cost, make it stable, and make it able to change fast. The product that got the company to product-market fit isn't the product that carries it forward. You have to remake it for the next phase, not by adding more, but by removing what's in the way.

References

Christensen, C. M. & Raynor, M. E. (2003). The Innovator's Solution: Creating and Sustaining Successful Growth. Harvard Business School Press.
- Ch. 8: Managing the Strategy Development Process
- Ch. 9: There Is Good Money and There Is Bad Money
Mintzberg, H. & Waters, J. A. (1985). "Of Strategies, Deliberate and Emergent." Strategic Management Journal, 6(3), 257-272.
Mises, L. von (1949). Human Action: A Treatise on Economics. Ch. XX §9: The Market Economy Affected by the Recurrence of the Trade Cycle
Christensen, C. M. Disruptive Strategy. Harvard Business School Online course. The term "Decoupling Point" as used in this article was learned in this course, where it marks the point in the value chain where it makes sense to shift from interdependent architecture to modular architecture. The extension to strategy and demand timing is the author's own.

I Wrote a Book About the Engineering Cost That Compounds After PMF

David Vartanian — Mon, 01 Jun 2026 18:37:31 +0000

Here's the pattern: engineering budgets at post-PMF companies grow faster than the product, and the budget looks justified. The architecture gets a small upgrade, the team gets a few more people, the roadmap absorbs another integration. Every individual decision is reasonable, so where does the cost actually go? It hides in the gap between decisions: the compounding, the waiting, the integration overhead that grows whether or not anyone is paying attention. That's the cost curve, and nobody owns it. The only thing longer than the curve is the list of reasons nobody is tracking it.

I wrote a book about this, and The Engineering Tax covers 29 chapters on the costs that compound after product-market fit: coordination overhead, integration sprawl, organizational friction, technical decisions that look harmless on day one and expensive once the cost has had time to compound. Each chapter pulls one cost out of the noise, names it, and shows how to measure it before it eats the margin.

Why a book and not a blog post? The costs compound across years, and a short post can't show the curve. They also interlock, meaning you can't address one cleanly without addressing the others. Integration sprawl, organizational structure, AI tools, technical debt, they all push on each other. A book is the smallest format that fits the actual problem.

Who it's for: founders and CTOs at post-PMF software companies (Series A through B, 25 to 200 engineers) who feel their team is moving slower every quarter but can't point to a single line item in the budget, and if that sentence hit, the book is probably for you. You know the cost is there. You just can't see it on any spreadsheet, and the spreadsheet is the only thing the board is looking at.

I shared the first chapter as a free read, and it walks through one specific cost pattern (the cost of teams waiting on each other in code reviews, in design reviews, in integration testing) and shows how it becomes an annual cost with nobody signing the check. The rest of the book goes wider and deeper, across the full post-PMF cost surface.

If you want early access when the book is ready, I opened a waitlist. One email when the book ships, and that email is the announcement.

Link: https://beamersoftware.com/the-engineering-tax/

What invisible cost is your team paying right now that nobody is tracking? Drop a specific example in the comments.
Dollars, hours, or both, whatever you can measure.

I built a free API that measures the cost of software complexity

David Vartanian — Thu, 28 May 2026 10:05:31 +0000

I spent the last few months researching the economics of software engineering. Specifically, what happens to costs when a product grows past what one team can maintain.

The same pattern kept showing up. Teams spend more time coordinating than building. Changes in one module break unrelated parts of the system. Features take twice as long as they should, not because the code is hard to write, but because the code is coupled to things it shouldn't be coupled to.

I call it the Sync Tax. It's a multiplier on every engineering hour. A multiplier of 2.0 means everything costs twice as much as it should. A multiplier of 4.0 means you're burning most of your budget on coordination and firefighting, not on output.

I built a small API around it. You plug in a few numbers about your codebase and team structure, and it returns the multiplier plus a dollar figure. No credit card needed for the free tier.

There's also an MCP server if you want to hook it into Claude, Cursor, or any agent.

https://complexity-cost-calculator.beamercloud.com/

I'm curious what numbers people get when they run their own teams through it.