Over Engineering or Over Accountability?

Yesterday when I was in the billing queue of a South Indian restaurant in the bus stand, an unexpected error in their billing system caused significant disruption. The restaurant serves its dishes on banana leaves placed over plates, adding a traditional touch and easing cleanup. The billing process is closely tied to the kitchen inventory(or at least I hope so with a fixed count of each dish), ensuring the cashier knows the availability of each dish before billing. The inventory system started showing that banana leaves were out of stock. Since every dish required a plate, and all plates were associated with banana leaves, the entire billing system halted allowing only tea and coffee to be billed. The resturant has a self service system where the customer bills first and then with the physical copy of the bill customers goes to the serving section hands over the portion of the bill to the waiter, who then orders the dish to the kitchen team. In short if “no invoice copy, then no order”. As a result, 7-8 customers left without placing orders because the system couldn’t process any orders. The billing team solved it by adding some additional banana leaves count from their backend inventory system in 10-15min.

The issue stemmed from an unnecessary dependency, tracking the usage of banana leaves as an ingredient. Either the stock entered in the inventory was incorrect, or it became incorrect when the cashier and team had manually adjusted the inventory to resolve the billing issue, highlighting how an over-engineered system or over-accountability can create critical points of failure.

What I think went wrong was

1. It is totally unnecessary to add banana leaves as an ingredient for every dish.
2. It may be an instruction or a need to track the usage of ingredients, but they could avoid banana leaves adding to ingredients as its not a direct/must ingredient.
3. The stock of banana leaves entered in the inventory was wrong (or became wrong the cashier and team went and added a new set of banana leaves to it to solve the billing issue). Whatever be the intention or usecase of adding the banana leaves as an ingredient, it caused their sales reduction and manipulated data in the end.
4. It is also required to know where to STOP and what not to do when trying to perfect the system and experience.

Lessons for the Product folks

This incident underscores some of my thoughts on Product development and operations listing it below:

• Simplicity is Key: Integrate only essential features without creating unnecessary dependencies that can become bottlenecks later.
• User Experience First: Always prioritize the end user’s experience. A system should enhance, not hinder, customer satisfaction.
• Know When to Stop: It’s crucial to recognize the point at which additional complexity no longer adds value but instead creates potential for disruption.
• Graceful Degradation: Design systems to handle failures gracefully. An alternative billing method could have mitigated the impact.

Let’s strive for smart, simple solutions that enhance efficiency without compromising reliability.