The Burger House: A Tale of Systems Thinking, Bottlenecks and Cross-Functionality

A few years ago, a small burger house opened on a narrow street in the business district of Rio de Janeiro, my hometown. A lot was going on there in the wake of the World Cup 2014 and Summer Olympics 2016. The idea was good: few, but very high-quality ingredients, and an open, visible kitchen in a small, cozy place.

As we used to run some of our training classes nearby, there was a day when my business partner Rodrigo de Toledo invited me to try their burger. We got there, I stood in the cashier line and waited just a little bit. The first thing I noticed was their system was optimized so ordering would be very efficient: the options were very visible and it very clear what I had to do. And then, when it was my turn to order, I had to choose: hamburger or cheeseburger? Add some bacon? Tomato, lettuce, onions, pickles, ketchup, mustard, house sauce? Add soda and fries? I made my choices, paid for your burger, stepped to the side and then… the whole experience went awry.

A bunch of people was standing disorderly at the waiting area, hoping to get their food while other people behind a counter were struggling to assemble the burgers and put together a large number of orders to deliver them to the hungry customers. Waiting a long time, fighting to grab your order just to find out you got the wrong burger or with unexpected ingredients was not unusual.

A few weeks later, Rodrigo went to this place again for a burger, and one of the two cashier positions was closed. The guy who was supposed to be there called sick that morning. Can you guess what happened? Chaos would you say? Not at all.

Here's what he experienced: he got to the store, has stood in line for the only available cashier and, of course, waited a little longer than usual. And then he had to choose from the few options available. A couple of individuals in the back were searing some burgers and frying potatoes ahead of time. He paid for his order and stepped aside, where surprisingly a few people were orderly standing waiting for their burgers. On the other side of the balcony, he could see people assembling the burgers and putting the orders together at a synchronized good pace. In a minute, he grabbed his burger in a tray and moved to the back where he could sit and enjoy his lunch. Cool, huh?

Yes, you got it well: the experience had improved! Way better, and one person shorter at the store. Any idea how this is possible? Please let me explain the "magic".

In the regular days, the assembling station - where a couple of line cooks assemble the burgers and put the orders together - is a bottleneck. The two cashiers, along with their optimized ordering system, are throwing a lot more work to be done than what is supported by this station, leading up to growing inventory, that is, orders to be delivered. Which puts pressure on the people working at that station: "Oh my god, we've got a huge number of orders to prepare!".

Those customers standing there waiting for their burgers - the next step in the flow - add to the pressure on that bottleneck. The cooks want to keep up, and they speed their pace over their capacity, which makes quality to fall. Lower quality means delivering burgers to the wrong people, and with the incorrect ingredients. Customers will return the food, which ends up lowering the throughput. As a result, they are selling fewer burgers.

What happened when the cashier didn't show up for work that day? A lower rate of orders, which relieved the pressure on the bottleneck. Luckily, the order inventory went down and stabilized to just the sufficient amount, so the people assembling the burgers could do the work, just in time. And they started doing it efficiently, in a sustainable pace, with fewer errors in preparation and delivering the food to the right people. Therefore, fewer people were standing there waiting for their orders. Yes, there was a longer wait at the cashier line. But not only the whole experience was a lot smoother for the consumer, as I can bet system throughput - the number of burgers sold - was higher that day (though nobody actually measured it).

But you know what? This causality is so counter-intuitive that the restaurant manager got the second cashier back the next day. And… the problems were back.

Just a few months ago, I was at an airport - as usual - in Porto Alegre, a southern Brazil city. If you like great meat, that's the city you want to go. But this time, I was just watching one of these international fast food chain stores at the food court. No real meat involved, then.

They had like five cashiers open. I could identify a few other stations, such as burger frying, burger assembly, potato frying and salad assembly. The cashier herself pours soda and puts the order together.

Suddenly, the store manager yelled something at the back, and one employee closed her cashier, washed her hands and went to help at the burger frying station. It took me a few minutes to understand the beauty of what happened there: the two guys at that burger station were in trouble, and the burgers weren't coming out as fast as needed to supply the orders. Therefore, orders started to accumulate. With the rising order inventory, the manager understood they were about to get deeper and deeper into trouble. Clearly, at that moment, that station was the system bottleneck.

Maybe that employee was a wizard at the cashier, but… where was she more valuable at that moment? Throwing more orders at the other stations? That would not only not increase the number of burgers sold, as it could, in fact, decrease it! So she could just stop doing her work, which would be better. But there was way more value on having her assisting burger frying, in any way she could possibly do to help speed it up.

