See something, say something — you owe a report, not a repair

Context

Almost nobody goes quiet out of malice. They go quiet because in most organizations, noticing a problem is treated as volunteering to own it. Flag the broken thing in standup and the reply is “good catch — can you take it?” Happen to be right twice and you’ve learned the lesson the org actually teaches: seeing things is expensive. So people stop looking. Or, more insidiously, they look and then talk themselves out of it — someone closer to this must already know; it’s probably intentional; I’d have to understand the whole subsystem to be sure.

What you end up with is an organization where the same defect is independently known to six engineers and reported by none of them, each assuming the others — who are closer to it — must have said something. That isn’t a character flaw in six people. It’s the bystander effectThe bystander effect (diffusion of responsibility)Darley and Latané's finding that the more people who witness a problem, the less likely any individual is to act on it — responsibility diffuses across the group until each observer assumes someone better placed has already handled it. The effect strengthens as the number of observers grows, which is why large organizations are structurally worse at raising things than small ones.en.wikipedia.org ↗ with an issue tracker: the more people who can see a problem, the less any individual feels responsible for raising it. Diffusion of responsibility is the default state of any system with more than one observer, and it takes deliberate design to beat.

Manufacturing solved this on the factory floor decades ago. The andon cordThe andon cord (Toyota Production System)A signalling system on a production line that any worker can trigger the moment they see a defect, calling immediate attention to it. The deal is explicitly two-sided: the worker is obliged to signal, and someone is obliged to come — the worker is never expected to diagnose or fix the defect themselves. Separating the duty to signal from the duty to repair is what lets it work at the speed of a moving line.en.wikipedia.org ↗ is a line any worker can pull the moment they see a defect, and the deal is explicit and two-sided: you are obliged to signal, and someone is obliged to come to you. The worker never has to diagnose, own, or fix the defect. Separating the duty to signal from the duty to repair is precisely what lets it work at the speed of a moving line. It’s the same trade available in software, and mostly we haven’t made it.

Security deserves its own paragraph, because the calibration you’d sensibly apply to a bug is exactly the wrong calibration here. For an ordinary bug, “is this worth interrupting someone over?” is a fair question and you’re reasonably placed to answer it. For a security issue you are structurally unable to answer it, because severity is a property of the whole system and you can only see your corner. Something that looks cosmetic from inside one service — a tenant id you can pass that nobody checks, a debug field echoed back in an error — is sometimes a complete authorization bypass viewed from outside. That asymmetry, a cheap false positive against a catastrophic false negative, is why security findings don’t get triaged by the person who found them. It’s also why ZFN-2Field Note · currentZFN-2 — Engineering priority orderingWhen concerns conflict, prioritize security > correctness > availability > performance — and never trade a higher-ranked concern for a lower one. The rule binds the moment you must choose. Cite it instead of re-arguing it.Why it's cited here: Why a security observation outranks the cost of interrupting someone — when the two conflict, the interruption loses.Open ZFN-2 → puts security at the top: when the two conflict, the interruption loses.

Recommendation

Report what you see, route it to whoever owns it, and keep the things you fix yourself small enough to review.

