Dávid Juhász Your best work disappears—along with your recognition.
Consider an aircraft’s flight system: triple redundancy, failover protocols, seamless operation. No heroic rescues. That’s how proactive engineering work operates—until someone asks, "Why fund what never fails?"
You write tests, harden systems, design fallbacks—all to ensure nothing goes wrong. The result? Silence. No incidents. No proof you were needed at all.
That’s the Visibility Paradox: The more you prevent failure, the more you must prove you were even there. The engineer who averted the disaster? Invisible. The team that fixed last month’s outage? Celebrated.
The litmus test: If you spend more than 20% of your time proving your work instead of doing it, the system is misaligned. Not in a "fixable-by-you" way—in a structural way.
This isn’t a cultural quirk. It’s how control systems work: Visibility isn’t a byproduct of good work—it’s the price of entry. That is the legibility tax.
This post will help you:
Diagnose the root cause: Why organizations hide your highest-impact work.
Spot the divide: Are you a Hero (firefighter) or an Architect (preventer)? And which does your team actually reward?
Pull the right levers: Tactics to reframe your work, automate proof, and make the system carry the burden of visibility.
Decide your next move: Recalibrate your environment—or find one that values prevention over heroics.
Organizations as Control Systems
Every meeting, report, or KPI isn't bureaucracy—it’s the price of control.
Imagine your organization as an aircraft:
Executives = pilots
Teams = subsystems (navigation, propulsion)
Metrics = cockpit displays
The question: How much of those readings is signal, and how much is noise?
In engineering, instrumentation exists to observe and adjust. In organizations, the same logic applies—but the "sensors" (reports, dashboards) often feel like drag.
Why Your Work Gets Buried
Hierarchies aren’t arbitrary; they’re control systems answering two questions:
Are we on course? (Observability)
How do we correct if we’re not? (Steerability)
Observability isn’t free. Every sensor adds weight; every report adds friction. The trade-off is baked in:
Startups operate like gliders: minimal instrumentation, high trust. A single Slack message reroutes priorities.
Enterprises resemble airliners: layered redundancy, rigid protocols. A 10-page document precedes trivial changes.
How Control Systems Fail Engineers
Legibility traps: Systems prioritize easy-to-track proxies (meetings held, docs filed) over meaningful outcomes (risks mitigated).
Human sensor problem: If the system can’t see your work, it assumes it isn’t happening—so it adds more "sensors" (reports, approvals) until it can.
Signal vs. noise: In startups, a senior engineer tweaks design at will; in enterprises, the same decision requires a 10-page doc.
*The system’s question isn’t "Are you doing great work?"—it’s "Can we see you doing great work?"* And if the answer is no, it will keep adding sensors.
Is Your Organization Measuring the Wrong Things?
Your frustration isn’t with control—it’s with inefficient instrumentation that fixates on the wrong details.
The goal isn’t to eliminate overhead—it’s to calibrate it. Ask:
Which metrics actually correlate with stability?
Where can we automate observability?
How much legibility tax is too much?
The misalignment isn’t random. It follows predictable laws that turn metrics into targets, replacing purpose with process and creating the illusion of control. Those laws explain why your organization feels optimized for documenting work, not doing it.
3 Laws That Sabotage Your Impact
Large organizations follow predictable laws—like physics. Most organizational friction stems from incentive misalignment: the gap between what the organization says it wants and what it actually rewards. Recognize these laws to work with the system, not against it.
Goodhart’s Law: When Metrics Become the Mission
When a measure becomes a target, it ceases to be a good measure.
— Charles Goodhart
The Core Issue: Goodhart’s Law is about the loss of information. Once a metric is used for control, it loses its ability to signal the truth about the system.
Where you’ve seen this: Teams measured by "tickets closed" split work into atomic, meaningless tasks. The dashboard glows green, but the information regarding "system health" is lost as technical debt explodes.
The behavior: Organizations gravitate toward legible proxies that are easy to track and easy to corrupt. Simple metrics create simple behaviors—often at the expense of quality.
The Countermeasure:
If you control the metrics, replace activity with outcomes (e.g., "post-deploy incident rate").
If you don’t, hit the target and redefine success by tying results to outcomes. "We met our PR goal and cut returning support tickets by 30% by addressing root causes." This steers the conversation toward better metrics.
Campbell’s Law: Metrics Corrupt What They Measure
The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures…
— Donald T. Campbell
The Core Issue: While Goodhart focuses on the signal, Campbell focuses on the corruption of the process. The harder you push a metric, the faster the culture degrades to meet it.
Where you’ve seen this: Sales representatives graded on "customer visits" pack calendars with low-value meetings. The activity metric soars; actual deals stagnate.
The behavior: If "uptime" is the sole KPI, teams over-provision infrastructure or under-report failures. The dashboard stays green; the system degrades.
The Countermeasure: Balance metrics. Pair "uptime" with "cost per request." For every metric, ask: "What behavior does this reward?" If the answer isn’t the outcome you want, complement it with a counter-metric.
Parkinson’s Law: Perpetuum Processum (The Self-Perpetuating Process)
Work expands so as to fill the time available for its completion.
— C. Northcote Parkinson
The Core Issue: Organizations suffer from "The Law of Triviality" (or Bike-Shedding)—the tendency to spend disproportionate time on trivialities (like the color of a bike shed) because they are easy to grasp, while complex issues go unexamined.
Where you feel it: A quick sync bloats into a 60-minute session with 12 attendees. A trivial change requires a "pre-meeting" to align on a document before work begins.
The behavior: You spend 2 hours documenting a 10-minute fix because "visibility" is used as a shield against risk. This is risk aversion disguised as diligence.
The Countermeasure:
Default to async written updates—writing forces precision; reading forces engagement.
Set artificial deadlines: "This decision moves forward by Friday—silence equals consent." Deadlines don’t just create urgency; they reveal what’s truly necessary.
Tune processes so that every step adds actual value.
The Tax of Visibility
Together, these laws ensure a predictable decay:
Information Loss: Work bends toward what is easy to measure, rendering the metrics "blind" (Goodhart’s).
System Corruption: What is measured is gamed, distorting the actual work (Campbell’s).
Process Bloat: The gaming and the "visibility" of the work become more important than the work itself (Parkinson’s).
In this context, visibility isn’t a byproduct of good work—it’s the currency. The question shifts from "How do we eliminate friction?" to "Where do we choose to spend it?"
This visibility tax doesn't just distort metrics—it creates a cultural fault line: the gap between the heros who get promoted for fixing visible crises and the architects who are ignored for preventing them.
Hero vs. Architect: Which Culture Dominates Your Team?
Every team sits on a spectrum:
Heroes are the firefighters—the engineers who thrive in chaos and are celebrated because they directly avert disaster or deliver immediate results in crises. The organization sees their impact because the alternative (failure) is tangible.
Architects are the preventers—the engineers who mitigate chaos and are overlooked because nothing breaks when they succeed. No fires. No escalations. Just a system that quietly hums along.
How the Cultures Compare
| Trait | Heroes | Architects |
|---|---|---|
| Visibility | High (crises are public) | Low (success is silent) |
| Recognition | Celebrated (saved the day!) | Overlooked (nothing broke) |
| Risk Tolerance | Thrives in chaos | Mitigates chaos |
| Work Style | Reactive (fixes fires) | Proactive (prevents fires) |
| Org’s Perception | "Indispensable" | "Invisible" |
| Career Growth | Promoted for heroics | Stagnates without advocacy |
| Key Metric | "Incidents resolved" | "Incidents avoided" |
| Legibility Tax | Low (work is obvious) | High (must prove value) |
The Hero-Architect spectrum isn't just about work styles—it exposes deeper cultural principles at play. Misalignment between personal principles and team culture leads to frustration, burnout, and stalled growth. Understanding your team's shared principles can help you determine whether your work style aligns with the culture—or if you're fighting an uphill battle against entrenched norms.
The Startup-Enterprise Reality
The irony: Startups act like they need Heroes (speed! hustle!) but survive via Architect work (scalable systems, automation). Enterprises claim to want Architects (stability! process!) but reward Heroics.
The real question isn’t about company size—it’s about:
Where your team sits on the Hero-Architect spectrum
Whether they're willing to shift and how much you can influence that
Your move—not the organization’s type—determines whether you thrive or burn out.
How to Rewire Recognition
The problem isn’t that proactive work is invisible—it’s that organizations are wired to react to what’s urgent, not invest in what’s important. Fixing this requires recalibrating feedback loops at both the systemic and individual levels.
Systemic Fixes: Make Prevention Visible at Scale
Large organizations drown in activity metrics (tickets closed, meetings attended) while starving for outcome metrics (system reliability, risk reduced).
How Metrics Shape Culture:
| Aspect | Activity Metrics (Hero Culture) | Outcome Metrics (Architect Culture) | How to Shift |
|---|---|---|---|
| Focus | What you do | What you achieve | Replace "tasks completed" with "problems solved" |
| Example Metrics | Tickets closed | Customer-impacting incidents reduced | Track "risks mitigated" not "tasks done" |
| Meetings attended | System reliability improved | Measure "reliability gains" not "attendance" | |
| Lines of code written | Technical debt reduced | Count "complexity reduced" not "lines added" | |
| PRs merged | Deployment failure rate | Monitor "quality" not "quantity" | |
| Behavior Rewarded | Firefighting | Fire prevention | Celebrate "crises avoided" not just "crises solved" |
| Organizational Impact | Creates dependency on heroes | Builds self-healing systems | Ask: "Did this make the system better or just busier?" |
| Long-term Effect | Technical debt accumulates | Operational resilience improves | Measure "future work avoided" not "current work done" |
| Cultural Message | "We handle the chaos" | "We design out the chaos" | Change narratives from "who fixed it" to "who prevented it" |
The metrics you choose don't just measure culture—they create it. Hero cultures emerge when you track activity; Architect cultures develop when you measure outcomes.
Three Levers to Pull Immediately:
Automate observability
Replace manual status reports with dashboards that highlight:System health trends (e.g., error budgets, uptime).
Prevented issues (e.g., "faults avoided due to proactive fixes").
Efficiency gains (e.g., "time saved by automation").
Measure outcomes
Stop rewarding busywork. Track value creation instead:❌ "Resolved 50 Jira tickets" → ✅ "Reduced customer-impacting incidents by 30%."
❌ "Attended 10 meetings" → ✅ "Shipped a zero-defect feature."
Tie engineering work to business results—like cost savings or customer satisfaction—to make it visible.
Reward simplification
Celebrate "negative work"—the effort to remove complexity. For example, "deleted 3 deprecated configs" yields fewer failure modes and simpler onboarding.
Personal Tactics: Prove Your Impact Without Burning Out
When the system ignores your work, translate it into a language it understands:
Create artifacts
Document risks you avoided:"Pre-mortems" for potential failures you mitigated (e.g., "We found X in staging; here's the fix and why it would've taken down prod")—clarifying "what could go wrong" like TDD clarifies requirements early.
"Anti-incident reports" (e.g., "Averted a 3-hour outage by catching X in staging").
Architecture decision records (ADRs) explaining why you prioritized resilience over speed.
Speak business
Leaders care about impact, not technical details. Frame your work as outcome:Cost saved (e.g., "This optimization reduces cloud spend by $250K/year").
Time reclaimed (e.g., "This tooling change cuts debugging time by 20%").
Risk reduced (e.g., "This refactor eliminates a single point of failure").
Use visuals
A before/after graph of "deployment failures" tells a stronger story than a bullet point about "improved reliability."
Stay or Go?
Not all organizations value prevention equally. Before deciding whether to adapt or move on, ask:
Does your organization reward stability or heroics?
Are promotions tied to firefighting, while quiet wins go unnoticed? If crises drive recognition, you’re in a hero-worshipping culture.Can you reduce the "legibility tax" locally?
If streamlining reporting or shifting to outcome-based metrics feels like rebellion, the misalignment runs deep in the system.
The 20% Rule:
If you spend over 20% of time proving rather than doing work, the system is misaligned.
Your options:
Adapt: Automate busywork and reframe your contributions in terms the system understands.
Influence: Introduce outcome-based metrics.
Leave: If resistance is default, the culture won’t change.
Evaluating your next opportunity:
Ask decision-makers:
"How is performance measured here?"
"What did the last person promoted from this role actually achieve?"
Listen for results, not activity. A culture that can’t articulate impact won’t recognize your strengths.
Overhead isn’t the enemy—misaligned overhead is. The friction is either fuel for improvement or a sign to move on. Constructive discontent—the gap between current reality and potential—only works in systems capable of change.
The best systems design their trade-offs with purpose. A well-built team shouldn’t need heroes—but it does need architects: those who build resilience so quietly that the only drama is in the stories of what didn’t happen.
Your 20% audit this week:
Measure: Track time spent proving vs. doing.
Act: Fix one thing—automate, eliminate, or document.
Share: Present results as experiments, not criticism.
The goal isn’t zero friction—it’s friction that pays dividends.