Webinar: Enabling the Right Technology for Results, with Matt Powell, Chief Technology Officer at FTD

Transcript:

Peter Crosby:
Welcome to Unpacking the Digital Shelf, where we explore brand manufacturing in the digital age.

Peter Crosby:
Hey everyone. Peter Crosby here, from The Digital Shelf Institute. Strategy, outcomes, people in process first, then technology. That's a pretty good rule of thumb, but for that to succeed, the business and IT leaders need to be in lockstep to put the right tech stack in place for the right outcomes, now and in the future. This is a podcast audio version of a webinar featuring, of course, Lauren Livak, Director of the Digital Shelf Institute and driving force behind the Digital Shelf Playbook series from the DSI, and our very special guest, Matt Powell, Chief Technology Officer at FTD, a 112 year old floral gifting marketplace, powered by a network of 10,000 small business florists, grocery stores, and retail gift shops. Matt and Lauren dug in deep on how to achieve that business and tech partnership for success.

Lauren Livak:
So I'm going to pass it over to Matt, and he is going to kick us off.

Matt Powell:
Great. And I know we've got kind of a lot of tech folks on the call, so for the folks who are in different stages, since we've got different kinds of people, forgive the things that feel perhaps elementary. But when we talk about a tech stack, what we're really talking about is a collection of technologies that are stacked together, joined together to deliver some capability or some user experience. And a tech stack is going to include both SaaS stuff and custom things, and often things that live in a bunch of different places that connect in all sorts of ways. And I think the first, and on the right, the visual here is kind of an oversimplification of FTDs digital shelf tech stack, which I'll talk about for a second, but I think one of the first things that's important to consider here is the concept of a stack has the idea of intentionality built into it.

I think part of what can create problems for organizations is when instead of being designed and intentional about what the different pieces are and the way the pieces fit together, different people are just off working in silos and doing different things. Because what ends up happening is duplicative solutions get put in place that overlap in unintentional ways, without really a plan, which spends money that generally our company doesn't need to spend, and also creates all sorts of integration hassle, and tech debt, which we'll talk about later. So I think it's important to think about this as something that's designed, orchestrated, measured, and improved over time, and being in pursuit of solving specific problems in specific ways, rather than a collection of one-off choices that are made by individuals who aren't thinking about the fact that what they're buying is a single platform. For us at FTD, when we look at what comprises our digital shelf, the foundational level is Salsify, which operates as our PIM, our product information management system.

We also rely on Salsify's digital asset management tools as our DAM, so that's the place where all of the image assets and things like this live to be served to every constituent that consumes digital shelf. On top of that, we have Elastic, which is a search appliance, which you know could argue, if you were a Salsify solution engineer, you're like, "Why do you need that? We should be able to do that without Elastic." For us, because of my SaaS business where I've got thousands of members who each have their own catalogs, which are versions of our catalog or inherited versions of our catalog, modified versions of our catalog, their own catalogs that are different than our catalogs, we needed a solution to take the base experience that we offer in Salsify and add more capability to it to meet that specific set of needs.

So on top of all of that, we have a Java based product microservice that abstracts Salsify and Elastic so that none of the downstream systems talk to that. That microservice supports outbound feeds for things like product listing ads at Google and other environments that do product listing ads. It also supports our SaaS business, so it supports our point of sale platform and our Shopify powered member eCommerce platform. And then that same product microservice is consumed by Nacelle, which is a composable data orchestration technology. And then Nacelle feeds into Shopify and it feeds into our custom headless web stores for FTD.com and proflowers.com. There's a lot of other stuff that happens here, but this gives you a good high-level sense of what the major building blocks are of our particular stack for doing digital shelf at FTD.

And when you think about the elements of a digital shelf stack, there are lots of different technologies to consider to support the people and the processes and the data that are necessary to deliver on the digital shelf. And to what extent these different types of solutions play a role is really a function of exactly what you're trying to do with the digital shelf. So for us, we don't have a big business in syndicating sales to other places. We support selling flowers off platform, but we do that in a way that's either FTD branded and generally it happens on our sites or it's branded by the partner and they're kind of setting the pricing and all that, and they're just sending us recipes. So we don't rely a lot on some of the things more syndication oriented, like consumer packaged goods companies would, where you're selling through a lot of distribution channels and you're trying to make sure price and brand and all that stuff is managed accurately, we have a different problem space.

Some folks, because of the way the product development life cycles work, rely heavily on PLMs and MDMs to manage foundational product information. So as you think about stack choices, it's really important to understand what specifically is your need state, and then what is the right collection of technologies to meet that. I think one of the places where people often go wrong in making stack decisions is they're vendor led. Somebody gets an interesting email from a vendor, the vendor talks about all the magic that the vendor's going to be able to do for them, that people are amazed. And then we bring the vendor in, in the worst of all cases, we don't do a proof of value or a proof of concept, and then we've got a solution that does part of what it was promised to do, that doesn't really meet our needs.

