David Faircloth

Hello everybody. Thanks for joining us today. I'm David Faircloth, senior director of our architecture and platforms at the Wendy's Company.

Hany Elemary

Hey, welcome everyone. My name is Hany Elemary, and I lead the engineering team at a global technology consulting company called Navalia. And Navalia has been partnering with Wendy's for the past three years in a couple of different areas. But I'm excited today to share this stage with David and also tell you a little bit about a digital transformation journey that we've been on — in terms of moving away from a layered team topology. So kind of, we were at a layered cake, if you will. And now we've kind of moved into domain-aligned or stream-aligned team topology.

And throughout the presentation today, we will talk a little bit about what were the trigger points, what were some of the pain points that we were dealing with, what were some of the challenges, and then we'll talk about the journey. And by the way, we're still pretty much on that journey as we speak. And we'll end with some of the results and the outcomes that we're starting to see here today.

So I'll pass it on to David and have him tell us a little bit about the Wendy's digital landscape.

Conversation

David: So we'll start out with Wendy's. If you're from the US you've heard of Wendy's, you can't get away from it — there's 6,500 stores around here. If you're not from the US, you've still probably heard about Wendy's. We've got almost a thousand stores outside of the US as well. So Wendy's is that square-patty quick-service restaurant. We don't sell the traditional round burger patties — they're square. The reason is, we don't cut corners. Our founder, Dave Thomas, in 1969 started doing that. The reason is, he wanted to make sure that his employees in the restaurant remembered "we're here for quality." And that's what we try to do.

So, shifting a little bit into that whole "don't cut corners" mentality is what people don't know Wendy's for, is our technology. What people fail to realize is that mobile app that you have on your phone, to order food ahead of time or anything — there's a lot of work that goes on in the background behind that. Currently today, Wendy's has 14,000 employees with 7,000 restaurants globally and continuing to grow. We've got a relatively large overall technology team, but our digital team is pretty small. It's 70 microservices running on a state-of-the-art platform that our platform engineering teams built. Cloud interoperability — we're not just single cloud. Started on one, moved to another, and then figured out what that transition period looks like and where the best spot is to land on that. So having that really helped with that and lead us to where we are today.

This is what we look like from a digital perspective. So when we take the whole IT group, we're only gonna focus on one. We have these "edge of the spear" type teams, and our digital team is one of those — where if we're gonna try something new, we're gonna do it with these teams, because they have more of an agile-type culture and they welcome change, which is something that's not super often in a lot of the legacy technology world.

So Wendy's today: last year, 2023, we did over $1.5 billion worth of sales through our digital platform. That's the mobile apps, that's the website, that's the kiosk, that's third-party delivery — that's all of those. Because of those multiple channels that we have, there's a lot of touch points that we have with our customers. And being able to iterate quickly is something that we pride ourselves on — to be able to do in a fast and resilient and reliable way.

The problem with this is we're growing exponentially — super, super terrific growth that we've been seeing here. The $1.5 billion from 2023 was half that just a few years prior. So we're seeing exponential growth of what our digital sales looks like. And that means that we're starting to hit some of those pinch points whenever you talk about transactional systems as large as what we have here.

Hany: Yeah, absolutely. So all of this is sort of putting a strain on our current team topology. And not only did we have these stats for sort of 2023, but we have much more ambitious goals for 2024 and 2025 as well. And we knew right off the bat that our current team topology was just not going to support us moving forward — or not support the scale and the outcomes that we really wanted to achieve in a predictable manner.

So I'm going to walk you through some of the challenges and some of the pain points related to the team topology that we were in. Like I was saying earlier, we were basically layered according to areas of competency. So we had your traditional mobile-app team, we had a web team and a kiosk team. We also had a services or API team. And in one case, we had basically a regional team that supported the Canada market, which is a thriving market at this point.

