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

A CEO signed off on a delivery date. Two weeks for a feature the team knew would take six. They didn’t say no, because the cost of pushing back in the moment felt higher than the cost of fixing it later. The feature shipped on time, and the structural damage got buried under the next sprint, invisible to the one person whose approval mattered most. That’s the risk almost no one talks about: a non-technical CEO making decisions on a picture of the technology that is missing the parts that matter most. The structural health of the software underneath the product is invisible to him. The people around him have incentives to keep it that way. The gap between what the software appears to be doing and what it’s actually becoming is where the company bleeds money.

This article is about that gap, and about why the CEO’s relationship to technology, as a concept he either understands or doesn’t, ends up being the single most important variable in the company’s structural cost. The argument is that the cost of not understanding the technology you’re building on is paid in a currency the CEO can’t see, and the company pays it whether the CEO looks or not.

1. The Asymmetry of Knowledge

There’s a familiar pattern in the early stages of a startup. A founder with a strong business background goes looking for a “technical co-founder.” He’s good at sales, good at strategy, good at the P&L, and comfortable talking to investors. The idea is that the business side and the technical side are two equal halves of the company, and the founder needs the missing half to complete the picture. The exchange is simple: the business person gives up half the equity, and the technical person gives up half the equity, and together they form a complete team.

The economic logic of this exchange is broken, and the reason is that the two halves are not equally hard to acquire.

Learning to think like an engineer takes years. It means developing the ability to manage complex, multi-variable systems in your head, to reason about consequences that don’t show up for months, to hold a mental model of a software architecture that has hundreds of interacting pieces. It’s a specific kind of disciplined logic, and it’s not something an adult can pick up casually, no matter how smart he is. The cost of developing an engineering brain, measured in time, effort, and the right kind of life experience, is very high.

Learning to think like a business leader is comparatively faster. Strategy, sales, P&L, and investor relations are skills a smart technical person can pick up with focused effort over a few years. They are not trivial. But they are not the multi-decade, identity-shaping work that engineering requires. A technical founder who reads the right books, sits in the right meetings, and makes the right mistakes can become competent at running a business. The reverse is much harder.

So when a non-technical founder offers 50% of the equity to “buy” a technical co-founder, examine the economic logic. I’m trading half my company for a skill set I could have acquired myself. It took the other person far more effort to acquire theirs. It’s buying something expensive with something cheap, and the asymmetry is what makes the deal bad for the buyer, even though it looks like a fair split on paper.

The result is a company that starts with a built-in imbalance. Half the equity goes to the person who contributed the harder skill. The other half goes to the person who contributed the easier one. From that point on, every decision about technology flows through a CEO who doesn’t have the background to evaluate it, and the imbalance is permanent.

2. Blind Commitment

There’s a second, more dangerous form of asymmetry, and it has nothing to do with equity splits. It has to do with what the CEO can and can’t see inside the product he owns.

A non-technical CEO operates in a state of perceived safety. He sees the product working, sees customers using it, sees revenue coming in, sees the team shipping features on schedule. From his vantage point, the technology looks fine. Reports confirm the sprint is on track and the deployment succeeded. The team says the feature is done. Everything looks like a healthy company, and the CEO makes decisions based on that picture.

The problem is that the picture shows what got done, not what the software is becoming underneath. A status report tells him the feature shipped but hides three things the CEO actually needs. Whether the system is getting easier or harder to change. Whether the next feature will take a week or a month. Whether the team is shipping fast because the code is healthy or because they’re working weekends to keep the brittle mess from falling apart. The state of the software is a structural signal, and the CEO is not seeing it, because nobody is reporting it in a language he can read.

This follows the same psychological pattern as an employee afraid to leave a job. He feels safe there and ignores whether the company is doing well or badly. He ignores whether his boss wants to get rid of him next quarter. The safety is real to him, and the risk is invisible. He’s not lying to himself, he just doesn’t have the information that would make the risk visible. The CEO version follows the same pattern. He thinks: my software is working, so the company is fine. But he lacks the technical background to tell the difference between “working” and “working in a way that’s costing us more every month.”

