Dashboards Aren’t Direction: Asher Perlmutter on Why Data Without Context Fails at Scale

Hi everyone. Today's guest is a seasoned franchise CTO, my friend, Asher Perlmutter. Asher and I have known each other for a couple years, and he's one of those people that just instantly connects the dots between technology and real world operations. Asher was previously the CTO of RBI, where he led technology across brands like Burger King, Popeyes and Tim Hortons.

And before that was working on big data problems at Microsoft and Google. Right now he advises a range of tech companies, including on the technology and consumer side, on how to scale smarter. Asher, welcome!

Thank you so much Gary. I'm really excited to be here.

Yeah, we're happy to have you. So let's kind of start with, you know, I gave you the two second background. I'd love for you to just give our listeners a little bit more on your background, how you made your way from the Microsoft and the Googles over to franchising.

Yeah, of course. So from an early age, I've always loved to build things. I, grew up in a house where my dad was an electrical engineer and instilled that creative mindset. Except he said, don't do electrical engineering, get out of the hardware space, do software, and you know, it really stuck with me.

So, went to Michigan, was always working on hackathons and projects, but wanted to go out to big tech, go out West Coast and learn from the best. Right? And so I interned in the Bay, spent some time at Google and then ultimately decided I wanted to be up in Seattle, with a little more of the outdoors as well, right.

That I loved, but really working on some interesting tech problems. So I was over at Microsoft working on Office 365 doing analytics across their whole customer base, which, at the time was about 10 million tenants and 900 million users. Yeah, so we were dealing with petabytes of data a lot before you know it became normal or accepted protocol.

But basically, we were looking at behavior across all Microsoft products, across the whole user base and providing reporting on usage and metrics that were going on across all these different companies. A lot of fun. And I did that for a few years, and then decided to pivot back to Google, but in Seattle, working on the Kubernetes and the app engine team. They were launching new features and coming out of Alpha. And so what happened, which was really interesting, was I still had that itch to get more involved with the end customer and be close to the user and have more ownership and responsibility. And so I was thinking of leaving Google and going to start my own business, and was put in touch with, RBI, the parent company of Burger King, Popeyes and Tim Hortons, which was based down in Miami where, where Burger King was originally founded. So flew down there, met the whole executive team. None of which were really tech literate, right? They, they knew they had an opportunity to accelerate the business, but didn't know how. So, I jumped at the opportunity to really come in and help shape the vision and future of the business with regards to technology.

So, I went and joined as the first engineer. They called me the director of engineering, but it was nothing really to direct at the time. So went through this crazy journey of working in the restaurants. I went, took a course in Burger Kings, making the Whopper, understanding all that.

I flew up to Tim Hortons, in Canada, and went to Tim's. Had to take the orders and I don't even drink coffee, which is really funny but I had to learn what a double double was and how people like their different orders they like. Sometimes they like two sleeves on their cup and all these random nuances that we have to understand and went through this journey of building consumer applications for the brands and businesses that help them, sell, right? So, really driving sales for us. Apps, websites, loyalty, kiosks, delivery became a big thing. And after launching these products in the US and in Canada, started to launch in some of our international markets. Across RBI, Burger King, Popeyes, Tim's, and Firehouse Subs were deployed in over 120 countries.

And so each country operates independently with a different franchising agreement, but we like to offer technology to those different regions and try and get them on the same tech stack that we built in the home markets. So, spent some time deploying over there and then grew my scope to also take on restaurant facing technology. So point of sale systems, back of house, so everything like labor scheduling, inventory management, supply chain, cash management, as well as our data warehouse and analytics and kind of franchise.

And the last unit that I took over was our franchise and data analytics organization, which was responsible for building reports and scorecards that we used in corporate and in the field with our franchisees to evaluate performance of the system.

Yeah, I think I'm not sure I understood that journey until just now about that you were kind of working on the big data problem and then you had to go back to square one, almost like joining a startup where you know, like you said, a new company and then working your way back to that data analytics, big data problem once again.

So, I'm curious about, that immediate transition. Going from a company that really understands software, Google, right? Like everyone in the company understands software, that's what they live and breathe, to a company that also has to understand something else. In this case, you know, coffees and sleeves and burgers and you know, there's a range of knowledge within a company like RBI.

What was that switch like for you?

