DEV Community: David Vartanian

Recruitment Is a Strategy Decision, Not an HR Task

David Vartanian — Tue, 11 Aug 2026 09:05:59 +0000

You tracked the cost of your own technical decisions, but the harder question is whether the people around you are the right ones for what comes next. The next article reveals that recruitment is your company's immune system, the interview decides the next two years, and creative destruction applies to human capital as surely as it applies to strategy. A team built on entitlement instead of execution is the fastest path from margin to crisis, and the leaders who treat hiring as strategy will have teams that survive pivots their competitors can't.

Recruitment and the Innovation Mindset

Recruitment is a strategy decision, not an HR task. The people you hire and how you treat them is the company's immune system against cultural and operational decay. This article is about treating human capital with the same discipline you apply to product strategy, and about removing the cultural elements that corrode it from the inside.

The interview is where the next two years of the company get decided. Run it well and the company hires its own future. Run it badly and the company hires its own disease.

Disclaimer

Before the substance, a direct note. If you lean toward the progressive or left worldview, this article will not sit well with you. I am intentionally hard on that mindset because it has radicalized into something destructive. What started as a political preference has become an ideology built on resentment and entitlement that corrodes company cultures from the inside. A team that adopts that mindset will watch its best performers leave and its worst patterns harden. If that sounds like an unfair characterization, this article is not written for you.

1. Creative destruction in practice

Innovation is like a biological process. For the new to flourish, the old must die. This cycle is what economists call creative destruction, and it is essential for a company's survival, and it must be reflected in its human capital strategy. A CEO who doesn't know what creative destruction is should probably not be a CEO.

Skate to where the puck is going. Christensen brought Gretzky's quote, "I always skate to where the puck is going to be". A leader must skate to where the money will be. This means acknowledging that current core competencies and roles that never change have an expiration date.
Nothing must die until it's time to die. Of course nobody should kill the main source of income. That would be suicidal and stupid. Germany killing its nuclear plants without an affordable source to produce energy is the kind of decision that only progressive politicians make. The CEO's challenge is to watch the current main source of income, accept that it will become obsolete at some point, and start developing the next one before the current one dies. That is what Christensen means by skating to where the puck is going to be.
Avoid the anti-stagnation trap. Massive layoffs trace back to leadership negligence. Constant, incremental reallocation of resources prevents the need for catastrophic, large-scale cuts. A company that protects roles losing their business value concentrates all the pain into a single day when the reckoning finally arrives.
Human capital depreciates like any other asset. Changing jobs, learning new skills, and acquiring new experience is what keeps a professional's market value from depreciating. The depreciation of human capital is a general principle, not a software-engineering one. Do not put modularization at the same level as the decision to stop learning. A company that protects static roles is actively harming the long-term career of the employee, and it is lying to itself about being kind.

2. Recruitment: filtering for the entrepreneurial mindset

Recruitment is the primary defense against systemic inefficiency and cultural decay, and the interview is the first filter that decides what kind of company this will be in two years.

Filter for the high-performer profile. Look for candidates with entrepreneurial experience, or people who have successfully handled major pivots. People who have built something from scratch, or steered a team through a major shift, understand that roles evolve, that comfort has an expiration date, and that stability lives in their ability to execute rather than in any job description.
Ask interview questions that actually test for it. Stop asking trivia and instead ask candidates directly how they reacted the last time their role changed, what they thought when the company pivoted, and what extra perks they would expect. Then listen carefully to how they answer. A candidate who treats the question as offensive is telling you everything you need to know. A candidate who answers with stories of adaptation is telling you the opposite and it's a sign that the candidate might be a valuable addition.
Keep the HR function healthy and ideologically neutral. The CEO is responsible for making sure the HR department is healthy. HR that is infected with the entitlement-and-resentment mindset will let the same people walk in through the front door. Party affiliation stays out of the interview. The behavior the mindset produces does not, and the resentful, hateful, and criminal mindset the left provokes is exactly the kind of behavior that earns the right to be screened out. You are judging a pattern that destroys teams and lives, and that pattern has a clear ideological fingerprint you would be blind to ignore. If a candidate carries the entitlement-and-resentment mindset into the interview and the company wants a toxicity-free culture, leave them at the door. One bad hire carrying that mindset can seed dysfunction for months.

3. Adult-to-adult partnership

The modern trend of wrapping jobs in comfort, perks, and "employment joy" has created fragile environments. Adults do not need their job to be constantly pleasant. They need a deal that respects their intelligence and makes them more valuable over time.

