I’ve had engineers come back to me more than once with a bug they want to close out. The version I remember best went something like this: hey, I have this bug filed, but it’s not really a bug. Operations and the associates aren’t using the system right. They’re pulling carts too early.
My response: it’s not a bug. This is how they use the system. We need to be resilient to how people actually use what we built, not just to the standard process we wrote down. Standard process isn’t the be-all and end-all. People are going to use our systems the way they need to, and that’s okay, as long as we plan for it and we’re ready to adapt.
A few of the other folks on this blog have been getting at pieces of this lately. Gwenn wrote about the myth of collaborative robotics and how, if people don’t trust the robot to stop for them, they’ll find another way to get the work done. Tina wrote about the mushy middle that people quietly absorb until you scale, and about the mythology operators build when a system doesn’t explain itself. And Dani wrote about tracking the verbs people actually perform instead of the job titles we design around.
The piece I want to add ties back to my last post, which was about systems thinking. People are part of the system too. I think that’s the mental model a lot of us are missing, and it changes what we should be designing for.
Ops is making it work in the real world
A few years back we launched the first building of a new sortation type. It had way too many process paths for any human to keep track of. Then the conveyance didn’t work, and we were on the verge of not launching at all.
What we landed on was running our process paths with the software the way it was designed, but running them in a different way that worked better for that building and filled the gaps from the conveyance not running. I already knew people were going to do what they needed to do to run their building the way it needed to run. Operations took a system that had been designed for specific scenarios, and in some ways in isolation, and made it run in the real world.
It was really clear to me, yet again, that our operations teams are really smart. They’re going to do what they need to do with our software to run their buildings effectively. Sometimes that’s the way we designed it. Most of the time it isn’t.
And honestly, I don’t think that’s a failure on either side. Every building runs differently and every ops team runs differently, and they’re doing what’s best to meet the requirements of their own building.
We can’t build a system that meets every requirement for every version of how someone might run a building. What we can do is design for how the building overall needs to run, and build in enough resilience, buffer and leeway for operations to run it the way they need to. Then we get their feedback, we incorporate it, and we work with operations instead of against them.
Standard work only takes us so far.
When nobody knows what the other side needs to know
That kind of adaptation doesn’t always go well, though. Sometimes it’s quietly doing harm that nobody on either side can see.
On one of the stations I’ve worked on, once we started really digging in with the training teams, we found out that the people training our new associates were teaching them the wrong things. These are the people who are really, really good at the job, the ones trusted to bring everyone else up to speed. And they were doing it with the best intentions.
They were teaching a fill level well below what the system could handle, teaching a manual check for something the system already calculates, and teaching a habit that was quietly causing quality defects.
Because they didn’t understand the system, we had associates doing a lot of harm to it with the best intentions in mind. They just didn’t know. And because it was coming from the trainers, it was going out to every new person.
The other one was pretty recent. We were on site talking to an operations manager who explained how he’d set up his building to run. He was toggling parts of the automation on and off based on what another system in his building was doing. Ours wasn’t designed with that in mind, and we hadn’t thought about the cascading effects. He didn’t know how our system was designed either, so he made some guesses. The way he was running it worked really well for the other parts of the system, but not for ours, and he was actually getting frustrated with how it was going.
He did reach out. That’s part of why we went to see it in person. We just didn’t understand what he was asking for. Without actually being there and talking to him, we were never going to figure it out.
The people part doesn’t have an owner
We own how the system performs, and operations owns running the building. But how people actually behave with the system, what they believe about it, and what that costs us should really sit with us. I don’t think we’ve built up the right expertise to do it yet, and I don’t think we incentivize it until it’s too late either.
It moves the system numbers just as much as an algorithm does. Sometimes we do write the requirements, and we get lucky and have someone like Dani, Tina or Mikell on the program. But translating that into engineering execution, and into the training and incentives for associates, is a much harder thing to do. So it shows up as bugs that get closed as user error.
The other place we’re not as good at this is with products that are already out in the field. When we’re improving something that’s already running, or troubleshooting it, we don’t take the human element of those changes into account nearly as well as we should. And it’s often more important there, because people are already trained and incentivized in specific ways. Changing that is a much harder lift than training someone on something new.
On one program we now have a whole category of features listed out for quality that are about frustration, and it’s so spot on. People act differently at different emotional levels. When people are frustrated, they’re going to throw stuff across totes. If they don’t trust the system, they’re not going to listen to the guidance from the system. We see that all the time, so now we design for it.
And I want to be really clear about something, because I never want this to read as the people not doing their jobs. They are doing a lot of work, and it’s hard work. As simple as we make it, it is physically taxing, and at times it’s mentally and emotionally draining too. I encourage everyone who builds these systems to go do the job, and to do it for multiple hours at a time. Do the jobs upstream and downstream of your system too, so you understand why the work comes to you the way it does, and what your work does to the people on the other side. It’s not enough to just go watch. It is hard.
Don’t make the associates think unnecessarily
This one came from that same station.
We had two modes. One where the associate verified every item, and one where they verified a single item and then moved the rest as fast as they wanted. Some associates were incredibly fast in that second mode.
But switching between the two modes cost them. When they had to change how they were working, they slowed down or their quality dropped. We were scared that standardizing on the slower mode would improve quality and cost us rate. It did the opposite. Rate went up overall, and so did quality. Once associates weren’t deciding which mode they were in, they had one process to run, and that simplification moved both numbers.
That’s what I keep having to reiterate to people. Simplify. Bring down the cognitive load on the associates.
It’s okay to make associates think when it’s important. But they can only carry so many things in their head at once, so the things we ask them to think about need to be the most important ones, and they need to be actionable. Not extra thinking for the sake of thinking.
Don’t make the associates think unnecessarily. There are places where human judgment is always going to beat the system’s, because the person has more information than we do. So use that judgment wisely. Don’t ask someone to hold something in their head for an entire session. Ask them to make a call in the moment, where their judgment actually helps.
There are going to be places where we have to take trade-offs, where a person really does need to make a call. Take the trade-offs. Just make them on purpose, with someone actually looking at what it costs, instead of finding out later in a quality report.
So what do we do about it?
Go do the job. Actually work the station, for hours, not a walkthrough.
When what people actually do doesn’t match the design, treat it as feedback instead of user error.
Sit down with the people teaching the job and have them teach it to you. Come in as neutral as you can, which is very hard to do on your own system. Listen first and get the feedback. Don’t come in solutioning or correcting.
Track cognitive load and be aware of it. Put it in the requirements and make the trade-offs against it deliberately, the same way you would any other constraint in the system.
Know what the people in your system are actually incentivized on, and influence it where you need to. Their incentives shape behavior more than your design does. That one deserves its own post, so I’ll write more on it.
People are not broken. They’re doing what makes sense given what they know and what the job demands. And if we were doing it, we’d do exactly the same thing.
Obligatory Note: All thoughts, opinions, and experiences are my own, and do not reflect the opinions or stance of my employer.