The blind commitment shows up when the CEO agrees to a delivery date. He commits to a customer, or to the board, or to himself, that a feature will ship in two weeks. The team, knowing the CEO is watching and not wanting to be the one who says no, agrees. They pull weekends and cut corners. They take shortcuts they know they’ll pay for later, because the cost of saying no in the moment feels higher than the cost of doing it badly. The system grows more interdependent. That’s a polite word for an architecture where every change in one part requires changes in several others. The cost of the next change keeps growing exponentially. The CEO never sees this, because the feature did ship on time. The commitment is met, and the structural cost stays invisible to him.

That commitment is not a one-time event. Every time the CEO pushes for speed without seeing the structural cost, the team borrows against future capacity to pay for current delivery. That loan accrues three forms of interest: a system that gets harder to change, a team that gets more tired, and a margin that gets thinner. The CEO never signed a loan agreement, but the loan is on the books, and the interest is compounding.

A CEO with engineering background, by contrast, doesn’t just “do tech.” He understands the system state, which is a different activity from managing the system, and the difference shows up in the quality of his decisions. He can look at the architecture and tell whether the next feature will be cheap or expensive, whether the team’s estimate is honest or padded, and whether the system is healthy or rotting. He can see the loan before it’s signed, and he can decide not to sign it, and the cost of that visibility is exactly the structural cost the business-only CEO is paying without knowing.

Over time, the engineering CEO outperforms the business-only CEO, not because he’s smarter, but because his decisions are made on more information. The advantage comes down to visibility: one leader can see the structural state of the system, and the other cannot.

There’s a pattern here that matters more than most CEOs recognize. A leader who sees the structural cost of a decision but reports only the comfortable picture is running the company on incomplete information. The cost doesn’t disappear because the truth is uncomfortable. It shifts downstream and compounds.

The right thing to do, when you know the system is fragile, is to say so, even when the truth is uncomfortable, even when saying it means admitting that the company is in worse shape than the last report suggested. Javier Milei, the Argentine president at the moment of writing this article, has a useful principle here. He says he will do anything to improve people’s lives, as long as the decisions are moral. So not at any cost, and that policies will converge to efficiency naturally by making them moral. The same applies to a company. The right move is the move that’s actually true, not the move that makes the next quarter look good. Preferring uncomfortable truths over comfortable lies is not a personality trait, it’s a job requirement, and the CEO who can’t do it pays the cost in a company that drifts further from reality every quarter.

3. Not Every Company Needs a Technical CEO

A company that produces technology operates under a different constraint than one that uses it as a tool. The technology-producer has to either understand the technology himself, or have a structural way to see it, and the rest of this article is about the cost of that choice.

Consider a CEO who runs a SaaS company, or a restaurant chain, or a marketing agency, or any business where technology is a tool the company uses but doesn’t produce. His problem is not understanding how the software works. His problem is hiring people who understand it and trusting their judgment. He doesn’t need to know what a database is. He needs to know whether the people he hired are telling him the truth, and he needs to know it in business terms, not in technical terms.

For a company that builds and sells software, the CEO faces a different challenge. He can either learn the technology himself, or he can hire people he trusts fully to tell him what’s going on, or he can have metrics that translate the technical state into the business language he already speaks. Each option has a cost. The first takes years. The second depends on trust and trustworthiness, which is fragile and breaks under pressure. The third is the only one that scales, but it requires the CEO to learn just enough about the metrics to read them and ask the right questions.

The same logic applies in any technical field. Consider a CEO of a pharmaceutical company who knows nothing about pharmacology. He will repeat the words “molecule” and “efficacy” and “trial.” A non-technical CEO does the same with “API” and “deployment” and “tech debt.” In both cases, the parrot-speak is the symptom. The disease is that the CEO is making decisions on a language he doesn’t speak, and the people who do speak it have no reason to translate it carefully.

A better goal is to make the CEO someone who knows what he’s talking about in his own domain, and who has the structural setup to hear the truth in the domains he doesn’t. The CEO can stay out of pharmacology. He can still know that his own words mean what he thinks they mean. The same goes for his team’s words. That confidence comes from the setup, not from the expertise.

4. The Risk on the Other Side

