---
id: 50
title: "See something, say something — you owe a report, not a repair"
status: current
kind: note
date: 2026-07-29
authors:
  - "Theo Zourzouvillys"
tags: [culture, ic, leadership, process, security]
summary: "Two standing duties beyond your assigned work: see something, say something, and leave things better than you found it. But the duty is to report, not to repair — route it to the owner and move on. Security issues always go to security, including ones you fixed yourself."
supersedes: null
superseded_by: null
aliases: []
crossrefs:
  ZFN-2: "Why a security observation outranks the cost of interrupting someone — when the two conflict, the interruption loses."
  ZFN-8: "Why a report carries a named author instead of being laundered as anonymous concern."
  ZFN-27: "Why raising a problem in someone else's system is the work rather than hostility, so reporting should cost the reporter nothing."
  ZFN-29: "The same protection applied after the fact — you only hear the truth about a failure if telling it is safe."
  ZFN-47: "Why clear contracts between teams are also the map that tells you who to send a report to."
references:
  - id: bystander
    title: "The bystander effect (diffusion of responsibility)"
    url: https://en.wikipedia.org/wiki/Bystander_effect
    abstract: "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."
  - id: andon
    title: "The andon cord (Toyota Production System)"
    url: https://en.wikipedia.org/wiki/Andon_(manufacturing)
    abstract: "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."
  - id: boy-scout-rule
    title: "The Boy Scout Rule — Robert C. Martin, 97 Things Every Programmer Should Know"
    url: https://github.com/97-things/97-things-every-programmer-should-know/blob/master/en/thing_08/README.md
    abstract: "Adapts 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."
  - id: asrs
    title: "NASA Aviation Safety Reporting System"
    url: https://asrs.arc.nasa.gov/
    abstract: "A 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."
---

## TL;DR

Working in an engineering org carries two standing duties that appear in nobody's job description:
**see something, say something**, and **leave things better than you found it.**

The part people get wrong is assuming the first obliges the second at full scale. It doesn't. **You
owe a report, not a repair.** Noticing a problem does not conscript you into fixing it — the report
*is* the contribution, and it is complete work on its own.

So: **route what you see to whoever owns it.** Bugs and design problems go to the owning team with
enough context to act on. **Security issues go to security, every time** — not through your own
severity judgment, not into a public channel, and never quietly fixed and forgotten. **Leave things
better** is the small-radius half: the drive-by improvement inside the thing you were already
touching, bounded so it stays reviewable. And say something about the *organization* too, not just
the code.

## 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
effect](ref:bystander) 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 cord](ref:andon) 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-2](/zfn/2-engineering-priority-ordering/) puts security at the top: when
the two conflict, the interruption loses.

> [!aside] The three people who already knew
>
> The tell that an org has lost its reporting flow is a triage meeting where three separate people
> say "oh yeah, I've seen that" about a bug filed for the first time that morning. Nobody was
> negligent. Each of them clocked it in passing, assumed the ones closer to it already knew, and
> went back to their own deadline. The information was in the building the whole time — it just
> never got written down anywhere the owner would look. That isn't a people problem. It's an org
> that made reporting feel like volunteering.

## 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-47](/zfn/47-govern-the-contract-between-teams/): 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 reporting](ref:asrs) 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 rule](ref:boy-scout-rule), 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-8](/zfn/8-dont-speak-for-anonymous-people/)).
- **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-27](/zfn/27-no-assholes-strict-definition/) draws that line before the fact — raising a
  problem is the work, not hostility — and
  [ZFN-29](/zfn/29-blameless-culture-with-a-hard-line/) 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 effect](ref:bystander) — why the number of people who can see a problem is
  inversely related to the odds any one of them raises it.
- [the andon cord](ref:andon) — the two-sided deal this note is built on: anyone may signal a
  defect, and someone is obliged to come.
- [the campsite rule](ref:boy-scout-rule) — leave-it-better, scoped to the code you were already in.
- [confidential near-miss reporting](ref:asrs) — aviation's non-punitive model, and why the problem
  you caught before it bit is still worth reporting.
- [ZFN-2](/zfn/2-engineering-priority-ordering/) — why a security observation outranks the cost of
  the interruption.
- [ZFN-8](/zfn/8-dont-speak-for-anonymous-people/) — name it and own it; a report carries weight
  when it has an author.
- [ZFN-27](/zfn/27-no-assholes-strict-definition/) — raising a problem in someone else's work is the
  job, not hostility.
- [ZFN-29](/zfn/29-blameless-culture-with-a-hard-line/) — the same protection after the fact: you
  hear the truth only when telling it is safe.
- [ZFN-47](/zfn/47-govern-the-contract-between-teams/) — clear team contracts are also how you find
  out where to send a report.

## Changelog

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