I think that is almost 100% of the time a recipe for disaster. The better place to start is to look at what we're trying to achieve, what capabilities we need, and what is the best collection of technologies to meet that. And forcing the potential partners that you're talking with about filling in those spaces, to be really, really clear about where they're excellent and where they're good. Because it's hard to be good at everything and often ... but you might not need excellence everywhere. So sometimes being good here or excellent here and good here is enough for that solution to be adequate for both spaces and sometimes it's not. And as we'll talk about later, that changes over time as your business matures.

Lauren Livak:
And Matt, one thing I'll add there is I think the same goes for an internal team. If someone comes to you and says, "We need a PIM," the questions really are about why you need that PIM, what are the problems that you're trying to solve? So I encourage, I know we have people from the tech side, also eCommerce and digital, if you have a technology gap, go to your technology team and say, "This is what I'm trying to do, or this is what I'm trying to achieve," rather than trying to pick one of these systems on the page because you don't necessarily need all of them and you might have something, to Matt's point, that already does a piece of this. So it's always really great to come from the lens of what is the problem I'm trying to solve, and then that's where that collaboration with the business and the technology team can really help you out.

Matt Powell:
I think that's really, really well said. And I say this, I have 225 engineers on my team, so we build a lot of software and we actually are at least as guilty if not more guilty of that when we build custom software as we are when we buy. And the reason for that is these labels have meaning to people. So someone comes along and says, "We need a PIM." And so that means one thing to one architect and one product owner, it means something else to another one. And so people go, "Okay, let's go build a PIM," and they go off and build a PIM. And particularly in an environment where the technical functions are over here and business functions are over there and they don't talk often, you could burn six months of building the wrong capabilities or overbuilding capabilities or underbuilding capabilities.

So I think that the clarity of we need a PIM and a DAM and a MRM is one thing, but then what and why do we need those things? What specifically do we need them to do and how do we need them to do it? And what is MVP and what is not MVP? What's a minimal viable product and what's past that are critical for getting it right and not wasting a bunch of energy. Yeah, so super well said Lauren, great add.

Lauren Livak:
Thanks Matt.

Matt Powell:
One of the things that Lauren and I talked about as we were preparing for this is what sorts of things lead to assessing your tech stack, reassessing your tech stack, making decisions about changing the components, and trying to zero in on some themes that drive most of those kinds of changes. Because ultimately, and we'll talk about this more as we go too, technology is really never done, it's always in a state of change. And I think that's been true for all technology for all of time, it's not like we invented the wheel and fire and we were like, "All right, we're done. Smoke if you got them." We keep going. And the same thing is going to be true for any tech stack that you're responsible for, but the kinds of things that indicate that you may have a need to reconsider the platform are bumping into a really important API's threshold limit, or I'm sorry, a really important KPIs threshold limit.

So we've been able to move this thing along and move this thing along and all of a sudden it's getting increasingly difficult to impact this KPI that we care about. That is often a signal that there's some barrier in the way, unless you're encountering a physics problem, which is like, we'd like to drive a higher order value and people are not going to spend any more money on that thing. Okay, well that's a different problem. But if we believe that there should be more opportunity in a particular KPI and it seems impossible or more difficult than makes sense, that's probably a platform problem that's hiding beneath that, what looks like a business problem. And you hear this a lot where people will say things like, "Well, we can't do this thing that our competitors can do because we have X problem." And it's like, well, are we stuck with that? Can we change that? How do we change that?

The other observation that I look for is the velocity of change decreasing. And so we've been able to put points on the board in terms of making things better and making things better, and all of a sudden the rate change there is just slowing down. That's often a signal for tech debt or a signal that your current needs no longer match your platform reality, and so you have to look at a change in your solution context. The third thing would be a material change in what's technically possible. So the world's evolving all the time, people are inventing new things, we're building new macro solutions. And so as the world evolves, sometimes you bump into a situation where it's like, wow, this thing that we were doing this old way is dated such that making a big change will allow us to unlock more value, and so how do we do that?

So that's sort of some externality in the marketplace. The machine learning capabilities scale a bunch, what can we do with that? I mean, an example of this that you're seeing really a lot over the last six months is what's been happening with AI generated art. The mid journey has taken what you can do with creating art as a novice using AI and put it in everybody's hands, and so that probably changes the way a lot of businesses can think about things. I used to work in the advertising business, if I was still in that business, I'd be thinking about how that should change the way we think about our creative process, if only for concepting, because if I can get AI to spit me out a bunch of things and maybe render the idea better than we could on our own, that's probably something worth doing.