But I think we all here know that meaningful work and meaningful features don't just get delivered at one of these layers, right? They cut across all of these layers. So this current team topology sort of created this artificial dependency between teams. It also created a structure where almost every team member's doing a lot of coordination with a team that's sort of downstream from them. And that required a lot of interruptions, it required a lot of context switching, which certainly impacted the feature delivery lifecycle. And also how quickly or how predictably we could deliver, you know, like these features.

And the way I would describe our entire team topology last year is that we were a team that was very high on coordination but very low on autonomy. And we wanted the inverse of that relationship.

So moving forward to talk a little bit about the second pain point that we were dealing with — which is basically where the focused expertise lied. We had product owners or product managers that were aligned towards these areas of competencies, or that were aligned towards these channels. So what that really meant is we had a product owner for the mobile app, a product owner for the web ordering and kiosk ordering, a product owner for services.

And essentially what happened is that now the same feature — so if we wanted to deliver, you know, like a brand-new payment feature, for example — that could potentially be prioritized differently because we have different product leadership on top of these channels. So prioritization was incredibly difficult. And because it was difficult, it also created more of a divergent customer experience, where the customer may jump on the mobile app, may find a feature that might not be available on web or kiosk, or vice versa. So that was particularly challenging.

Then, in our code base, also created a little bit of redundancy in terms of implementation — whether that redundancy was sort of across different channels (the same features implemented in different ways, or maybe in the same way but sort of logic distributed across different channels), and sometimes redundancy went across markets like Canada or the US for instance.

And then at the same time, prioritization is one of the hardest things in software engineering, in particular product development. This team topology really exacerbated this particular problem because now you're prioritizing all of the features within one particular platform. So one of the things that we found out — and we sort of started saying within the Wendy's organization — is that product managers or product owners don't really need to be experts in a channel. They need to be experts in the customer and their pain points. They need to be experts in the types of capabilities that we need to deliver to the customer and the type of experiences that the customer finds when they interact with some of our products. So missing domain knowledge was particularly challenging.

David: And what all that did is it really added artificial friction points to our teams. So now when we had a feature come through for our teams, it was having to go up the chain on one side, over to the other chain, and back down to get the development group. So it was leadership having to come in every single time — every feature, every tech-debt item — and say, "hey, these are the ones we wanna prioritize across all of the streams." And really had to be more hands-on with a lot of the areas, and take all that autonomy and decision-making away from the teams, which was just purely artificial friction that slowed everything down.

Hany: Absolutely. And it's hard to have a presentation like this without naturally talking about Conway's Law, right? I can't believe we went sort of like half day without talking about Conway's Law. So, paraphrasing — Conway's Law states that organizations tend to produce systems that mimic their communication structure and organization structure. And our organization structure was one that created this sort of siloed knowledge — not really an organization that created this domain knowledge. And it was apparent in the divergent customer experiences and lack of expertise — not just from a product perspective, but also from a development team, from a design team perspective — lack of expertise in the domain and particular customer pain points within specific journeys.

And if you haven't had the chance to read the Team Topologies book, I cannot recommend it enough. The Team Topologies book basically talks about [four] team types that exist within any organization. You have stream-aligned teams — and that's essentially what we ended up pivoting to. You have enabling teams, you have complicated-subsystem teams, and you have platform teams. And David will be talking about platform teams here in just a second.

But we basically knew that we needed to shift to stream-aligned teams, and that really needed to be the primary team topology within the Wendy's digital organization. These are teams that are organized around specific business outcomes. They need to have full autonomy of releasing software with minimal to no dependency. And if we go back one slide, that's not what we had previously — we just created the hierarchy or artificial sort of dependency across teams. So we knew that something needed to change at this point, and that we needed to pivot to this.

David: So then we get to our journey of, "hey, we've established what our problem is, we know what that looks like, so how do we do that?" Because to do big org changes like this — and do a whole culture shift — it takes top-level buy-in. You gotta go up to your C-suite and your VPs and say, "hey, here's what we need and here's why," and explain the problem to them. So we got that — it was clear that we needed something different, they agreed to that. So they actually challenged us. They said, "how do we build the ultimate customer experience in QSR?" So we started to flip the problem up on its end with this. Our leadership is saying we wanna look at what our problem is here for the customer points, and then make sure that our organization is gonna mimic that.