The deal is mutual. A job is a high-alignment partnership. The company benefits from expertise and highly effective organization. The employee benefits from compensation and, crucially, experience that updates and increases his market value. That is the entire contract. Anything beyond it, framed as a "right" paid by the employer, is a fiction that has to be paid for by someone, and it usually ends up being paid for by the people who actually produce.
The "rights" myth. The concept of employer-paid rights, beyond the agreed compensation and the professional growth the deal already includes, is rejected. A job is a partnership. The moment "rights" become the dominant language, the company is one step away from being run by grievance committees. And let's not start talking about labor unions.
Boring work is part of the deal. Cleaning up legacy code and removing accumulated complexity is a project, not a permanent job. Adults must accept that work is not always pleasant, and the right move is to do the project without drama. The last couple of decades, especially the software engineering industry, wrapped the job in comfort, perks, and "employment joy." That madness did not come out of thin air. It came from a time when engineering talent was scarce, expensive, and hard to replace, so companies competed for it with perks, and engineers learned to abuse the industry and started to feel entitlement for those perks. Those market conditions are gone now. Engineers today can't find a better job as quickly as years ago, and companies can be more clear about the terms of the deal going in.
Dealing with toxicity. Entitlement and resentment act as a cancer. Managers must identify toxic behavior, like envy-driven complaints and a focus on "rights" over "results," and remove it as soon as possible. One warning, then an exit. Give zero millimeter to the people who carry this mindset, because they will use it to destroy the team from the inside. Every manager owns the team's behavior, not just the CEO. The standard is one bad behavior and a warning, two and they are out. Keep political views out of recruitment and judgment. The behavior the mindset produces is fair game, and the modern left is not shy about producing it. If the manager doesn't do his job removing toxicity, then his best performing people will leave first.

4. Exit protocol: transparency over shock

If a company is transparent from day one, a layoff or a role elimination is never a surprise. The employees already know the trajectory because the company has been telling them.

Give the depreciation warning early. Employees should be informed early when their current position or department is losing its business value. The information is the basic respect due to an adult who can use it to make better decisions, and framing it as cruelty is a mistake. If a CEO announces in some all-hands that he will never conduct a layoff, he's lying. Start preparing your exit with enough time.
Try to relocate first. When a role or department is losing its business value, the first move is to see if the employee can be relocated into a different business unit or position. A company is, at the end of the day, a group of people working together toward a shared goal. If the fit between the person and the role is gone, the cheaper and more respectful move is to find them a different seat inside the same company before looking outside. In practice, transferring good employees to different positions should be a more common practice, because it preserves institutional knowledge and saves the company the cost of recruiting and training a replacement. The employee stays because the new role is a better fit, not out of any fanatical sense of loyalty. Staying in a bad role out of guilt, fear, or cult-like attachment is not a virtue but a slow harm to the employee's market value, and the company should not encourage it.
Make the break clean. If retraining fails after multiple attempts, the most respectful and financially sound act is a clean break. The company should budget for it, the same way it budgets for any other predictable cost. Some exits are caused by toxicity, and those should be fast. Others are not bad hires at all. People keep evolving, and sometimes they just become incompatible with the role as it now exists. Either way, the budget for parting ways cleanly is part of running the company in good order.
Mutual termination is a sign of respect, not failure. When the no-surprise protocol has worked, the exit conversation is between two adults who already share the same facts. A mutually agreed contract termination is a sign that the company appreciated the employee but has to keep moving. There is nothing personal in it, and that is exactly what makes it dignified.
Spin-offs. Transitioning a team or department into an independent business unit is a valid strategy for managing stable-but-depreciating sources of income. This works at the team or business-unit level, where a coherent group of people can be set up to run on its own. People are not swappable modules, and that principle still holds. But a team is a business entity, and treating it like one is fair. From the company's point of view, individual employees are still resources that can be hired and fired at convenience. The job of the CEO is to keep the company alive, not to keep every individual seat safe.

5. Stability anchor

In a world of constant change, stability is found internally, not in a safe seat. The seat will move, but the skills travel with the person.

Performance is the motivation. High performers find their stability in their own ability to execute and in the market value they keep building. The person who needs a fixed job title to feel safe will burn out the moment a reorg affects him. The person who trusts his own execution will treat the reorg as part of the job.
Keep the cultural anchors fixed. While roles and strategies change, the company's core mission and its standard of excellence remain fixed. Those are the only anchors that hold under pressure. Roles change, strategies pivot, but the mission and the bar do not bend for convenience or politics.
Move from job security to freedom. Cultural change is required here. The high performer finds motivation in the experience and the high performance itself. The cultural aspect should help the employee gradually shift from a "security first" mindset to a healthier one based on freedom, not totalitarianism. That is the real antidote to burnout, and it is the only one that scales.

