The Compiler Decides Right and Wrong, Hierarchy Decides Qualification

Zhang Ming and Li Ting joined the same internet company on the same day, both fresh graduates.

Zhang Ming worked in backend development, Li Ting as an administrative specialist. After their three-month probation, their experiences diverged completely.

Zhang Ming independently submitted his first feature in his second week. Code review was conducted by a senior engineer on GitHub, with comments that were direct and specific: “This could use concurrency optimization,” “Missing edge case handling.” No meeting room, no “let’s reconsider,” no “let the director look it over.” By the third week, his code went live in the production environment, and the monitoring system showed everything was fine. His probation evaluation stated: “Already possesses the ability to independently deliver.”

Li Ting spent her second week revising meeting minutes. The first draft went to her supervisor, who circled three places needing “more formal wording.” After revisions, the director commented, “Isn’t this conclusion being drawn too early?” The third version reached the VP’s secretary, who replied, “The leader is busy this week, let’s discuss next week.” Three weeks later, the minutes were finalized, but the matters discussed were already outdated. Her probation evaluation read: “Needs more time to familiarize with company style.”

This isn’t a gap in ability or effort. It’s a gap in validation mechanisms.

A Forgotten History

Today’s flat technical teams have taken a long detour.

In 1968, NATO held a conference in Germany that would later become legendary. Software projects were frequently delayed and over budget, and the industry realized the need for a methodology as rigorous as engineering. This conference gave birth to the concept of “software engineering” and spawned a management system mimicking traditional engineering: detailed requirements documents, rigorous phase reviews, and multi-level sign-offs.

The Waterfall model was formally proposed in 1970: Requirements Analysis → System Design → Coding → Testing → Operations/Delivery, where each phase must be completed before the next begins. This approach dominated the software industry from the 1970s to the 1990s, with organizational structures imitating traditional manufacturing: Project Managers, System Architects, Module Leads, Programmers, with clear hierarchies; Requirements Review Meetings, Design Review Meetings, Code Review Meetings, Release Review Meetings—an endless series of meetings.

Fred Brooks documented the struggles of this era in his 1975 book The Mythical Man-Month. He formulated the famous law: “Adding manpower to a late software project makes it later.” Communication costs grow exponentially with the number of people; while hierarchy provides control, it also creates bottlenecks.

The shift occurred in 2001. The Agile Manifesto was published, with 17 software pioneers declaring: Individuals and interactions over processes and tools; working software over comprehensive documentation. This wasn’t an evolution in management philosophy, but an organizational change forced by tool evolution.

Git was born in 2005, making asynchronous collaboration possible with distributed version control. GitHub launched in 2008, integrating pull requests, code review, and continuous integration into a single workflow. Validation costs plummeted: CI tells you if the code is correct; PR reviews discuss if the design is good; live data speaks to whether the feature is useful.

The validation mechanism shifted from “human approval” to “machine + data,” eliminating the necessity for hierarchical layers.

The Verifiability Spectrum

All work can be measured on a spectrum: how quickly, at what cost, and by whom your output is validated for correctness.

At the far left end are programmers. Write code, press Command+B, and the compiler tells you if it’s correct in 0.3 seconds. Submit a PR, the CI pipeline runs tests, and gives a coverage report in 15 minutes. If there’s an issue, it’s rejected on the spot; if not, it’s merged directly. The entire validation process doesn’t require anyone to “appreciate” or “gatekeep.”

At the far right end is another group in organizations. The marketing department writes an annual brand strategy. Is it correct? No one can give an answer within three days. Maybe market share will provide feedback in six months, but by then the person in charge may have left. Before the “right or wrong” is revealed, this strategy requires supervisor review, director evaluation, and VP approval. Not because these people are smarter than the executors, but because before the outcome is revealed, hierarchy itself is the only source of certainty.

Flatness isn’t an attitude; it’s a byproduct of verifiability. When work can be objectively judged by machines or data, supervisory hierarchies become redundant. Git’s diff tells newcomers “where they wrote it wrong” more clearly than any supervisor; Sentry’s error logs pinpoint problems more precisely than any mentor.

Bureaucracy isn’t an attitude either; it’s an emergency response to ambiguity. When work lacks objective validation standards, organizations must invent an alternative mechanism to create “temporary certainty.” This mechanism is hierarchy: each level of “approval” is insurance against the uncertainty of the final outcome. A five-level approval doesn’t guarantee a correct decision, but ensures that if it’s wrong, responsibility is dispersed and processes are compliant.

Four Validation Mechanisms

Deconstructing organizational validation mechanisms layer by layer, programmers and non-technical roles stand on different combinations.

Machine validation is the programmer’s core privilege. Compilers, automated tests, CI/CD, monitoring alerts—these tools judge right and wrong at near-zero cost. Code review typically focuses not on “correctness” (the machine already verified that), but on “quality.” This means reviewers don’t need to be “superiors”—any experienced colleague can review. In open-source communities, an anonymous contributor’s PR can be reviewed by any maintainer, without knowing their level.

