Confidence numbers stay human and per-leader - Brady translates them, Engineering does not remap to his scale
Situation
Bjorn brought Brady Dibbles push for a uniform, consistent cross-team definition of the confidence column. Peter rejected it in a DM thread on 7/29 evening and repeated the same ruling to Nathan on 7/30. Confidence is a human thing. That is why we call the column that. It is not computed immutable expectation of delivery for a reason. Justin is risk averse, so he will not put a 99 when he can imagine millions of ways for something to go wrong. Another leader might. The team will learn over time what Justins 90 means. On Bradys ask: the real and only question is what does Brady want to do with these numbers that he cannot do - what is he going to do with a 95 different than a 90. If Brady wants to turn the numbers into high/medium/low or into ranges in his own process that is fine, but that is him translating, not asking Engineering to fit an arbitrary mapping. If he wants a structured definition of exactly what high/medium/low means, now he is losing the experience of engineering leadership and having a function fill out his numbers. Peter also rejected high/medium/low outright: the minute you have high/medium/low it is not functional enough and you end up with twelve gradations and the same problem. And he told Bjorn to test it empirically - ask Duane if he can work with the numbers Justin is providing, the answer will be yes.
Reasoning
The confidence column exists to carry a senior engineers experience-based judgment, compressed into a number they can produce in four seconds and therefore keep current daily near a target date. A formula or a cross-team standard would strip out exactly the thing that makes the number worth having. Peter also named the second-order cause: Brady is WHY someone like Justin will not put high numbers down - if you are working with someone you feel is constantly looking for things to say you were doing wrong, you rapidly start communicating lower numbers. So a uniform standard would not fix calibration, it would drive the numbers down. The translation burden belongs on the consumer of the data, not the producer.
Additional Context
Same 45-hour window in which the TPS report was repointed at the ENGD board and Peter re-derived both boards from purpose at the Engineering Weekly. This is the third distinct attempt in a week by a peer function to make an engineering artifact serve their process shape. Peter also read the ask as a level signal to Bjorn: it is the sort of question a junior PM would ask, not a VP of prod.
Observed Evidence
Direct quotes across two sources one day apart. Slack 7/29: Confidence is a human thing. That is why we call the column that. Fathom 7/30: no, you do not [need them to mean the same thing]. Plus the empirical test instruction: Ask Duane if he can work with the numbers Justin is providing. The answer will be yes.
Matching Patterns
Confidence Breakdown
Reasoning Depth Analysis
People Involved
Source
reflection
AI Confidence
96%
Related Context
slack
Justin is risk averse. So he is not going to put a 99 when he can imagine millions of ways for something to go wrong. The team will learn over time what Justins 90 means. Bradys not going to get people on different teams in different domains to have consistent meanings for their estimates.
slack
Confidence is a human thing. That is why we call the column that. It is not computed immutable expectation of delivery for a reason. If Brady wants to make up his own translation formula, he can. But it will be wrong so frequently as to be useless.
fathom
Bradys like, well, I need the confidence numbers between Justin and Nathan to mean the exact same thing. I am like, no, you do not. These are confidence. They are in different domains. I want the value of your experience in those numbers.
Outcome
Aug 13 TPS report shows confidence spread wide and unnormalised across teams - no remapping to a common scale.
Rating: 4/5
Decision ID: 30102074-9ed8-498c-bb64-e3ee41214b4c