• Say it even when you can’t fix it. The report is a deliverable, not an apology for arriving without a patch. “I don’t have time to chase this and I’m not certain it’s real, but here’s what I saw” is a genuinely valuable message. Send it.
• Route to an owner, not to the void. A message in a channel nobody owns isn’t a report, it’s a diary entry. Find the team that owns the thing — which is one of the quieter benefits of ZFN-47Field Note · currentZFN-47 — Govern the contract between teams, not the code inside themTeams own services end to end; one team owns the gateway that dispatches to them. Govern exactly one thing centrally — the contract at the boundary (schema, identity, errors, idempotency) — and enforce it at runtime. Don't mandate libraries; ship them as an opt-in blueprint.Why it's cited here: Why clear contracts between teams are also the map that tells you who to send a report to.Open ZFN-47 →: a system with clear contracts between teams also tells you who to talk to. And if you genuinely cannot find an owner, that’s the finding — an unowned system is a larger problem than the bug you started with, and it goes to whoever can assign ownership.
• Security goes to security, through their intake. Not through your assessment of severity, and not on the assumption they already know. Use the real intake path rather than the nearest public channel: for security specifically, that routing discipline matters more than speed, because a vulnerability discussed in the open is a disclosure. Report the ones you caused, especially those.
• Never fix a security issue quietly. Even when your fix is correct, one line, and already shipped. The owners need to know the hole existed: whether it was exploited before you closed it, whether the same pattern sits in four other services, whether anyone has a notification or disclosure obligation. A silent fix throws all of that away and leaves a repo with no memory. The class of the bug is the finding; the instance is the least of it. This is exactly what aviation built confidential near-miss reportingNASA Aviation Safety Reporting SystemA confidential, voluntary, non-punitive reporting system where aircrew report safety events and near-misses — including their own errors — with immunity from enforcement action in exchange. It exists because the incident that almost happened is the cheapest safety data available, and you only receive it if reporting is safe and easy.asrs.arc.nasa.gov ↗ for — the incident that didn’t happen is the cheapest data you will ever get, and the only reason it flows is that reporting is safe.
• Write reports someone can act on. What you saw, where, when, how to reproduce it, and how confident you are — including “I may be misreading this.” Then, explicitly: whether you’re offering to work on it or handing it over. Say which. That ambiguity is a large part of why people don’t report at all, so resolve it yourself instead of making the receiver ask.
• Leave it better than you found it — with a bounded radius. While you’re already in the file: the stale comment, the misleading error message, the missing test, the log line with no context. This is the campsite ruleThe Boy Scout Rule — Robert C. Martin, 97 Things Every Programmer Should KnowAdapts the Scouts' campsite rule to code: leave it a little cleaner than you found it. The emphasis is on small, continuous, uncoordinated improvement — a better variable name, a decomposed function, a removed duplication — on the argument that a codebase rots through a thousand individually-tolerable decisions and recovers the same way.github.com ↗, and it’s among the highest-leverage habits available in a large codebase precisely because it needs no coordination at all. Keep it small, keep it in the neighbourhood of what you were doing, and split it into its own commit when it muddies the diff.
• Don’t let “better” become a rewrite. The discipline is the boundary. A drive-by refactor of code you don’t own, inside a PR about something else, isn’t leaving it better — it’s making a reviewer evaluate a change they didn’t ask for, in a context where they can’t separate your intent from your accident. Past roughly “a reviewer can see at a glance that it’s right,” the correct move is back to reporting: file it, name the owner, move on.
• Say something about the org, not just the code. The duty isn’t only technical. One person who understands a critical system; a rota with a single name on it; two teams three weeks into building the same thing; a process everyone quietly routes around. Raise those the same way — and name it as your observation rather than laundering it through anonymous concern (ZFN-8Field Note · currentZFN-8 — Don't hide behind anonymous 'people'Never invoke unnamed 'people' to carry weight — 'a few people are concerned', 'some think'. It launders one view as phantom consensus and makes the listener argue a crowd they can't see. Name them and bring them in, or own it. If they can't speak up, fix the culture.Why it's cited here: Why a report carries a named author instead of being laundered as anonymous concern.Open ZFN-8 →).
• If you receive reports, make them cheap. This is the other half of the andon deal, and it’s where the whole thing lives or dies. Have a known intake. Answer. Thank people — including for the false positives, which are the running cost of a working sensor network; the day you sigh at one is the day the flow begins drying up. And don’t reflexively answer a report with “can you own this?” You’re allowed to ask. If it’s your default, you are training the org to stop telling you things.
• Keep the report separate from blame. Reporting a problem in someone else’s system is not an attack on them, and receiving one is not an accusation. ZFN-27Field Note · currentZFN-27 — Don't tolerate assholes — but be strict about what one isDon't tolerate assholes — people who demean, belittle, punch down. But filter hard on the word: disagreeing, raising ideas, or opening a competing PR isn't being an asshole, it's the work. Assholes attack people; colleagues attack problems. Don't let the label silence dissent.Why it's cited here: Why raising a problem in someone else's system is the work rather than hostility, so reporting should cost the reporter nothing.Open ZFN-27 → draws that line before the fact — raising a problem is the work, not hostility — and ZFN-29Field Note · currentZFN-29 — Blameless culture, taken seriously — and its one hard lineWhen something breaks, support the person, don't blame. Run post-mortems with ceremony and learn at every level — software, org, culture, process, even solo. Blameless protects honest mistakes, not dishonesty: evading or blaming gets coached; hiding evidence is a firing offense.Why it's cited here: The same protection applied after the fact — you only hear the truth about a failure if telling it is safe.Open ZFN-29 → draws it after. Both fail in the same way: when the messenger pays a cost, you don’t get fewer problems, only less information about them.

Consequences

Easier:

• Problems get caught by whoever happens to be standing nearest them, which is a far wider net than any owning team or scanner.
• Reports arrive while things are still cheap. A design concern raised in week one costs a conversation; in month six it costs a migration.
• Security gets a real picture of the estate instead of only what its own tooling can see from outside.
• New joiners become useful immediately. They can still see the strange things everyone else has stopped noticing, and this gives them a legitimate way to say so.
• Nobody has to be a hero. The bar for contributing outside your own lane drops from “fix it” to “write four sentences.”

Harder:

• A live report flow is a real and permanent triage load. Someone reads, routes, and answers, every day, forever.
• You will get false positives and duplicates, and you have to actually welcome them — which is harder than agreeing that you should.
• “Leave it better” needs active policing in review, or every PR grows a tail of unrelated changes and reviews get slower for everyone.
• Walking past something you could have fixed, having filed it instead, feels like negligence — especially for strong engineers. It isn’t; it’s prioritization. But it’s uncomfortable, and it probably should be.