And then the last thing would be a material change in the business need, something dramatic changes. So for me, I came into FTD about six months after a bankruptcy and there had been some work on building some new platform for eCommerce. Pre bankruptcy, the business had owned 12 brands, post bankruptcy, it owned two, a bunch of the technology had engineered against the problem of supporting N number of brands. What it meant was the two brands that were getting arguably mediocre solutions in some places because the orientation had been the support multiplicity as opposed to these two things directly. So we had to rethink about what we were doing to support these two brands in the right way because the business's reality changed when it divested these other 10 brands or so.
And then when thinking about how to make those decisions, we've decided we need to make some changes, what are the things that inform our decision? Do we build? Do we buy? If we're going to build something, in what technology? If we're going to buy something, in what technology? Where should it be hosted? Who should manage it? All that stuff. One of the things that Lauren and I talked a lot about and that we talk a lot about internally at FTD is that there just are no perfect stakeholders. We don't call anybody that works outside of tech, the business at FTD, because FTD is a technology company, but our stakeholders outside of tech will often say things like, "I don't want to launch this until it's done." And I say, "Great, we're just never going to launch it because it's never going to be done. There's always going to be things that are changing."

So accepting that things change faster and slower at different times based on reality is important, but trying to get it done is just unfortunately not a state that's really accessible. And I think that drives a lot of the thinking. So when you think about build versus buy as an example, if your business is mostly not a tech operation and needs tech as an enabler but really doesn't have much of a center of gravity there, then you probably want to be really careful about what you build because you're just not set up to maintain it. So those kinds of considerations become really important. But one of the things that we always look at is cost. So what is it going to cost us to build it ourselves? What does it cost us to buy it? And how is that different this year versus on a five year horizon?

Because sometimes it makes sense to rent something for a year or two years because you don't have the time to focus on that thing right now and there are other more important things and you want to improve it, but long term you know that it makes more sense on a total cost of ownership basis to build the thing. So looking at both the short term cost and the short term benefit, as well as the long term cost and the long term benefit can be really important. Being clear about what problem we're trying to solve. So going back to not letting a vendor partner direct what your solution needs to be, but getting really clear on what your problem space really looks like and not allowing jargon or different ways that people think about what an acronym means, to get in the way of clarity, be really explicit about what we're trying to do and how it's going to work, and thinking about how that will affect the culture.

What does it mean to buy a thing? What does it mean to rent a thing? What does it mean to build a thing? How do those things affect the way that tech and non-tech stakeholders internally relate to the thing? What already exists? What are the other systems that are around? How are they set up for integration? What sort of support do they need? Where are they hosted? How are they going to talk to these other systems? How specifically are things going to integrate? What's the time to market and the time to value for one alternative versus the other? What does adoption look like? All of these kinds of things that are about ... I think trying to find the center of Venn diagram and then we'll talk about this a little bit more too, where business stakeholders have acute needs right now and there are vendor partners who are in a position to solve those needs, certainly more quickly than you can internally, but tech has a responsibility to think about long-term asset management.
How do these pieces fit together? How do they create InfoSec risk? How do they support the team's long term requirements for first party data and all of that sort of stuff? And trying to figure out together what's the right decision for now, based on short term and long term effects for everyone?

Lauren Livak:
And I think the key part of that sentence, Matt, is together. These questions are not questions that happen in a silo with the technology team. They are every stakeholder who touches what you're trying to solve as a problem involved in that conversation. And for those that always ask about how we can be more agile, how can we think about this differently? Well if you can create a standard set of questions within your organization that every time something comes up that you think you need a new technology, you can go through, it makes this whole process a lot easier because then you don't have to reinvent the wheel every time. So really think about using these questions to build some sort of framework between them. I like the non-tech versus tech, instead of saying IT versus the business, but the non-tech versus tech teams to come together to be able to repeat this every time something like this comes up.

Matt Powell:
Well, and I think a lot of it's about empathy too. A big non-starter in my team is speaking to non-technical partners in ways that uses technology to create information asymmetry. So you don't get to use language that somebody else doesn't understand, purely to manipulate the argument. Your goal is actually to help the other person understand what you're talking about so that they can be involved in the decision, not have it happen to them. And this happens in both directions. You see people who are P&L owners, act like tech can't possibly understand what the business's needs are and they try to obfuscate the reality by over complicating the business's reality, the P&L reality, and tech does the same thing by using jargon as a way to hide concepts that are really quite simple to understand. And the more that teams can spend understanding how the model of their business both works, like how does revenue become EBITDA, if that's what you track? How does a visitor become a customer and how does a customer become a repeat customer?