User validation solves “is the feature useful?” A/B testing lets conversion rate numbers decide “which version is better,” without needing a review meeting. User behavior data (DAU, retention, feature usage frequency) forms the product’s “health check report,” and PMs make decisions directly based on data.

Expert validation has relatively clear standards. Whether code is good or not has industry consensus—readability, maintainability, performance, security—these dimensions can be discussed, learned, and standardized.

Hierarchical validation is the fallback when the first three fail. Writing a brand strategy has no compiler to tell you “syntax error.” Creating a budget plan has no A/B testing to tell you “which version has higher conversion.” The right/wrong standards for these tasks are vague, delayed, and subjective. Each level of “approval” is insurance for the decision. More importantly, hierarchy plays the role of a “standard generator” in ambiguous work: this direction aligns with leadership intent, that wording isn’t careful enough, this budget exceeds conventions.

Programmers can rely on 1+2+3, completely bypassing 4. Non-technical roles can only rely on 4. This is the dividing line between flat and bureaucratic.

Reality Beyond the Theory

The same Google has vastly different structures for engineering teams and marketing teams.

Engineers can question a VP’s technical decisions because technical right/wrong has objective standards. An engineer can point out in a mailing list that the VP’s proposal has performance issues, attach benchmark data, and the VP either refutes the data or accepts the conclusion. Rank doesn’t affect right/wrong here.

But involving budget approvals for marketing campaigns, brand compliance, supplier selection—each step requires signatures. This isn’t Google being “two-faced”; it’s because marketing campaign outputs cannot be machine-verified and must create certainty through hierarchy.

Putting Silicon Valley tech companies and large Chinese state-owned enterprises side by side, the surface is cultural difference, but the actual difference is business difference.

A central SOE’s approval chain: Staff drafts → Section Chief reviews → Division Chief gatekeeps → Department Head approves → Supervising leader signs off. Five or even seven levels. The core business of this enterprise is policy execution, resource allocation, and relationship coordination. The right/wrong standards for this work are themselves vague and context-dependent. Before the outcome is revealed (which might take three years to know if a decision was correct), hierarchy is the only mechanism that can provide “temporary certainty.”

Conversely, if this seven-level approval process were applied to Google’s code development process, what would happen? The compiler can judge right/wrong in 0.3 seconds, and seven-level approval would be “meeting to confirm” already determined facts. Engineers would break down, products would be delayed, and top talent would leave.

A reasonable organizational structure isn’t about pursuing “the flatter the better” or “the more standardized the better,” but about matching validation mechanisms to the nature of the work.

Tool advancement moves this boundary. The data analysis field has witnessed this shift: twenty years ago, analysts’ reports required multi-level reviews; today, the automation of data pipelines and the traceability of data lineage allow “data correctness” to be largely verified by tools. As a result, data analysis teams can be flatter than marketing teams.

How to Choose: Starting from Three Questions

Three questions help you position how flat your team should be:

Question One: Can your core output have its right/wrong judged by a machine within 24 hours? If yes, you have the conditions to be flat. If not, you need hierarchy or other forms of “artificial certainty.”

Question Two: If you removed all middle management, how long could your team operate? Middle management typically plays two roles: validation (gatekeeping quality) and coordination (information flow). In technical teams, these functions have been replaced by machines and tools. In non-technical teams, middle management is often both validator and coordinator. Remove them, and you’ll find decision paralysis.

Question Three: How often, on average, are your “mistakes” exposed? Programmers are corrected by compilers daily; the mistake exposure cycle is in minutes. Brand strategy, organizational change, strategic investment mistakes have exposure cycles measured in quarters, years, or even three years. The shorter the mistake exposure cycle, the more aggressively you can flatten; the longer it is, the more hierarchy serves as your protective mechanism.

Based on the answers, derive four strategies:

High verifiability + wants to be flatter: You already have the conditions. Invest in the toolchain to further compress validation costs, then gradually reduce hierarchy.
High verifiability + still hierarchical: You’re wasting resources. Re-examine those “traditionally requiring approval” steps.
Low verifiability + wants to be flatter: You need to first invest in “verifiability tools.” Once tools are in place, structure can follow.
Low verifiability + still hierarchical: You might be reasonable. Focus on optimizing hierarchical efficiency rather than blindly flattening.

There is no universally correct answer for organizational structure. The divide between flat technical teams and bureaucratic non-technical teams isn’t accidental; it’s a rational response to their respective “validation costs.” Zhang Ming’s flatness and Li Ting’s hierarchy are both organizational adaptations to the nature of the work, not judgments of individual capability.

Understanding this allows for better decisions: if you pursue flatness, first invest in tools that make work verifiable; if you must face hierarchy, understand its functional value, then optimize it.

Don’t be misled by “this is how Silicon Valley does it” or “this is how big companies do it.” The key is matching, not imitation.