New obligations:

• Owning teams have to be able to hear about problems they didn’t schedule without treating the messenger as the problem.
• Every system needs a findable owner and every report needs a findable intake, or “route it to the owner” is advice with nowhere to land.
• Security needs an intake path that a mildly-unsure engineer will actually use at 4pm on a Friday.

References

• the bystander effectThe bystander effect (diffusion of responsibility)Darley and Latané's finding that the more people who witness a problem, the less likely any individual is to act on it — responsibility diffuses across the group until each observer assumes someone better placed has already handled it. The effect strengthens as the number of observers grows, which is why large organizations are structurally worse at raising things than small ones.en.wikipedia.org ↗ — why the number of people who can see a problem is inversely related to the odds any one of them raises it.
• the andon cordThe andon cord (Toyota Production System)A signalling system on a production line that any worker can trigger the moment they see a defect, calling immediate attention to it. The deal is explicitly two-sided: the worker is obliged to signal, and someone is obliged to come — the worker is never expected to diagnose or fix the defect themselves. Separating the duty to signal from the duty to repair is what lets it work at the speed of a moving line.en.wikipedia.org ↗ — the two-sided deal this note is built on: anyone may signal a defect, and someone is obliged to come.
• the campsite ruleThe Boy Scout Rule — Robert C. Martin, 97 Things Every Programmer Should KnowAdapts the Scouts' campsite rule to code: leave it a little cleaner than you found it. The emphasis is on small, continuous, uncoordinated improvement — a better variable name, a decomposed function, a removed duplication — on the argument that a codebase rots through a thousand individually-tolerable decisions and recovers the same way.github.com ↗ — leave-it-better, scoped to the code you were already in.
• confidential near-miss reportingNASA Aviation Safety Reporting SystemA confidential, voluntary, non-punitive reporting system where aircrew report safety events and near-misses — including their own errors — with immunity from enforcement action in exchange. It exists because the incident that almost happened is the cheapest safety data available, and you only receive it if reporting is safe and easy.asrs.arc.nasa.gov ↗ — aviation’s non-punitive model, and why the problem you caught before it bit is still worth reporting.
• ZFN-2Field Note · currentZFN-2 — Engineering priority orderingWhen concerns conflict, prioritize security > correctness > availability > performance — and never trade a higher-ranked concern for a lower one. The rule binds the moment you must choose. Cite it instead of re-arguing it.Why it's cited here: Why a security observation outranks the cost of interrupting someone — when the two conflict, the interruption loses.Open ZFN-2 → — why a security observation outranks the cost of the interruption.
• ZFN-8Field Note · currentZFN-8 — Don't hide behind anonymous 'people'Never invoke unnamed 'people' to carry weight — 'a few people are concerned', 'some think'. It launders one view as phantom consensus and makes the listener argue a crowd they can't see. Name them and bring them in, or own it. If they can't speak up, fix the culture.Why it's cited here: Why a report carries a named author instead of being laundered as anonymous concern.Open ZFN-8 → — name it and own it; a report carries weight when it has an author.
• ZFN-27Field Note · currentZFN-27 — Don't tolerate assholes — but be strict about what one isDon't tolerate assholes — people who demean, belittle, punch down. But filter hard on the word: disagreeing, raising ideas, or opening a competing PR isn't being an asshole, it's the work. Assholes attack people; colleagues attack problems. Don't let the label silence dissent.Why it's cited here: Why raising a problem in someone else's system is the work rather than hostility, so reporting should cost the reporter nothing.Open ZFN-27 → — raising a problem in someone else’s work is the job, not hostility.
• ZFN-29Field Note · currentZFN-29 — Blameless culture, taken seriously — and its one hard lineWhen something breaks, support the person, don't blame. Run post-mortems with ceremony and learn at every level — software, org, culture, process, even solo. Blameless protects honest mistakes, not dishonesty: evading or blaming gets coached; hiding evidence is a firing offense.Why it's cited here: The same protection applied after the fact — you only hear the truth about a failure if telling it is safe.Open ZFN-29 → — the same protection after the fact: you hear the truth only when telling it is safe.
• ZFN-47Field Note · currentZFN-47 — Govern the contract between teams, not the code inside themTeams own services end to end; one team owns the gateway that dispatches to them. Govern exactly one thing centrally — the contract at the boundary (schema, identity, errors, idempotency) — and enforce it at runtime. Don't mandate libraries; ship them as an opt-in blueprint.Why it's cited here: Why clear contracts between teams are also the map that tells you who to send a report to.Open ZFN-47 → — clear team contracts are also how you find out where to send a report.

Changelog

• 2026-07-29: First published as a Field Note.