And what are the levers of that? What are the costs of that? And then similarly, what is our tech stack today? Where are we effective? Where are we not effective? What kinds of things get in our way? How do we think about, as a pre existing model, what we should build and what we should buy? Where do we all believe that we create competitive advantage and competitive moat through those things? So that there's a way to have a conversation about the way it should work even before you bring a particular decision into it, and then the decision flows through and the model gets refactored based on that so that it gets better. It's amazing how much more fun it is when business stakeholders and tech stakeholders are aligned about what we're trying to do as a business because then they help each other, versus this other thing of no trust because nobody believes that anybody's telling them the truth about the whys or how hard it is or whatever, and it can be painful, but it's worth it.

And then, great segue, as you think about how to make decisions about the stack, as we've been talking about, it's important to start with a map of needs and also current realities. The problem we're trying to solve is this, the things that are important to how we solve that problem are this, the criteria for success for improving that problem is this. This is our current environment, this is our infrastructure environment, this is our application environment, this is our team's skillset, their capacity, what we think is important to them. And then what should we build, what should we buy and what should we use, reuse or think differently about on our own? And they're often not binary decisions, sometimes it's buy a little bit of this and build this thing around it. We think a lot about what is commodity and where we can establish and maintain competitive advantage by building something unique of our own.

If it's a commodity, our attitude is we want someone else's R&D investment to drive our benefit. So when I got to FTD, we were home rolling an AB testing platform, that struck me as absolutely insane for eCommerce because they exist, they're good, they've got billions of dollars invested in them, why in the world should we try to do that on our own and how can we make it better? Conversely, when I got to FTD, there was a project to build a new point of sale system in partnership with a point of sale provider. And our point of sale needs are very, very specific to our business because we run this omnichannel commerce engine for small businesses that lets them do business in any digital channel, whether it's walk in or phone or Facebook or eCommerce, in one environment and nobody in SaaS POS land does that.

And so it was like, well we're not going to do that, we got to build that ourselves because that's our competitive mode. So working through all that stuff and really being honest about where the team is and where competitive advantage is created, and then thinking tactically about how to break pieces down so it's like, well actually 80% of this is something we can get from someone else, but there's this 20% that really needs to be our secret sauce. So how do we design a tech stack that benefits from that commodity capability and makes it do something new that it couldn't do because of this special thing that we've added to the top of it?

And then more on thinking about build versus buy, and I think there's a lot really to unpack in here. You can really find yourself upside down if the pricing for something that you're buying is say session based and your initial plan is you're going to run it in this small slice of your business and it's really useful. And so now all of a sudden you've got demand for running this capability everywhere, but that makes the costs scale in a factorial way that kind of really doesn't make sense. I think that speed to market ends up being a really important and often considered opportunity from a tech perspective. A lot of folks who have a job like mine will look at something and go, "This isn't something that we're getting a lot of benefit from renting. We can totally build this ourselves. It would be better if we did it but we can't get to it for 18 months," and then 18 months becomes 24 months.

But because they have enough weight, they prevent their business partners from going out and doing that thing now. What they may not be paying attention to in that case, is because they're divorced from the P&L, is holy crap, we could have delivered a 5% EBITDA growth if we had just done that this year, even if it's not what we want to do long term. Sometimes it's okay to throw something away if the return on investment for the period of time that it runs is worth it. And so speed to market is one of those ... long term cost is a thing that I would argue that often business stakeholders under consider, because they're not thinking about the way the asset will express itself in the ecosystem over time. And I think speed to market is one that tech will often under-represent.

So as you think about navigating these conversations from multiple sides, try to think about it through the lens of the problem space that the person next to you at the table is dealing with. My job is to drive the P&L, if I can drive another nickel today, I'm going to. And if my job is to protect the infrastructure and drive long term IT asset value, then I'm kind of always going to want to move everything at a slow rate. And there's such a thing as healthy tension, those are healthy tensions and navigating it in partnership with aligned incentives is a very powerful way to create value.

Lauren Livak:
And I think the key here is really it's a balancing act. And so what we talk about with having the right partnership between the tech and the non-tech team is so critical because it's not a black and white answer. If someone on the webinar today comes up and asks a question, we might answer differently based on their business versus another question that someone comes to us with because it just might not make sense for the factors that we have on the screen here. So I think that's just an important thing to ingrain in your mind too, that it really is a balancing act and at different times you can make different decisions. And to Matt's point, this is a super extensive slide, it will be available in the recording if you really want to kind of read through it, which I do encourage you to do because it's helpful criteria when you're thinking through something like this.

Matt Powell:
Yeah. And I think to your point, the most important thing really is partnership. Let's agree together about what's important now, what's important tomorrow, what's important two years from now, and how do we then chart a course to get there? And that's really what this slide is about is that we're always in a constant state of evolving maturity, and a mistake that I've made a lot in my career is assuming that you can go in a straight line from one place to another, that change is a ramp and in my experience, change is a staircase. And so you have to accept that sometimes, and sometimes the question is what gets us to the next stair, so that we can then get to the next stair. And I found this to be true for talent, process, structure, systems, everything. Sometimes you go, "All right, the kind of person that I need in this role is this kind of person," but that person is not going to fit into the organization today. So you have to improve the rest of the organization and then hire that person.

