Your integration plan is missing John’s spreadsheet | Mike Dattilo, Xerox

Episode 24 - Your integration plan is missing John’s spreadsheet | Mike Dattilo, Xerox

Matt: Welcome to Data vs. Commerce, where we explore the messy middle between database and doorstep. I'm Matt Johnson.

Floyd: And I'm Floyd Blaikie. Let's dig in.

Floyd: Well, hello everybody. Coming off the heels of our very spooky Halloween episode, I think we've got maybe some horror stories, but maybe also some very inspiring, hopeful stories from someone I think is really in the trenches right now doing the thing, because they have grown by acquisition, as so many businesses do, and I'm really excited to introduce this guest.

Mike, you wanna tell us a little bit about yourself?

Mike: Sure. Thank you for having me today. Mike Dattilo. I'm a senior director of our e-business organization here at Xerox, which encompasses all of our commerce, business, B2C, B2B, partner, as well as a lot of other marketing technologies. But I think we'll be mainly talking about some of the commerce and data spaces today.

Floyd: I'm trying to get this segment off the ground. This lives in my heart and in my mind, but I would love for us to be doing commerce confessions. Maybe it's just because I've seen too much reality television. Probably less than the average person, still too much. What is the wackiest thing that you have ever seen inside of a commerce system or inside of commerce operations?

Mike: Yeah, probably the wackiest thing is just the amount of manual intervention that goes into some of these processes as you do acquisitions and such. And the amount of people manually looking at orders and making decisions and routing, and it's... First of all, do we realize how expensive this is, right, to do this?

Secondly, we're losing all this precious time from the order fulfillment to start kicking off, right? But yeah, that's a tough one 'cause there's lots of wacky things that we've seen. But I think probably just in this day and age, the lack of automation that's in place with a lot of these systems still.

Matt: Yeah. And that is, yeah, that's interesting. One of the things that I was just thinking of when Floyd asked the wackiest thing, I have seen... and we're gonna talk about legacy systems a little bit, right? We're gonna talk about what does an architecture look like?

What has it been built on? Where does the information about that system or systems live? And one of the things that I recently saw with a client was an architecture map that was built on a Word doc, and it looked like it was made from Microsoft Paint. I kid you not. There was little squiggly...

Like, seriously, there was squiggly lines. It looked like it was a mouse being dragged across the screen. So, I'm sure you've seen something... I'm sure you've seen better than that, Mike. But maybe talk to us about what you're up against, especially when it comes to integrating systems.

Mike: Yeah, for sure. Yeah, definitely some that are in better shape and some that are in equal shape, right? And frankly, some that don't have an architecture diagram at all. It's just like, "Oh, we use Vendor A," and it's like, "Okay, well, what is Vendor A? And what do they do? And how do they connect?" And so on and so forth. And so a lot of times it's kind of doing the reverse engineering of how it's supposed to work, how it's supposed to connect. And again, devil's in the details is, there's a lot of commerce that's very consistent throughout whatever you're gonna sell, whatever experience that you have.

But there's a lot of niche as well out there, and I think that's really where the bodies are buried is in a particular industry, in a particular product type. Like, "Oh yeah, we forgot to tell you, this other process kicks off over here after the order's placed," or this sort of thing.

Or, "You need to do this sort of authentication," so on and so forth. But yeah, lots of different variation from kind of where the starting point is. But I think it's the learning of how do you get the details that you need to do the connections? And especially in the point of lots of acquisitions are going on throughout many industries right now.

And oftentimes people will decide to move in a different direction if they're acquired. And so making sure that you get the information that you need from those individuals who are the kind of product experts, process experts before they're not there, right? Because if you start in a place where you have some good documentation, that's the best scenario.

I would say there are few times in my career where that has been the case, including my own teams. I'm not throwing shade at anyone else. But it's then making sure that you kinda understand what's the important questions to ask, what's the right type of documentation and format to get those questions within.

And hopefully that person's gonna partner with you kind of throughout the whole process. But if they don't, you wanna get as much of that information as you can, so you can be as successful as possible.

Floyd: Can you walk us through the battle that you're fighting today? 'Cause it sounds like that you're actively working to integrate a bunch of systems to... You've got an acquired organization being folded into Xerox. What's the landscape today? Paint the picture for us.