So we started out with — as Hany was talking about — these four [team types] here. We're gonna mainly talk about stream-aligned, but stream-aligned in itself did not solve our problem. So we first had to come in and establish a platform engineering team to build out this platform. I could talk for days on end about platform engineering and my just passion for what that is and how it can unlock teams. So I'm gonna try to make this super quick and just talk about platform specific. I'm only gonna talk about the three aspects of the platform that really unlock some of these stream-aligned team capabilities that we were needing here.

The first one is commonality. What we saw before is whenever you have teams go off and they're working on things in a different way and trying to do this high-collaboration, there's not a lot of commonality with what your applications look like, how they're deployed, how they communicate. There's really no contract specific to that. And so what ends up happening is, if everything's not deployed the same, if everything's not running the same, you're gonna have all these big issues anytime you make a little tiny change. And as we know with microservices, you wanna make changes all the time — whenever it's stagnant is whenever you're going to introduce more and more risk. So we had to first come in and put down a commonality.

We also had to talk about the runtime. The platform is not the workloads specifically — it's actually the infrastructure and the automation around that that runs those workloads.

And then we had to do the informed designs aspect to this. This is that enforcement that we were talking about earlier this morning up in the Azure ballroom. When you talk about these teams coming in and having to enforce what this looks like, you have to inform the designs and architecture of your applications to make sure that they're sustainable long-term. We wanna make sure that we're no longer relying on tacit knowledge, but instead sticking to the same standards and principles. This also allowed us to reduce some of the friction points around things like security and networking and other aspects to our system — by being able to come in and say, "this is how your applications need to be designed and communicate from this perspective. We have security built into this." And a lot of the goodness that you get from the DevOps culture comes in the form of this platform design here, and the infrastructure and technology that we were able to deliver with it.

Hany: Right on. And really what David and his team was able to do is essentially lay the groundwork for us to make that shift successfully, and reduce the cognitive load from the stream-aligned teams as we sort of embark on that journey. And I love the statement right here, because it highlights what might be known as the inverse Conway maneuver, right? Which is a corollary to Conway's Law. And the best chance — or the best way — of achieving the outcomes is to really align towards them. Is to enable our teams and structure our organization, structure our communication in such a way that it can start to push on the architecture, that it can start to push on the processes within the organization and our teams, to actually enable autonomy in releasing and more of that focused expertise around domains.

So we started on that journey, and we ended up with four squads, if you will — or four teams. One team was structured around a digital ordering journey in particular. Another team was structured around loyalty and offers and sort of creating that customer frequency, and ensuring that the customer wants to come back. Another team was basically focused on digital payments and creating more of a frictionless checkout experience. And then the last team was customer engagement — how do we engage the customer, how do we keep them coming back.

And the beautiful thing about this particular structure — beyond just the autonomous nature of these teams — is that the return on investment, the ROI, can be realized at different points. Whereas before, that wasn't the case. The stars had to align, everything had to align in order to realize the ROI. We also started to see a lot more efficient prioritization. And now prioritization wasn't just for one channel — the prioritization happened within a particular area, within a particular journey, for all channels. And that enabled us to create more consistent experiences for our customers across all of these channels. And also set ourselves up for what we might call leveraged implementations or common implementations — as David was talking about from a platform perspective. But we wanted to achieve that even within the stream-aligned teams. We wanted to create these common implementations that can be easily scaled to other markets like Canada or other markets that may be common in the pipeline.

David: It's important to note too that that's not the entirety of the digital system. We also have a squad specific to program support, to make sure that we're able to unblock blockers that come along with process and just corporate life. So we have support for our individual squads. We also have those super-complex subsystem groups as well, that they really focus on what is our technical debt from a historical perspective. It may not be related to feature debt or anything else like that, but our system has got some long-in-the-tooth code aspects, if you will, or we need to upgrade versions of software, things like that. We actually have teams that are focused purely on tech debt to completely remove them away from the prioritization of features, to make sure that we're still knocking down tech debt on a very regular basis.

