In standups you keep hearing engineers refer to a scaling limit as a known thing, but it has never appeared on any risk register or in any status report. What do you do with that?

Short answer

Widely known and never escalated usually means the risk has no owner and no threshold, not that it is being hidden. Get it written down with a trigger and an owner, and find out why the existing escalation path did not carry it.

Assume no owner before you assume concealment

When something is common knowledge on the floor and absent from every artefact, the usual cause is structural rather than dishonest. The engineers know the limit exists, they have no evidence about when it bites, and nobody has ever asked them to attach a date or an impact to it. A worry in that state cannot be escalated, because an escalation needs something a decision-maker can act on and "this will not scale forever" is not that. Meanwhile each engineer assumes someone senior already knows, because it gets mentioned in standups every fortnight and nobody has ever reacted with alarm.

Reading it as concealment leads to the worst available response, which is arriving at the team with the discovery framed as a governance failure. That gets you a defensive tech lead, a downgraded description of the risk, and no further volunteered information for the rest of the program. The information you just found came to you because people talk freely in front of you, and that is an asset with a very short half-life once you spend it badly.

Turn a worry into something a decision can be made about

The work is conversion. A risk that can be governed needs four things a standup mutter does not have: what specifically breaks, what observable measure tells you the limit is approaching, roughly when that measure crosses, and what it costs when it does. You get all four in a forty-minute conversation with two or three engineers, and your job in that conversation is to ask for numbers without pretending to know the system better than they do.

The right column is the version that can be escalated, funded, or knowingly accepted. The left column can only be worried about. Notice that none of the conversion requires you to be the deepest engineer in the room; it requires you to keep asking the dimension, the measure and the date until the answer stops being an adjective.

The measure matters more than the estimate. A risk with a monitored trigger — "review when peak writes exceed eighty percent of the ceiling for three consecutive days" — survives your own departure from the program and stops the argument about whether two years is really two years. A risk with only a guessed date invites the exact response the tech lead will give you, which is that it is far enough away to ignore.

flowchart TD
    A[Heard in standup, absent<br/>from the register] --> B[Ask engineers for<br/>dimension, measure, date]
    B --> C{Can a trigger<br/>be defined}
    C -- Yes --> D[Register it with owner<br/>and monitored threshold]
    C -- No --> E[Spike to establish<br/>the measure first]
    D --> F{Decision needed<br/>this program}
    F -- Yes --> G[Escalate with cost<br/>of acting and of waiting]
    F -- No --> H[Accepted with a named<br/>owner and a review date]

The branch worth pointing at is the bottom right. Accepted is a legitimate destination, but it is only legitimate when someone with authority accepted it in the open, with a review date attached. That is the difference between a decision and a drift.

Accepted versus never decided

A large share of long-lived technical risk has genuinely been considered and consciously deferred, and re-escalating it wastes credibility. So before raising anything, find out whether a decision already exists. Ask the tech lead directly whether this was ever put to anyone, and look for the artefact — a design document, an architecture review record, a note in a planning doc. If the deferral was deliberate and someone owned it, your contribution is to give it a trigger and a review date rather than to reopen it.

If no such artefact exists, then it has never been decided, and that is the finding. The distinction is worth stating explicitly when you raise it, because "this risk is unowned and undecided" is a very different message from "engineering has been ignoring a scaling problem", and only one of those keeps you welcome in the team's room.

Raise it with the team, not around them

The path that preserves everything is to co-author. You write the register entry with the tech lead's name on it as owner and yours as the person tracking it, you show them the wording before it goes anywhere, and you let them make the technical claims in the forum where it is raised. This costs you a few days and buys you two things: the description stays accurate, because the person who understands it wrote it, and the engineers learn that telling you things results in support rather than in a spotlight.

The failure mode is going straight to a director with a risk the team has not seen written down. Even when the risk is real and the escalation was justified, the team experiences it as being reported on, and the next scaling limit gets discussed somewhere you are not standing.

What actually separates a strong answer here

Weak answers stop at "I would add it to the risk register and escalate it". That is the mechanical half and it is the easy half. The part that distinguishes an experienced program manager is asking why the existing escalation path failed to carry this, and then fixing that: the risk review was a status meeting with no slot for unquantified worries, the register only accepted items with a numeric probability nobody could supply, or raising architectural concerns had visibly cost someone before. One risk found by luck is one risk. A path that now carries them is every future risk.

A risk everyone knows and nobody owns is not being hidden from you, it is waiting for someone to give it a measure and a name.

© 2026 Preptima. Originally published at preptima.com.