Mike: Yeah. I mean, it's kind of all over the place on both sides. So the reality is the Xerox infrastructure was still not fully integrated into singular systems, so we have multiple systems across different countries and our different kind of customer audiences, partner, B2B customer, B2C customer.

But also the same thing from some of the acquisitions that are coming in. And so if you take a jigsaw puzzle, shake it all up, and throw all the pieces on the table, that's kind of where we're at, you know?

Floyd: Two or three different jigsaw puzzles all...

Mike: Yeah, that's the better picture there.

But I think we have sorted mostly through, like, okay, what is the picture as it exists today? And also, we've kind of now got the box cover of what puzzle do we wanna build. And we're somewhere in that in-between journey of sorting the pieces out to say, "Oh, that doesn't fit the puzzle piece we wanna build. We're gonna put it in this pile. This one does. We're gonna put it in this pile." And like I said, we've got literally dozens of different systems across the different company systems. And everything's not necessarily gonna be one system in the end.

We do use Adobe Commerce as kind of our North Star from a commerce management perspective, but that's gonna integrate into ERP systems. And as an example, when our distributor orders things, that's gonna be more through a web interface directly to back to the backend systems, which for us is gonna be SAP S/4HANA.

So yeah, I think, again, we've sorted out those puzzle pieces. We have a picture of the end picture that we're trying to build. And we've got some of those pieces and components in place. We're starting to actually put some of the pieces together. We see the bottom left corner of the puzzle now that we actually wanna put together.

But there's still a long road ahead of us, and it takes a lot of different teamwork across a lot of different teams to make these things happen, not just the commerce team. We're working with IT teams, working with customer experience teams, working with brand teams. How do we want this experience to work?

And a lot of those things change over time too. So we have a initial North Star and roadmap we put together, but one thing is constant with business is change. And there's a lot of change that happens through these acquisitions and just in general with AI technology coming in and, oh, we didn't have this last year.

Where does this fit into the different architecture that we have this year? And so just being open to change that plan and being agile enough to kind of pivot to the next important business priority that you're working on is really where we're trying to kind of focus the team now.

Matt: It reminds me of... and this is like an ongoing joke. I hate talking about AI because I feel like it'll just get washed out...

Floyd: And yet...

Matt: Yeah, and here we are.

Mike: Every conversation.

Matt: But I was gonna say, talking about the puzzle analogy, which I think is a really great analogy, by the way.

We can also say, like, Lego sets, right? Like, throw a bunch of Lego pieces on the table. And when it comes to, from our perspective, if we're working with a client and consulting on an architecture, building integrations, the hardest part of that entire process, it was... writing code took some time, but it was the requirements gathering really is what the challenge has always been.

And AI has helped us kind of, at least to a large degree, organize all those puzzle pieces, having the conversations with the right people, right? Feeding those transcripts into an engine that helps us to build it quickly and get to a point. But there's a pro and a con to that because I think you mentioned this on an earlier conversation, some of the documentation that AI can create is, like, hundreds of pages long.

And that can be as much of a problem as the scribbles in a Word document, right? Well, what have you seen, and what would you say are some best practices for sorting this puzzle mess out?

Mike: Yeah. I would 100% agree. Understanding kind of the scope of the project is half the battle and usually probably even more than half the time, right, that you get on a project. And a lot of times that's not taken into consideration. People wanna know the implementation time, but it's like, well, first we have to even know what we're implementing.

And to your point, yeah, I've kind of seen both extremes. Very little to no documentation that no one is ever gonna sit down and read or more or less update, right? Because it's just too long and too detailed. And I think the sweet spot is somewhere in the middle.

I think you have to kind of decide on... So for us, what we focus on, we wanna understand the architecture. So having kind of that one-page architecture diagram of how do the pieces fit together, what are things that are kind of inside the box, what are things that are outside the box, that kind of thing.

And specifically when you're going to need other departments' help. So in y'all's case, you may be helping a client, and that client may be a department within an organization, but oh, this piece, you're gonna have to get another department to align their schedule to deliver this piece so that we can connect to it, kind of thing.