Hany: Absolutely. So how does this setup now impact our teams, our product? And one thing that we started to see develop — we're not done with this journey by any means — but what we started to see is that focused expertise. And not just from a product perspective, but now engineers, designers, QAs, data analytics started to basically have a better understanding of the customer and their friction points. So that domain expertise started to emerge a lot more than it was once before.

We started seeing also faster decision-making. Because now you're making decisions around priority within a confined area of the journey. Yes, you are duplicating that maybe across channels, but it's still confined to a specific domain — and that made things go much smoother. There's no longer having sort of like decision by committee. And no longer did we have to sort of go back to the leadership and play all these maneuvering games. It's just — the team knows what their workload looks like, they have their ceremonies together, and they start to manage that together.

And then the last thing that was actually really cool to watch is the team started to become self-organized around the duplicated business logic around these channels. And they started pushing down that business logic towards more of the API and the services layer. That way we start to have this common implementation, or leveraged implementation, that not only serves these channels but also serves potentially future channels that we may have, and future experiences that we may have down the road.

David: It also unlocked us the ability to do what we like to call "tours of duty." We can actually take someone from one squad working on specific features and move them to a different squad, working with a whole different set of people. It allows us to remove ourselves from that tacit-knowledge aspect to it, and make sure that we're diversifying the context around the entire team. And we do this outside of just the digital development squads. We're doing this with the platform teams, with the quality engineering groups, the security team — all the above. And we're putting them into these tours-of-duty feedback cycles, so that we can continually better ourselves and our squads and how we're aligned and what that looks like, and how we're communicating with each other.

Hany: Yeah, and I cannot emphasize this point enough. Just because it's sort of, you know, siloed one way — layered — but also siloed another way, almost like when you're vertically aligned. So with these tours of duty that David is talking about, we actually were enabling others to kind of learn from one another. So I think that's critical. You don't want to do that too often, but also you don't want to sit on it for too long.

So what did a squad look like? This is essentially what a particular squad looked like, more or less, with different head counts based on the workload for the squad. Obviously had the product lead or the product manager, a business stakeholder, will have a tech lead, might have business analyst or a technical analyst depending on the nature of the work. Designers, prototype developers, web devs, mobile devs, services or API devs, QA, and data analytics.

And like I was saying before, they would have their ceremonies together. But we didn't just want to create this sort of autonomous team structure and say "great, now go do great things." We wanted also to give clear guidance to these teams about what results should they be tracking, what KPIs they should be building towards. And that was absolutely critical because for, let's say, the digital ordering squad, their KPIs — or some of their KPIs at least — was to increase conversion rate or decrease the time it takes to actually create an order and check out an order. For the payment squad, we wanted to decrease the decline rate for certain payment methods or payment types. For customer engagement, that's typically measured in what's known as MAUs or Monthly Active Users. For the loyalty and offer squad, we wanted to create that frequency. We wanted to understand: are the offers applicable to the customers? Is there an offer that's working better than another offer, so on and so forth.

So having these measurable KPIs, and having the team report on these KPIs on a monthly basis, has been absolutely tremendous. Because now we know exactly where we need to go and we're just getting after it. And if for whatever reason we're not achieving these outcomes, we're having a conversation, we're making some adjustments. Even if it means adjustments to the KPIs themselves and making them more realistic or whatever the case might be.

David: Two special call-outs on this slide. You'll notice that we have QA embedded into our squads directly. This is an emphasis on QA automation specifically. So as the cards are coming up, we're actually able to write all the tests necessary for those, to make sure our feedback loops through the SDLC cycle is much faster for us. That's been a game-changer rather than dev goes, does a card, finishes the card, transitions to QA, then they pick stuff up and start looking at it — we're embedding them on the team so we can get those faster feedback loops.