Closing

The pattern across every section is the same. The company is a living system, and the people inside it are the immune system. When recruitment misses, the company hires its own disease. A culture built on grievance instead of results destroys any team from the inside. Executed poorly, the exit protocol concentrates all the pain into a single day. And confusing a fixed seat with stability creates stagnation, not safety. The CEO's responsibility is to keep the company alive sustainably, and to do it with adults, on adult terms. Anything else is pink cotton wrapped around a slow death.

References

Schumpeter, J. A. (1942). Capitalism, Socialism and Democracy. Harper & Brothers. The concept of creative destruction as the essential fact about capitalism, describing the process of industrial mutation that incessantly revolutionizes the economic structure from within, destroying the old one and creating a new one. Wikipedia
Christensen, C. M. (1997). The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business School Press. Christensen's foundational work on disruptive innovation, which reframes the Gretzky quote "skate to where the puck is going to be" as a strategy for anticipating market and technology trajectories rather than optimizing current positions. Wikipedia
Christensen, C. M. & Raynor, M. E. (2003). The Innovator's Solution: Creating and Sustaining Successful Growth. Harvard Business School Press. Christensen further develops the "skate to where the puck is going" metaphor in the context of strategy development, urging companies to track shifting customer "jobs to be done" and emerging trajectories. HBS Faculty
Christensen, C. M. (2001). "Skate to Where the Money Will Be." strategy+business, Issue 23. An interview where Christensen explicitly invokes the Gretzky idea to explain why companies like IBM divested from microprocessors and operating systems, staying where the money used to be instead of skating to where it was going. strategy+business

Decisions That Look Good Today and Hurt the Company Tomorrow

David Vartanian — Tue, 11 Aug 2026 08:59:01 +0000

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.

Bridging the Strategy and Technical Divide

A CEO who doesn't understand the technical implications of what he asks for runs a higher risk of making decisions that look good today and hurt the company tomorrow. This article is about closing that gap, not by turning CEOs into engineers, but by giving them the cultural and financial conditions to hear the truth from the engineering department and act on it appropriately.

1. Cultural Mandate: Freedom of Speech and Expertise

The foundation of a high-functioning organization is a culture where transparency is non-negotiable. Without it, every other rule in this chapter collapses, because the CEO ends up deciding on filtered information and calling it leadership.

The Expert Rule: Like Steve Jobs said, leaders hire experts to be told what to do, not to tell experts what to do. A CEO's primary cultural duty is to make sure people can speak up without fear or intimidation. If the room goes quiet when the CEO walks in, the culture is already broken, and the technical decisions made in that silence will eventually show up in the margins.
Explicit Requirements: To avoid misunderstandings, the CEO has to be explicit when making requirements, especially across different functions where words carry different weight. Only in an environment of freedom and psychological safety can employees be themselves and provide honest assessments.
Tech Stack Ownership: Unless the company is a small venture with no structure, the CEO should not interfere in technical decisions like the tech stack. Tech leaders must have the autonomy to ignore a CEO's technical preferences in favor of what is best for the company's technical health. There is one exception worth naming, and it is a real one: when the CEO has a serious engineering background and contributes as a technical leader rather than as the boss. A founder-CEO who still writes code, reviews architecture, and earns the room's respect on the merits is a different case from a CEO who reads a few blog posts and starts dictating tech stack choices. The line is whether the involvement produces real technical output, or just status interference.
Should the CEO Be in Tech Meetings: This is a cultural question, not a calendar question. If people are wired to hide details from upper management, that is the problem to fix, not the meeting to avoid. In a small company the CEO will naturally sit in technical discussions because the company is the team. In a company with formed departments, the CEO usually has better things to do, but the principle stays the same: the CEO will have the last word anyway, and the quality of that word depends on whoever has direct contact with the CEO and what they choose to communicate. So, is it a bad thing that the CEO attends technical meetings? Not really, but the CEO must be technically competent. And if he is, that definitely inspires respect.

2. The Financial Reality of the Quick Requirement

When a CEO pushes for a feature to close a deal or meet a market demand, he's making a high-stakes financial trade-off. The trade-off is rarely visible in the moment, which is why it almost always goes wrong, and by the time it shows up in the numbers, the optionality to fix it cheaply has already disappeared.

