Podcast Series
Unleashing the Power of Technology: Strategies for Smooth Implementation
Transcription:
Kali Jakobi:
Welcome to Data Disruption, a podcast all about data problems, solutions and innovations disrupting the private markets. I’m your host, Kali Jakobi. Let’s talk data.
Hi, everyone, and welcome back to Data Disruption. As always, I’m your host, Kali Jakobi. And today, I’m very excited to have John Coleman from Carlisle with us today. John, welcome to the show.
John Coleman:
Thanks, Kali. Really happy to be here, and excited to just have a conversation today about what we’re talking about.
Kali Jakobi:
Awesome. So John, before we get started, tell us a little bit about your background and your role at Carlisle.
John Coleman:
Great, thanks. So at Carlisle, I’m a product owner in our deal valuation technology space, so I’m responsible for managing our deal valuation technologies, and really focused on transforming and innovating those products into a space where we feel like we’re really creating a positive add value for our business or creating an improved user experience or user interface. As far as my background, I actually started in financial operations and not this actual technology space that I’m in today. Worked with a firm called Brown Advisory and worked my way up through financial operations with them. And they’re focused on serving high net worth clients who have very complex investment portfolios, which is how I navigated into this private equity financial space. But I did a little bit of everything over there at Brown, from complex portfolio and investment setup, client onboarding and offboarding, managing our CRM, investment book of record, data, just looking at all things like that.
Eventually after a while, our firm started to invest in technology to help take what were a very manual process at the time and transform them, digitize them, and really create strong workflow platforms that our colleagues could use to really be successful in this space. And we had a lot of success. I think I just got tapped on the shoulder for that role. I don’t really know how I fell into it. I think I was just the subject matter expert and was set to represent us from that space. And eventually I just fell in love and I went and got my Certified Scrum Product Owner certification, and really just started digesting all things product that I could. Had a great time at Brown. We did a lot of cool things. We were able to be really innovative, eliminated a lot of manual work, data silos for folks.
And then eventually, Carlisle just reached out to me and said they were looking for someone to do the same kind of thing. And I just saw it as an opportunity to take everything that I learned before and redo it but do it better, more improved, more efficient, more accurate. And just overall, I’m really excited to be here at Carlisle now and taking on this effort. And I think we still have a long way to go, but we’re certainly getting there. And I’m really excited for what the future will bring.
Kali Jakobi:
I love it. A man of opportunity, for sure. So when it comes to an overview of investment data technology implementation in today’s day and age, you by far have an insight to best practices there. What is the impact of this gone poorly have on these firms? And tell us a little bit about what you’re seeing.
John Coleman:
The impact can be really bad if things are done poorly. Sounds like you might know that from experience. But overall, just looking at data technology and implementation today, I think you’re going to … especially in the financial space that I serve, I recognize that a lot of industries are already up-to-date on this. I think overall, finance investment typically is always a bit behind the curve maybe by 10 to 20 years or so. So I think you’re going to see a lot of growth and attention in this space from investment firms and investors over the next, let’s call it five to 15 years. I think you’ll see a big increase in that, and getting people who have expertise in this space trying to help navigate those implementation processes.
As far as best practices and really how to do this best, I mean, I think it really starts at the very beginning, whether you’re proper project planning, you really have to start off by getting everyone in the business on the same page, whether that’s your stakeholders, your subject matter experts, your technology folks, your business sponsors, whoever it may be. Everyone really needs to be on the same page about what we’re trying to accomplish with this data implementation. How do we get it from point A to point B? What are our actual goals? I think sometimes different groups can have different goals or different opinions about what the right solution is. And if you start developing before you lock that down, you’re shooting yourself in the foot and might end up having to debuild what you already built to scale back and then rebuild from there to get to the actual end point, which no one ever wants to do. Costs time, money, slows everything else down. So no fun from there.
I think the other really big thing that sometimes often can be overlooked is you can lose buy-in from your business or your users. And it’s really hard to get back on track once that’s done. And I think oftentimes the blame might get put on the product when it’s more it was a challenge with the implementation or the foundation for the implementation. Maybe we didn’t come together properly as a team or as a business and really define our data sets, define our data definitions, understand what our data is, who’s responsible for maintaining it, how do you add new data, how do you get rid of old data, just all those kinds of change management controls and things like that. When we aren’t on the same page upfront, you might build a product that’s not what the business wanted, and therefore they start to lose faith or lose confidence in the product. And it’s just not ideal, and it’s hard to get back on track.
And then you also maybe lose buy-in from the testing that you need once it’s their turn to do the testing, or even from when it’s time to do training, maybe they’re less focused on training, and therefore you’re just further shooting yourself in the foot, because now they’re frustrated with the product because it wasn’t exactly what they wanted. And they might be even frustrated further because now they’re not fully bought in, and they don’t actually want to learn how to use the product, which I don’t think is necessarily the case everywhere. It’s not the case here. I think it’s more just I’ve seen it happen in the past and I know it can be challenging to get everyone on the same page, especially when you see a lot of growth over time. A lot of times when people are starting to look at data solutions, it’s because they have had a ton of growth and therefore maybe they’ve lost the set of controls that they had. And they need to pull that back in and reign that in with the new system.
And when you have all that legacy data, you have mergers and acquisitions and different people have been using the same values for different purposes, it’s really hard to get back on track. So just taking the proper time to really build out the right project upfront, making sure we have clear pictures of what our MVP is, our iteration one, iteration two, it’s all going to be helpful in actually getting to the point of your end goal, creating the add value for your business, and getting ultimately the return on investment that you’re looking for from the product.
Kali Jakobi:
Well, I definitely hear you when you’re talking about the challenges there. In your experience, though, specifically when we’re talking about cleaning up complex data, how can companies go about addressing them? I mean, I feel like we all have heard how hard it is, but how do you do it?
John Coleman:
Yeah, I mean, I wish I had a perfect answer. I don’t. I think it’s a different answer for everyone based upon what your current data foundation is, but I really think you need to make sure you have the right subject matter experts in the room. And I don’t think that’s always going to be just your technology and data people. That’s going to include the right business folks, the people who are actually using this day-to-day, and using your information to make business decisions.
Cleaning that up, it’s tough, but ultimately it’s just a lot of work that has to be done. And you really need to take the time to sit down and go through your data set and define each piece of data, define the definition. It comes back to that concept of change management. I think what’s really been successful from what I’ve see in the past is a review committee or some type of committee that is … “We feel this is equal representation from our business units or our people that are involved with this product or impacted by this product.”
Making sure that if someone wants something new, they want to make a change or asking to clean up something, get rid of a piece of data, get rid of a field, whatever it may be, add new ones, we direct that through this change committee. And essentially, it’s the right group of subject matter experts that are able to ask the right questions. Does this change make sense? If yes, should it be implemented across everywhere, or is it just a very specific set of data that this applies to? Does this need to flow downstream to other systems? How are other teams using the same piece of information?
So I think that’s really helpful before making any changes or really starting the development, is just locking all that down and making sure everyone’s in agreement we have the appropriate sign-off, because if not, you’re going to roll something out and then it’s going to be in production, and some unintended consequence that no one thought of or just was overlooked because everything is complicated. There’s a lot of moving parts in all businesses. So something gets overlooked and then you roll something out and you have to roll it back because you broke something, and it’s just frustration. It leads to that poor lack of confidence.
So I do think change management review committee and just having those processes really defined within your organization, that’s even less … Yes, you need a technology perspective, but as a business, you really need to be thoughtful about that process and take time before you really look at implementing any technology. You don’t want technology to be a Band-Aid. You want it to be a long-term solution. And in order for it to be that, you’ve got to build the right foundation to build off of.
Kali Jakobi:
I was actually going to ask a follow-up question to this, but you just started to go into, but how long before you start looking at technology should you be prepping your data? You hear so much about you just try to jump in and get that Band-Aid fixed with technology, but a lot of it comes from in-house understanding what you actually need. How long would you say that takes before you start looking for technology?
John Coleman:
I think that’s a really big takeaway for anyone to hear and to listen, especially businesses that are looking at technology right now. It’s really ask yourself, am I actually in a position to do this? Is my data ready to go to be in-taken by a product or a software and be able to actually export it into whatever you’re trying to transform it into, whether it’s managing a workflow, creating forecasting, modeling, reporting, anything like that. As far as amount of timeframe, I guess it depends on when was the last time you cleaned your data up and how complex it is. Have you gone through any mergers and acquisitions? I think that’s a really big thing, too. If you’ve gone through any acquisitions, how integrated is that business actually in your business yet, or is it more you really need to get them fully integrated into your processes and your workflow first before you look at the technology? Are you thinking about doing both at the same time?
Ultimately, you have to be able to set those standards across your business for your technology to actually be scalable and for it to function the way that you want to. I think you could take anywhere from a few months to a couple years to actually do that. It’s ultimately, how quickly does the business want to ask their people to spend their time and resources focused on this effort? I think sooner the better. I do think it’s something you should be looking at regardless of whether you’re the one to implement a new product or not. Ultimately, data is one of the most powerful assets that we have at our disposable as a business to be able to use and make effective business decisions from.
Kali Jakobi:
Yeah. I’ve been hearing from leaders in the space the notion that quote, unquote, “Software does not equal good data.” And on the same train of the Band-Aid fix, I hear this becoming becoming increasingly popular. Can you explain what that sentiment means to you and why it’s important for companies to really understand that?
John Coleman:
I think it’s really important to understand. I’m glad that it’s actually an idea that’s picking up in the industry. I think to your point, a lot of people just think technology is a solution for everything, where technology, in my head, the way I think about a product or a data solution or whatever the thing that you’re looking at is it’s probably most likely just going to be the conduit or the tool that empowers you to actually be able to track, maintain, manage, control your data, your processes, your workflows. It’s more this is what supports your ability to do it. It’s not the actual foundation behind it. Ultimately, that’s your business. That’s, what do we do as business experts in our space? These are the steps that we’re taking. These are the pieces of the data that we’re tracking, the things that we need to know, the steps that we’re taking.
It’s really important to get the foundation right. Software does not equal good data. Software, once again, is the conduit. You cannot build a solution on a poor foundation. It’s just not going to work. It’s just like a house. If you build a house on a poor foundation, it’s eventually going to break or it’s going to be a Band-Aid and it’s not actually going to solve your end goal. And then you’re going to end up spending more money, more time trying to actually get to your end goal, where if we actually just took time up front, corrected the foundation, got the data where it needed to be, created the right change management control processes and then implemented, I think firms will have a lot better experience with the implementation process as a whole, save themselves a lot of money from the cost of implementation, as well as generate a much larger return on investment over time from the implementation itself.
Kali Jakobi:
Right. I like the house illustration. I mean, it doesn’t matter how great your kitchen is and how techy your house is, if you have a crappy foundation, it’s not going to be there for long.
John Coleman:
Exactly. You’re as strong as the foundation that you’re built on, is I guess the best analogy that I can think of to describe this concept.
Kali Jakobi:
Right, absolutely. We’ve talked a little bit about driving change within the big company and how challenging it is to get everyone on the same page, all in the same room. Can you share some strategies that have worked for you in implementing new technology or processes?
John Coleman:
Yeah, that’s another great question. I think this biggest strategy for me that I have found to be successful is being aware of your stakeholders, your business sponsors. And when I say being aware, I mean not only aware of who they are, but aware of their understanding of an implementation. A lot of times this might be their first product implementation, whether that’s waterfall or agile. Agile is the more standard today that we’ve shifted to over time, but a lot of times it’s these people’s first interaction with something like this. They don’t have any background on how a process like this works or a project like this works. They’re an expert in what they’re an expert in, and that’s their business field that they’re working in.
So I think getting those people on the same page and explaining, “How does an agile project work, how does a project implementation work? Here’s what I need from you, here’s what I’m expecting from you. I’m expecting you to work with me to build out requirements, to find requirements. I’m expecting you to look at demos and provide feedback. I’m expecting you to do tests to make sure that what we’ve built is accurate.” And letting people know what it is that we’re actually taking on and what they can expect throughout this process is going to be really key, because if not, you’re going to be in the middle of your development and you’re going to say, “Hey, I need you guys to do X, Y, Z things.” And they’re either going to say, “I have no idea what I’m doing.” And it’s going to be a total loss, and you have to spend a lot of time correcting that, or they’re going to do a half job essentially and not fully do it to the way or the quality that you need it to be. And therefore you then release it and you got to roll it back because something went wrong, or just unexpected things that we didn’t account for originally weren’t there.
So I think that’s really, really important. And I think you also just need to balance the expectations with people as you go. I know I’m talking about upfront right now, but as you go, these projects are very adaptable. They can change from a week-to-week basis, especially depending on what’s going on with your business. So I think it’s balancing the business with that, as well as recognizing you’re here to implement a project. And this isn’t always their number one responsibility either. So it’s being mindful of that and trying to create a forum or thoughtful ways to be able to actually get the buy-in and the time that you need from them and work into their schedule.
I think some of the ways I found that to be successful is having them join daily huddles and stand-ups that maybe they wouldn’t join; not that they need to go to every one, but it helps them understand what we’re doing. You’re doing your sprint review, so communicating back to them what we’re doing every one to two weeks so that they understand that this project is actually moving forward, it’s not sitting in a limbo. And that way you can also use that as a time to communicate with them, “Here’s what I’m going to need from you over the next week or two.”
I would say those are some of the big things, but I always circle back to you need buy-in from your business and the people that are asking you to implement this product or this project. And ultimately, they need to be with you hand-in-hand throughout the entire process for it to be successful. Ultimately, we’re the experts on the technology, but they’re the experts on their own processes. And I need the buy-in and commitment from them in order to get them what they actually want in the end. And I think we all know we want to get through the business’s actual end goal and not whatever we think the end goal may be, because that’s actually going to make the business happy, create the add value that they’re looking for, and the return on investment that they’re looking for.
Kali Jakobi:
It sounds like buy-in and clear and defined expectations are the foundation for building the foundation.
John Coleman:
Yeah, I think that’s a good way to describe it. I know agile’s all about jumping into the process and getting something off the board, but you got to at least know what you’re working towards for your MVP at first, and then what you’re working for towards iteration one and iteration two. I’ll also say, I think when you’re building something out too, it’s really important to be mindful and communicative with your business about what you can get done in your MVP and what you can’t get done, or what’s in scope and what’s not in scope. I think oftentimes they’re thinking about the end final product, and you’re really just trying to get an MVP off the ground to then do your next iteration or one or two from. But it’s also really important to make sure you’re taking down the notes, jotting down what they want for iteration one or two. That way once that MVP’s up, you can go right into that stuff and start adding on these bells and whistles that most likely your business is looking for.
Kali Jakobi:
In a perfect world, we would have plenty of time to get our data together before we implement technology, but as you already mentioned, a lot of times this is somebody’s third, fourth, fifth priority because they’ve got everything else going on in their day job too. So why should investment firms invest in technology now to drive change? And what benefits can they expect to see?
John Coleman:
Yeah, I think that’s a really great question, because this is actually helpful in communicating why they should actually make this their priority, why it’s important for them to invest time and resources at this now rather than later. I think I’ve got four things that come to mind off the top of my head, and maybe I’ll touch on each one a little bit. But the four things that I’m thinking of are return on investment, deregulation, employee retention, I’ll call it I guess key man dependency or knowledge transfers.
I guess starting with number one, return on investment, obviously one of the biggest ones that people are always going to be looking for when thinking about the product. But ultimately, what I found a lot of times the reason firms are looking at products is because whatever they’ve got going on today is too much for them to control or it’s out of control at this point. There’s a lack of accuracy or there’s a lot of manual work going on. And with that process, not only are they spending time doing manual entry, but they also might be just investigating data or investigating things that are going on.
It’s like, “Hey, I have this value showing on this company or this portfolio or this investment in my portfolio. I don’t understand how this value got here, where it came from.” And then people are spending an hour or two hours … And it’s usually not just one person. It’s a handful of five people, 10 people trying to figure out how we got this incorrect calculation in here. Where’s this data flowing? Are there downstream impacts that we need to be worried about? How do we get it fixed? Is it a bug? Just a lot of different things going on. And when you really think about it and you start to put your business cap on, every single one of these people that is spending time troubleshooting data or manually entering data at a whole, there’s … let’s call it an hourly cost for all of this human capital that you’re using in order to manage these processes.
Over time, that cost just continues to increase. The faster you can get a solution in place to help implement those processes of manual entry and eliminating that for them, you’re going to create an ROI sooner rather than later, and then that ROI continues to multiply over time. And then addition to that, as your firm continues to grow and scale, the solution in ROI also grows and scales with it. So technically, that’s a really big added value, because not only are you giving time back to the colleagues to work on actual add value work that they’re subject matter experts in and that helps generate business revenue, essentially, you can either go through the cost of implementing a product that can scale your business and create continuous growth in ROI over time, or you can keep doing what you’ve been doing and continue to pay for the hourly rate of all your colleagues or everyone working on troubleshooting all these things and having them doing this manual work and paying for them to do that instead of the actual add value work that you really would like to pay them to do.
The next topic I’ll say is deregulation. I think especially in the financial space where I feel like we do have a bit of that drag, I guess I’ll call it, or maybe we’re behind the industry standards that we’re seeing in other markets, I think it’s only a matter of time before investment clients, regulators are expecting a standard across the industry of you need to have certain data implementation tools, data management tools or workflow platforms in order for us to actually consider you compliant. I think you’ll see a day where the regulators recognize the amount of risk to still doing manual work, doing things in Excel, doing things that lack business rules and I guess safeguards and safe rails that can actually help your business is a risk. It’s a risk to not only your business but also them as investors.
And I can even see in our investment space specifically where your SOC clients that require you to have these SOC certifications in order to be able to actually manage their assets, they’re going to have a set of standards of saying, “You need to have a cloud software in order to actually manage your data. You can’t do data offline,” or anything like that. It could be any type of product. Eventually, you’re just going to start to see more of a standard where if you don’t have these products, you’re going to be deregulating yourself out, or if you don’t have some kind of solution for this, you’ll deregulate yourself out of the market, which you don’t want to do. And then when you find out that you might be deregulating yourself, you’re going to then be in a rush to get something implemented. And you’re probably going to implement something badly just to get over the line to not be deregulated. And then one, you’ve created a poor user experience, exposed yourself to more risk, and then you’re spending more money to actually go back and fix the problem rather than just addressing it ahead of time now.
The other one I’ll talk about is employee retention. I mean, especially when you’re talking about manual processes, manual data entry, data flow, and just other general workflow tools that can help you be more efficient with your business, no colleague wants to do manual entry, especially not your high-paid colleagues that are … I hate to say “over it.” I don’t know if that’s the right way to say it. But they’re experts with 20, 30 years’ of experience in whatever segment they’re an expert in. It’s not a great use of their time or whatever it is hourly rate that we’re paying them to actually be doing this kind of work. They should be focused on the true add value work that can help them.
And then lastly, outside of retention, I’ll say this is a really big one that I’ve noticed in the past, is key colleague dependency when knowledge … I think about this one as someone who used to sit in the actual business space and was one of these people who are considered the subject matter experts … is a lot of times these processes that you’re responsible for doing for the business, it’s generally all managed in your head combined with a very loose … I’ll call it a procedure manual or workflow tool or guide on how to do this. When those people continue to grow, whether they move onto a new firm or retire, get moved over to a new team, once those people go, they’re trying to do a knowledge dump of everything that they know to whoever’s taking over, or the team. It’s generally not going to be as effective as it could be. And you’re losing someone with probably years of experience and expertise of seeing every single scenario under the sun around what can happen within this workflow or this technology.
By migrating those over into a product and digitizing your workflow, your tools and your platform, the system’s actually able to manage and control that flow you. Now, that’s not to say that you won’t need the experts and the business doesn’t need to know how things work under the hood and the rules that they should be following, but the system will essentially be enforcing the business rules, the guidelines, telling people what the next steps that they should be taking in order to do whatever the workflow is. It’s all going to be more managed by the system rather than being reliant on the user, which gives the users, the subject matter experts, more time, more efficiency to be able to actually complete their work, and less asking people questions on, “How do I do X, how do I do Y? I have a weird scenario, how do I do this,” kind of thing.
Kali Jakobi:
Right. Less getting all bogged down in the cogs of things and more able to drive the business forward as a whole.
John Coleman:
Yeah, exactly. So I think those are, I guess at a high level, the four things that I really think you should be looking at technology for, because it will drive change and it will create a better outcome for your business. So that’s return on investment, looking at potentially deregulating yourself, employee retention, making sure you’re keeping your employees happy with workflows that they enjoy and aren’t cumbersome to them. And then lastly, you’re eliminating this key man dependency work silos that people often find themselves in and reducing just your overall firm’s risk exposure to that space.
Kali Jakobi:
Awesome. So for my final question, John, we’ve talked a lot about the ups and downs of data implementation, of technology throughout the space, risks associated. Let’s end on a high note. What does it look like to have a successful implementation of new technology? We know that it takes a long time, we know that there’s a buy-in and how to get there, but what does that actually look like, and some key elements to ensure that success?
John Coleman:
Yeah, that’s another great question. I think to me, it’s almost like a two-part question. How do you ensure the success? And then also, how do you measure the success and really translate it into a return on an investment? As you just mentioned, there’s a million moving parts. But I’ll go back briefly to, one, proper product implementation, project planning, however you want to call it, whatever’s the way that your firm says it. But just making sure you have the right requirements up front. You have the right experts in the room, the right stakeholders involved, engaged, bought in. And everyone knows what our goal is from A to B and what we’re trying to accomplish, especially with MVP, iteration one, iteration two, and so on. I think that’s going to be your first step to success, just making sure that everyone is on that same page.
But next, it’s actually going to be working with your stakeholders throughout the process. I think it’s really important to continue and repeatedly demo your products to your stakeholders, to your business users, to your user base, and ask for their opinion of it, make sure it’s working as they intended. And the more often you do this, the better, because the moment that you take a step in the wrong direction, it’s easier to take that one step back to go back into the right direction, versus if you take three steps forward and realize that you made a incorrect step four or five steps to go, you’re probably going to have to debuild all the way back there and then rebuild from there, which is time and cost all associated with that.
So I do think demoing repeatedly and often is really important, and then as well as I’ll say testing. Not only should you be having your standard QA and UAT testers from folks on the technology side, but you really want to have your business subject matter experts go in here, test this information, test with some of what you think is your most complicated scenarios that you’ll be expecting to go through this product or this workflow, whatever it may be, and ultimately have them do it, make sure from their perspective it’s working.
I think ultimately, our side of the technology, we can only be experts to the point that we know the process. We are typically just slurring the process as part of the implementation plan, and any formal expertise that we might have from our historic career backgrounds. But the current experts on what needs to be done is going to be the subject matter experts sitting in the business space. So having them test is going to be really key to actually having a successful product and knowing that when you go to production, that this will create add value and benefits for the user base that this has rolled it out to.
And then lastly, I’ll just talk about, I guess this is around the measurement, is … and you can do this early on as well, defining success and maybe setting some key performance indicators on how you would set success or measure success. But doing it throughout the process to make sure you’re tracking and working towards that goal is really good. But then at the end also, once you’ve rolled something out, especially after you’re MVP and you’re heading into iteration one and iteration two is thinking about the feedback that you’ve taken from that or the results of your MVP and quantifying it. So let’s say you’ve got hours saved. How do we quantify that into a return on investment based upon the average user base’s dollar cost value for work? Or if we’re talking about reducing risk, what’s the amount of risk that we reduce?
That one’s a little more harder to quantify in a dollar figure, but if we’re able to quantify some type of risk reduction, that’s really great, as well as thinking through rejection rates … or if you’re doing something with your workflow processes that are more things that are implemented by business rules, rejection rates where people are having to send things back and forth to get things corrected, being able to measure how little you’re having to do that now as a result, as well as what additional things you could do to make that value better in iteration one, in iteration two, is going to be key to actually measuring your success. And that’s going to be really important when it comes time to take a look back at your project and be able to say, “Here’s what we accomplished, and then here’s the plan going forward. And this is how I know that we’re still on the right direction going forward.”
Kali Jakobi:
Amazing. Well, for those loyal listeners of Data Disruption, you know that our final question is never about data. It is what I affectionately call a personality question. So John, your personality question for today is if you could have dinner with anyone famous tonight, dead or alive, who would it be?
John Coleman:
It’s definitely a tough one. I’ll be try to be a little more creative with my answers. I feel like the common answer here is probably going to be a relative that has gone away, unfortunately, which definitely is going to be number ones in the books. But being more creative and fun for the end of the podcast to keep things exciting, I think I’m going to have to go with Michael Jordan. I mean, one, I’m a big sneakerhead, so I collect Jordans, Dunks, all those kinds of things. And then two, I’m a very avid basketball fan and player. So to be able to have dinner with who I consider to be the GOAT is going to be a great experience for me. I’m sure there’s probably some more time. There’s probably some dead people that I should really be thinking about putting on my list, but let’s go with Michael Jordan for this question.
Kali Jakobi:
It’s hard to really think through all the people on the spot. And for those listening, you can’t see, but John has an incredible sneaker collection as his background, which I just think is great. Always adds some personality to your work-from-home calls. I would have to say my answer would be … This is a big recency for me. I recently have discovered how funny John Oliver is. I don’t know if that’s something that people are wildly familiar with, but my fiance has actually gotten me onto a little wormhole of his YouTube videos. And I just think he’s hilarious. So I would love to have dinner with him or someone of the comedic field.
So that’s all we have today for our Data Disruption episode. Thank you all for joining. If you want to talk more about all of the technology implementation that we just talked about, I mean, John obviously is a great resource to chat through these things with. You can reach out to both of us on LinkedIn. And John, thanks for coming on the show.
John Coleman:
Thank you, Kali, for having me. It was great to be here. Had a ton of fun, and super excited to share any information that may be helpful to anyone.
Kali Jakobi:
Awesome. Till next time.
Thanks for listening to this episode of Data Disruption, by Charles River. If you like what you heard, share and leave us a review. It helps others discover the show, and I thank you for it. And if you’d like additional insights related to this conversation or others, go to our website at www.crd.com. Till next time.
Information Classification: General
5271691.1.1GBL
The material discussed is for informational purposes only. The views expressed in this material are the views of the author and are subject to change based on market and other conditions and factors, moreover, they do not necessarily represent the official views of Mercatus and/or State Street Corporation and its affiliates.