Yeah, it was a little overwhelming at times, right? Because there was, no understanding of what technology could do for the business. And so there were so many processes that, had these opportunities for improvement and there was just not even a knowledge of how do you even begin, right?

So the language didn't exist for communicating between the business folks and IT. I remember a very funny thing, the IT team sat on a different floor at headquarters than marketing and ops and everyone else in the business, and it really wasn't considered part of the business. And so part of the challenge at the start was changing the culture. Not only were there no tech people, but there was not a great understanding.

Right. Well, it's interesting cause now, you know, we're in 2025, presumably every organization knows that tech is some form of, their strategy. But I think that there's not quite an understanding of what's at the core, right? I guess in your experience or your belief. What's at the core of any good foundation for a consumer facing brand like RBI in the QSR space?

Yeah, you know it, it's a great question. I think it depends a little bit on which space of consumer you're in, right? But it always boils down to understanding your product. And so what I mean is, in the restaurant space, that's food. If you're a Best Buy or selling a retailer, you're selling a different product, than a restaurant or a hotel space, or fashion.

But you are selling a product at the end of the day. There's a SKU, you're thinking about your customer base and everything. And so really understanding what you are selling, and how to tie it back in with the marketing and ops teams. So I think the foundation for us, or what I, picked up on was we needed to understand what we were selling and turn it into something technical that we could model and use, and build against. So, we have physical restaurants and need to be able to communicate and connect with those. So establishing APIs and kind of an architecture for talking to our systems and understanding what we are doing.

Right, so let's talk about those intersections. You kind of mentioned the marketing, the POS, all those different ones. Having built technology myself, it's often easier, you know, you talk about an API. It's often easier to just connect at the aggregate rather than going down to that really high fidelity data, right?

So, you know, how do you think about that trade off between highly interconnected, versus lost in translation versus too much integration to build? Walk me through that piece.

Yeah, it's so interesting because we also faced interesting challenges like any large organization does that there's so much variability across the system, right? So one franchisee uses POS A, another one uses POS B and how can you create a generalization over that and make it easy enough for you to run your business while still handling that uniqueness across the system.

And so, one of the things we did early on was create a middleware layer that could really help us identify the generic way of representing a burger. So a great example is how we think about, a drink, right? So one point of sale system will represent a large Coke as PLU 1, 2, 3, 4, PLU or SKU, right, some unique identifier. Another franchisee or another POS system will represent this as small, medium, large type of drink, right? So large is ID 57, and then with a modifier that is that flavor of the drink Coke, Sprite, Fanta whatever. So you'll have 57 with modifier of 2 right. Versus the 1, 2, 3, 4 PLU. And a customer doesn't really care about all these nuances. They just wanna buy a large Coke, right? We wanna look at the sales and reporting for that but handling these different systems and being able to say, it's okay that it's different, but we don't want to have to worry about that. And so creating that generalization across this, and that applies in a lot of different areas.

Got it. So you guys really created a kind of translation layer, right? Or kind of a thesaurus, if you will, for you guys where there's a way to tie everything back and provide that connectivity. Now, I guess you guys immediately started sitting across tremendous amounts of connectivity, right?

You have this piece, then you start plugging in different systems, people start transitioning. What were some of the problems that you encountered as you started connecting things together?

Yeah, so a lot of different challenges, but I'll take one of the first ones which had to do with just the fact that we were deployed in, or we were trying to deploy in 7,200 Burger Kings across the US. Like our team, we were based in Miami, hiring engineers there but we wanted to go launch an application that ran across the country and worked in all of these stores and all those restaurants were configured in different ways. So even if a lot of them had the same point of sale system, we could have had networking issues, different dependencies, different versionings going on across the whole system. And so it took a lot of collaboration with other business units. It wasn't always the tech problem. It was tying the technology into the business that tended to cause a lot of frustrations. And so we had to build the right partnerships within the organization to help diagnose all of that and move quickly.

So we're not, you know we can't send our engineers to all 7,000 whatever locations.

Interesting. So it was kind of a connective tissue for the organization itself. I guess I'm thinking usually those relationships have some give and take, right? It's like, help me figure out this mess of data and I'm gonna give you and I am curious. What was the give there on your team's behalf to you know, the marketing, the operations teams,

like what was it that you guys were giving them?