And so you might have to make a decision about the right person for this spot is this person today because they get us up to the next step on the staircase. And the same thing is true for all of these technology decisions. What is the right thing now to get us over whatever this hurdle that we're in front of now and then what will be the right thing tomorrow? And some of that is the way your team evolves, some of that is the way your business evolves, some of that is the way your stack evolves, some of that is the way external technology evolves. I had a meeting yesterday, we're like going to war on site performance because our websites are just about a year old and we've been working on migrating workloads from our old websites to our new websites, and now we're really focused on optimization and driving the core web vitals performance score.

And we use React and Next.js on our front end. And there's a big set of changes for Next that are coming out, they're going to solve some performance problems that we have, but we don't know exactly when, they're like three to six months out. So we talked about making a fundamental change in the way that some of our pages are built for now, for three to six months because it's that impactful for us to make the performance of the site better for three to six months, even though we know we're going to do something and then throw it away with something new in three to six months because of an externality, which is a technology change that we know is coming.

Lauren Livak:
And I'll just jump in here in terms of the maturity curve that we've created around the digital shelf. So for those who have not seen this, it is on the Digital Shelf Institute website and we like to think about the digital transformation that comes with going through changes around people, process and technology. And to Matt's point, there are many different stages and there's different things you need to do to get to each stage. So going from a collect to enhance takes people, process, technology to get there and then going from an enhanced to expand might take a different team structure, it might take a different tech stack. You might need to think about improving your processes in a different way.

So this is all to say, to the point that Matt made before, it is not a one and done type of thing, and depending on where you are in your maturity, you have to make different decisions. So there's tools from the Digital Shelf Institute that can help you do that, if you want to take something like this maturity curve to help you see kind of where you are on your journey, it can really help inform some of those questions we talked about around how should you be thinking about technology, what should you be investing in and what are the problems that you're trying to solve?

Matt Powell:
And you can also make one of those, you can make a maturity curve for yourselves based on what you believe the major gates the business needs to pass through are, the capability needs to pass through. And that can be really helpful because sometimes too, it's hard for people to get comfortable with less than perfect today, until they understand that we're all aligned about what the next phase looks like and the next phase looks like and the phase after that. And it can be very helpful to organize business activity underneath expectations of platform capability. So starting to go, all right, look, there's this perfect El Dorado that we know we'll never get to at the far right of the curve that kind of should look like this. And what are the logical tranches that exist before that and how do we get there from a technical capability standpoint? And then how do we line up the way that the business behaves underneath what the technology can do in those moments?

And then everyone can kind of surround that, boards can make investment decisions based on that, CEOs can hold teams to account based on that and technology teams can make business stakeholders comfortable that the things they're doing right now are right for today and for tomorrow and not be having this constant battle of why we're not building the perfect thing yet because we all understand the stairs that we have to go through to get there.

Lauren Livak:
And you can include it in your joint business planning. So I love that idea, I think it's a great point, to be able to talk through with the broader business. So we have another poll, so I am going to launch it so that everyone gets a second to see it. So we really want to understand what resonates with the audience as we're talking through a lot of these things. Do any of these sentences resonate with you and/or which ones do? So IT doesn't understand the business needs. Tech and the business have a great working relationship. The business doesn't understand the resources needed to deliver the software. Or the tech and the business are very siloed functions. So if everyone could jump back on and vote on the poll, we would love to get your thoughts, super helpful for Matt and I as we go through and we talk about these things.
So I will give everyone another couple of seconds. I see some answers coming in and I will close it in 5, 4, 3, 2, 1. All right, let's share the results. So it looks like, oh, it's a tie, so 50% say the business doesn't understand the resources needed to deliver the software and 50% say tech in the business are very siloed functions. Matt, are you surprised by these answers?

Matt Powell:
No, and they kind of go together, which is silos, people don't understand what's going on on either side. And I think it's hard because if you were in tech, and you don't have a great relationship with the non-tech partners across the organization, vendors are constantly hitting the entire org with the barrage of it's so easy to do everything and that's the environment you're answering for. It's not unfortunately, and this is largely, I think, tech's fault historically, is that there just isn't that trust. And so what ends up happening is that there's a belief that things are being made more difficult and a belief that there's no BI tech and then a belief from tech toward the business that the business doesn't get it and doesn't care. And these things are perpetuated by the way that we all behave together and the way that we all interact.

