Back to podcasts

REI's composable transformation advice

July 9, 2023 / 24:27 / E35
Download
podcast-bg
Kat Valdre and Jason Greely from the REI Platform engineering team share their composable transformation story. They discuss the challenges they faced while decomposing their monolithic architecture and their approach to building trust across the organization as they embark on a years-long transformation. Their transparent and refreshing perspective on tech transformation will resonate with anyone who feels their progress is slower than they (or their organization) would like to move. Kat and Jason provide valuable insights and advice for any business making a major technological shift. 

Timestamps:


1:41 What were things like at REI before they decided to go composable
04:06 What pushed REI to start their composable transformation?
06:25 The importance of introducing changes in manageable parts
07:54 What composable will enable for the business
11:17 Advice for companies embarking on composable transformation
12:55 Dealing with differing opinions and disagreements
13:57 The importance of documentation
16:41 Hurdles and challenges REI has faced along the way 
18:50 Managing expectations and maintaining morale when transformation takes a long time

Jasmin: [00:00:00] If you've ever felt like your tech transformation isn't moving fast enough, you need to listen to this episode. Kat and Jason from the REI platform engineering team shared a composable transformation story. And it is a multi-year process. But their approach to this daunting task is just so refreshing.
They are very transparent about their challenges and how they've approached them, one at a time. And while they decompose the monolith, they're also focused on building trust across the organization, and they share how to do that as well. You're listening to People Changing Enterprises. I'm your host, Jasmine Guthmann.
Please enjoy this [00:01:00] episode with Kat and Jason from REI.

Jasmin:Tell me a little bit about each of your roles at REI.

Jason: I am a solutions architect for the content and experience management platform. So covering CMS, experience management, all of the content orchestration up until the last mile delivery and rendering of our content.

Kat: And I am engineering manager in our platform org and one of the teams I support is the content and experience management platform.

Jasmin: Wonderful and REI is currently in a transition towards moving to a composable architecture. What prompted that change? What were things like before?

Jason: Yeah, so we were pretty monolithic, I think about three or four years ago, they started to decompose. So just ripping things out of the monolith, going into more of a distributed architecture. We all work in a pretty siloed fashion. So, I think that combined with the [00:02:00] shift in technology and our general angst with our current platform at the time led to the push to a more composable architecture.
I think it's been a long time coming for sure. I think we tend to be modern thinking, but maybe a little slow-moving. So what that's resulted in is the mindset is there. And the initiative is there, but the tools old, it's led to possibly a little bit more effort than anticipated to maintain things in current state.
That's what prompted us to look to a new application for our platform specifically. But yeah, it's going pretty well. Again, it's going very slowly. I think we still have another year or so to go. And then after that, like I mentioned, it's going to turn into how do we make this more composable, or how do we take the applications we have currently that are now out of the monolith and modernize those and make them a little bit easier to support within that new architecture.

Kat: I think what is worth mentioning is we started this journey in second half of [00:03:00] 2021 by looking into all the capabilities we had and where we were lacking. And that itself was months long process, even before we got to a point where we started looking at possibilities, what is out there. So overall, I think from the initial thought that we should move to more composable architecture and something more modern.
To the point where we have migrated off of our existing CMS, it's going to be a three-year process. And that's just a migration. We're not fixing everything. We're just moving. It's a very slow house move.

Jasmin: Yeah, and you're really in for the long haul, but there's... various aspects that resonate very deeply for one starting small and acknowledging that you're not going to just rip and replace whatever platform or architecture you had in place and you're there's just too much going on while you're running a business, let's [00:04:00] not forget that we want to, we need to build the engine while flying. We can't just turn it off and say, yep, no, we're not going to sell anything for the next three years while we fix our technology stack. Where did you start with that journey? What was your biggest pain point back in the day?

Jason: I should clarify. So what Kat's talking about, what I'm talking about are, it's almost like this effort is radiated into these other teams. So we had a very big central monolith with search and SEO and content and all these things piled in. All those teams are siloed, so they're ripping their stuff out. We're ripping our stuff out. Now we're using a monolithic CMS in a headless fashion, and that's where it's our turn to say, okay, this is brutal, let's go and evaluate. So, our original monolith has another year or so. We have a long way to go, because we have all of our collections to migrate and that kind of thing. So, clarifying there. I think with us specifically, so within the content and experience management platform, our last [00:05:00] solution, or I guess current, or half current, we've had for ages. Not the most user friendly, not the most developer friendly. So you get both sides of the house getting this snowball of anger and resentment towards the solution.
And then you add in what I was talking about where we're using it just incorrectly, which makes everything so much worse. And eventually can't do it headwards. Okay, enough is enough. We need to start looking at things. I think a challenge with that, because both sides of the house is upset and angry with the current solution, the trust there.
Tends to go away, so the developer side is working on just keep things afloat. The other users are questioning our decision-making, like, why does this suck? How can it be better? Why aren't you guys making it better? And the initiative comes from both sides to look for a change, but we had to work to bring that back together and be both be involved in the process to make sure that one, we're both comfortable with the solution, but also to rebuild that trust that was eventually lost over time, not [00:06:00] because of any given action, but just because the experience was not all that great.

