In a manager-report relationship, whenever a report encounters a problem (or wants to call an [[Audible]] on a previous decision), it's better for everyone if it's done in a way that minimizes the manager involvement to the minimum possible. This is because: * [[Time is asymmetric in organizations]], and manager has less time * Report has more context to make the decision However, reports have [[bounded accountability]], and they can't make arbitrary decisions, for instance, you can't take a feature website down because you received one cease and desist letter. Therefore, there needs to be a "protocol" between the report and the manager, and there are essentially different levels of updates that can happen there. Here's what it looks like for me: | Level | Description | Confidence in decision | | --------------------- | --------------------------------------------------------------------------------------------------- | -------------------------------------- | | 5 // FYI | Something happened, action already taken, but thought you should know | >95% | | 4 // Sanity check | Something happened, I'm pretty sure about what action to take, but please validate before I take it | 80-95% | | 3 // Solved dilemma | Something happened, we have options A, B, C to react to it, and I'm recommending option A | 50-80% | | 2 // Unsolved dilemma | Something happened, we have options A, B, C, but I'm actually not sure which one to go with | 10-50% | | 1 // Blocked | Something happened, and I'm not sure what to do, please help. | 0-10%, or<br>[[Knightian Uncertainty]] | As the relationship between manager and report grows, the report's confidence should grow and more and more updates should flow into higher levels. You can know this also by seeing that the suggested or taken action matches with the manager. It's also important to take into account how consequential and irreversible a decision is, [[One-way vs two-way doors|one-way doors]] should always flow to the lower levels. Last, it's not only applicable in a manager <-> report relationship, it also works when cross-functional partners need input from each other. For instance, if eng finds out that the original product spec is hard to build but there's a workaround, they can also go by this method, and then give whatever relevant update looks like to product. #published 2025-02-08