And same thing for me internally, that's a big challenge is everybody has their own roadmaps and their own timeframes and how do you align these things, such that you're ready when they're ready, and you can kind of make that connection and you're not months or even quarters off on the timeframes that you have.

So architecture diagram, I think is super important and keeping that up to speed all the time. I think we get lazy on those and we implement a new search feature, we implement a new suggestion engine, and we forget to go back and update that diagram, right? So I think that's really important. Data flows I think is another really important aspect to this.

And that can be pretty tedious. I'm not gonna lie. We have some pretty gnarly data flow diagrams. But super important to kinda understanding where, from the first customer integration, where does the data go? How does it get processed? How does it get disseminated to different system? Where does that data reside?

So you have some data residency laws about physically where it resides, but also just from a system standpoint, where you don't wanna store all your PII information in every system that's there. So you wanna have some mapping of where that needs to be, and kinda only store that data where it needs to be accessed and be able to kind of combine those things.

So architecture diagram, data flow documentation. And I will say that the third place is where I do think a lot of the different tools that people are able to use now are providing good code documentation. So again, ten years ago, frankly, most of us had pretty terrible code documentation because it took time for an individual to go and document something.

Heck, a lot of people aren't even writing the code these days. You get the documentation in the compiled pieces of the code as you're using whatever it may be, a cloud developer tool, so on and so forth. And I think that is important though to kinda understand what is this chunk of code even trying to do, you know?

And I think in the modern tools, that has become much easier. Unit testing, I think would be the other thing that I would say. It's not technically documentation, but it does help you understand what are your main user goals that you are testing. And also for us, that's one of the things that allows us to move really quickly, is we have a lot of automated unit tests that when we build, we know that if it's a major user experience and it's gonna break, it's gonna break on that automation regression test, the unit testing that's gonna run, and not when a customer tells us after we've deployed code that, "Oh, by the way, I'm not getting my order confirmation email anymore," that kind of thing.

So those are some of the foundations. It's gonna be different. Different industries are gonna require more documentation. So something like healthcare as an example, you may have to have some other documentation that's needed there. But finding the right balance, I think too much is not good. Too little is not good. Somewhere in the middle that people are actually going to use, they're actually gonna reference, and that you can actually keep up to speed. I think that's the key.

Ad: Your integration layer holds your e-commerce stack together, and your best engineers spend most of their time making it work. Pivotree delivers integrations in half the time and at half the cost. Then we watch them twenty-four seven in production for a fixed monthly fee. Get started with a free integration sprint.

Learn more at www.pivotree.com/integration. That's www.pivotree.com/integration.

Floyd: I think that when we think about bringing all these systems together, integrating a bunch of disparate systems, whether that's just you're optimizing what you have or there's an acquisition scenario. When we're thinking about the gotchas and the places that you encounter, the snags and the hang-ups, people's minds go to the platforms.

But how much of that effort is actually digging information out of human brains, right? 'Cause there's always somebody in the organization that has, like, a load-bearing spreadsheet that no one else can access, and if they go on vacation, everything falls apart. Like... found a lot of that throughout your project?

How did you deal with that?

Mike: Yes, for sure. And again, not just with recent acquisitions, but going back in my career, I would say the human element is the hardest element. I mean, frankly, kinda easy to understand what technology does and how to plug that together. But to your point, understanding, oh, there's literally a pricing spreadsheet that John over here maintains and loads every day, you know?

Nobody told us about that, kind of thing. And I think the human element is an often overlooked piece. And again, that goes into what we talked about before with requirements and how that cycle is actually usually one of the longer cycles in the development project, is understanding how things are.

And I think as practitioners, especially if you're maintaining a system for a business, you have to understand kind of what your choke points are, where do you have critical singularities. And in those cases, not only do you need to help in setting the time to allow those people to create documentation, but also to encourage cross-training within team members, knowledge sharing.

And it's not the fun and sexy things, and this is where I think it's very easy to overlook. It's also not something that's going to generate new revenue. But I think it is going to help in the speed at which you can move. It is gonna help if you do happen to have attrition to be able to get that backfield and move forward very quickly.

