You’re sitting in a conference room, trying to explain why the “simple” login feature will take three weeks instead of three days. The VP of Engineering—who hasn’t written code since college—cuts you off mid-sentence.
“Look, I don’t need to understand the technical details. Our competitor shipped something similar last month. Just make it work.”
You try again. “But their system probably doesn’t handle enterprise SSO, multi-factor authentication, or—”
“Those are implementation details. The business need is clear. How hard can it be to check a username and password?”
You leave the meeting knowing you’ll spend the next month building something fragile, then the next six months fixing it. But the VP will get credit for “driving execution” while you’ll be blamed for the inevitable production issues.
This scene plays out thousands of times daily across the software industry. We’ve created the only professional field where practitioners are routinely overruled by people who fundamentally don’t understand the craft.
Imagine this conversation in a hospital:
“Doctor, I don’t need to understand the medical details. Just remove the tumor. How hard can it be?”
Or in a courtroom:
“I don’t need to understand the legal technicalities. Just win the case. How complicated can contract law be?”
These scenarios sound absurd because they are. Yet they perfectly describe how the software industry operates every day.
But there’s a deeper issue at play—one that explains why this dysfunction persists despite its obvious absurdity. Software work is fundamentally invisible to those who don’t do it.
Imagine you manage a warehouse, but there’s a catch: you can never enter it. Every morning, your workers drink a shrinking potion that lets them slip through a tiny door. They spend their day inside, then grow back to normal size when they emerge. You can see what they bring out—packages delivered, orders fulfilled—but you can never see how they work inside.
This is exactly what software management looks like.
When developers “shrink down” and enter the codebase, they see things that are invisible to everyone else:
The Chaos: Piles of code stacked haphazardly, with critical functions buried under layers of deprecated features. Important data models hidden behind walls of technical debt. Security code scattered in random corners where no one thinks to look.
The Narrow Passages: Convoluted dependencies that force you to crawl through fifteen different modules just to change a simple business rule. Spaghetti code so tangled that touching one piece breaks something seemingly unrelated across the warehouse.
The Hoarding: Thousands of lines of dead code that no one dares remove because no one remembers why it’s there. Duplicated functionality everywhere because it’s easier to build new than to find and reuse existing code.
The Navigation System Only Insiders Know: Tribal knowledge about which functions are safe to modify, which databases are reliable, which APIs will actually work. Senior developers who’ve mapped the maze in their heads, while new hires get lost for weeks.
The Infrastructure Held Together with Hope: Load-bearing systems that everyone knows are broken but no one wants to touch. Critical dependencies maintained by developers who left the company three years ago.
When experienced developers talk about “code smell” or “architectural debt,” they’re describing the state of this invisible warehouse. But managers, standing outside, can only judge by what comes out: features delivered on time.
From outside the warehouse, everything looks fine:
“The team shipped the authentication feature. Great!”
What they can’t see: The developers had to navigate through a maze of legacy code, copy-paste functionality from three different systems, and create a fragile solution that will break the moment someone needs to add two-factor authentication.
“The mobile app is getting good reviews. Excellent work!”
What they can’t see: The codebase is such a mess that adding new features requires changing hundreds of files. The team is one junior developer away from complete chaos.
“Our deployments are automated. We’re very modern!”
What they can’t see: The deployment scripts are held together with duct tape, commented-out code, and prayers. One configuration change in the wrong place brings down the entire system.
This isn’t just about software—it’s about human psychology. We can only value what we can perceive. A manager can walk through a physical warehouse and instantly see:
But code? Code is invisible. Managers can see the output—working software—but not the process, the structure, or the sustainability of how it’s built.
Because managers can’t see inside the warehouse, they measure what they can observe from outside:
These metrics tell you nothing about the internal state. A warehouse can ship packages on time while slowly collapsing from the inside. By the time external metrics show problems, the internal structure may be beyond repair.
Here’s where it gets insidious: a chaotic warehouse can sometimes appear more productive in the short term.
The Messy Warehouse:
The Organized Warehouse:
The manager, unable to see inside, naturally concludes that chaos is more efficient than order.
Here’s the most telling point: No manager would ever ignore a real warehouse that looked like a shambles. Why? Because there’s always a chance a stakeholder might do a walkthrough.
Imagine if a board member, major client, or potential investor announced they were visiting your facility tomorrow. Would any manager say “eh, the warehouse is a disaster, but packages still come out, so it’s fine”?
Of course not. They’d be in there at midnight reorganizing shelves, clearing pathways, labeling everything, and making sure every surface was spotless. Not because it affects productivity (it might even hurt short-term productivity), but because appearances matter when people are watching.
But code? No stakeholder will ever look at your codebase. The CEO will never ask to see your authentication module. Investors don’t audit your technical debt. Board members don’t review your architectural decisions.
This creates a perverse incentive: You can let your digital warehouse be an absolute disaster because no one important will ever see it.
A retail manager keeps the floor clean not because it improves sales (though it might), but because the district manager might visit. A factory supervisor maintains organized production lines not because it’s strictly necessary, but because corporate executives tour the facility.
Software managers feel no such pressure. Their “warehouses” could be complete disasters—spaghetti code, security vulnerabilities, technical debt everywhere—and as long as features ship, no one will ever know.
Physical workspaces reflect on professional reputation in a way that code never does. A doctor with a messy clinic, a lawyer with a disorganized office, a restaurant with a chaotic kitchen—these things damage professional standing because they’re visible to clients, colleagues, and superiors.
But a CTO can run an engineering organization with terrible code quality, architectural disasters, and systemic technical debt, and as long as the company hits its quarterly targets, their reputation is intact. They might even be praised as “execution-focused” and “business-oriented.”
The disconnect is staggering: We judge leaders in every other field by the quality of what they create, but in software, we judge them solely by what they deliver, regardless of how they deliver it.
Compare software to other fields where the work itself might be invisible to outsiders, but professional oversight creates accountability:
A patient can’t see what happens during surgery, but the medical profession has created multiple layers of visibility:
Peer Review: Other surgeons observe procedures, review decisions, and can challenge approaches. Medical conferences are filled with case studies where practitioners scrutinize each other’s work.
Chart Reviews: Every decision is documented and can be audited by other medical professionals. Poor documentation or questionable decisions are visible to peers.
Mortality and Morbidity Conferences: When things go wrong, the entire medical team reviews what happened. The surgeon must defend their decisions to colleagues who understand the work.
Hospital Privileges: Surgeons must demonstrate competence to other surgeons to operate at a facility. Technical skill is evaluated by technical peers.
Licensing and Continuing Education: Regular assessment by professional boards ensures practitioners maintain standards.
Professional Consequences: A surgeon who consistently makes poor decisions faces peer pressure, license review, and potential removal from practice.
Most clients can’t evaluate legal strategy, but the legal profession has created oversight mechanisms:
Opposing Counsel: Every legal argument is challenged by another lawyer who can spot poor reasoning or sloppy preparation.
Judicial Review: Judges (who are experienced lawyers) evaluate the quality of legal work. Poor preparation or weak arguments are immediately visible to the court.
Bar Associations: Professional organizations set standards and can discipline lawyers for inadequate representation.
Case Law and Precedent: Legal decisions are published and scrutinized by the entire profession. Poor legal work becomes visible to peers.
Continuing Legal Education: Regular requirements to maintain professional competence.
Professional Reputation: In the legal community, word spreads quickly about lawyers who do poor work. It affects their ability to get cases and work with other attorneys.
Now look at software:
No Peer Review: Code reviews exist in some companies, but there’s no profession-wide standard. Many developers never have their code reviewed by anyone competent.
No Professional Documentation: Architectural decisions are rarely documented in ways that other professionals could evaluate.
No Failure Analysis: When systems fail, there’s rarely any professional review. Companies might do postmortems internally, but there’s no profession-wide learning.
No Professional Licensing: Anyone can call themselves a software engineer. There’s no gatekeeping mechanism to ensure competence.
No Continuing Education Requirements: Developers can go decades without learning new practices or being evaluated by peers.
No Professional Consequences: A developer who writes terrible code faces no professional sanctions. They can move to another company and continue the same practices.
In medicine and law, even when the work is invisible to clients, it’s visible to professional peers who have the expertise to evaluate it. This creates powerful incentives for quality:
Professional Reputation: Your standing among people who understand your work matters for career advancement.
Peer Pressure: Other professionals will challenge poor practices because they reflect on the entire profession.
Knowledge Sharing: Good practices spread through professional networks because practitioners can recognize and discuss quality work.
Standard Setting: Professional organizations establish and enforce quality standards.
Software has none of this. There’s no professional community that evaluates code quality, no peer pressure for excellence, no professional consequences for poor work. A developer’s reputation is based on their ability to ship features and navigate corporate politics, not their ability to write quality code.
This lack of professional visibility and accountability explains many of software’s problems:
No Standard of Care: Medicine has established protocols for common procedures. Law has standard practices for common legal problems. Software has no equivalent—every developer reinvents solutions.
No Professional Growth: Without peer feedback and professional standards, developers can plateau early and never improve their craft.
No Collective Learning: Medical journals publish case studies of failures. Legal journals analyze important cases. Software has no equivalent mechanism for profession-wide learning from failures.
No Quality Assurance: Other professions have mechanisms to identify and remediate poor practitioners. Software has no such quality control.
No Professional Identity: Doctors see themselves as part of a medical profession with shared standards and ethics. Most software developers see themselves as employees, not as practitioners of a professional craft.
The result is what we see today: an industry where technical excellence is neither recognized nor rewarded, where poor practices persist and spread, and where there’s no mechanism for professional development or quality assurance.
Now consider what it’s like to be a developer in this environment. Every day, you shrink down and enter a warehouse that’s falling apart. You navigate through chaos, work around broken systems, and try to build something stable on a foundation of quicksand. Then you emerge and are judged by people who have no idea what you just endured.
Working in a poorly architected codebase isn’t just technically challenging—it’s psychologically exhausting. Every change you make requires holding dozens of interconnections in your head:
“If I modify this function, will it break the email system that depends on it? What about the reporting module that calls it indirectly? Did someone hard-code assumptions about this return value somewhere else in the codebase?”
In a well-architected system, you can reason about changes locally. In a chaotic system, every modification is a high-stakes puzzle where the wrong move can cascade into system-wide failures. The cognitive load is crushing.
Compare this to other professions: A surgeon operates in a sterile, organized environment with predictable procedures and reliable tools. A lawyer works with established precedents and clear procedural rules. A developer works in digital chaos where anything might be connected to anything else in ways that nobody documented or remembers.
You become an expert in navigating the chaos, but this expertise is invisible and unvalued:
You know that the user service will timeout under load, but you can’t get time to fix it.
You know that the authentication system is held together with deprecated libraries, but the business wants new features, not security updates.
You know that the database schema is poorly designed and will cause performance problems, but refactoring it would take weeks and deliver no visible features.
You’re like a structural engineer who can see that the building’s foundation is cracking, but everyone keeps asking you to add more floors because the building “seems fine” from the outside.
Perhaps most damaging is being forced to build things you know are wrong. You’re a craftsperson who cares about quality, but the system rewards cutting corners:
You want to write tests, but there’s no time in the sprint.
You want to document your code, but documentation doesn’t count toward your performance review.
You want to refactor the brittle components, but you’re told to “just add the feature on top.”
You want to discuss architectural concerns, but you’re labeled as “too technical” or “not business-focused.”
This creates a form of moral injury—the psychological damage that comes from being forced to act against your professional values. You know how to build software well, but you’re systematically prevented from doing so.
When you try to explain technical problems, you sound like you’re making excuses:
“This will create technical debt” sounds like “I don’t want to do the work.”
“This approach isn’t scalable” sounds like “I’m overthinking it.”
“This will cause security vulnerabilities” sounds like “I’m being paranoid.”
You’re like a doctor trying to explain disease to people who don’t believe in germs. The problems you see are real and serious, but they’re invisible to everyone else. This isolation is psychologically devastating—you’re surrounded by people who think you’re either incompetent or difficult when you’re actually the only one who understands the true state of the system.
Living with poorly built systems creates constant anxiety. You know the system is fragile, but you don’t know when or how it will break:
Will the deployment script fail because someone changed a configuration file?
Will the database crash because the poorly optimized query finally hit a large dataset?
Will the integration break because a third-party API changed their response format and we never implemented proper error handling?
You’re constantly waiting for the other shoe to drop, knowing that when it does, you’ll be blamed for not preventing it—even though you were never given the resources or authority to build it properly in the first place.
The worst part is being told the problems don’t exist or don’t matter:
“The system is working fine” (because the failures haven’t become visible yet).
“You’re overthinking it” (because the complexity is invisible to management).
“Our velocity is great” (because we’re measuring story points, not maintainability).
“Just ship it” (because technical debt is someone else’s problem).
You start to question your own judgment. Maybe you are overthinking it. Maybe this is just how software works. Maybe you’re the problem for caring about code quality when everyone else seems fine with the chaos.
This psychological burden leads to a predictable pattern:
Stage 1: Frustration - You try to advocate for better practices and get shot down.
Stage 2: Adaptation - You stop fighting and just do what’s asked, even though you know it’s wrong.
Stage 3: Cynicism - You stop caring about code quality because caring hurts too much.
Stage 4: Escape - You leave for a company that might value engineering excellence.
Stage 5: Repetition - You discover the new company has the same problems.
Many developers cycle through this pattern multiple times before either finding one of the rare excellent companies or leaving the industry entirely.
The psychological toll compounds over time:
You lose confidence in your ability to estimate work because chaotic systems are inherently unpredictable.
You lose trust in your colleagues because you’ve been burned by poorly understood dependencies.
You lose enthusiasm for learning because new technologies just become more complexity layered on top of existing chaos.
You lose faith in the profession because there’s no community of practice to support quality standards.
The software industry has a hidden mental health crisis. Developers are burning out not because the work is technically difficult, but because they’re forced to work in psychologically toxic environments that undermine their professional identity and values.
We measure developer productivity, but we don’t measure developer wellbeing. We track deployment frequency, but we don’t track how many developers are having anxiety attacks about system reliability. We celebrate rapid feature delivery, but we don’t count the cost in human suffering.
The invisibility problem doesn’t just affect code quality—it affects the mental health of everyone forced to work in these invisible disaster zones while being judged by people who can’t see the chaos they’re navigating every single day.
The consequences of software’s invisibility aren’t theoretical. In the past 12 months, we’ve witnessed spectacular failures that, while we can’t definitively prove they stem from poor code quality or architecture, certainly highlight the risks of managing complex technical systems without full visibility into their internal state.
On July 19, 2024, CrowdStrike pushed a faulty security update that crashed 8.5 million Windows computers worldwide, causing what experts called “the largest IT outage in history.” Airlines grounded flights, hospitals canceled surgeries, banks shut down, and emergency services went offline.
What We Know: The faulty update contained a logic error that triggered an out-of-bounds memory read, causing instant blue screens of death. CrowdStrike’s own post-incident review revealed that their Content Validator component had a flaw that allowed the problematic update to pass validation.
What This Reveals About Visibility: The technical details of how this error passed validation are likely invisible to CrowdStrike’s business leadership. They can see that systems failed, but the specific architectural decisions and testing processes that allowed this failure are in the invisible warehouse of software development.
The Recovery Challenge: Fixing each affected machine required manual intervention—a human had to physically visit each computer, boot into safe mode, and delete the corrupted file. This manual recovery process suggests systems that weren’t designed with robust failure modes, though we can’t definitively attribute this to poor architecture without insider knowledge.
The Scale of Impact: Over $10 billion in damages. Delta Airlines alone filed a $500 million lawsuit. What’s clear is that a single software error had massive global consequences, highlighting our dependence on systems whose internal workings are invisible to the decision-makers who deploy them.
The Afterthought Response: Following the CrowdStrike incident, many organizations suddenly demanded security patching and system updates—work that should have been ongoing but was treated as an afterthought until disaster struck. This reactive approach perfectly illustrates the invisibility problem: fundamental system maintenance only becomes a priority when failures make the technical reality visible to management. The house of cards was always fragile, but it took a spectacular collapse for decision-makers to see it.
In September 2024, attackers compromised the maintainer account for popular npm packages like “debug” and “chalk”—packages downloaded 2 billion times weekly. Within hours, malicious code designed to steal cryptocurrency was distributed to millions of applications worldwide.
What We Know: The attack succeeded through a convincing phishing email targeting the maintainer’s 2FA reset process. The malicious code was designed to intercept cryptocurrency transactions and redirect them to attacker-controlled addresses.
The Visibility Challenge: Most organizations using these packages had no idea they were depending on code maintained by a single person, or that this person could be compromised. The complex web of dependencies in modern applications creates a scenario where critical infrastructure depends on invisible individuals and processes.
The Detection: The community spotted the malicious code within 15 minutes and had it removed within two hours. This rapid response happened because knowledgeable developers were actively monitoring the ecosystem—not through any formal oversight process.
What This Reveals: The incident exposed how much of our software infrastructure relies on trust relationships that are invisible to the organizations depending on them. Decision-makers approving the use of npm packages likely have no visibility into who maintains them or how they’re secured.
AT&T’s network went down for 12 hours, affecting 125 million devices and preventing 92 million calls, including 25,000 emergency calls. The cause was described as an “equipment configuration error.”
What We Know: The specific details of the configuration error haven’t been publicly disclosed, but it was significant enough to bring down a major cellular network for half a day.
The Complexity Factor: Modern network infrastructure involves thousands of configuration parameters across multiple systems. The fact that a single configuration change could have such widespread impact suggests systems where the relationships between components may not be fully understood or visible to those managing them.
The Life-and-Death Stakes: When 25,000 emergency calls couldn’t get through, the abstract concept of “system reliability” became a matter of life and death. This highlights how invisible technical decisions can have very visible human consequences.
Microsoft reported 1,360 vulnerabilities in 2024—an 11% increase from their previous record. These were security flaws discovered in widely-used software across Windows, Office, Edge, Azure, and related products.
What This Number Represents: While we can’t definitively attribute these vulnerabilities to specific development practices, the sheer volume and year-over-year increase suggests that security considerations may not be keeping pace with feature development.
The Visibility Gap: Most organizations using Microsoft products have no insight into the security review processes, code quality standards, or architectural decisions that affect their risk exposure. They can see that patches are released, but the underlying reasons for these vulnerabilities remain invisible.
Rather than speculating about the specific technical causes, these incidents highlight something more fundamental about software management:
The Invisibility of Risk: In each case, the technical risks that led to failure were likely invisible to the business decision-makers who had ultimate responsibility for the systems. CrowdStrike’s executives couldn’t see into their validation processes. Organizations using npm packages couldn’t see their dependency chains. AT&T’s leadership couldn’t see the configuration complexity. Microsoft customers couldn’t see the security review processes.
Reactive Priority Setting: The pattern across all incidents is reactive rather than proactive management. Security patching, dependency auditing, configuration management, and validation processes only became urgent priorities after visible failures made their importance clear.
Complex Dependencies: Each incident involved complex systems with dependencies that were poorly understood by the organizations relying on them. This complexity was largely invisible until it failed.
The Illusion of Control: Organizations believed they had visibility into and control over their technical risks, but these incidents revealed how much of their infrastructure depended on invisible processes, people, and systems.
The combined financial impact of these incidents—over $15 billion in direct costs, plus immeasurable downstream effects—represents the price of operating critical systems without full visibility into how they work.
These weren’t acts of nature or sophisticated nation-state attacks. They were failures of complex technical systems where the people responsible for operational decisions lacked visibility into the technical realities that determined success or failure.
Whether better code quality or architecture could have prevented these specific incidents is unknowable without insider access. What is clear is that in each case, critical technical decisions were being made by people who couldn’t see inside the systems they were responsible for managing.
Behind each of these incidents were engineers who likely saw the problems coming but couldn’t get the attention of decision-makers. There were probably code reviews that flagged risks, architectural discussions that raised concerns, and testing protocols that could have caught the errors.
But in the invisible warehouse of software development, these warnings get lost in the noise of deadline pressure and feature delivery metrics. The people who can see the problems don’t have the authority to fix them, and the people with authority can’t see the problems.
This is the human cost of the invisibility problem. Not just the psychological toll on developers, but the societal cost when critical systems fail because we’ve organized our industry around the assumption that technical expertise doesn’t matter for technical decisions.
When developers try to explain the internal state, it sounds like excuses:
Developer: “We can’t add that feature quickly because the authentication system is tightly coupled to the user interface.”
Manager: “That sounds like over-engineering. Can’t you just add the code where it needs to go?”
Developer: “We need to refactor this module before adding new features or it will become unmaintainable.”
Manager: “Refactoring doesn’t deliver value to customers. Just add the feature.”
Developer: “This approach will create technical debt that will slow us down later.”
Manager: “We’ll deal with later when we get there. Customers need this now.”
The manager isn’t being unreasonable—they literally cannot see what the developer is describing. It’s like trying to explain color to someone who was born blind.
Other engineering disciplines solved this with blueprints, diagrams, and models. Civil engineers don’t just describe bridge stress—they show computer models of load distribution. Architects don’t just talk about structural integrity—they create visual models that non-architects can understand.
Software has tried to solve this with various visualization approaches:
But none of these truly convey the experience of working inside the codebase. None show the difference between elegant, maintainable code and a fragile house of cards.
This invisibility problem explains so much of what’s wrong with software:
Why technical debt accumulates: Managers can’t see it, so they don’t prioritize fixing it.
Why rewrites are common: By the time problems become visible (through outages, security breaches, or inability to add features), the only solution is starting over.
Why good engineers leave: They spend their days in chaotic warehouses while being judged by people who think the warehouses are fine because packages still come out.
Why non-technical managers succeed: They optimize for visible metrics that don’t reflect internal reality.
Why technical excellence is undervalued: You can’t value what you can’t see.
Until we solve the fundamental invisibility problem, software will continue to be managed poorly. Some approaches that help:
Code archaeology tours: Have developers literally walk managers through code on screen, explaining what they see and why it matters.
Technical debt as financial debt: Express technical debt in dollars and time, making abstract concepts concrete.
Before/after refactoring demos: Show how much faster a feature can be implemented after cleaning up the code.
Failure storytelling: When systems break, trace the failure back to the architectural decisions that caused it.
But ultimately, this may be an unsolvable problem. Software might always be invisible to those who don’t write it. Which means the only real solution is what we’ve argued throughout this piece: technical decisions must be made by people who can see inside the warehouse.
The tragedy isn’t that managers can’t see the code. The tragedy is that we’ve organized our industry around the assumption that they don’t need to.
Walk into any hospital and you’ll find something remarkable: the people making life-and-death decisions have actually saved lives before. The Chief of Surgery got there by performing thousands of surgeries, not by optimizing surgical “throughput metrics” from a spreadsheet.
When a surgeon says “This operation will take six hours, not two,” nobody responds with “Can’t you just make fewer incisions?” The complexity is respected because the decision-maker understands it.
In law firms, the Managing Partner has tried cases, negotiated deals, and felt the weight of having someone’s freedom or fortune rest on their legal strategy. When they allocate resources to a complex case, they understand why thoroughness matters more than speed.
In aviation, the Director of Flight Operations has felt the stick shake in turbulence and made split-second decisions at 30,000 feet. When a pilot says the weather is too dangerous to fly, that pilot’s judgment carries weight because the decision-maker has been there.
In architecture, the Principal has drawn blueprints that became real buildings where real people live and work. They’ve seen what happens when you cut corners on foundation work—the cracks appear later, and the building becomes uninhabitable.
The pattern is clear and universal: in every profession except software, technical decisions are made by people who understand the technical work.
But there’s something else these professions understand that software doesn’t: you can’t rush mastery.
When someone tells you they’re a surgeon, you don’t worry about their experience level. There’s no such thing as a “junior surgeon” operating on patients. The path to surgical competence takes over a decade:
That’s 9-15 years before society lets them make life-and-death decisions alone. And throughout this entire process, they’re working alongside experienced practitioners, handling real cases, with immediate feedback when they make mistakes.
Law follows a similar pattern. Fresh law school graduates don’t argue before the Supreme Court. They become:
The legal profession doesn’t throw new graduates into courtrooms and hope for the best. They apprentice under experienced attorneys, observing hundreds of cases before handling their own.
Even trades understand this. Electricians spend 4 years in apprenticeship before touching live wires unsupervised. Plumbers work under master plumbers for years before handling complex installations. We don’t let apprentice electricians wire hospitals or apprentice plumbers design water systems.
But in software? We hire a computer science graduate on Friday and expect them to architect user authentication systems on Monday.
Software is arguably the most complex intellectual work humans have ever attempted. A modern application might contain millions of lines of code, integrate dozens of systems, and handle edge cases that would make a chess grandmaster weep.
Yet this intricate craft is routinely managed by people who couldn’t debug a null pointer exception if their career depended on it.
Picture the typical technology company leadership:
The CTO who asks “Can’t we just use AI to write the code faster?” without understanding that AI-generated code still needs to be architected, tested, integrated, and maintained by humans.
The VP of Engineering who schedules a “quick sync” to discuss why the mobile app crashes, then spends the meeting asking why the team can’t just “add more servers” to fix a client-side bug.
The Director who insists that “code is code” and asks why the iOS developer can’t help with the backend database optimization—after all, they’re both programming, right?
These aren’t hypothetical examples. These are conversations happening in conference rooms across Silicon Valley right now.
This fundamental misalignment doesn’t just create frustration—it breeds a self-reinforcing cycle of mediocrity that gets worse over time.
When managers can’t read code, they can’t distinguish between good and bad engineering. They evaluate developers using the only metrics they understand: how fast they ship features and how few complaints they generate. Code quality, architectural soundness, and long-term maintainability become invisible.
Unable to assess technical quality, managers default to measuring what they can see: delivery speed and feature quantity. Developers quickly learn that taking time for proper testing, documentation, or architectural planning isn’t rewarded—it’s punished as “slowness.”
Experienced engineers recognize dysfunctional environments and have options. They leave for companies that value engineering excellence. The brain drain begins.
With competent engineers gone, poor practices become normalized. Code reviews become rubber stamps. “Quick fixes” become permanent solutions. Technical debt accumulates like compound interest.
Junior developers who ship features fast—regardless of quality—become the organizational heroes. They’re celebrated in all-hands meetings and get promoted rapidly. Everyone learns the lesson: speed beats quality.
Sarah, a junior developer at a mid-size startup, learned this lesson quickly. Her first feature—a user notification system—shipped in record time. What the business didn’t see was that she had hard-coded email addresses, skipped error handling, and copied notification logic instead of creating reusable components.
When users started complaining about broken notifications three months later, Sarah had already been promoted. The senior developer who spent two weeks refactoring her code got no recognition—after all, “fixing things” doesn’t show up in the feature delivery metrics.
New developers learn from this poisoned environment. They absorb dysfunctional practices as “how software is built” and carry these anti-patterns to their next roles, spreading the dysfunction like a virus.
The worst outcome: false heroes eventually become managers themselves. They hire developers who work like they do—fast and loose with quality. They’ve never seen engineering excellence, so they can’t recognize or demand it.
This management structure creates consequences that are completely invisible to non-technical decision-makers:
The 3 AM Pages: When poorly architected systems fail at midnight on weekends, engineers get called to fix them. The business sees high uptime percentages in reports; they don’t see the human cost of maintaining fragile systems.
The Feature Request That Takes Six Months: When a “simple” feature requires rewriting half the codebase because the original architecture was a mess, managers blame the engineering team for “over-complicating things.”
The Security Breach: When code written under time pressure without proper review creates vulnerabilities that expose customer data, the headline reads “Company Hacked”—not “Company’s Rush to Market Compromised Security.”
The Great Rewrite: When technical debt makes the codebase unmaintainable, companies spend millions rebuilding systems from scratch. This is treated as an “innovation initiative,” not as the direct consequence of years of poor engineering management.
Marcus, a senior engineer at a Series B company, watched this play out in real time. The product team wanted to add real-time collaboration features to their document editor. The original codebase was a mess of global state and copy-pasted event handlers that couldn’t support real-time updates without major refactoring.
“How long?” asked the VP of Product.
“Six months if we do it right,” Marcus replied. “Two weeks if we hack it in, but it’ll break everything else.”
“Let’s go with the two-week option. We can fix any issues later.”
They went with the hack. The feature worked for the demo. Six months later, they’re spending $2 million on a complete rewrite because the document editor had become unmaintainable.
One of the most destructive aspects of this cycle is how it creates and celebrates false heroes—developers who appear to be high performers because they deliver quickly, while leaving a trail of technical debt that others must clean up.
Picture Alex, a new graduate who joined a fast-growing startup. Eager to impress, Alex ships features at breakneck speed by:
Each feature Alex ships appears to work. The product team is thrilled. Alex gets promoted.
What nobody sees is that Alex’s code is a ticking time bomb:
Meanwhile, senior developers like Jamie spend their time:
Jamie appears “slower” because she’s not shipping features—she’s preventing disasters. When Jamie raises concerns about technical debt, she’s labeled as a “perfectionist” who “doesn’t understand business priorities.”
The cruel irony: Jamie is fired during the next layoff for “low productivity,” while Alex gets promoted to Senior Developer.
The software industry does have internships, but they’re largely theater—designed more for recruiting and PR than actually developing competent engineers.
Picture the typical tech internship:
Week 1: Orientation, laptop setup, and a “fun” onboarding project that gets thrown away Weeks 2-10: Building a small feature or tool, mostly working alone with occasional check-ins Week 11: Presentation to leadership about the “impact” they made Week 12: Conversion offer based on whether they “shipped something”
Compare this to a medical residency:
Month 1: Shadowing experienced doctors, learning hospital protocols, understanding patient care workflows Months 2-12: Gradually taking on more patient responsibility under constant supervision, with experienced physicians reviewing every major decision Years 2-7: Increasing autonomy, but still working within established teams, handling increasingly complex cases, with immediate feedback when things go wrong
The medical resident isn’t building toy projects—they’re handling real patients under expert guidance. When they make mistakes, experienced doctors catch them before anyone gets hurt. When they succeed, it’s because they’ve learned to apply proven medical knowledge to real situations.
What software internships actually teach:
What they don’t teach:
Most damaging of all: internships teach students that software development is about individual contribution rather than collaborative mastery. The intern who “ships a feature” alone gets the return offer, not the one who spends time learning the existing codebase and asking thoughtful questions.
Imagine if software followed the medical model of extended, supervised practice:
New graduates would join teams as code residents, spending their first year:
No code resident would work alone on significant features. Every commit would be reviewed not just for correctness, but as a teaching opportunity.
Code residents would gradually take on more responsibility while still under close supervision:
Only after years of supervised work would engineers be trusted with:
After 7-10 years of proven excellence, engineers would become master practitioners capable of:
The reason software doesn’t follow this apprenticeship model isn’t because it’s impossible—it’s because it’s expensive and our industry is optimized for short-term extraction rather than long-term excellence.
The VC-driven startup model demands rapid growth and immediate productivity. Investors want to see teams “moving fast and breaking things,” not carefully training the next generation of craftspeople. A startup that spent two years properly training engineers would be seen as “inefficient” compared to one that hired experienced engineers and shipped features immediately.
The public company quarterly earnings model prioritizes features shipped this quarter over engineering capabilities built over multiple years. Wall Street rewards companies that can show immediate productivity from new hires, not ones that invest in long-term apprenticeship programs.
The talent wars mean companies are competing to hire experienced engineers away from each other rather than investing in training their own. Why spend three years developing an engineer when you can pay a premium to hire one who’s already trained?
But here’s what this short-term thinking costs us:
The companies that do invest in serious engineering development—like Google’s internship programs that span multiple years, or Stripe’s emphasis on engineering mentorship—consistently outperform their peers in technical execution.
Building a real apprenticeship culture in software requires fundamental changes:
Economic incentives must change. We need investors and boards that value engineering excellence over raw velocity. We need metrics that reward learning and mentorship alongside feature delivery.
Time horizons must extend. Companies must be willing to invest in engineer development over multiple years, even if it means slower initial productivity.
Senior engineers must teach. The most experienced engineers must see teaching and mentorship as core parts of their role, not distractions from “real work.”
Hierarchies must reflect competence. Just as hospitals don’t let residents perform surgery unsupervised, software companies shouldn’t let inexperienced engineers make architectural decisions without guidance.
The software industry can choose to become a true engineering profession, with the apprenticeship systems and standards that designation requires. Or it can continue as it is: a collection of people with computer science degrees hoping their hastily-built systems don’t collapse under the weight of real-world usage.
The stakes are too high for us to keep choosing the latter.
Want to see what software development looks like when it’s actually managed by someone who understands the craft? Look at the Linux kernel—the most successful software project in human history, running everything from smartphones to supercomputers to the International Space Station.
Linus Torvalds doesn’t just lead the Linux kernel project; he is the final authority on every line of code that goes into it. Nothing—absolutely nothing—gets merged into the mainline kernel without going through a hierarchy of technical review that ultimately ends at Torvalds himself.
The Linux kernel development process would horrify most corporate managers. It’s “slow,” “bureaucratic,” and gives one person “too much power.” It’s also produced the most reliable, scalable, and widely-used piece of software ever written.
At the bottom: Thousands of developers submit patches. These aren’t features written in isolation—they’re carefully crafted changes to a system they’ve spent months or years studying.
Subsystem maintainers: Experienced kernel developers who’ve earned Torvalds’ trust over years manage specific areas like networking, filesystems, or memory management. They understand both the technical details of their subsystem and how it interacts with the rest of the kernel.
Lieutenant maintainers: A small group of developers who’ve demonstrated exceptional technical judgment over many years. They can make broader architectural decisions, but still subject to Torvalds’ review.
Torvalds himself: Makes final decisions on anything that affects kernel architecture, design philosophy, or overall direction. He regularly rejects patches from brilliant engineers if they don’t meet his standards for code quality, design elegance, or long-term maintainability.
You don’t become a Linux subsystem maintainer by shipping features fast or impressing managers in meetings. You earn it through years of demonstrating technical excellence:
Years 1-2: You submit small patches that fix bugs or add minor features. Most get rejected with detailed technical feedback. You learn the kernel’s coding standards, design philosophy, and how to write patches that actually improve the system.
Years 3-5: Your patches start getting accepted more regularly. You develop expertise in specific subsystems. Maintainers begin to trust your technical judgment on narrow issues.
Years 5-10: You might become a maintainer for a specific subsystem. This means other developers submit patches to you first, and you’re responsible for ensuring they meet kernel standards before passing them up the hierarchy.
Years 10+: Only after demonstrating exceptional technical judgment over a decade might you be trusted with broader architectural decisions.
The results speak for themselves. The Linux kernel:
Compare this to the typical enterprise software project:
What makes Torvalds’ leadership so effective isn’t just his technical knowledge—it’s that he applies the same rigorous standards to everyone, including himself. He’ll reject patches from kernel veterans if they don’t meet his quality bar. He’ll rewrite code from respected maintainers if it doesn’t fit the overall design vision.
Most importantly, he makes technical decisions based on technical merit, not politics, deadlines, or business pressure. When someone submits a patch that would make the kernel faster but less maintainable, Torvalds rejects it. When someone wants to add a feature that would break existing APIs, he says no.
This is what happens when someone who deeply understands the craft has final authority over technical decisions.
Imagine if Linux were developed like typical corporate software:
The VP of Linux Development (who hasn’t written kernel code in years) would set quarterly OKRs for “kernel velocity.” Teams would be measured on how many patches they merge, not on code quality.
Product managers would prioritize features based on market research rather than technical architecture. The kernel would accumulate layers of poorly-integrated functionality because “users are asking for it.”
Junior developers would be assigned to rewrite core memory management because they’re “fast” and “hungry,” regardless of their lack of experience with low-level systems programming.
Quarterly reviews would pressure maintainers to lower their standards to hit patch quotas. Technical debt would accumulate as corners got cut to meet deadlines.
The result would be an unstable, insecure, unmaintainable mess—like most enterprise software today.
The Linux model proves that rigorous technical governance works. But it requires something most software organizations refuse to accept: technical decisions must be made by people who understand the technical implications.
This doesn’t mean every project needs a benevolent dictator like Torvalds. But it does mean:
Here’s what’s beautiful about the Linux model: once developers prove their technical competence over years, they get enormous autonomy. Subsystem maintainers can make major technical decisions within their domains without asking permission. They’ve earned that trust through demonstrated mastery.
But this autonomy is earned, not given. It comes after years of having your work reviewed, critiqued, and improved by people who understand the craft better than you do. It’s the opposite of the typical corporate model where new graduates get “ownership” of complex systems before they understand how they work.
The paradox is that strict technical governance early in a developer’s career leads to much greater creative freedom later. Developers who’ve internalized excellent engineering practices through years of mentorship and review can be trusted with major architectural decisions. Developers who’ve never been held to high standards can’t.
This is what real engineering apprenticeship looks like: rigorous training under master craftspeople, followed by increasing autonomy as competence is demonstrated. Not the fake “empowerment” of giving complex technical responsibilities to people who haven’t yet developed the judgment to handle them well.
So what would it look like if software companies actually honored engineering excellence? How do you break the cycle and build something better?
The prerequisite is simple: people making technical decisions must understand technology. This doesn’t mean every executive needs to be coding, but they need to distinguish between good and bad engineering decisions.
At Stripe, the CTO and engineering VPs regularly participate in architecture reviews. They understand the technical tradeoffs in payment processing, the complexity of handling international regulations, and why certain features require more time than others. When an engineer explains why a feature needs careful implementation, the response isn’t “just ship it”—it’s “what do you need to do it right?”
Real technical assessment means evaluating how candidates think about complex problems, not whether they can reverse a binary tree on a whiteboard.
GitLab’s hiring process includes:
They’re not testing trivia—they’re testing judgment.
Culture lives in the details. Engineering excellence requires systematizing quality into every part of the development process.
Code Review as Education: At companies like Shopify, senior engineers use code reviews to teach, not just gatekeep. They explain why certain patterns are preferred, share context about system history, and help junior developers grow.
Architecture as a Discipline: Technical decisions get the same rigor as business decisions. Architectural Decision Records document the thinking behind major choices. Changes that affect system design require review by multiple senior engineers.
Testing as Insurance: Comprehensive testing isn’t optional—it’s what allows teams to move fast without breaking things. Netflix’s culture of “you build it, you run it” means engineers feel the pain when their untested code breaks production.
Instead of measuring “velocity” (story points per sprint), excellent engineering organizations track:
These metrics reward sustainable engineering practices instead of just raw output.
Large organizations face unique challenges, but size doesn’t have to mean lowered standards.
Microsoft’s DevDiv manages thousands of engineers working on Visual Studio, .NET, and developer tools. They maintain quality through:
Google’s Site Reliability Engineering embeds software engineers in operations roles, ensuring that the people managing production systems understand the code they’re running.
Organizations that invest in engineering excellence see exponential returns:
Airbnb’s investment in infrastructure and tooling allows them to deploy hundreds of times per day with minimal risk. Their “trust and safety” features—built with careful architecture from the beginning—handle edge cases that would break hastily-built systems.
Stripe’s obsession with engineering quality allows them to handle millions of payment transactions with industry-leading reliability. Their careful approach to financial systems engineering enables features that competitors can’t match.
Linear’s small team ships features faster than much larger organizations because they invested in excellent tooling, clear architecture, and comprehensive testing from day one.
Yes, the market demands speed. Users want features yesterday. Investors want growth this quarter. The company that ships first often captures the market. This is economic reality, and we can’t ignore it.
But here’s what the “move fast and break things” crowd gets wrong: speed and quality aren’t mutually exclusive. The choice isn’t between shipping in 3 months with garbage code or 18 months with perfect code. It’s about being strategic with quality where it matters most.
The key insight: not all code is created equal. Some code is temporary scaffolding, some is critical infrastructure. Treating them the same is where both extremes fail.
Core Infrastructure: Build Right Authentication, data models, API design, security layers—these are your foundations. Cutting corners here isn’t being fast, it’s being reckless. An extra month getting these right saves years of pain.
Feature Code: Build Fast, But Smart User-facing features that might change? Build them quickly but isolated. Use feature flags, clear interfaces, and modular design so they can be replaced without destroying everything else.
Experiments: Build Disposable A/B tests, market validation features, experimental UIs—build these as throwaways from the start. Put them behind abstraction layers so when you throw them away, they don’t take your core system with them.
Smart teams have figured out how to satisfy market demands while maintaining technical integrity:
Start with a Walking Skeleton Ship a minimal but well-architected core in weeks, not months. It doesn’t do much, but what it does is solid. This becomes your foundation for rapid iteration.
Invest in Developer Velocity Good tooling, automated testing, and CI/CD aren’t slowing you down—they’re speeding you up. The hour spent setting up tests saves days of debugging. The day spent on deployment automation saves weeks of manual releases.
Technical Debt as Strategic Choice Take on technical debt consciously, not accidentally. Document it, isolate it, and have a plan to pay it back. “We’re hard-coding this for the demo but will make it configurable in v2” is strategic. “We’ll figure it out later” is not.
Parallel Track Development While one team ships features quickly, another refactors and strengthens the foundation. The feature team gets market feedback, the platform team ensures the system doesn’t collapse under growth.
Yes, Facebook started with messy PHP code. But look closer at what actually happened:
They didn’t just “fix it later when they had money.” They nearly collapsed multiple times from technical debt. They had to invent entire new technologies (HipHop, HHVM, React) just to survive their own architectural decisions. The cost of fixing their early mistakes was astronomical—likely billions in engineering effort.
More importantly, Facebook succeeded despite their technical debt, not because of it. They had first-mover advantage in a winner-take-all market. Most startups don’t have that luxury.
Here’s what customers actually care about:
Here’s what they don’t care about:
A badly-architected product that exists beats a well-architected product that doesn’t. Customers can’t use your beautiful codebase if it’s still in development while your competitor’s ugly hack is solving their problems today.
Venture capitalists aren’t stupid. They know that most startups fail, and the ones that succeed often need complete rewrites. But they also know that:
Market timing matters more than code quality. Being first to market with a viable solution often determines success more than technical excellence.
Technical debt is a tomorrow problem. If the company succeeds, they can afford to fix it. If it fails, the technical debt doesn’t matter.
Speed indicates execution ability. Teams that ship fast—even if cutting corners—demonstrate they can deliver. Teams that take forever perfecting their architecture might be too slow for the market.
Product-market fit beats everything. A terribly-built product that users love will get funding. A beautifully-built product that users ignore won’t.
This creates a rational incentive to prioritize speed over quality, at least initially.
Look at the modern software landscape:
No-code platforms let non-programmers build “applications” by dragging and dropping components. The resulting systems are unmaintainable nightmares, but they ship in days, not months.
AI-generated code produces barely-functional solutions that would horrify any experienced developer. But if it works 80% of the time and ships today, the market often chooses it over a properly-built solution that takes months.
Outsourced development to the lowest bidder produces codebases that are practically unmaintainable. But if it gets you to market first, you can always rebuild later.
Framework-of-the-week development where teams use whatever’s trending, regardless of whether it’s appropriate, because it’s faster than learning to do things properly.
The market is essentially saying: “We don’t care if it’s held together with string and chewing gum, as long as it works right now.”
This might be acceptable if we were just talking about toy applications and startup experiments. But increasingly, our critical infrastructure is built this way:
Healthcare systems processing patient data are often cobbled-together messes because hospitals needed something “yesterday.”
Financial platforms handling millions in transactions are built on foundations of technical debt because speed to market mattered more than security.
Government systems that citizens depend on are frequently the result of lowest-bidder contractors shipping as fast as possible.
The same market forces that reward shipping fast in the startup world are now determining how we build systems that society depends on.
Instead of seeing this as an impossible choice, smart teams have figured out how to use quality as a competitive advantage:
Quality Enables Speed Well-architected systems are easier to change. Good test coverage means you can refactor without fear. Clean code means new developers onboard quickly. The initial investment in quality pays compound returns in development velocity.
Quality Reduces Costs Every bug in production costs 10-100x more to fix than in development. Every security breach costs millions. Every rewrite costs years. Quality isn’t expensive—lack of quality is expensive.
Quality Attracts Talent The best engineers want to work on well-crafted systems. They’ll take pay cuts to work somewhere that values their craft. When you have better engineers, you build better products faster.
You don’t have to choose between shipping fast and building well. Here’s how successful teams navigate the pressure:
Week 1-2: Architecture Sprint Before writing any feature code, spend two weeks getting the core architecture right. This isn’t over-engineering—it’s laying the foundation that makes everything else faster.
Week 3-12: Rapid Feature Development With solid foundations, you can move fast without breaking things. Features plug into well-defined interfaces. Changes don’t cascade through the system.
Continuous: Refactoring Friday Every Friday, fix technical debt from the week. Don’t let it accumulate. Small, continuous improvements prevent the need for massive rewrites.
The 80/20 Rule for Quality 80% of your problems come from 20% of your code. Identify the critical 20%—usually data models, core algorithms, and security code—and make it excellent. The other 80% can be “good enough.”
As an individual engineer, you can’t change the market overnight. But you can navigate it strategically:
Document Everything When pressured to cut corners, document it. “Per management decision on [date], implementing without tests to meet deadline.” This protects you and creates awareness of technical debt.
Propose Alternatives Don’t just say “this will create technical debt.” Say “We can ship the MVP in 3 weeks with approach A, but we’ll need 3 months to fix it later. Or we can ship in 5 weeks with approach B and avoid the rewrite.”
Build Allies Find the people in your organization who care about quality—they exist, even in dysfunctional companies. Work together to demonstrate the value of good engineering.
Choose Your Battles You can’t make everything perfect. Focus on the changes that matter most: the core systems, the security-critical code, the data models that everything depends on.
Instead of waiting for the market to change, be the change:
Demonstrate Value When you do get time to refactor or improve architecture, measure the impact. Show how it improved deployment frequency, reduced bugs, or sped up feature development.
Educate Non-Technical Stakeholders Use analogies they understand. “Technical debt is like deferred maintenance on a building. We can skip it for a while, but eventually the roof caves in.”
Start Small You can’t fix everything, but you can make your corner of the codebase excellent. Others will notice and want the same for their code.
Build Culture Celebrate code quality wins. Share postmortems that show how good architecture prevented disasters. Make engineering excellence visible and valued.
The market reality is challenging, but it’s not insurmountable. The best engineers and the best companies find ways to deliver value quickly while building systems that last. The key is being strategic about where and when to invest in quality, not abandoning it entirely.
But here’s an even more uncomfortable truth: even if we could fix the market incentives, we’d still face an insurmountable obstacle—the people currently in power have no reason to change a system that put them there.
Look at who’s currently running engineering organizations:
The Non-Technical CTOs who’ve built entire careers on managing without understanding. They’re not going to suddenly admit they’re unqualified for their jobs. They’ve spent 20 years climbing the corporate ladder by being good at PowerPoint and politics, not code. You think they’re going to step aside for someone who actually understands technology?
The Fast-Shipping Heroes from the previous generation who got promoted for cutting corners. They don’t see technical debt as a problem—it’s how they built their careers. They’re not going to suddenly value code quality when speed is what got them their VP title.
The Failed Engineers who moved into management because they couldn’t hack it technically. They actively resist technical excellence because it reminds them of their own inadequacy. They surround themselves with mediocre engineers who won’t challenge their authority.
These people aren’t going to reform a system that rewarded them. They’re going to protect it.
Here’s how entrenched leadership maintains its power:
They hire people worse than themselves. A non-technical manager will never hire someone who makes their lack of technical knowledge obvious. They’ll hire someone who speaks their language—business buzzwords, not technical reality.
They promote based on politics, not competence. The engineer who makes the boss look good gets promoted, not the one who writes the best code. Technical excellence becomes a liability if it threatens management’s ego.
They redefine success to match their skills. When you can’t evaluate code quality, you change the metrics to things you can measure—tickets closed, features shipped, presentations delivered. Engineering excellence gets defined out of existence.
They create processes that entrench their position. Performance reviews that weight “leadership” and “communication” over technical skills. Reorgs that eliminate technical leadership roles. Promotion committees staffed by other non-technical managers.
David, a principal engineer at a large tech company, watched this play out over five years:
“Our CTO couldn’t write FizzBuzz if his life depended on it. When our most senior architect challenged him on a terrible technical decision, the architect was ‘restructured out.’ The message was clear: technical expertise is a threat, not an asset.
Now our ‘technical leadership’ is entirely people who know how to manage up. They’ve systematically pushed out anyone who actually understands how our systems work. The codebase is collapsing, but the leadership metrics all look green because we’ve redefined what success means.”
This creates a death spiral that’s almost impossible to escape:
Year 1: Non-technical leader hires slightly less competent engineers who won’t threaten them.
Year 2: Those engineers become team leads and hire even less competent engineers.
Year 3: The new standard is established—mediocrity is normal, excellence is “over-engineering.”
Year 5: Anyone competent has left. The entire organization has forgotten what good engineering looks like.
Year 10: The company is now structurally incapable of recognizing or producing excellence.
Even if someone wanted to fix this, they’d face massive institutional resistance:
HR departments built around non-technical evaluation. They’ve created entire frameworks for assessing engineers that have nothing to do with engineering ability. They’re not going to throw out their competency matrices and behavioral interview guides.
Board members who don’t understand technology either. They hired the non-technical CTO in the first place. They evaluate success based on stock price and quarterly earnings, not code quality.
Investors who’ve made fortunes from the current dysfunction. The VC who got rich from Facebook’s “move fast and break things” approach isn’t going to suddenly demand engineering excellence from portfolio companies.
Business schools that teach technology management without teaching technology. They’re producing the next generation of non-technical CTOs right now, teaching them that engineering is just another “resource” to be optimized.
Most damaging of all: the current leadership is comfortable with their incompetence because everyone around them is equally incompetent.
The non-technical CTO goes to conferences full of other non-technical CTOs. They all reassure each other that “leadership is about vision, not technical details.” They share strategies for “managing technical teams” without understanding what those teams actually do.
They’ve created an entire ecosystem that validates their approach:
They’re not living in denial—they’re living in a carefully constructed alternate reality where their incompetence is reframed as leadership.
Here’s the truly depressing part: we’re now multiple generations into this dysfunction. The people who could fix it—who remember when software was led by people who understood software—are retiring or already gone.
The new generation of developers has never seen anything else. They think this is normal:
They don’t know there’s a better way because they’ve never seen it.
Fixing this would require something like a revolution:
Current leadership would need to voluntarily give up power. The non-technical CTOs would need to step aside for technical leaders. The fast-shipping heroes would need to admit their approach was wrong. The failed engineers in management would need to acknowledge their limitations.
This will never happen voluntarily.
Boards would need to fire successful executives. They’d need to remove CTOs who are hitting their quarterly targets but destroying long-term technical capability. They’d need to value engineering excellence over short-term metrics.
This will never happen without external pressure.
The entire industry would need to change simultaneously. One company improving their engineering culture while competitors continue shipping garbage would be commercial suicide.
This will never happen through market forces alone.
So here’s where we are:
The system isn’t broken. It’s working exactly as designed. It’s just designed to produce and reward mediocrity.
And the people running it have every incentive to keep it that way.
There’s another fundamental truth we need to confront: most software is orphaned at birth. Nobody actually owns it. Nobody’s name is on it. Nobody’s reputation depends on it. It’s just code that exists, maintained by whoever drew the short straw this sprint.
Linus Torvalds doesn’t just maintain Linux—he owns it in the deepest sense. Every line of code that goes into the kernel reflects on him personally. When there’s a bug, it’s his reputation on the line. When there’s a security vulnerability, he takes it personally. Linux is his life’s work, his legacy, his baby.
This is why Linux works and most corporate software doesn’t.
Walk into any large company and ask who owns the authentication system. You’ll get blank stares, followed by:
“Well, Team Alpha built it originally, but they got reorged.”
“Team Beta maintains it now, but they’re focusing on the new platform.”
“I think Sarah knows the most about it, but she’s leaving next month.”
“We just try not to touch it. It mostly works.”
This is orphaned code. It has no parent, no guardian, no one who cares about its future. It exists in a state of communal neglect, modified by whoever needs to add a feature, maintained by whoever can’t avoid it.
Software in most companies is a commons—a shared resource that everyone uses but nobody owns. And like all commons without governance, it gets destroyed by negligence and short-term thinking.
Every developer who touches the codebase has the same calculation:
“I could refactor this mess, but I’ll be on a different team in six months. Why should I care?”
“I could write proper tests, but my performance review is based on features shipped, not code quality.”
“I could document this properly, but I’m not going to be here when someone needs to understand it.”
“I could fix this technical debt, but it’s not my problem—I didn’t create it.”
The result is code that accumulates damage with every commit. Each developer adds their hack, their workaround, their quick fix. Nobody cleans up because nobody owns the mess.
Modern tech companies make this worse with their obsession with “rotation” and “mobility”:
Engineers rotate teams every 12-18 months to “gain broad experience.” Just when someone starts to understand a codebase deeply enough to improve it, they’re moved to something else.
Managers rotate even faster, ensuring that nobody in leadership has any long-term investment in code quality.
Products get handed off between teams like hot potatoes. The team that builds something is never the team that maintains it.
Reorganizations happen constantly, breaking any sense of code ownership that might have developed.
Tom, a senior engineer at a FAANG company, described it perfectly:
“I’ve worked on seven different products in five years, not by choice but because of reorgs. I’ve never seen the long-term consequences of my architectural decisions. I’ve never had to live with my own technical debt. Every codebase I touch is someone else’s mess that I’ll hand off to another stranger in a few months. Why would I care about code quality? I’m just passing through.”
Even “full-time” employees are essentially contractors now. The average tenure at tech companies is 2-3 years. Everyone’s building their resume for the next job, not building software for the ages.
This creates a contractor mentality even among employees:
Nobody’s building a cathedral they’ll be proud of in 20 years. Everyone’s adding bricks to a wall they’ll never see completed.
Look at successful open source projects and you’ll see the opposite pattern:
PostgreSQL: Tom Lane has been a core contributor for over 25 years. He knows every line of code, every design decision, every historical artifact. It’s his life’s work.
SQLite: Richard Hipp has maintained it for over 20 years. He takes personal responsibility for every bug, every feature, every line of documentation.
Vim: Bram Moolenaar maintained it for 30 years until his death. It was his creation, his responsibility, his legacy.
These projects work because someone truly cares. Someone’s name is on it. Someone will be embarrassed if it breaks. Someone cares about its future.
There’s no pride in corporate code because there’s no ownership. You can’t be proud of something that isn’t yours. You can’t take satisfaction in craftsmanship when your work will be destroyed by the next developer who touches it.
Imagine if cathedrals were built the way we build software:
We’d have no Notre-Dame, no Sagrada Familia, no St. Peter’s Basilica. We’d have piles of stones that vaguely resemble buildings.
Companies try to address this with “ownership” initiatives that are pure theater:
“You own this service!” (But you can’t make architectural decisions without committee approval)
“You’re the code owner!” (But you’ll be rotated off in six months)
“Take ownership!” (But your performance review is based on delivering features, not maintaining code)
“Act like an owner!” (But you have no equity and will be laid off if the stock price drops)
This isn’t ownership—it’s responsibility without authority, accountability without control. It’s asking people to care about something they don’t actually own.
Real craftsmanship requires ownership over time. A craftsperson needs to:
None of this is possible in the modern software industry where:
Imagine if software companies actually had ownership:
Code would have names on it. Not just git blame, but real attribution. “This authentication system was architected by Sarah Chen. She’s responsible for its design and quality.”
People would stay with their code. Engineers would maintain systems for years, not months. They’d live with their decisions and learn from them.
Reputation would follow quality. If your code is garbage, everyone would know. If your code is excellent, that would follow you too.
Pride would be possible. Developers could point to systems and say “I built that, and I’m proud of it.”
Accountability would be real. If a system fails, the person who owns it would be responsible for fixing it, not some random on-call engineer who’s never seen the code before.
Real ownership is incompatible with modern corporate culture:
Companies want interchangeable resources, not craftspeople with deep expertise in specific systems.
Managers want flexibility to reassign people, not engineers who are tied to specific codebases.
The job market rewards job-hopping, not staying with one codebase for a decade.
VCs want rapid scaling, which means hiring quickly and rotating people freely, not building deep expertise.
The result is what we have: millions of lines of orphaned code, maintained by nobody, owned by nobody, and gradually rotting from neglect.
Most software is garbage because nobody truly cares about it. Not because developers are incompetent, but because the system ensures that nobody has any reason to care about code they don’t own, won’t maintain, and will never see again.
Torvalds can reject bad patches because Linux’s quality reflects on him personally. Corporate developers accept bad code because they’ll be at a different company before the technical debt comes due.
Until software has real owners—people whose names are on it, whose reputations depend on it, who will maintain it for years—we’ll continue building digital garbage that barely works and that nobody’s proud of.
The tragedy isn’t that we don’t know how to build better software. It’s that we’ve created a system where nobody has any reason to try.
The software industry stands at a crossroads. Every day, more of our world depends on code. Banking, healthcare, transportation, communication—it’s all software now. The stakes of getting this right have never been higher.
Yet we’re building this critical infrastructure using management practices that would be considered malpractice in any other field. We’re making multi-million-dollar architectural decisions based on PowerPoint presentations instead of code reviews.
The cost isn’t just measured in failed projects or security breaches. It’s measured in the opportunity cost of what we could build if we organized ourselves like other serious professions.
What would the tech industry look like if we required technical competence for technical leadership? If we measured success by the quality of what we build, not just the speed at which we ship? If we treated software engineering as a true engineering discipline with the standards and practices that designation demands?
Some companies are already showing us the way. The question is whether the rest of the industry will follow, or whether we’ll continue down the path of managed mediocrity.
The choice is ours. But the clock is ticking. Every day we delay, we embed dysfunction deeper into the systems that increasingly run our world.
The next time you’re in that conference room, listening to someone who’s never written production code make technical decisions that you’ll have to live with for the next five years, remember: this doesn’t have to be normal.
Software can be better. We just have to decide that we want it to be.
If you’re a leader who recognizes your organization in the dysfunction described above, here’s how to turn things around. This isn’t a overnight transformation—it’s a gradual evolution that can start today.
Don’t try to transform the entire organization at once. Pick one team—ideally one working on critical infrastructure—and make them your excellence laboratory.
Give them time: Allocate 20% of their sprint for refactoring and tooling improvements. Yes, they’ll ship fewer features initially. That’s the investment.
Give them authority: Let them own their technical decisions. No architecture committees, no management overrides. They succeed or fail on their own choices.
Give them stability: Keep the team together for at least two years. No rotations, no reorgs. Let them see the long-term consequences of their decisions.
Measure differently: Don’t measure story points or features shipped. Measure deployment frequency, defect rates, mean time to recovery, and developer satisfaction.
After 6-12 months, this team will be outperforming others despite spending less time on features. They become your proof that excellence works.
Every hire is a vote for the culture you’re building. Start hiring differently:
Hire senior engineers who’ve maintained systems for years, not job-hoppers who’ve never seen their technical debt mature.
Value teaching ability: Engineers who can mentor and elevate others are worth more than brilliant lone wolves.
Test for quality mindset: In interviews, ask about technical debt they’ve paid down, systems they’ve refactored, bugs they’ve prevented.
Pay for excellence: Yes, engineers who write quality code cost more. They also create 10x less work for everyone else.
Most companies force excellent engineers into management to advance. This removes your best technical talent from technical decisions. Instead:
Create Principal/Staff/Distinguished Engineer roles with compensation equal to management tracks.
Give them real authority: Principal Engineers should have veto power over architectural decisions in their domain.
Make them visible: Have them present at all-hands, write technical strategy docs, and mentor across teams.
Require technical competence for technical management: Engineering managers should be able to review code and understand architectural tradeoffs.
Once you have successful pilot teams and technical leaders, expand gradually:
Month 1-3: Tooling Investment
Month 4-6: Process Evolution
Month 7-12: Cultural Shift
Year 2: Institutional Change
Leadership will have concerns. Here’s how to address them:
“We can’t afford to slow down” Show them data: Companies with high-performing engineering teams deploy 200x more frequently with 2,400x faster recovery times (DORA metrics). Excellence enables speed.
“Our competitors will beat us to market” Point to companies like Stripe, Linear, and early Google who dominated specifically because their technical excellence enabled features competitors couldn’t match.
“We can’t find engineers who meet these standards” You can’t find them because you haven’t been looking for them. They exist, working at companies that value their craft. When word gets out that you’re serious about excellence, they’ll come.
“This sounds expensive” Calculate the cost of your last production outage, security breach, or major rewrite. Compare that to the cost of paying engineers 20% more. Excellence is cheap compared to failure.
For CFOs and boards who need numbers:
Reduced Incidents: High-performing teams have 5x lower change failure rates. Fewer incidents means lower operational costs.
Faster Delivery: After initial investment, excellent teams deploy more frequently with less risk. Feature velocity increases, not decreases.
Lower Turnover: Engineers stay at companies that value their craft. Reducing turnover by 50% saves millions in recruiting and onboarding costs.
Security: Well-architected systems have fewer vulnerabilities. One prevented breach pays for years of engineering excellence.
Scalability: Systems built right scale smoothly. You avoid the massive rewrite costs that cripple growing companies.
The hardest part isn’t starting—it’s maintaining momentum when pressure mounts:
Create Excellence Advocates: Identify engineers passionate about quality and make them official advocates with time allocated to improve practices.
Visible Metrics: Dashboard key quality metrics where everyone can see them. What gets measured gets managed.
Regular Audits: Quarterly reviews of code quality, technical debt, and engineering practices. Treat them as seriously as financial audits.
Protect the Investment: When pressure comes to cut corners, calculate and communicate the true cost. Make technical debt visible to business stakeholders.
Celebrate Wins: When good architecture prevents a disaster or enables rapid feature development, make it visible. Share the counterfactual—what would have happened without the investment in quality.
Companies that successfully transform their engineering culture gain massive advantages:
The transformation isn’t easy, but the alternative—continuing to accumulate technical debt until the system collapses—is worse. Every day you delay makes the transformation harder.
Start today. Pick one team. Give them the space to excel. Use their success to drive broader change. In two years, you’ll have an engineering organization that’s a competitive advantage instead of a liability.
Despite this bleak landscape, there are companies that genuinely value engineering excellence. They’re rare, but they exist. If you’re an engineer who cares about craft, finding these companies can save your career—and your sanity.
How do you identify a company that actually values good engineering before you join? Look for these signals:
Technical Founders or CTOs Companies founded by engineers or with CTOs who still write code tend to understand and value engineering. Look for leaders who can discuss technical tradeoffs intelligently, not just parrot buzzwords.
Long Tenure Check LinkedIn. If engineers stay for 5+ years, that’s a strong signal. If everyone leaves after 18 months, run. Companies with good engineering cultures retain good engineers.
Open Source Contributions Companies that contribute meaningfully to open source understand code quality. They’re not just using open source—they’re maintaining it, which requires high standards.
Technical Blog Quality Read their engineering blog. Are they solving hard technical problems or just announcing features? Do they discuss failures and learnings, or just victories? Honest technical content signals honest technical culture.
Interview Process How do they evaluate you? If it’s all behavioral questions and no code review or system design, they can’t evaluate technical quality. If senior engineers are involved in interviews, that’s a good sign.
Code Ownership Model Ask during interviews: “Who owns the authentication system?” If you get a clear answer with a name, that’s good. If you get “the team,” that’s a warning. If you get confused looks, run.
Some warning signs that a company doesn’t value engineering:
“Move Fast and Break Things” Mentality This was Facebook’s motto when they were building their technical debt mountain. Any variation of this philosophy means quality is explicitly not valued.
Non-Technical Engineering Leadership If the CTO’s background is in sales or product management, engineering is not a priority. If they brag about “not needing to understand the technical details,” engineering is actively devalued.
Rapid Team Rotation If they brag about engineers “gaining broad experience” by rotating teams every year, they don’t value deep expertise or code ownership.
Feature Factory Metrics If they measure success by features shipped or story points completed, they’re optimizing for quantity over quality.
“Agile” Theater If they’re obsessed with sprint velocity, daily standups, and retrospectives but never mention code quality, testing, or technical debt, they’re cargo-culting process without understanding engineering.
Outsourced Core Systems If critical systems were built by contractors or outsourced teams, leadership doesn’t value engineering enough to invest in it properly.
While company cultures can change, these organizations have historically valued engineering excellence:
Stripe Known for exceptional API design, comprehensive documentation, and engineers who deeply understand financial systems. Their interview process is rigorous and technical leadership actually leads technically.
Netflix Pioneered many distributed systems practices. Their “you build it, you run it” philosophy ensures engineers care about code quality because they’ll be debugging it at 3 AM.
Shopify Maintains a massive Ruby on Rails monolith successfully through exceptional engineering practices. They invest heavily in developer tooling and testing.
Linear Small team shipping high-quality features faster than companies 10x their size. They prioritize engineering excellence from the start rather than planning to fix it later.
Valve No managers, engineers own their work completely. Their games run for decades because the code is maintained by people who care about it.
id Software (in the Carmack era) John Carmack’s leadership created a culture of technical excellence that produced groundbreaking engines. Engineers owned their code for years.
Smaller companies and startups can be hidden gems if:
Don’t just let them interview you. Ask questions that reveal their engineering culture:
“Can you describe a recent technical decision and how it was made?” Listen for: Who was involved? Was it technical people or management? Was long-term maintainability considered?
“How do you handle technical debt?” Good answer: Regular time allocated for refactoring, technical debt tracked like features Bad answer: “We’ll fix it later” or blank stares
“Who’s been maintaining [core system] the longest?” Good answer: “Sarah’s been owning that for three years” Bad answer: “It’s been handed around” or “We all share responsibility”
“Can you show me some code you’re proud of?” If they can’t or won’t, they’re not proud of their code
“What happens when an engineer disagrees with a technical decision from management?” The answer reveals whether technical expertise is valued or overruled
“How long have your senior engineers been here?” High turnover in senior roles means they’re not retaining talent
Silicon Valley companies often have the worst engineering cultures because they can always hire more engineers. Companies in smaller tech hubs may value retention and quality more because they can’t easily replace people.
Remote-first companies that were remote before COVID often have better engineering cultures because they had to be disciplined about documentation, async communication, and code quality from the start.
Even good engineering companies have trade-offs:
They may pay less than companies that are burning VC money for growth They may move slower on features because they’re building things properly They may be more selective in hiring, making them harder to join They may be smaller with fewer opportunities for rapid advancement
But if you value craft, mentorship, and building things you’re proud of, these trade-offs are worth it.
Working at a company with engineering excellence is an investment in your career:
Even if you eventually join a less excellent company, you’ll bring those standards with you. You’ll be the senior engineer who teaches others what good looks like.
These companies are maybe 5% of the market. Most companies don’t value engineering excellence, and that’s not changing soon. But those 5% do exist, and they’re looking for engineers who care as much as they do.
The challenge is finding them before you’re too burned out to care.