And my favorite little anecdote of this from recently is again, when I was new at FTD, our video conferencing platform was WebEx. And the CEO at one point called me and was like, "No more WebEx. It's embarrassing." We were doing partnership calls with the Martha Stewart's of the world and things like that and people kept making fun of him that we were on WebEx and not Zoom because all the cool kids were on Zoom. And it's like, whatever, they do the same thing, who cares? The goal is to make the user happy. So the person on my team who is responsible for telephony and all that, I said, "Hey look, we're going to term our relationship with Cisco on WebEx. We're going to move to Zoom." First complaint, it's going to be super expensive. I said, "No, it's not, not everybody in the company needs one. I don't know why everybody had a WebEx address. Figure out who actually needs them. We'll allocate them based on need, we can share them if we need to, make it cheaper, not more expensive. Next problem."

Calls me a day later. Here's the thing, the young guy in me really likes this, but the technician in me hates it. Our job is to support users, so I don't care what the technician thinks because when you say technician, what you're talking about is a person who centers the technology, not the people. And that's not what we're about. The technology's role is to enable the user not vice versa. And so there really needs to be a way of engaging that approaches it that way, and that should lead to a better understanding on all sides. And it should lead to an environment where when vendors hit the organization, there's a standard way of processing them in partnership so that everything goes the way that it should go.

Because what invariably happens is that if there isn't trust, where the business is strong, the business brings in partners without IT's buy in, and then tech is forced to figure out how to make those things work inside of the ecosystem, which creates tech debt, which then makes it harder for them to move faster and support the things that the business wants, and it just becomes a degrading proposition over time. And so part of the way that we solve that is with very clear goal and tactical alignment, there's not an IT plan or something that sits separate from the business plan. There is a business strategy that has kind of a maturity goal for each year over a five year period for the business, that's built in partnership between the head of our consumer division, who's a P&L owner, the head of our member division, who's our SaaS P&L owner and me, as the head of our tech division.

And so we got together and we framed a strategy and then out of that we framed where we wanted to be on the maturity curve against that strategy this year, next year, blah, blah, blah, for five years. And then what were the five critical strategic initiatives that we wanted to do each year in pursuit of those things? And then what are all the activities and milestones that sit underneath that in priority order? How does that drive our board level goals? And we basically signed up for 15 shared goals. There's no tech goals that are different from consumer goals, that are different from member goals, it's all one set of goals. And that way when someone comes along and says, "Hey, I just found a new way to generate half a million dollars in EBITDA, let's go do it." We're all on the same team and I say, "Great, what do you want to swap?"

Because you already know that we have a fully baked plan that you bought into with me, that we funded together. Do you want to change anything? What do you want to change? And that level of collaboration and shared ownership for goals is amazing for problem resolution and it totally changes the narrative. And what it leads to is business stakeholders playing defense for tech when necessary in their own organizations. Someone comes along and says, "Well this is stupid, we should do this. They're not focusing on my problem." And their boss says, "You don't have your own problem. We have a problem. We have one set of things we're trying to do as an organization that we're all lined up against together."

So that's kind of the first bullet here, having transparent conversations about goals. What we have done in the past is the business stakeholders would decide these are the things they wanted to get done and kind of what it would mean to the P&L. And so then we would then make milestone commitments to those things by dates. So they would be held to things like an EBIDTA target or a revenue target or an order target or a new customer target, and me and my team, we would hold ourselves to the date level commitments that sat underneath that. It was a terrible idea because when anybody came along with a change that was a better idea, we would still have to support it, but we didn't have a good mechanism for renegotiating milestone commitments, so it would be added on top. And what you would get is no forgiveness for a missed milestone, but an expectation to do more.

Or the opposite, where we would say no to a good idea to protect a milestone commitment and we would then miss the say EBITDA target that we had together because we gave up a higher EBITDA opportunity in exchange for hitting a milestone commitment. And so not only did we work to have transparent goals and objectives this year, but we also worked to make sure that they allowed for enough flexibility to react to changing market conditions. So our shared goals as divisional leaders are all clearly economic, it's an EBIT from a channel or a revenue from a channel or a revenue from a category that either drives the commitment we make to the board for the three key metrics of cash EBITDA revenue or the strategic commitment that we're making to one another about driving the business in this way against maturity.

And it allows us to do things like point number three, which is address pain points on both sides. This thing that we were planning to do became technically harder than we expected. How are we going to pivot together to achieve the same economic target? This thing was easier, how can we double down on it? This thing is more productive, how can we double down on it? So the way our goal architecture works is the company, the enterprise has a board level commitment to free cash flow revenue and EBITDA, divisional leadership has a commitment to the kind of 10 or 15 metrics that really drive that. Then within my division, my leadership has a commitment to all of the things tech has to do to drive those initiatives with as much flexibility built into it by being at the EBITDA revenue level as possible.