A risk exists in the other direction, worth naming, because the goal here is to be honest about both sides.

A technical CEO can over-focus on the technology and treat a mature company like a young one. He can spend months refactoring a system that was working fine. Maybe the code looked bad to him. Maybe he didn’t like the language it was written in. He chases architectural elegance for its own sake, mistakes cleanup for building, and treats the technology as the ultimate goal. He forgets that the technology exists to serve a business, and that business exists to serve customers who pay for value, not code beauty.

This is the same problem in reverse, and the answer is the same: a clear chain from what the customer values to what the company does to what the engineers build. The technical CEO has to ask, for every technical decision, why this change, why now, and what does it do for the customer or the margin. If the answer is “the code looks better”, the work is unjustified. If the answer is “this reduces the cost of the next feature and increases the profit margin”, the work is justified.

This is part of the business education a technical CEO needs to acquire, and it’s the easier side of the asymmetry. Learning to value the business over the technology is faster than learning to value the technology over the business, because the business side is more legible to non-technical advisors, customers, and investors. The technical CEO can learn it by being in the room with the right people and paying attention.

The Austrian economist Ludwig von Mises, writing in the early twentieth century, described human action as always being about what a person values most at a given moment. The decision to refactor a system, or not to, is the same kind of decision as any other economic decision, and the trade is honest only if one can see both sides. Limited vision on either side produces undervaluation on the other. The goal is to see both, and the technical CEO is closer to seeing both because the technical side is the harder side to acquire.

5. Recovery Process

Realizing your company has been operating under a heavy Sync Tax triggers a natural panic. The Sync Tax is the extra effort every change has to pay to keep the system’s parts aligned. A Sync Tax of 6x means every dollar of direct work comes with six dollars of structural overhead. Panic leads to random cuts, and random cuts make the structural problem worse.

The right reaction is closer to what Argentina’s government did in 2023 when it took over an economy with decades of accumulated dysfunction. The word for it is “shock therapy”, but the name is misleading, because nothing about it is instant. It’s a sequenced process, and the sequence requires deep understanding of the specific business being fixed. The patterns are more or less the same across companies, but what to do, in what order, and how fast, is always unique to the organization.

The first move is to stop adding weight to a structure that’s already failing. New feature development gets paused, not forever, but long enough to do the work of separating the parts of the system that are pulling each other down. You can’t repair a foundation while the roof is still being built on top of it, and you can’t untangle a software architecture while new features are still being woven into the mess.

The second move is to identify the part of the system that’s causing the most damage per dollar spent, and fix that first. The best analogy is credit card debt. If you have five credit cards with different interest rates, you don’t pay them off in random order. You pay off the one with the highest interest rate first, because that’s the one costing you the most per month, and every month you leave it unpaid is a month of money you’re never getting back. In a software system, the highest-interest module is the one where every change causes the most regressions. It’s where the team is most afraid to touch anything. It’s where the cost of the next feature is highest relative to the work being done. Find that module, decouple it from the rest of the system, and the next feature that touches it will be cheaper than the last one. That’s the first interest payment.

The third move is sequencing. The pattern of decoupling is universal, but the order of operations is not. A payment module might be the worst interest rate in a SaaS company, and a checkout flow might be the worst interest rate in an e-commerce company. A company that sells to enterprises might need to modularize its authentication system first. Every new customer integration touches it. A company that sells to consumers might need to modularize its notification system instead. That’s where the regressions are clustered. The general principle is the same. The specific order is determined by the specific business.

The fourth move is the one most CEOs skip, because it’s the one that doesn’t show up in the metrics they care about. It means keeping up the maintenance work that prevents the next accumulation, because complexity has a higher chance of coming back when the team is under pressure to ship. Recovery only sticks when the maintenance work is built into the regular cadence, the same way a person who has paid off credit card debt builds the habit of not running the balance back up.

6. Metrics as Proxy Education

To operate the recovery process above, a non-technical CEO needs to read the numbers, and that means translating the technical state into a business language he already speaks. The metrics described in this article are the bridge between what the engineers see and what the CEO needs to act on.

Three of them matter, and they map directly to the three questions a CEO actually needs to answer about the software.