Because I'll tell you, there's nothing more slow than trying to reverse engineer how something is working without the person who knew how it worked. And I've had many times in my career where that happens. And oftentimes too, you don't even find out until system is live and somebody says, "Oh, the whatever OST report isn't running anymore."

And you say, "What's the OST report?" Like, we've never even talked about this. So yeah, I think the people piece is a huge piece. And I think it's a big part of us as leaders to make sure that we're not putting people out on an island. But also that we build that time in for them to be able to keep that documentation and such up to speed.

Again, for us, but also for them. The people want career flexibility, and you have employees who feel like, "Oh, I don't wanna leave the company in a bad spot, but I have this great opportunity," kind of thing. So I think it's best all around. But yeah, I think that is one of the biggest challenges and again, it's even one we will always face.

It's not an easy thing even now. Like, I know it's something that we need to do, but you always get in kinda crunch time where you have to make trade-offs, you know? And it's, do we do cross-training right now on this thing that we just did and released? Or do we get to this next high priority project?

And I think it is, like I said, building some of the time into your schedules to do that, building some of the redundancy to do knowledge sharing, and those sorts of things. But also, like I said, the documentation we talked about before, that's gonna help with those things too. If you have that architecture diagram and you happen to have a spreadsheet or Smartsheet object in here, you can be like, "Ooh, what's that? And what happens here?" And so on and so forth. And again, the need to keep those things up to speed as well, up to date.

Matt: I come across this a lot in manufacturing because of all of the different workarounds that happen inside of this ecosystem. Things that ERP isn't doing, but it lives over here, and there's a little workaround that we built. And so if you take a look at this diagram, this architecture, right?

Even if it is documented, when you zoom in, like, if it's a map and you zoom into it, well, there's nothing on the diagram. But in real life, there's about 25 different workflows and hands that touch things, right? And that's where... So if you are bringing in an SI like us, or if you're re-platforming, or you're looking to tie some new systems together, if that stuff isn't somewhere, you are going...

This is why projects take two years when they could take nine months, potentially. And we see it quite a bit. So if that stuff's not there, it has to be built. That's the priority. And so when I tie this back to data, product data, it is not the sexy thing because of all of the work that has to go into it before it actually becomes sexy on the website, right?

All of the governance work, and it's the same thing in the IT department, in the e-commerce department. You've gotta do the unglamorous work of documentation. And then do you have a system that closes the loop? Just like you would govern a product catalog, you don't publish it and it's done.

You publish it, and then you continually maintain it. And that's where it seems like most organizations struggle. And God forbid that person wins the lottery and moves to Fiji, you're really in trouble, right?

Mike: Yeah, good for them, bad for you. Yeah, no, absolutely. I agree. And again, that's where it has to be built into your process. And we were talking before, our process is intentionally iterative and agile. And it's actually more of a Kanban style than anything else because the reality is, the business changes all the time.

And if I have this... you mentioned why projects take two years. I've seen these big two years waterfall type project plans. The amount of change your business is gonna go through in the next two years is unbelievable. I mean, think about two years ago, right? And all of the LLM, AI, all the kind of things that came into our world since then.

If I had a project that says it's gonna take me two years, and I'm gonna ignore all of this change and not do any of that and deliver a project in twenty twenty-six, we're gonna miss the mark on those things. And so our process is intentionally iterative. But in that, to your point, it is keeping the core components updated as you get through those iterations.

But it allows us to kind of just look at, again, what are our business priorities? And as they change, we can look at to say, "Okay, this is what our plan was to do next. Is that still the most important thing for the business?" And if not, we're able to kind of say, "Nope, we need to set this back, and there's something new that has come in, and this is now the next most important business object that we have to go work on."

And kind of break that down and put that into task and go work on that. Now, the other priority's still on the list. It's just no longer first. Now it's second, you know? And so we're gonna work through those things. And it's never that easy where you have a number one thing and a number two thing.

But you can't have ten things, right? Is you gotta say, "Okay, well, these are the top couple, top few things that we're gonna work on in parallel." If you have, "Well, these are the top ten things," I'm going to make equally slow process on all ten of those things, right? And everyone's gonna complain that their thing isn't done quickly.