The other call-out here is the data team. We wanna make sure that not only are we a data-informed company, that we're a data-driven company. The only way to do that is to get our data teams closer to the development that's happening — of where we're gonna be generating that data, what it's gonna look like, curated and how it's gonna flow to the system. So, no throw-it-over-the-wall type thing.

Hany: So now that we've adopted this team topology, obviously things didn't magically start working. We have to go through this journey. And as I mentioned a couple of times now, we're still pretty much on that journey, and there's a lot of pitfalls and a lot of tendencies — if you're embarking on a similar journey — that might be beneficial to go through. And they really span three different segments: people, process, technology.

On the people side: change is hard, and change will inevitably slight someone, and someone will feel like something is being taken away from them. Legitimate concern, legitimate feeling. But at the same time, you have to understand that if you are committing to this, you are moving forward, and that you want folks to jump on that train — but that train is moving. So sort of like the typical leadership and change management things need to essentially happen here as well to ensure that folks are on.

David: Yeah, and a lot of that just came down to our culture. As a culture, we like to talk about, we wanna move fast, we want to embody change — all of those things — and making sure that those words are being used with the team, not just from a technology perspective but a team perspective. We try to hold everything very loosely in the hands for who's gonna be on what squad. And that's kind of why we've enforced those tours-of-duty type aspects to it, to make sure that we're not relying on a single person and the knowledge that they have. But instead, we need to make sure that — hey, it's okay to change around and move and go to — "you're not liking this project, let's move you to another one." We're trying to just create that culture to embody change and want to see it coming, so that as the next thing comes on the horizon, we can go ahead and adapt to it in a much better and healthier way.

From the people perspective, these three common tendencies here is across the people, process, and technology. We view these as our pillars for success. We're successful one because of the people. That's first and foremost — that's been bashed to our head today, if you will. Everybody's been saying that, because it's so true. You have to focus on the people, the process, and then the technology.

Hany: Spot on, spot on. And then on the people side, there will also be some tendencies. I mentioned earlier we were moving away from layered cake, but a common tendency is to sort of go towards sliced cake. And you don't want that either. You don't want a team to be together but then sort of working — services engineers versus like mobile or web — working sort of like in silos. But it's an understandable tendency. And it's obviously for us as a leadership team to kind of work with the team, advise, and encourage some practices like cross-pairing and things of that nature. So we want to get to more like cupcakes as opposed to these sliced cakes, if you will.

David: From a technology perspective, this is where I like to harp on platform engineering. Platforms — that's why they're needed, they're so great, they're wonderful. But it's kind of the truth of, you have to have that foundational aspect there — whether it looks like a platform for your group or SaaS solutions or whatever it's gonna be. Having that technology foundation there to unlock the teams and drive what it's gonna look like. You have to have those feedback loops from your team — they have to be able to inform what they need and what that's gonna look like. So we really found our stride from the technology perspective with that.

I'll also say here, this is where shadow IT kind of comes into — everybody has shadow IT or you've seen it in your career. The reason shadow IT happens is because of those pain points that are not being solved today. So we really try to look at those shadow-IT initiatives that come up, and "hey, these people are doing it this way with these tech." We start asking ourselves: why? Why are they doing that? And we'll start to bring that into the fold to see if we can unlock that as a capability for the rest of the teams. Because if one team's having that issue or constraint, the others might be having it as well.

Hany: Right on. And on the process side, you ultimately want that full release autonomy, but again — just because you've adopted this team topology doesn't mean that you're gonna have it right off the bat, because your architecture might not be in the right shape to actually afford you that release autonomy. So just be cognizant of that, and ensure that there is some aspect of maybe release management or release coordination. Eventually you do want that autonomy and you want the process to change, but just be cognizant of that as you shift. And then there are inefficient CAB processes and all that fun stuff that also needs to be streamlined.

And on the technology side, like we talked a little bit earlier about how the platform and the platform engineering capabilities that David and the team developed were just such a huge enabler for us. And like I said earlier, we view that very much as a prerequisite to our success as we go through this journey.

Okay, so what were the outcomes that we started seeing?