Yeah you know, it was great because we found success in building relationships with the other business units. And so a great one was in that first year we did the marketing team, the first CMO for Burger King came up with this awesome idea of doing Whopper Detour. I'm not sure if you saw this, but it was a really successful campaign where if you were driving and you were within a few hundred feet of a McDonald's, we would send you a notification saying, hey here's a one cent Whopper if you go to Burger King in the next 30 minutes.

Right and take the customer away from our competitor and to our business. And so the marketing team came up with this awesome idea that they wanted to go execute on, and worked with the tech team. Reached out to us, which was a great change in behavior, to say, hey, how can we go accomplish this?

We spent time with them discussing the mechanics of this and what we would need to do, understanding location, services of the users. Having push notifications enabled, how do we get a whole customer base already set up on that, right? Because you kind of need those to identify where the customer is and communicate with them in real time.

And can you assign dynamic coupons only to a specific user, at a specific time and not make it available, to the whole system. And so coming up with ideas that overlapped with marketing or operations, or whoever we were working with that gave them what they were trying to do but aligned with what we were trying to build for the system. Building a generic modular platform that would ultimately drive sales.

And I think what was important here is we were all working towards the same goal. When everyone in an organization, whether it's marketing, ops, technology, is aligned to the goals of the business. If we all agree on what our metrics of success are, it's a lot easier to work together.

Got it. So it clearly it was, you know, sales and ultimately maybe franchisee profitability. Right? That's kind of the, the ultimate driver there.

So, you know, you guys are focused on sales, but I'm imagining this push notification, and all the different failure points. Like what if the notification, what if the location services, what if the marketing team doesn't have it right?

Like, there's just so many things there, so I guess what's the way to track that follow through to the field team, to the ops team, and all the way through to the customer?

Great question. It's really, a bunch of collaboration and communication. And having a very diligent, project plan. As an engineer, I definitely always depended on my product manager counterpart and the product organization, but it's really taking responsibility for the whole picture and knowing that, hey we need to go get legal sign-off, we need to make sure the whole field team which is deploying with like, over many hundreds of field team members across the system, they're going and communicating to each franchisee in their region and training the team members and the managers at every single location, providing documentation. Giving them the notification in advance, you know, two, four weeks in advance. So it's not a surprise when it comes out. So it's really running something across multiple work streams and making sure we're constantly sharing information back and forth. I remember we would do standups twice a week with someone from pretty much every function.

We had legal, we had marketing, we had ops, field, tech all in the room. Always talking about, alright, here's the latest update. How are we doing? Everyone share what's going on? Where are the frustrations? Where are the concerns? And we wouldn't pull the whole engineering team into that, but we had representatives across every group.

I guess final question before we get to the facts. How, I guess, you know, you have all these people in a room that are busy solving a problem day in, day out all the time. How do you know you're winning during the problem solving, and how do you know you've won?

Well, definitely great questions. How do you know you're winning while we're in the heat of it. I think that really starts at the beginning when we're coming up with the strategy and the plan and making sure what we were trying to build is architected in a scalable way.

Like in a way that we feel confident isn't damaging the system. I'll take an example. Like our loyalty architecture 'cause we didn't launch with our loyalty system but we knew we wanted it to be extremely flexible. Like, we weren't sure if it was gonna be points based or visits based, or dollar spend.

And how are you gonna assign these offers to these systems to people? Are we going to do it by cohorts based on individual users? Do we want to do something at the store level? Region level? Coming up, spending the time upfront, really architecting and thinking out, alright, here are the basic building blocks we want, and even if we have to cut some corners while we're executing on the short term, having that north star of where we're ultimately trying to go to is really helpful while you're working on the project saying, okay, we're starting with, more simple version where, hey, the offers are only gonna be able to be assigned to everyone and that's okay, but let's still maintain the structure so we can think through this and how to change it or improve it in the future. So, it's tough. I think this one also goes back to the communication.

Awesome. Well, I mean, it's cool, right? There's kind of a consistent through line of, you know, starting with the business, then building to the data and getting to what's the consumer doing back to what can we do with that data, back to how do we serve it, you know, back to the franchisee and ultimately to the consumer.

It's kind of a full circle of capturing data to actionability, which is dizzying to imagine at a scale like RBI.

Asher, what a joy, great to chat. Thanks for being on the show, and excited for our listeners to hear what you have to say.

Thank you so much.