And that's a thing, again, that you're gonna have to work with your leadership team on is, it is much better to have a smaller number of projects that are prioritized that you can get done quickly and deliver business value on than to slowly make progress on a bigger collection of projects.

Floyd: Absolutely. Mike, I'm gonna try to squeeze one more pearl of wisdom from you before we go. So I think that you're in an interesting, maybe kind of unique situation because you came in from an acquired business, and now you're running the commerce show at the acquirer. So you're wrapping your own previous systems into the business infrastructure right now.

If you could go back in time and grab yourself by the shoulders and shake yourself and tell yourself to do something differently before you start that process, what would you have done differently?

Mike: Yeah. I mean, honestly, it's hard to prepare for those things because it's not like you see them coming, right? And so I think in general, the thing in any acquisition process, whether you're being acquired or you are the acquirer, I think it's really just being very open to, we don't know the right solution yet.

Let's get all of the options on the table. Let's discuss where it is that we want to go as a corporation, and then let's evaluate the options that we have. And that's always hard, and frankly, it's always full of emotion, right? Is, on both sides is, we've got the best system, we've got the best system, we've got the best process, we've got the best process.

And I think for me, probably the best thing is just, again, remember, we're a team now, and we all want what's best for the company and taking some of the kind of emotion and... again, in that vein, there have been things, and very recently there has been some decisions where it's like, "Wow, I don't know that this is the best decision or this is the best software that we could use, but it is the best decision for the company of where we are right now."

All right? And it's helping people kinda come together and do that. But as far as in the previous role, how do you prepare for those things? I do think it's a lot of things we talked about here, right? Is, you need to have the right level of documentation.

I'm not saying everything. Again, you don't want the 100-page document, but you need the right level of documentation. You need to understand if you do have critical singularities. And the moment that you hear the news that, "Hey, we're gonna be acquired," so on and so forth, prioritize getting those people cross-trained and getting that documentation done and so on and so forth.

And again, it's not always because you're gonna lose them, because the company is integrating. You may lose them because they're not interested in the way the direction is going with the company. They were happy the way things were, and things are going in a different direction. And so just looking at those things that are critical that you're going to need as part of that integration journey, and starting to prioritize those things.

Because I will say in the initial acquisition timeframe, it's chaos, right? It's really unclear to know what to do. We had this whole roadmap. Now we're being acquired. Do we continue on this? Do we not? And so I would encourage people, instead of just kinda going full blow, full board and continuing on your roadmap and these sorts of things, pause a little bit, have the right conversations, again, on either side with the company that is being acquired or who is doing the acquiring.

And make sure to get the right documentation and cross-training and things done.

Matt: Man, this is so good, Mike. I really appreciate you sharing that because doing the next right thing, and what I'm hearing you say, too, and this is not something you talk about on Data vs. Commerce very much, but it's the human thing, right? It's the humility that teams have to have in a world where things are rapidly changing.

Whether that is an acquisition moment, whether that is a new technology that is impacting the way our business works or the way our customer's business works, this requires a lot of patience and clarity and... And so much of what we talked about is really, it's the human side of making this technology work.

And leadership looks like what you just said. We only can do the next right thing. We can't do the next 20 things. And we have to be able to pause, look at where we're at, find the gaps. Where are we not documenting? Let's do the hard work first so that we can reap the benefits later.

Mike: Great summary. Yeah, I couldn't have said it better myself.

Floyd: All right, Mike, if people wanna find you, where can they find you?

Mike: Yeah, I'm all over LinkedIn. I'm pretty active there, so just look up Mike Dattilo on LinkedIn. That's the best way to reach me. And yeah, happy to chat with anybody if they got projects going on and wanna talk about those. I run a Adobe user group on commerce as well, so if you're on the Adobe platform and interested, look me up there, and we have quarterly meetings there.

Floyd: Nice. Thanks so much, Mike. It was a pleasure having you.

Mike: All right. Thank you all. Appreciate...

Matt: Love it. Thanks, Mike.

Announcer: Thanks for tuning in to this episode of Data vs. Commerce. New episodes drop weekly. So if you're responsible for any part of how products get from a database to a doorstep, subscribe now on Apple, Spotify, or wherever you listen.