David: Yeah, this is the hard part. So you go onto this big journey, you get your VPs in alignment, you get your C-suite in alignment, they're putting money towards this, they're saying "yeah, we can take the bandwidth hit, yeah, we believe in this" — but now you have to show them why did we do all that work. What is the measurability? They talk about those SMART goals — you have to have some type of measurability. And so we decided to jump into DORA with that.

If you guys were here in cap-three-eight just a little bit ago, Nathan went over the past decade of DORA metrics, and we really went into that. I had the luxury of meeting Nathan last year. We've talked quite a bit, and he's really helped us set the foundation for what that looks like here at Wendy's, where we specifically were looking at eliminating red tape by implementing these lean processes. But we have to have measurability on top of that. We'll get into what our scores are here in a little bit, where we can show that improvement. But this is really where we look at from the outcomes perspective — is we have the people feedback from it. We know that our people are happier with it. They're not hitting the burnouts that they were before. They're not hitting the frustration points that they were before. Our process is changing and adapting to what we need it to be. And our technology's stable and resilient, and able to see us into the next decade, if you will — in terms of the growth that we're expecting from it.

Hany: Yeah, absolutely. And it's not just about — you know, I know Nathan made this call earlier — it's not just about improving these metrics to improve these metrics. They actually mean something to the business. And for us, we'll see here what they actually meant.

Before we embarked on this journey, this was our score. If you go to the DORA website, you'll be able to take the assessment, or it'll provide a report like this. This was our score. We're kind of like deploying and releasing once every month to six months. Change failure rate wasn't great. Mean time to recovery wasn't great. And — whoops, I'll go back.

David: No, that's great. That's where we are today. You see that 7.5 there — we're tracking in the direction we want to go. We're seeing positivity in every single one of these lanes here. There's a couple of them that we like to think that we're a lead in. But at the same time, we know there's so much that we can do to be better with it. DORA is not the only metric that we're sending up though. There's other things as part of what our system looks like and some of the KPIs from the teams that we have to look at.

Hany: Maybe we'll take a couple — I know we're out of time. We'll take a couple more minutes if it's all right. The one call-out that Nathan also made earlier that was so profound is: speed gets you stability in the software engineering business. And when he said that, I just couldn't help but sort of think of an analogy. I don't know if anybody here is a Formula One racing fan, or like watches Formula One — maybe like a handful. Arguably, like some of the fastest cars possible. But in order to get the car to actually turn so fast at like 200 miles an hour, you need to gain speed to get enough heat into the tire. And if you don't do that, then the car will start slipping and sliding because it's not gripping to the tires. So speed in this case afforded us that stability. And David is gonna talk a little bit about this chart here.

David: So this is the other metric that we're talking about here. It's not just about how we can determine what our internal development looks like — it's, what are our customers experiencing, what is our business stakeholders experiencing. And this is a chart here showing what our incidents overlay is. So you'll see, here's what our P1s and P2s were. We're only looking at the first quarter of every year, just 'cause I didn't wanna give out too much information here. But you can see the trajectory — as we increase the speed of our deployments and we've realigned our teams, we're actually seeing a drastic downtick in what our incident look like. But at the same time, you'll see that yellow line there — that's a drastic uptick. That's our revenue and sales that we're doing through this system. So by doing this and implementing the teams in the right way and really getting people on board with not only what we're building but servicing the customer, we're seeing dramatic results from a sales perspective as well as a reduction in all the fires that we don't like to fight.

So this is where we come to what's next. This is all I got for that. We're on the journey. We started it, we clicked the go button, but we're still on it. We know that as technology continues to evolve and change, our teams need to do that too. So we're trying to build the culture up with those tours of duty that I discussed before, to make sure that as the road turns left — and this is the way technology's going — we can adapt to that from a culture perspective, while making sure that our teams are motivated to get their job done.

Hany: Awesome. So the only thing that we're asking of you: if you have embarked on this journey, or a similar journey, please, let's get in touch. Let's compare notes and share some feedback. Thank you again so much for coming in.

David: Thank you. We'll be around.