Kat: Yeah, it's almost like that thing where, like a family history in some countries where you've been fighting for generations and finally the youngest generation comes along and asks, why can't we just all get along? We all want the same thing. We want to live in peace and harmony. Can't we just do that?

Jasmin: And that's a fantastic comparison, Kat. And I think trust is a big component. Tell us a little bit about how you rebuilt that trust between the departments because that sounds like a monolithic feat, let alone the technology underneath

Kat: it. It is a monolithic task and in some aspects, you have to go into it with the expectation that you cannot fix everything. If you get a certain percentage, that is sufficient to move forward. And the moving forward in itself will build more trust. So if you can get a [00:07:00] fraction of a department to align, that is enough initially. I was listening to one of the latest podcast episodes. I think it was with Booking. com about how you cannot change everything as part of CMS migration. And it is so true. Focus on what you must do and then everything else will follow. If you try to change both the content management system and processes and people around it at the same time, you set yourself up for failure.

Jasmin: Yeah, people can only handle so much change at any given time. So if you change one thing over here.
You don't want to change that other thing over here, so they have something to hold on to that is familiar and that they're comfortable with. We tend to think about technology first and ignore that there is people that actually work with the tools. And that probably the people in the process portion of things, many times is the more difficult or the change that needs the longest for adaption to happen.But if we want to [00:08:00] hone in on the technical part, what are some of the exciting things that you're going to be able to do? Once you're moving into that more composable architecture, what are you looking forward to? Why are you embarking on that journey?

Jason: Yeah, I think just the prospect of having a modern solution in and of itself, it could be anything really is exciting. Having that technology available to us will unlock a lot of things that multi-channel content use freeing up our devs to do other things like quality of life enhancements working on the experience management portion and plugging those gaps where we've not really had that platform before because it just didn't fit with our tooling didn't fit with our architecture and also being pretty much fully decoupled from anything so if we hate it someday we can just move on with an asterisk it always sounds easier than it is but it's freeing us up to make more informed decisions As well as just unlock our users to be able to do more things like it's for us it's pretty night and day what we're [00:09:00] coming from and where we're going to So I think just having the time to work on those things instead of working on the application itself is probably the most appealing part and that's more of a SaaS thing.

Kat: And there's also other angles. So, for example, it allows us to explore technologies that historically have been hard to introduce but now come out of the box. So, we have it. Can we explore it further? That's one angle. Another angle I like that is technology-related, but it's also related to my job as a manager, is when we started taking apart the monolith, we ended up in a situation where we have now so many microsites that it's unmaintainable. So bringing it all back together because we can build reusable content models. So it also means less one-off work. Developers can actually work on improvements or other maintenance. So, yes, it goes [00:10:00] back to people topic on my side, but it's all related to technology. So having a content management system that can work with our design system. Instead of duplicating the efforts, so Jason is an architect. He's looking at the bigger picture on technology. I'm looking at the bigger picture from the people and connections point of view.

Jason: An example of this, so kind of going back to the monolithic topic, the appeal of the monolith is that everything's there. It's accessible. Everything is in one place. Decomposing that we're in a position now where, like Kat mentioned, we have a bunch of microsites. We have a bunch of different services. Being able to free our devs from the app maintenance lets us take a look at things like federated APIs, which we would have never had time to do before, which can give us a similar experience to a monolith, but help keep things decomposed to some degree. To your point, like, being able to work on that, which our devs are... Very excited about, very excited across the co-op to actually implement something like that. Instead of doing these little tickets, I need to change a [00:11:00] content model. So let me just redeploy my entire stack. Yeah, it's going to be very helpful to keep them motivated, to really keep pushing forward towards the architecture that we want and need honestly.

Kat: Yeah, I am looking forward to the day when we no longer have Wednesday morning 7 a.m. We have to take the CMS offline to do an update. Everybody log out. Don't do anything. That will be a very good day.