Repayment Contract: Any "quick and dirty" implementation must include an estimation and prioritized plan for the "real" solution (modularization, refactoring, or whatever restores long-term health). This repayment is part of the total cost of the feature, not an optional follow-up that can be discussed later. The quick path and the real path are not two separate budgets. They are one budget, and pretending otherwise is how companies quietly never break even due to complexity.
Informed Responsibility: The tech department's duty is to provide a proper, data-based assessment, not an inflated or biased one. Once the CEO has been informed of the technical consequences and the efficiency debt, the responsibility shifts. From that point on, it is the CEO's job to protect the company from the consequences of his own decision, and the team should not feel obligated to absorb the cost of an informed override.
Debt Spiral: If a CEO insists on not paying back the debt, a couple of things follow. Margins compress as the system gets harder to change, and good people leave first, because they are the ones with the most options. The CEO may keep raising funds (some are very good at that) while the culture erodes. At some point, the business performance forces a decision, by which point the optionality is gone. Employees are free to leave well before that moment. That is not the only good or well-paid job, and pretending otherwise is a disservice to the people who trusted the company with their careers.

3. When Estimation Stops Matching Reality

The point of the cultural rules in Section 1 is to make sure the CEO hears the truth. The point of this section is to make sure the CEO can verify it, because culture is not enough on its own. A team can feel completely safe speaking up and still hand the CEO unrealistically optimistic numbers, sometimes because the engineers themselves don't know how long the work will take, and sometimes because they want to avoid a fight. The CEO needs a way to see, from the numbers alone, whether what is being reported reflects what the team is actually experiencing on the ground.

The cleanest way to do that is to compare what the team said a project would take against what it actually took. Call this the estimation gap: the difference between the time the project was estimated to need at the start, and the time it consumed in the end. A single project slipping is normal, and it can happen for honest reasons, like an unexpected dependency or a sick week at the wrong moment. What is not normal is a pattern, where two-week estimates keep becoming two months, where the same team keeps missing the same way, where the gap keeps growing. A pattern like that means one of two things, and both are the CEO's problem. Either someone is hiding bad news to avoid the conversation, or the system has become so entangled that even the engineers cannot predict it, which usually means the cost of complexity has crossed into territory the team can no longer estimate at all. In both cases, the CEO is making decisions on a polished version of the truth, and the polished version is the one that looks best in the next planning meeting.

This is also where the yes-men problem shows up in the data, even when the culture feels healthy. The manager who only says "yes" to avoid conflict does not have to lie about a single number. He just has to give an over-optimistic estimate and let the project slip quietly, and then give another over-optimistic estimate next time, and let that one slip too. Over a year, the board sees a team that consistently delivers late, and a culture that looks fine, and a CEO who cannot explain the gap. The pattern is the message, and the message is that the team has stopped trusting that the truth will be received well. The CEO can fix that, but only if he sees the pattern, which is why the numbers have to be tracked and surfaced instead of buried in retros that nobody outside the engineering department ever reads.

When the pattern is visible, the CEO has a lever that does not require technical expertise. He can ask, project by project, what was estimated and what was delivered, and the gap will speak for itself. He can also push for direct access to the people who own the work, which in most companies means the engineering leads or the module owners, the people closest to the code, rather than going through a chain of managers who have learned to soften the message before it travels up. When a company fails, it's almost always because of the leadership, and never because of the people under them.¹ Investors who specialize in buying failed companies know this, which is why the first thing they do is fire the entire C-suite² and start asking the people doing the work what actually happened. The leadership is the variable that explains the outcome, and the people doing the work almost never had the authority to change the trajectory.

4. Complexity, Competitors, and the Vicious Circle

Complexity, rather than the monolithic architecture itself, is the primary business risk as a product matures. A monolith is just a tool, and what makes a tool dangerous is how carelessly it gets used over time, especially by people who don't have to live with the consequences of that use.

How the pressure to keep up turns into technical debt

As a product succeeds, competitors arise, which makes users more demanding. That pressure leads to over-optimistic estimations from tech departments. Engineers pad estimates to avoid a fight, not because the work is actually fast, and the CEO takes the over-optimistic number as truth. Features get added on top of an architecture that was never properly modularized, and the system slowly stops being predictable. The cost of the next feature rises, the cycle repeats, and the CEO concludes the team is "slow," when in fact the team is paying interest on a debt nobody is tracking.

When chasing a competitor's feature is a symptom, not a strategy

When a competitor launches a flashy feature and the instinct is to follow immediately, that is usually the sign that the decoupling point is past due. The right response is rarely to copy the feature, and more often to ask why the company ended up in a position where copying is hard.

The trade-off most CEOs get backwards

