Calibration
Under, just right, over.
| Situation | Under | Just Right | Over |
|---|---|---|---|
| Scoping this week's work | Treats the ticket as the whole job. Does not ask what larger outcome the work is for. | Names the larger outcome, then cuts this week to the smallest slice that tests it. The team can see the ambition and still finish something real by Friday. | Inflates a one week ticket into a program before anyone has tried a small version. Nearby commitments slip while the plan grows. |
| A customer asks for a tweak | Builds exactly the tweak and stops. Never asks whether the request points at a bigger gap. | Ships a useful fix this week and writes down the larger need it hints at. The customer is helped now, and the next bet is informed instead of locked into a dead end. | Pauses the tweak to redesign the whole product around one request. The customer waits, and the team spends the week on a vision that nothing can test yet. |
| Writing the proposal | The writeup only covers what the team already knows how to do. The ask is safe and easy to forget. | States a destination that would matter if it worked, then proposes a cheap first proof. Reviewers can argue both the ambition and the first step in the same meeting. | The proposal is all destination and no first step. The room agrees with the vision and leaves with nothing to build this week. |
| When a constraint feels fixed | Treats headcount, tooling, or policy as immovable and shrinks the idea to fit. Nobody asks whether the constraint should change. | Names the constraint, checks whether it is real, and either works around it or makes a specific ask to lift it. The idea stays large enough to matter, and the ask is concrete enough to answer this week. | Insists every constraint come off the table before any work starts. The team waits on permissions while a smaller proof could have run. |
| The standup update | Reports only the task. Teammates cannot tell what larger bet the work belongs to. | Ties today's task to the larger bet in one sentence, then says what will be true by Friday. People leave knowing the direction and the week's proof. | Uses standup to restate the long vision. The update runs long and nobody knows what is shipping. |
| Reviewing a design | Approves a design that only clears the current ticket. Does not ask what happens if the bet actually works. | Asks how the design would hold if usage grew, then accepts a simpler first version if the path to that scale is visible. The author leaves with a small build and a named next constraint. | Rejects every simple design until it handles imagined future scale. The first version never ships, and the team keeps redrawing. |
| Picking the next experiment | Picks the safest test, the one that cannot change anyone's mind. The bigger question stays untouched. | Chooses an experiment small enough to run this week that would change the larger bet if it failed. The team accepts a clear no in exchange for a clearer direction. | Designs an experiment so large it needs new infrastructure first. The question that could have been answered this week waits. |
| A workaround shows up | Notes the workaround and moves on. Treats it as a one-off instead of a signal of a larger unmet need. | Eases the immediate pain, then spends a short pass asking what job people are hiring the workaround for. A bigger opportunity is named without dropping this week's work. | Throws out the current plan to chase the workaround as the next platform. Focus scatters and committed work slips. |