The other night at Taco Bell

The other night I was in line for Taco Bell drive-thru. It was a one-window drive-thru with roughly four car lengths between the ordering station and the window. It was a particularly busy night, the Mexican Pizza just came back in stock, and the car in front of me just finished getting their order and pulled away. Before I could move up an employee stretched out the window and held their hand up to signal to me to not move forward. This wasn’t the first time I had seen this behavior, but in the past I always thought they were doing something cleaning related due to COVID-19. Tonight it dawned on me.

You see, in the quick-serve restaurant industry (fast-food) one of the metrics for service is how long an order takes to prepare. They have displays that tell each station what to put in for which order and a clock on each order showing how long it has been in the queue. When a station is done with their work they clear (‘bump’) the order and move to the next. The main order queue’s clock is stopped when the order leaves the hands of the cashier or drive-thru employee. Throughout the hour, day, month, etc. these order times are averaged and you can report on the order statistics/metrics. In fact I used to make some of these reports and their mega-rollup report the SDR (Sales Daily Report). These reports are kept and reviewed for store bonuses, staff performance, etc.

Fast-food metrics

So how to you improve your store’s performance in these metric? You can work faster or more efficiently. You can hire more staff. You can clear the order before you are technically done with it. All of these methods have their own issues. Working faster/efficiently is not always an option. With razor thin margins and low unemployment rates, hiring may not be feasible. If you clear the order before it is done you effectively just add the time to the next order. The last option is that you can stop taking orders. Yes, this can piss off the customer by producing longer wait times, but those wait times (which would be there regardless) aren’t captured in the system or in a metric.

THIS is what I believe they were doing when they asked for me to wait. With four car lengths between ordering and receiving if I had moved forward a new car would reach the order box and a new order would have its time started. With me sitting there an extra 2 to 3 minutes they could bleed down their order fulfillment times.

Note that the next time I went through (I enjoy my Taco Bell, thank you) I found that there was an additional metric of ‘time to take payment’ that the person at the window must take payment within 30 seconds of the car pulling up. So if the car doesn’t pull up the timer doesn’t start and they don’t fail their metrics. The person at the window that night was also helping to bag the food. I’m betting the cause was being short staffed. However, it still highlights employees fudging metrics and adds the question, “Are those good metrics to begin with?” And, no I don’t think they are.

What about our own metrics?

Ok, so that’s Taco Bell and for the record I’m not faulting the individual stores/employees for doing this. The restaurant culture of punitive metrics is a long rant I’ll keep to myself for now. And my audience doesn’t normally run restaurants, so why does this all matter? Because every team does something like this. They fudge a number or two, omit tickets that may be “out of family”, and tailor their metrics to exclude the areas of software development that are ‘inconvenient’ to report on. How do we fix this?

First, let me introduce a catchy named concept called the ‘watermelon project’, that is a project that seems all good (green) on the outside (to external people) but is having real problems (red) on the inside. I want clearly differentiate between projects who may have bad metrics but are generally working, and those watermelon projects that are covering up their failures with bad metrics. This is important because problematic projects need more help. Fixing metrics for a floundering project is a large task because you need sift through a variety of metrics to help find the cause of the failure. (Unless you already know the real cause, but if that were the case you should be fixing it rather than playing around with metrics.)

Discussing a good metric

With watermelon projects out of the way, lets look at metrics themselves. My criteria for a good metric is that it tells a story of how the project is doing, is tailored for the audience, and is as simplistic as possible.

What I mean by ‘telling a story’ is that the metric conveys the work and effort the team has put in; conveying both where the team was and where they are now. This showing of progress (or lack there of) offers rough a trajectory for the future. This is having the metric’s numbers in more concrete context. If I show that last week the team got five (5) tickets done, is that good, bad, and why? In contrast if I show that we completed five (5) tickets, where our average is ten (10), but our team was half staffed this week, you can put those numbers together and see that everything is nominal and going as planned.

For the audience, ask yourself who is trying to gain insight from your metrics? It is rare to find a single metric that is useful for both the internal team and external stakeholders. For example, Scrum’s velocity is great for the team to find trends in their work and figure out how to change. However, external stakeholders won’t understand what story points mean. If you have metrics that are bad for the audience you often invite concerns and questions from your stakeholders. These can be annoying to squash and can cause unnecessary project changes. What does an average of ‘24 items per sprint’ means. If you are averaging 24 points per sprint, why are you not doing 30 per sprint? If you did 15 items in your last sprint what failed? Do your sprints normally swing between 15 and 33 points or is there something wrong?

As mentioned, if a stakeholder with power doesn’t understand the metric and gets concerned by that they may force changes in the project. The standard, “I don’t understand it so it must be bad.” Rather find a metric that speaks the language your intended audience is comfortable using. For C-level or your project management office (PMO) that may be budget (actual cost), earned value, cost variance, and all of those project management calculations. For team managers that may be throughput (which is my favorite metric), for marketing or product services it may be schedules and remaining timelines.

This feeds into the last criteria, simplicity. The more you have to explain the metric itself, the more likely the metric isn’t worth using. I’m not talking about the story the metrics tell, but rather the meaning of the numbers and charts themselves.

Lets go back to Taco Bell for another taco and looking more at metrics. While working in restaurant software, I was once informed that the key metric Taco Bell used for location performance was the number of tacos it sold. That since almost all of their meals come with at least one taco, supposedly someone realized everything ends up averaging out to “more taco units sold = better the store performance.” How true this was/is, and the nuance of it, I’ll probably never know but it is an interesting concept and goes back to the idea of simplicity. Would multiple metrics trying to show every facet of the team’s progress be better than one main key performance indicator (KPI)? Can you turn that chart of many lines down to a few numbers updated on a weekly basis? This is the idea of simplicity.

For another example, I have seen some PMOs put stoplight dots in their reports as quick indicators of good, bad, and warning. “Team Y is doing X (Green Dot)”, “Team A is doing B (Yellow Dot)” This helps external stakeholders quickly review the report, “Team Y has a green light here and they achieved their delivery last month, so I’ll just skim this section. Team A was doing great, but they have a yellow light. I should pay a bit more attention but not stress out over it.” Again, the idea of simplicity.

Take-away

First, do not lie to your stakeholders. If your project is having problems be clear about that. It will lead to hard and unpleasant conversations, but those are needed. On the flip-side, if you believe your project is ultimately going well, be clear about that too. The disconnect between how you believe your project is working and what the metrics show is an important thing to look into. It will either show you that your metrics are bad or that your opinion needs adjusting.

Second, Take a look at the metrics, numbers, reports, and communication you are giving out. Are they telling the true story of what is happening, are they tailored to the audience (team, stakeholders, etc.) to help them understand, and are they as simplistic as can reasonably be? If not, or if you are unsure, talk to them and figure out what they want or would help them better understand.

Finally, I really wish Taco Bell had a wrapper that didn’t end up sticking to their hard taco shells, and rip the bottom off the shells as you scrape it out, and into your mouth so you don’t drop anything and make a mess with the beef and cheese all over the place, looking like a caveman shovelling food off the ground into your mouth. Yes, I can get the soft taco, but sometimes you want a corn shell and need to eat while driving so you can’t get a Mexican Pizza that you wished still came with green onions like it did in 2001… Time to go back to the drive-thru.