Tech must assess the costs of following with and without modularization. Sometimes, losing a few customers to a competitor while focusing on modularization is the better choice, because once the system is modular, the cost of every future feature drops. The variable CEOs miss is that modularization is an accelerator, not a tax, the tax is precisely not modularizing. Paying the modularization cost now means paying less for everything that comes after.

5. Negotiation and Performance Incentives

Negotiation is a core requirement for engineering managers. Nobody should say "yes" automatically, no matter the position or hierarchy level. The company that runs on automatic "yes" answers is the company that runs into a wall, and the wall is always more expensive than the conversation would have been.

Negotiation is a shared job, not a confrontation

Negotiation is not a confrontation. It is the process by which two sides with different expertise align on what is actually being asked and what it actually costs. PMs, engineers, and engineering managers should all be expected to push back when the math doesn't work, and to do it with data, not opinion. Of course if the negotiation is successful, everyone wins and the company wins.

How PMs should be measured

Product Managers must be rewarded for shipping features that generate value and revenue without increasing incidents or complexity. An "incident" here means a system failure users actually notice, like an outage, a broken checkout, or a data loss, and these are the events that hit revenue directly, which is why a CEO should care about them even without a technical background. The "efficiency metric" is the team's measured output per unit of effort, and it gets worse as complexity grows, because more effort disappears into coordination, rework, and bug fixes that exist only because the system is fragile. Increasing complexity makes the next incident more likely, so the two metrics (value shipped and complexity added) have to move together in any honest PM assessment.

Rewarding the work that prevents fires

Success should be rewarded through bonuses or mentions for keeping complexity low and systems incident-free, because this is the kind of work that prevents fires, and the company that rewards it will have fewer fires. Rewarding only visible heroics creates more heroics, which usually means more fires.

Firefighting is extra work, not a cultural ideal

Outages and "heroic" fixes caused by accumulated complexity should be treated as extra work, compensated with pay or time off, but never glorified as a cultural ideal. The company that celebrates the engineer who pulled the all-nighter to recover from a preventable outage is the company that will have more preventable outages, because the celebration teaches the team that heroics are how you get noticed.

Hiring as the first filter

The first defense against estimation padding is recruitment. Try to hire people who give honest estimates even when an honest estimate is uncomfortable. If a department systematically pads estimations, that is a corrupted incentive, and the people driving it should not stay in roles where their numbers decide the company's roadmap. Better to say an uncomfortable truth than a comfortable lie. Test it in interviews to raise the moral bar of your company.

6. Feasibility and Cleanup

Every new requirement should pass a feasibility check before the team builds it. In practice, this means sitting down before work starts and asking the team a few questions that have nothing to do with enthusiasm for the feature. How long do you actually expect this to take, given the system as it is today, and not the system as it was a year ago? Has the team been missing its estimates recently, and if so, by how much, and on what kind of work? When the team touches this part of the product, do things tend to break in unrelated places? Are there features the team is currently afraid to change because the last time someone tried, something else fell over? If the answers are mostly "no, things have been stable," the feature is probably fine to build as proposed. If the answers are "yes, the system is fragile in that area, and our estimates have been off by a factor of three," then the feature as proposed is a bad idea, and the conversation has to escalate, because the CEO is being asked to make a trade-off he does not yet see.

The point of the feasibility check is not to slow the company down but to surface the trade-off before the work has already cost the team a quarter. The CEO can still override the recommendation, but he does it with eyes open, and the override becomes a real decision with a real price, rather than a feature that quietly eats the next two releases.

The other half of this section is the work that almost never gets prioritized, which is the cleanup of accumulated complexity. Cleaning up and removing complexity is the opposite of "doing nothing." It's the work that keeps the company capable of doing the next thing, and the work itself stays invisible until it stops happening. Until CEOs and boards get reeducated on this point, it will always be a problem, because the absence of removal work never announces itself, it just slowly lowers the ceiling on what the company can ship next. The job here is not to lecture investors or boards on what to think. The job is to make the cost of accumulated complexity visible through metrics and software, so the reeducation happens on its own. Once the CEO can see complexity eating his margins in numbers he trusts, the conversation changes by itself.

Closing

The pattern across every section is the same. The CEO is the single point of failure for the company's technical decisions, not because the CEO builds anything, but because the CEO sets the conditions under which the truth can reach the decision. Get the culture wrong and the truth gets filtered before it travels up. Get the financial framing wrong and the quick decision looks cheap, and the cost of the slow one is never discussed. Get the metrics wrong and the truth stays invisible until a customer notices. Get the incentives wrong and the truth gets punished by the people who could have delivered it. When the conditions are right, the CEO still has to make hard calls, but those calls get made on reality, and the company has a chance of holding its margins and its speed at the same time. When the conditions are wrong, the company ends up making the decision anyway, just at a worse price, with fewer options, and usually under pressure from a board or an investor that has run out of patience.

