Decisions That Look Good Today and Hurt the Company Tomorrow

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

Footnotes

1. 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 ↩

2. 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 ↩