The first is a measure of how tangled the different parts of the code are with each other, called Connascence Degree. The way to think about it from a business perspective is as a measure of structural fragility. If the degree is high, the system is brittle, and the next change is more likely to break something that was working. The financial implication is that the cost of every feature is higher, and the risk of every release is higher. The CEO doesn’t need to understand the math. He only needs to know that a high number is bad and a low number is good. He should ask for the number. If he doesn’t ask for it, the team has no reason to track it.

The second is the Sync Tax Multiplier itself, which is the ratio between the total cost of a feature and the direct work that went into it. A multiplier of 1x means every dollar spent on the feature produced a dollar of value. A multiplier of 4x means every dollar of direct work came with three dollars of structural overhead, paid in coordination, rework, debugging, and the slow erosion of the team’s ability to ship the next thing. The CEO doesn’t need to compute the multiplier; watching it over time is the job, and reacting when it climbs matters too. The multiplier rising is the most direct signal that the company pays more for every unit of output. That’s a margin problem no investor will tolerate forever.

The third is the regression rate, which is how often a change to the system breaks something that was working before. A high regression rate is a direct tax on the team’s morale, because it means the team is spending more time fixing what they already built, and less time building what the customer asked for. From a business perspective, the regression rate is operational risk. The CEO can read it the same way he reads any operational metric. A rising number is a warning sign. Ignoring it is how companies end up making emergency announcements at 3am.

These three metrics, tracked over time and reported honestly, are the cognitive bridge between the engineering department and the executive office. They translate the gut feeling of a senior engineer into the financial language the CEO already uses. They equip the CEO to read and act on the report without needing to become an engineer.

The metrics described above are useful, but they haven’t been proved yet in the rigorous sense. They’re reasonable proxies for the underlying cost, and they correlate with the things a good engineer would notice by intuition, but they’re not the same as a controlled study. So the metrics are a supplement to engineering judgment, not a replacement. A CEO who has access to an honest engineer with twenty years of experience should trust that engineer’s gut, even when the metrics don’t fully capture what the engineer is seeing. The two together are stronger than either one alone.

This is true of every profession, by the way. Doctors have intuition the lab tests don’t fully capture, lawyers have intuition the case law doesn’t fully capture, and engineers have intuition the metrics don’t fully capture. The metrics give the CEO permission to see the cost, and the intuition gives the CEO permission to act on it. Neither one is sufficient on its own, and the company that uses both is hard to argue with.

Closing

The pattern is that the CEO is the single point of failure for the company’s technical decisions, not because the CEO builds everything, but because the CEO sets the conditions under which the truth can reach the decision. A CEO who can’t see the structural cost will commit to things he doesn’t understand, and the company will pay the difference between what was committed and what was actually possible. A CEO who can see the structural cost will make different decisions. He gains that vision through technical training, blind trust in a team that has earned it, or metrics that translate the system state into business language. The company will be the one paying the lower cost.

The recovery process is the same in every company that has accumulated too much complexity: stop adding weight, identify the highest-interest module, decouple it, and keep doing the maintenance work. The metrics give the CEO permission to see the process, and the intuition of a good engineer gives the CEO permission to lead it. Neither one is enough alone. Both together are what a technology company needs from its CEO. The cost of not having both is paid in compounding technical debt and shrinking margins, and that cost lasts as long as the imbalance lasts.

References

1. Milei, J. (2025). “Milei: El continente esta despertando, rugiendo y gritando ‘Viva la libertad, carajo!’” Argentina.gob.ar, April 2025.

   • Palabras del presidente de la Nacion en la Argentina Week 2026

2. Mises, L. von (1949). Human Action: A Treatise on Economics. Ludwig von Mises Institute.

   • Online edition

3. “Economic reforms of Javier Milei.” Wikipedia.

   • Economic reforms of Javier Milei

4. “Connascence.” Wikipedia.

   • Connascence

5. “QA Metrics: The Most Important KPIs for Quality Assurance Teams.” TestBooster, 2025.

   • QA Metrics

6. Page-Jones, M. (1992). “Comparing techniques by means of encapsulation and connascence.” Communications of the ACM, 35(9).

   • Connascence.io - About