I spent a long time in my teens and early 20’s working in restaurants. To be honest, I loved just about every minute of it. It’s exciting, you’re never idle, and it’s usually not boring: you either get immediate gratification from happy customers leaving a nice tip, or you’re on the defensive, thinking on your feet to save an experience after something has gone wrong.
In contrast, technology, I’ve found, requires more of an investment to get to the gratification of a job well done. I’ve also always felt like certain aspects of technology, like coding, are somewhat therapeutic for me, whereas restaurant work mostly wasn’t. And, occasionally, technology work can be monotonous and boring.
In spite of the quite dramatic differences between the two working environments, I sometimes find myself thinking about restaurants when I’m working on software or systems. It turns out that some of the tenets of restauranteurism, or just waitering or bartending, can be applied to work in the tech sector. Allow me a bit of license to riff on some of them here:
- Treat your station as a single table. If one table needs a refill on a drink, chances are so do one of the other 4 tables that are all within 10 feet of that one. Save yourself some running by checking with all of the tables when one asks for something. In geek terms, this maps to looking for wins across multiple projects in your environment. Does your app need user authentication or a mail transport service? Chances are other projects do too. Looking for these kinds of wins can also help distribute the load of creating the requirements, and foster a sense of shared ownership in the result.
- Anticipate the need. Your customers shouldn’t have to ask for everything they need. Ideally they wouldn’t need to ask for anything they need, because you’d keep an eye on their drinks, you’d notice that someone wasn’t eating their salad and suspect something is wrong, you’d know that having kids means the first thing to the table is a huge stack of napkins, etc. The point is, there’s what’s happening now, and what is, in your professional opinion, likely to screw that all up. Your experience will likely guide you to solutions that are likely to keep that from happening. If not, you’re about to get more experience. Just like in technology 😉
- Presentation counts. All restaurants fiddle with the light levels, the music rotation, how food is placed on the plate, the garnishes added to drinks, and any restaurant you’d want to eat in is fastidious about tiny, tiny details from sweeping the entry foyer, to replacing tablecloths, to tossing old-looking napkins, to replacing chairs with tiny pinhole tears in the leather. Why? Because a restaurant is, in the process of serving you, also constantly selling you through your experience there. Of course, your software should do this, but you can get deeper than that: all of those ideas you have that nobody listens to, or you can’t get approval for? You’re missing some details. You don’t have any metrics, or you’re giving a geeky experience to a business-y audience, or you’re not presenting your idea in the form of an experience, or you’re creating a vision of a present instead of a product in the mind of the person with the checkbook.
- Presentation can’t save poor quality. You can put all kinds of shiny AJAX-y Bootstrap-y stuff all over your site. It could be the nicest UI in existence. If the service doesn’t work, you’re toast. And those ideas you’re trying to sell internally? You’d better be confident they’ll work and have a solid execution plan, because a couple of bombs and no amount of presentation goodness is going to get you to “yes” again.
- Consistency! Food quality, presentation, service… the entire dining experience, from the moment you set foot on the property to the moment you leave, should ideally be completely 100% consistent. Completely predictable. Zero surprises. It makes the restaurant easy to get to know, because if you’ve seen one, you’ve basically seen them all. Now think about the naming of your variables. Do you abbreviate here and write it out there? Think about how you package your software. Do you sometimes provide an XML config file and sometimes INI format? Think about your code layout. Do you sometimes use inheritance and sometimes composition, when either will do? Do you sometimes test? Do you sometimes… anything? Small inconsistencies add up. I believe we’re pretty much all guilty of them sometimes, but we should all strive to minimize them.
- Minimize Complexity. Very little inside of a restaurant is complicated or complex. Inevitably, the friction points where small complications live are where problems arise. A huge number of issues within a restaurant are human error: mistaken orders, mismatching food to table when the tray is assembled, food under- or overcooked, drinks made wrong or sent to the wrong table, miscalculated bills, forgotten requests for drink refills or side orders, the list goes on for an eternity. Ironically, computers are employed to help with some of it, and the food service world is better for it on the whole. In technology, and I’m sure in most jobs, most of the issues are more with the people than the technology. From forgotten feature details to overlooked metrics, from miscommunicated load projections to undocumented security policies, the clumsy inner workings, and inter-workings of human beings gets us every time.
- Mise en place! This is a French term, and I don’t speak much French, but in a kitchen it means “have your shit together and easy to reach, kid”. Chefs on a line will have a shelf or some other space that’s within arm’s reach where they put bowls and bottles of things they need all the time. The pre-meal time for a chef is spent double-checking that this small area is picture perfect, double-checking that refills and extras will be easy to grab during the shift, and making sure there’s no excuse for failure. I see teams fail at this quite a lot, actually. The mise en place for a technology worker are all of those things that need to be in place in order for a service to go to production. Metrics and monitoring. Hardware allocations. Infrastructure service dependencies. Security concerns. Power! I cannot count how many times a service has gotten to the week of deployment before a request to allocate storage in production was created, or the number of times hardware arrived before anyone thought about where it would be plugged in, or what that would do to the uptime provided by the UPS during an outage.
Overall, I’d say it’s been for my progress in the technology industry to have grown and learned lessons from experiences in other industries, even if those experiences sometimes came from rather menial roles. Also, as my great grandmother used to say, all of that sweaty, smelly work was also good for me: “It builds character!”