References

Leadership IQ, "Why New Hires Fail (And What To Do About It)". 46% of new executives fail within 18 months, with 89% of failures attributed to attitudinal and behavioral factors (coachability, emotional intelligence, motivation, temperament) rather than technical skill. https://www.leadershipiq.com/blogs/leadershipiq/executive-failure-rates ↩
AlixPartners, "Private Equity Portfolio Company CEO Turnover Survey" (2017). 73% of CEOs are likely to be replaced during the investment lifecycle, with 58% of replacements occurring within the first two years. https://www.alixpartners.com/media/16458/ap_private_equity_survey_may2017.pdf ↩

Treat Every Module Like an Outside Company

David Vartanian — Thu, 30 Jul 2026 09:40:21 +0000

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.

Autonomous Cooperation Protocol

A modular system treats each module as an independent service provider, more like a separate company than a department inside one. The module does a specific job for the entity that called it, which we'll call the caller, and the caller isn't the end user of the whole product. The end user is the responsibility of whoever owns the user-facing experience, not every module down the stack. This is the discipline that keeps business logic encapsulated and stops modules from making decisions based on global state or context they shouldn't have access to in the first place. The full set of rules this article describes has a name. It's the Autonomous Cooperation Protocol, and the rest of the article is the protocol itself: the rules a module has to honor, the boundaries it has to defend, and the costs of breaking either.

Before going further, a quick note on the word "independent," because it's the source of a common misunderstanding. Every module exists because something else needs the job it performs. Modules are independent in the sense that they can be replaced, refactored, or rewritten internally without asking anyone's permission, but only as long as they keep delivering what the rest of the system demands from them. Other modules are stakeholders, which is a useful word here because it captures the relationship precisely. A stakeholder gets a say in what the service must deliver, but the stakeholder's involvement ends at the interface. Ownership, operations, and internal data access belong to the team that runs the service. If a service isn't being demanded, it has no reason to exist, and that includes the user module, the account module, and the rest. Demand is the only thing that justifies a service's existence in the first place. The same logic that justifies creating a service is the same logic that justifies keeping it alive, which is the same logic that should justify killing it the day the demand goes away.

One important clarification on the word "sovereign." Sovereignty in a modular system means one module is free to design and change its own internals without external approval. Each module has full authority and ownership over its own domain, its own data, its own code, and its own decisions. The boundary of that authority is the well-defined interface that connects the module to the rest of the system, which is the same role the contract plays in the ownership standard. Authority and ownership are required for the system to work, but they're required internally, never over another module. A module that tries to exercise authority over another module's domain, its data, or its decisions has crossed the boundary, and the contract is what makes the crossing visible.

This framing matters because the violations discussed below come from a confused mental model of who owns whom. When an engineer treats a module as an internal database they can read from whenever convenient, the module has been turned back into a department. The discipline is to keep thinking of it as an outside company, and to keep the relationship transactional.

What a Speed Trap Looks Like and Where It Comes From

The most common threat to this discipline is pressure for speed, and it rarely starts with engineers being careless. It comes from three sources, and they tend to compound. A CEO or business leader pushes the tech team to ship faster because the quarter's ending, a competitor shipped something, or a stakeholder is asking for a release date. A product design hides complexity, so the task as written looks small when it's in fact a structural change. Or the translation from product requirement to technical task loses the architectural constraints entirely, and the engineer receives a ticket that says "add a username here" with no mention of which domain the username belongs to. In all three cases, the engineer responds most likely with the path of least resistance, which is to add convenience data: passing extra information "just in case" or "so the next module doesn't have to fetch it."

The shortcut is forbidden for economic reasons. Developing software without these shortcuts may look more expensive today, because some other module also has to develop something it didn't need to develop before. The company pays for that extra work now in exchange for never paying the perpetual sync tax on every future change, which is what happens when modules are quietly coupled through "just in case" fields. The trade is between paying once and paying forever. If the company is making good decisions elsewhere, it has the time and money to pay for the "expensive" version, and the long run will be cheaper. The shortcut feels free in the moment and isn't free at any other moment.
There's also a corporate reflex that makes the trap worse, which is throwing more engineers at the problem. This is a well-known anti-pattern disguised as a solution. When leadership responds to a slow delivery by adding headcount, what they're actually saying is that the architecture is fine and the people are the bottleneck, and the engineers know that isn't true. You can staff a tangled system with a hundred engineers and you'll get a hundred engineers the whole day in meetings stepping on each other. The mark of a mediocre manager is reaching for headcount. The mark of a leader is reaching for the interface, which means fixing the contract, the boundaries, and the data flow, not adding more people into a system that's already leaking.

