Marta ran operations at a mid-sized distribution centre, and in spring her company approved a small fleet of autonomous carts to move totes between packing stations and the dispatch dock. The vendor demonstration had been flawless. The floor team was curious. Then Marta did something her director found slightly odd: she booked the canteen for an hour, put out biscuits, and told her supervisors, “Assume the robots have been a disaster. Tell me what happened.” This is the story of that hour, and of how a pre-mortem shaped a robotics rollout that could have gone very differently.
The room, the biscuits and the blank cards
Marta handed everyone an index card. She asked for stories in the past tense, with no names and no politeness: “Six weeks after go-live, the robots were switched off because…” The room started slowly. A supervisor admitted, grinning, that he had been dreading this meeting because he had a list in his head already.
Within ten minutes the cards piled up, and the stories had a common texture. They were not about artificial intelligence or dramatic crashes. They were about ordinary floors and ordinary people.
What the cards said
- “The aisle by packing station four was always full of pallets, so the carts kept stopping and queueing.”
- “The wifi had dead spots near the freezer door, and carts froze there.”
- “Night shift was never trained, so they unplugged a cart that seemed stuck.”
- “Nobody knew who to call when one stopped at two in the morning.”
- “Pickers walked in front of the carts out of habit and the carts stopped constantly.”
- “The vendor updated the software and routes changed overnight.”
Marta noticed that the cards mentioned almost nothing about the robots’ capabilities. The risks lived in the building, the shifts and the habits. This matches what robotics teams often report: the machine is the part that was designed and tested, and the workplace is the part that was not. The overview of how automated guided vehicles fit into warehouse work makes a similar point about preparing the site and not only the vehicle.
From cards to a short, real plan
Marta grouped the notes into four clusters and asked the supervisors to vote on the two that scared them most. “Nobody owns a stopped robot at night” and “the building was not ready” won. Her team then wrote one action each, with a name and a date.
- A walk of the whole route with a floor supervisor and a facilities technician, noting every blocked aisle and wifi dead spot, with a fix list due before the carts arrived.
- A one-page card taped inside the control cabinet, listing who to call at any hour and what a stopped cart usually means.
- Training sessions for all three shifts, including a ten-minute “what to do when it stops” demonstration.
- An agreement with the vendor that software updates would be announced in advance and tested on one cart first.
The fleet side of the plan benefited from reading practical guidance such as beginner advice on keeping a group of robots running smoothly, which helped the team decide how to watch the carts without drowning in alerts.
A thought borrowed from the security crowd
Marta’s cousin works in software and had once sent her an article from DevSecOps Now, a DevSecOps site with a blog about securing CI/CD pipelines. The idea she took from it was simple: treat the path by which a change reaches a live system as something that can break. For her, that path was the vendor’s software update arriving on the floor, and it earned a line on the plan.
One more detail from the voting stage is worth keeping. Marta asked each supervisor to say which card they believed least, and the room laughed when the least-believed card, about the freezer door, turned out to be the one a technician had already seen happen at another site. Disagreement about likelihood is useful in itself: it tells you where someone should go and measure instead of guessing, and the freezer-door check cost a single afternoon with a tablet and a walk around the dock.
Go-live, and what actually happened
The first week was not smooth, but it was calm. A pallet appeared in the narrow aisle despite the new markings, and carts queued exactly as one card had predicted. The supervisor who had written that card walked over, moved it and added a floor line. On the second night a cart stopped near the freezer; the night-shift lead read the card, made one call, and the cart was moving again in minutes. Nobody unplugged anything.
The vendor’s software update arrived in week five. Because the team had asked for notice, it was tested on one cart first, and a changed route that would have clogged the dock was caught and reported. Handling this kind of surprise is the same family of ideas described in the piece on designing robot systems that cope with faults.
What Marta would tell another team
When a younger manager asked her later what mattered most, Marta said three things. Hold the session before the robots arrive, because afterwards everyone is defending a decision. Invite the night shift, because they will see things the day team never does. And write everything on cards, because nobody argues with a card.
She also said that the exercise changed the mood. The supervisors, who had expected to be told how to work around the new machines, felt asked instead. Their warnings became the plan, and a plan made of their own warnings is a plan they defend.
The robots now move totes every day. The canteen biscuits, she admits, were the cheapest piece of equipment in the whole project.