Jasmin: Amen. Nobody needs those anymore. And please no more replatforming. What advice would you give someone in a similar organization to yours? If they were starting on their composable journey or a phrase the other way around, what do you wish you had known when you started, but you didn't?

Jason: I think the biggest thing for me is just being persistent with it. I come from a background in a SaaS startup world where everything moves so fast and coming to an enterprise like this, they move slowly, which is [00:12:00] understandable and there's a lot at stake. There's a lot of opinions to get in your court before you can go do a thing. So I think being persistent with your idea and your vision, no matter how long it takes is probably going to be the most important thing. And the more allies you build, both in your organization, other side of the house and with vendors, I think a lot of people resent sales calls or the sales pitch, but they're also looking for the same people.
They're looking for champions across the board. And when you do your diligence and you're comfortable with them. Get them in there as well. So I think building a team around you that are just across the enterprise outside of your organization to help push your vision, I think, is another huge thing to really be focused on and keep driving that forward, no matter how long it takes, or if you find that you're in the valley of motivation and people are getting frustrated, just keep pushing through it.

Kat: That was a really good point, Jason. What I would add to that is build your core team. So it is very [00:13:00] tempting to include everybody in every decision-making process. Build your core team that will be the decision makers because a lot of people have opinions. But then there's a core group of people whose opinions and directions should matter. It is very tempting to include everybody. That takes a very long time. Sometimes you just have to make a decision which way to go.

Jason: On that note, people with differing opinions, and it goes back to the trust thing as well, and how we tried to navigate that and rebuild trust. Going into the evaluation being, one, as educated as possible before engaging those people, showing that you understand. The problem case showing that you understand why there's resentment or angst for any given solution before you go and say, here's a new thing that we want to do, I think helped. Quite a bit. And starting with that core team, it's all about alignment, right? So starting with that core team, making sure we have our criteria, making sure we know what we're talking about [00:14:00] before bringing to that wider audience really helped rebuild that trust where they might think now, okay, they know what they're talking about. They know why we're upset. Maybe. There's some glimmer of hope that they're going to make an okay decision and then trying to bring them into that decision-making process early and often, I think, helped quite a bit to ensure that we're all on the same page and we can shoot for the same goal. They might not care about the IT side or the architecture of it all. One is pretty much unlocking the other.

Kat: I think what also helps, especially when you're working on a larger org with a lot of stakeholders, is documenting your process and how you approach things. So we are now a year post our POT with it last year and I have gone back and referenced those documents multiple times. So having that track record It's very useful. It's a lot of extra work to maintain it, but it's [00:15:00] worth it.

Jasmin: And that is such a general rule that is so often ignored, I find, right? It's do send the, do write the meeting notes in the first place, but then also make them available and distribute them and make sure that there is, I'm tempted to say evidence, but also just backup, so you can go back to see what did we discuss, what did we decide, what did we all agree on, and for what reason. And it's out there in the open. It's nothing that you're doing behind closed doors that, you know, nobody has access to. It actually helps create and rebuild that trust.

Kat: Yes. We often go into these projects thinking the people who started it will finish it. And just like Jason mentioned, it takes a long time and people move on for various reasons. So having this level of documentation essentially is beneficial for [00:16:00] everybody. So for example, when I started at REI, it was six months into the initial scoping and determination where we're at. I spent my first two months watching recordings of those meetings to catch up.

Jasmin: Yeah. And it doesn't have to be as dramatic as hiring or firing or retiring or anything really. Change is the only constant these days. You never know. And maybe you will be the person appreciating the documentation. Maybe you're the person who leaves and you want to make sure that the knowledge isn't lost with you. Venturing off on your next adventure. Exactly. And what were, I'm sure along the way, not everything was nice and cozy and comfortable. Change never is. What were some of the difficult conversations that you needed to have?

Kat: I would have to say some of the challenges we [00:17:00] faced initially when we had narrowed our candidates down to three was really digging into the capabilities versus the slide decks presented too often. The slide decks are amazing. The product can do anything you want. And this is why you do proof of technology where you actually try to implement and see how far it goes. And sometimes you discover things you didn't expect. And you need to really reconsider. Is this a breaker? Can we move on or does it stop here?
Jason: I think another thing. It's not really, it might've been a hurl, but not necessarily a struggle. It just took a while is removing bias. I come from this vertical e-com content. My knowledge of these things were years old, so I had to remove my bias. There are people on both sides of the house that might have some preconceived notions.[00:18:00] for better or for worse. So it took a bit to hollow out a space really where we're saying, okay, here's our vision for what we want to do from an architecture system level. Let's put a black hole over the application that serves that and look at this objectively using the criteria we all agreed on at the beginning of the process, using the information we've collected and documented to come to an educated and rational decision instead of making an emotional decision.