Anatomy of a Module-to-Module Request

Every request from one module to another is a small contract, and the contract has three parts. If any part is missing, the receiving module either has to guess (which means it's no longer independent) or has to fetch data from somewhere it shouldn't know about (which means the caller has already broken the discipline).

The first part is service identity, which identifies the two modules involved in the conversation. The caller is named and the receiver is named, and ideally the receiver is named with its version, for example payments-v2, so the system knows exactly which service is being asked. Service identity is the equivalent of knowing which company you are calling and which department inside that company is picking up the phone.

The second part is transaction identity, which is a unique ID for the specific request, for example txn-7a3f9b. Transaction identity is what guarantees that if the network fails and the caller retries, the receiver can tell it's the same operation and not a new one. This is what stops a customer from being charged twice when a payment request times out and the system tries again. It's the difference between a system that behaves correctly under failure and one that quietly corrupts data.

The third part is subject data, which is the IDs relevant to the work being done. A user_id or an order_id is typical. The crucial point is that these IDs are carried in the transaction, not used to make routing decisions inside the receiver. The receiver doesn't ask "who's this user and what tier are they?" The receiver does the job it was asked to do with the data it was given. If the job requires knowing the user tier, that fact has to be in the payload, decided by the caller, and the receiver treats it as input.

Why the Payload Must Be Self-Contained

For a module to be truly autonomous, it mustn't depend on any other module during its internal processing. This is the part an engineering team gets wrong first, because it requires the most discipline when the temptation to cheat is highest. An engineer on a deadline doesn't see this pattern as "cheating." It looks like a common practice.

Before sending a request, the caller gathers all the data required for the transaction and packages it into the payload. If module B needs data from module C to do a job for module A, the flow is this: A calls C, gathers the data, packages it into the payload, and then calls B. From B's perspective, module C doesn't exist. Using only the payload and its own database, B processes the request. This sounds like extra work for A, and at the moment it's, but the whole point of paying it now is that the work isn't paid again. When module A changes, modules B and C don't have to change with it, because A gathered the data B needed from C, packaged it into a payload, and handed B a self-contained request. In a tangled system, every change to A forces changes in B and C, and the cost compounds with every modification. In a modular system, the cost of change stays inside A, and the rest of the system doesn't care.

To see why the extra work is justified, consider a worked example. Consider four modules, A, B, C, and D. For transaction X, A needs data that only C can provide, so A calls C first. A calls C, gets what it needs, builds a payload, and calls B. Using only the payload and its own database, B processes the request and returns a response. Three conditions make this allowed. The data pulled from C has a specific purpose, so it isn't convenience. The data isn't being passed to make a decision in B, only to satisfy a processing requirement. B doesn't use the data on behalf of A. The data serves B's own processing, which happens to be the job A is paying for.

What's forbidden is the pattern where A sends a username to B just so B can pass it to C, which is the pattern that sneaks in when engineers are chasing the local minimum. A field is a requirement only when it's immediately processed by the receiver. Anything else is a forwarding violation, and forwarding violations are how modular systems decay from the inside. A field forwarded once is a debug session next year. A field forwarded across a system is a rewrite in five years.

Ownership, Contracts, and the Cost of Borrowing Data

A module owns its internal logic, full stop. The database schema, the queues, the libraries, the language it's written in, the way it caches its results, none of that is visible or relevant to the rest of the system. The interface is the contract, and the contract is the only thing the rest of the system is allowed to know about.

This is the shield. As long as the interface remains stable, the module can refactor its internals on a Friday afternoon and no one in the rest of the system notices. If a module decides to split its database, change its primary key format, swap its queue provider, or rewrite its business logic from scratch, the other modules don't need to change a single line of code. The whole point of paying the cost of a contract is to buy that freedom, and any rule that limits that freedom is a tax on the team's future.

The mirror image is the responsibility of the caller. If module A "borrows" domain data from module C, which means A reads C's database directly or pulls a field C didn't promise to expose, and then C changes its internal structure and A crashes, the fault is entirely A's. C's allowed to change. C's encouraged to change because change is what keeps the system from ossifying. A's crash is a punishment for breaking the boundary, not an unfortunate accident, and the team responsible for A should be told so in plain terms.

There's a related question about how strictly to validate the contract, and the right answer is "as strictly as possible at the cheapest moment." Full schema validation is done at deployment, using a tool that checks the contract between modules before they ship, and one common tool for this is Pact. A well-disciplined practice is to do this check once, on the way in, and trust the result. At runtime, only the request envelope and the coordination mode (synchronous or asynchronous) are validated, because checking the whole contract on every request is wasted work. The contract was already verified. Re-verifying it on every call doesn't add safety but latency.

A note on versioning, because the instinct is to lean on it. Versioning is itself a moving part, and every moving part is a place where the cost of change goes up and the risk of breakage goes up with it. In an ideal world, a well-designed interface never needs to change, because the function it describes is stable. Adding a new requirement to an existing interface is the wrong move. The right move is to expose a new interface for the new requirement. That said, contracts do change eventually. Business needs evolution, and the system has to evolve with them. The good practice here is to make contract changes expensive and rare, not cheap and frequent, and versioning can too easily become the latter. A team that treats versioning as a license to change contracts casually is a team that has stopped respecting the discipline.

Errors Travel in Codes, Not in Strings

Errors have a source, and the source is the only module allowed to know what the error means in technical terms. The module where a failure originates returns a machine-readable code. For problems inside the module itself, it reports a 5xx code: the database is down, the service crashed, an integration timed out. For problems caused by the caller, it returns a 4xx code: the request was malformed, a required value was missing, the caller isn't authorized to ask for this. Other modules propagate the code up the chain without translating it, because translating it would require them to know the meaning, and that would couple them to the failing module's internals.

On-Demand Reporting as an Economic Discipline

In a modular system, relationships between modules are strictly demand-driven. Every interaction is explicit and justified by actual need. If a dashboard, an analytics tool, or an aggregation module wants data, it has to demand it from the service providers. If the demand doesn't exist, the work to prepare the data is waste, and the waste is paid by the module that shouldn't have been producing it in the first place.

The temptation to push data is the same temptation as the convenience data in a payload, and it has the same economic shape. An engineer thinks "we have this data anyway, let's just send it to the warehouse, it might be useful." And it might be useful, and the report that consumes it might be read by a CEO, and the report might justify a real decision. None of that justifies the cost of producing the data on the off chance. The cost is paid by the producing module on every transaction, for as long as the system runs, for a benefit that may never materialize. If the report is worth building, the report is worth asking for. If the report isn't worth asking for, the report isn't worth the cost of feeding.

This is the same logic that justifies the existence of every service in the first place. User data justifies the user module's existence. The payment module exists because something needs payment processing. The reporting module processes aggregated data because something demands it, and each one of those demands has to come from somewhere real. A demand that exists only in the head of the engineer who "thought it would be useful" isn't a demand. Treating it as one is how modular systems bloat into data pipelines that pay for themselves in maintenance and pay for nothing else.

What Leaders Actually Have to Defend

Leaders who understand software architecture have to accept that the Autonomous Cooperation Protocol beats headcount, every time. The protocol is what determines whether the team can move fast or whether the team will drown in coordination overhead, and headcount is irrelevant to the protocol. Adding engineers to a tangled system doesn't untangle it. Adding engineers to a modular system without maintaining the discipline doesn't stay modular for long. More people means more pressure, more pressure means more convenience data, and more convenience data means the system becomes coupled in ways no one is tracking.

The job of a leader in this context is to protect the constraints. A request to ship faster triggers a question about what the constraint is, not a removal of it. When a request comes in to add a field "just in case," the discipline calls for refusing and explaining the cost. For a request to throw more engineers at a slow team, ask whether the team is slow because of the team or because of the architecture. The answer is almost always the architecture, and the architecture isn't fixed by hiring. These aren't popular answers, and they require a leader who is willing to be unpopular in the short term so the company isn't slow and unprofitable in the long term. That's the difference between a manager who focuses on this quarter and a leader who focuses on the next ten years.

References

Brooks, F. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Brooks' Law describes how adding manpower to a late software project makes it later, which is the underpinning of the "throwing more engineers at the problem" anti-pattern discussed in this article. Wikipedia
Pact Foundation. Pact Contract Testing Framework. Code-first tool for testing HTTP and message integrations using consumer-driven contract tests.
Fielding, R., Ed. (2022). RFC 9110: HTTP Semantics. Internet Engineering Task Force. Defines the 4xx (Client Error) and 5xx (Server Error) HTTP status code conventions referenced in the "Errors Travel in Codes" section. MDN Web Docs

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.