Of course, for that to be possible, that employee needed to know more than her single specialty - being a cashier. She needed to know something about frying a burger. Instead of professionals who know a lot about one single thing, people who can also do a couple of other things well are needed. It doesn't matter whether she would only be able to be of some help, any help, or if she could do the whole act, as long as if with sufficient quality. Any of that would bring value to the system, where working at the cashier at that moment would not.

And what if, in another moment, the bottleneck laid on another station, like assembling the salads? She or someone else would need to know how to help there as well. Maybe another cashier?

The point is, given all activities needed in a system to produce something end-to-end (in that case, to deliver an order), the more of it team people know how to do, the better it is for the throughput of the system. Having cross-functional individuals is the key there.

It is not hard to figure out that whatever your system produces, whether it is burgers, software or anything else, its throughput will always be limited by its bottleneck. It will never deliver faster than what the bottleneck allows it.

Not onIy that, but if you optimize any stage of your system before the bottleneck, there will be a rising inventory, which has its cost, and will possibly also increase the pressure over the bottleneck and lead it to sacrifice quality. If you optimize any stage after the bottleneck, it will starve and keep asking for more, thus increasing the pressure on the bottleneck as well. Both may help reduce the throughput. In other words, optimizing any stage without looking at the system as a whole - what we call "local optimization" - will possibly lead to system sub-optimization.

It is important to notice that, in that case, they used a manager to tell them when and how to act in those situations. But, with a self-organizing team, its members themselves would find ways to understand when their work in progress had reached a reasonable limit and then take action.

Now picture this pretty usual software development team. The DBA is busy creating and updating the database tables. The back-end developer is busy building the API to access them. The business logic person is busy creating the classes. The front-end developer is busy creating the dynamic HTML. The designer is busy creating the design. And the tester, at this moment, is idle waiting for something to test. The manager is happy because he is keeping almost everyone "productive." But at what rate are they creating anything end-to-end, anything that works?

They do get a lot started, but not so much done. What if they would work in priority order, starting with the most important things? What if they would limit the amount of work they could have in progress, so they wouldn't start anything new before finishing more important stuff? What if they would break those silos or, at least, blur those borders and start sharing responsibility and helping each other?

Impossible? Well, as with the second burger house story, they would get a lot more done! Once testing is the bottleneck, it is more important that the DBA guy helps in that task than if he creates one more table. Or if the bottleneck is the front-end, the back-end guy would need to give a hand! As a benefit, one would learn from each other, and they would grow as a team!

In this new scenario of better throughput, quality, and motivation, titles lose importance and having different knowledge and skills becomes key. No matter what the team members used to call themselves, they will now have different jobs with their teams: one is doing whatever each do best, but only when it is necessary. The second is teaching others, which is not just a gift to others, but to the team as a whole and thus, back to them. And three, getting out of the comfort zone, learning from others in the team and taking on work in different areas whenever there is a bottleneck.

Fourth would be working with their managers, so they can help or, at least, get out of the way. As counter-intuitive as this all is, there is no surprise in learning that too many managers today simply don't get it. They worry about people doing their jobs in their silos. They worry about keeping people busy - "busyness" is their key metric. They worry about people having a lot started, but they forget that finishing stuff is what really matters.

As we often hear from practitioners of Kanban, a framework for knowledge work inspired in the Toyota Production System and the Theory of Constraints, the crucial thing is to "stop starting and start finishing!"

About the Author

Rafael Sabbagh has over two decades of experience with a variety of digital product development scenarios, programming languages, methods, and techniques. Rafael is the co-founder of Knowledge21, an international training and consulting company, and leader in Brazil’s market. He is a Certified Scrum Trainer (CST) and a member of the Scrum Alliance Board of Directors (2015-2017). He has a master’s in business and a Computer Engineering degree. Rafael has done training and consulting in over 20 countries in the last few years. By traveling and interacting with different communities and cultures, he has got a global view on how software is being developed around the world, what the main challenges are and ideas on how one can get around them. Besides IT conferences, Rafael has also been to over a dozen Scrum Gatherings in different countries (as a speaker at many of them). He wrote and published, in 2013, the first book about Scrum written in Portuguese. It is today a well-known reference in his country.

Contributions by Rodrigo de Toledo, Marcos Garrido, and Carlos Felippe Cardoso