And then their departments have whatever goals are necessary at a squad level to drive those outcomes, and those things are quarterly because quarterly, the leadership team's decision about the best way to achieve the outcome might change, and so we allow for that. And then the last point, we've hit this a couple of times, just avoiding jargon and speaking the same language. If the tech team has product names for things, everyone uses those product names so that there's utter clarity about what we're talking about. If there are KPIs, those KPIs have one definition, that definition is governed, the data is shared, it comes from one place. There's no, my data versus your data, there's no, my way of my definition versus your definition.
And shared language for knowledge workers, like pretty much all of us are, is gating to be able to communicate and imagine the world the same way because we're making it up, it's not like an assembly line where you see something moving down that's at you. It's all based really on a shared understanding about concepts and constructs. And so avoiding jargon and having a shared lexicon for how we talk about the business is ridiculously important.

Lauren Livak:
And the other thing I want to double click on a bit is that shared goals piece. So the number one thing, and I think that also kind of came true in the poll, that I hear, is that all of the functions are siloed. We have the non IT, we have the IT, no one is talking to each other. Shared goals helps to solve that problem. And I've said this several times in all the different webinars we've done for the digital shelf playbook, but what gets measured, gets managed, it's human nature. So how can you get everyone on the same page, going towards the same exact goal? That is a huge way of removing those silos because naturally everyone's moving towards the same thing.
So I would really think about, in your organization, if you don't have that, to begin thinking about that, especially in the world that we live in where you have to be omnichannel and you can't just be the eCommerce team and the in-store team. Omnichannel means shared goals, bringing everything together and everybody wins and everyone's on the same team. So I can't emphasize that enough that it's definitely something you should be thinking about if you haven't already.

Matt Powell:
And related to that too, I think for the folks on the webinar here that have come from the tech side of things, in my experience, it is very challenging to impossible to effectively execute with a functionally aligned technology org. Because what ends up happening is you've got a team of software engineers over here, a team of quality engineers over here, and some product people over there and UX over there, and the problem is the only way to really orchestrate in that environment is to goal people on functional outcomes. And now you create a major fire break between how you're driving the incentives for those individuals and what the business actually cares about. And in the same way that behavior will follow incentives, design will tend to follow organizational structure from a software perspective, annoyingly. And so for us, we have domain aligned teams instead of functionally aligned teams.

So my departments are econ tech, big data, network tech solutions, which is my SaaS business, infrastructure, finance tech, and then those teams are organized cross-functionally. So there is no software engineering team, there is no QA team, there are centers of excellence that crosscut departments and squads, but the teams are organized around users business problems and business domains cross-functionally and goaled together against business outcomes, which creates the conditions for that kind of shared responsibility all the way down the line, because people understand my job is to drive conversion rate and AOV using software, which is a completely different way of thinking. So a real life example of where these partnerships can work really well, so we've been launching new SaaS products, our new point of sale just launched a month ago it's second big version. We launched our small business eCommerce platform in the spring and we bumped into a problem.

The business leader of our member P&L came to me and said, "Hey, I've got a huge issue here as we gear up to launch the new POS, we're struggling with the eComm platform already and we're struggling for a couple of reasons. One, it's just harder to operationalize than we expected." And what that has meant is that some of the things related to automating the rollout, because this platform supports thousands of our membership, are not working as expected because there's some things that are harder to do by API than we thought it was going to be and then Shopify thought it would be, because this is a different kind of partnership for Shopify. It's Shopify plus stores, on top of middleware that we build, interacting with our network and they've just never done anything like that before. And so there is a bunch of manual steps to light up customers. So there's that plus the fact that FTD hasn't launched new SaaS products in over a decade, so there's no internal muscle memory for it.

They were kind of looking at this launch of this next product and being like, "We don't have the right team, we don't have the right skills. I need more people to hit the sales targets." And so we started talking together about how do we hit our objectives? Because our fiscal year is July to June, it's like middle of the first quarter when this conversation is happening. And it's like, okay, well do we cancel the launch of the second SaaS product and double down on the first one because the EBITDA expectation for the second one is relatively low for this year, but it's a big strategic hit? No, we can't do that. Can we do this? Can we do this? Can we do this? We can't make it easier to operationalize. So through talking about it, the question the tech asked is what else does this team do besides these things? It was like, well, a ton of other stuff. Let's look at automating that.

And so they sent us a spreadsheet of all the things that that team does and we've identified, wow, there's a whole bunch of other stuff that we could automate that's not related to these SaaS products and give back about 50% of this team's time. So that's what we started to do. And that would never have happened if we didn't have shared goals, and it would never happened if we didn't have aligned incentives. What would've happened instead is that division would've been pushing on my division saying, "The operational failure is your problem, go figure it out." And we would've been unable to do that because of challenges with our partner. And so instead what we got to is something that not only will solve this problem, but will create more dividends because it delivered more free time into the organization to do other things.

Lauren Livak:
Great example of what shared goals really looks like. And in the effort of time, I'm going to skip the poll because we have about six minutes left and I really want to make sure we get to tech debt because I think this is important. So Matt, I'll give you this one here.