Kat: I would have to say this is one of those few times where Excel is your best friend.

Jasmin: True.

Kat: And we did the same thing. We had an Excel spreadsheet scoring and weighing all the criteria that mattered. And it has helped tremendously after to explain why they would choose this or not that, what was the score, why they would choose that score. It's a lot of information in one document, but it is priceless.

Jasmin: [00:19:00] Oh, absolutely. And it comes back to your earlier point, Kat, you want it in writing. So you can just whenever someone has a question, you can send them straight into the data, basically, and say, Hey, there's good reason for this. It wasn't something that we took lightly.
Here's the full rationale or happy to give you a short run-through, which kind of brings me to how to keep people motivated and engaged throughout the change process and you're right smack in the middle of it and you still have years to go. So how do you keep everyone, how do you keep the fire burning?
How do you walk through that valley, Jason, that you described and how do you manage expectations?

Jason: It's hard, and it's just that it's managing expectations. I think coming out of an evaluation when you finally purchase something, you've got the highest hopes. Everything looks perfect. And the second [00:20:00] you're into the implementation, you're like, Oh, yeah, implementation suck, and they're really hard and they take forever.
It's taking the shine away from it almost a little bit at the beginning, but still, like I mentioned, being persistent throughout and reminding people where the winds are. We just went live with our first CMS a couple weeks ago now, I think, a few weeks, or with our first microsite in our new CMS. And the reaction was so dull. It wasn't, it didn't feel like an accomplishment where we spent a year plus evaluating things. We spent another year, or almost a year, rather, trying to build something and get it into production. And we finally did that and I was like, oh great, now what's next? Kat had to make everybody stop and be like, hey guys, this is huge. Let's rewind a little bit and celebrate the success and then we can move on. Somebody in the group needs to be hyper focused on these milestones outside of the roadmap where it's okay, this is a win. Let's share our win internally. Let's share it with the org. Let's get some good vibes back and that'll hopefully push us through [00:21:00] these little ebbs and flows of motivation and morale.

Kat: What it feels like when you go live with your first part is you get more recognition externally when you talk to other companies who are part of that journey themselves and they know what it's like. And internally, it feels more like, are you done yet? Question mark. But yeah, so sometimes I have to be the cheerleader and remind us how far we've come so far. It is amazing what we have done. Good things are to happen in the future.

Jasmin: That is exactly what a team needs. You need that one person that is hyper-focused on what the things the team is doing actually mean in a bigger context, and it's so easy to lose sight of the big picture and the vision while you're deep down in the weeds trying to get it done. How do you work against that, oh, is it done yet, sentiment?

Jason: Yeah, that's another tough one, and I think sharing the wins. [00:22:00] Goes not only within your group, but the people that are waiting to use this new thing that you promised two years ago, if they see progress towards their turn. They're still stuck with a solution that they hated, and they're still going to be stuck with it for a while. So I think it's really what you said, educating, going back to all of your documentation. Yeah, here's this, it might feel like a dangling carrot, but here you are on the roadmap. We're coming up soon. We're making progress. Here's our execution rate and just giving them the information to maintain, again, trust that we are going to get to you. You're right here. Here's the little arrow moving towards your spot, and we'll get there soon. And if there are delays, or if there are improvements to the process where you can expedite some of these things, sharing that feedback as well.
Just making sure they're always in the loop on where they are in the process. One, it reminds them, yeah, there's this thing that we can use soon. But two, they don't feel like They're being ignored or, you know, kicked [00:23:00] to the curb or something because you just want, don't want to give them bad news. So I think keeping them close to it, at least through communication, not through, you know, sitting every meeting is, is going to be the most important thing there to manage their expectations, keep some level of excitement for what's coming, but also, you know, temper expectations if it's not going to be for a while.

Jasmin: And I think it goes back to the building trust element, right? Because, you want to be authentic, you want them to trust you that you're getting to whatever their item is on a roadmap as fast as you can, and with the best possible quality. And you're not rushing it haphazardly, nor are you delaying it you know, intentionally, you're doing the best you can, and you need their buy-in and their trust to make that happen.

Thanks for listening to People Changing Enterprises. This show is brought to you by Contentstack, the leading composable digital [00:24:00] experience platform for enterprises. Got a question or suggestion? Email us at podcast@contentstack.com. If you like the show, Please leave us a rating or review on Apple Podcasts.
We'll be back next week with a new episode helping you make your mark.

Share on: