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

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

1. 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
2. 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
3. Fowler, Martin. "Conway's Law." martinfowler.com, October 2022. https://martinfowler.com/bliki/ConwaysLaw.html
4. 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/
5. "Story Point." Wikipedia. https://en.wikipedia.org/wiki/Story_point