Matt Powell:
Cool. So I think that tech debt is often misunderstood and for a lot of stuff in here, if you look at our definition of tech stack, and if you Google definition tech stack, they're going to look quite similar. The tech debt one is not going to look similar because there's a fair amount of debate on what tech debt is. And if you Google it, most commonly you're going to see something like, this tech debt is what happens when technology teams take shortcuts. Which is true to the extent that it is a way that you can end up with tech debt, but I think shortcuts in this context inherently seems like it's laziness, which if you apply the other things that we're talking about in this discussion, it's probably not, it's probably time to value. We're going to do something that's maybe less ideal from an architecture or engineering standpoint to benefit time to value, and that can be a shortcut.

But the other thing that can happen is the world can change. So a huge part of my tech debt is systems that are 20 years old, that at the time they were launched, were state of the art. They're not state of the art anymore. That's not anybody taking a shortcut, that's just the world changing. So we like to define tech debt as the gap between the currently possible ideal solution and our solution, which can be the result of shortcuts that are good shortcuts or bad shortcuts, which can be the result of macro change in technology or can be the result of macro change in the business or can be the result of changes in talent. There's all sorts of ways you get there. And generally speaking, like all debt, some amount of it is appropriate because we're not building software in academia, we're building solutions to create business value, and so sometimes shortcuts are the right thing to do.

But it's important to manage because it becomes wind resistance on progress over time. It negatively affects developer experience, it negatively affects business stakeholder experience, it negatively affects quality and it negatively affects velocity. So it's something that has to be created intentionally, managed intentionally and eliminated intentionally based on value delivery to the business. But it's not something to be afraid of, but it is the kind of thing that going wrong in some of the things that we talked about earlier, can really create. There were a dozen and a half places at least where we had significantly scaled overlapping solutions that cost several hundred thousands of dollars when I got here, and no one could explain to me why. Even today I have three different eCommerce stacks that take consumer eCommerce orders, two of them take less than 10% in aggregate.

I've got three different systems that do order management. I've got three different points of sale. Some of these things by design, some of these things not by design, and that's just what happens. And so it's important to make good decisions to only create tech debt when you intend to, but then it's also important to expect it and plan for it and manage it, to incorporate it into yearly planning, to be talking about it with partners across the business, to make sure that stakeholders outside of tech understand the specific types and format of tech debt that you have and what the negative impacts are, so that you can make shared decisions about when to change them. What's often done is tech teams go, "We're going to reserve 10%, 15%, 12% of our time for tech debt." I think that's a terrible solution. I think the better thing to do is to collaborate together about deciding of all of the things we could do right now, what are the next most valuable? And sometimes that's eliminate some tech debt, sometimes it's create new features. More often than not, it's some combination of both.

But if you're clear about the role of each piece of your stack and how it will evolve, if you're clear about spend, if you're thinking about balancing decisions based on time to market and efficiency, what your team can do in all that, and you have kind of a plan for how you're rationalizing things, it doesn't have to be that scary. And I think when you get comfortable with things being in a constant state of flux, it's sort of easier to deal with because it's just one part of the things that are going to change. But when tech debt is weaponized as a way to spank and punish technology teams, then technology teams will tend to hide it, which will then tend to lead to a less velocity available to the rest of the business to consume, and it just gets yucky from there. So I would strongly recommend pulling a flashlight out, shining a light into the shadows on topics like tech debt and collaborating together with empathy to find ways to eliminate it, to create value for the business.

Lauren Livak:
Thank you so much, Matt. And I know we have about two minutes left, I wanted to just try to summarize some of the key takeaways. I know there was a lot of information in there and thank you, Matt, for sharing all of your anecdotes and stories, which I think are super helpful to the membership, in order for them to make it real in their organizations. But we've said this a bunch, your tech stack powers the business and it's important for all functions, it's non tech and tech that need to be involved in this conversation, you need to work together in order for it to be successful. You need to take into account where you are in your journey. You are going to make very different decisions in the beginning of your journey, the middle, there's really is no end. But as you mature and as you get more progressive down your digital transformation journey, don't treat IT and the business as two separate functions.

I really like the idea of tech versus non tech, try and think about that. Create shared goals, march towards the same thing so that you're all trying to solve the same problem. And then also accept that tech debt is a reality and plan for it. You might make a decision to acquire some tech debt because of a niche market that you're trying to get to or a niche kind of thing that you're trying to do. So to Matt's point, really be open, have open conversations, and collaborate across the entire business. So I always like to close on a quote, "A finished full feature product does not exist, it will always grow and shift and there is no done."

Peter Crosby:
Thanks to Matt, and as always, Lauren, for this final webinar in our digital shelf playbook series, at least for this year. Become a member of digitalshelfinstitute.org and you'll never have to wonder what's coming next. Thanks for being part of our community.