A few months back, the small Japanese restaurant down the street from me was renovated. The owner redesigned the layout of his business to solve a vexing problem: How to stay in business when faced with a continuing pattern of employees not showing up for work.
The layout of his restaurant went from this:
Figure 1: The pre-automated local Japanese restaurant
To this one:
Figure 2: The neighborhood Japanese restaurant after automation
The new layout eliminates the need for servers. It turns out, the people he hired to take orders and bring food from the kitchen to a customer’s table just weren’t showing up for work. We’re not talking one or two random no-shows; rather, it was habitual behavior among the workforce he hired, mostly high school grads and college students. Each day was turning into a crapshoot. He’d get a text an hour or two before the beginning of a shift reporting some other excuse: sickness, lost dog, whatever. Usually, the note closed with the inevitable, “Sorry, won’t be in today. See you tomorrow.”
So he automated.
Related Content: An Unanticipated Obstacle to Full Automation
The new design is working out well. You come in. He directs you to a table. There’s a touch-screen monitor at each table diners use to place their order. The orders go directly to the kitchen, which is separated from a row of tables by a glass partition. When a dish is ready, the owner (who also happens to be the chef) or an assistant passes the food out to the diner’s table under an opening at the bottom of the glass (see Figure 2, above). At the end of the meal, the owner meets you at the front station where you pay the bill. No more wait staff. No more cashiers. No more “I can’t make it today” texts.
Automating to Stay in Business
Removing the servers and using automation was not an easy decision for the owner. His business is not some large-scale, multi-unit corporate enterprise looking to automate away human labor to increase profit margins. This guy has worked seven days a week for 10 years to build his business into a mainstay of the neighborhood. He prefers to employ humans but he can’t. He’s automating because the available human labor is unreliable. He believed that using such an unreliable workforce would eventually put him out of business. He really needed to make the change.
So he did.
No Employees, No Employee Retention
So far, things are going well. However, now the kitchen staff is beginning to join the No Show Club, despite the fact that he is hiring kitchen workers at a rate of $14 an hour—a good wage for kitchen work. What’s causing people to go MIA? Maybe it’s the product. After all, how many California rolls can you make before going nuts out of boredom? Maybe he’s difficult to work for. And I doubt they’re jumping ship to work at Mickey D’s; the Golden Arches is only paying $10 an hour. In any event, the owner has a employee retention problem that, my guess is, he’s going to solve using automation.
What Does This Have to Do with DevOps?
At some point, every human being becomes unreliable. Some have poor work habits, but most simply are being human and humans make mistakes. That’s how we’re built. Some of us make a few mistakes, while others make a lot. But, we all make mistakes. Most of us learn from our mistakes, and we still make others. Our human nature to make mistakes makes us inherently unreliable.
Machine intelligence doesn’t have this problem. It will get things right, eventually. And then, once operating reliably, it’s rare for that intelligence to revert to a state of unreliability. A human can become unreliable at any point in time—taking a sick day, resigning from the job or all the mistake-making that comes with learning a new skill or technology.
We in DevOps have a lot in common with the owner of my neighborhood Japanese restaurant. Most of us have worked really hard to keep our customers happy and coming back, well beyond the typical 40-hour work week. For the most part, we’ve been successful.
Our success increases demand. When demand goes up, the complexity of our work increases, as does the need for more reliable operations. But at some point, our inherent human unreliability kicks in. We make mistakes. To keep things going reliably, we automate. Then we move on to the next thing. Fortunately, for the foreseeable future, there will be a “next thing” to move on to.
Still, intrinsic to our work is a motivation to eliminate human labor from the technical landscape. We have no evil intention. We just want to do the best job possible. Given the choice between a script and a human doing the work, we’re going to choose the script every time. The script will evolve to 100 percent reliability. The human won’t.
As I said, for now, it’s not really a problem. There will be a next thing to move on to. And, in terms of my neighborhood sushi joint, maybe the out of work no-shows will get the message about the value of showing up at a job on time and ready to work. Or, maybe they won’t. Maybe as automation becomes the standard of labor fulfillment for repetitive work, immature workers will never be given the opportunity to get the experience they need to enable them to master basic employment skills. After all, they’re human and some point will become unreliable. So why hire them at all? Why not get a few computerized gizmos to do the redundant work and then focus on keeping customers satisfied and staying ahead of the competition?
Having no employees translates into having no unreliable employees. A business without unreliable employees is an efficient business. Efficiency in business is what it’s all about.
And this, my friends, is the case against human employment in the age of automation.
