
Change Management Strategies for Data & Analytics Transformations
Summary
Transcript
Large enterprises will always have some internal groups that are more change-averse than others. But progress often necessitates change, and how well you navigate the change management process can make or break your success as a leader.
Michal Levitzky is the Head of Data & Analytics (CDO) at Migdal Group, a leading insurance and finance company in Israel. Michal has spearheaded the introduction of data and analytics functions at multiple organizations, and she knows a thing or two about negotiating the complexities of change management during analytics transformations.
In this episode, Michal shares her advice for AI leaders driving meaningful change at their own companies. Plus she details her philosophy on structuring data and analytics teams for maximum efficiency and collaboration.
We discuss:
DAVE COLE
Hello, welcome to another episode of the Data Science Leaders podcast. I'm your host, Dave Cole. Today's guest is Michal Levitzky. Michal, how are you doing today?
MICHAL LEVITZKY
I'm great, thank you. Thanks for having me here.
DAVE COLE
Awesome. So, for those of you listening today, Michal is the Head of Data & Analytics (CDO) at the Migdal Group. She has over 20 years of experience in finance and insurance, the past seven of those being in insurance.
We have three topics today. The first topic: Michal did not start in the world of data science, but does that matter? She’s a data science leader today.
The second topic: data science change management. Michal has worked in very large companies which have been around for many years. She has been a bit of a change agent, introducing data and analytics into these teams in a meaningful way.
Last but not least, we're going to talk a little bit about BI in data science. I think there's a good conversation to be had. Should BI and data science teams be under one roof? Should they be separate teams? How do they collaborate? How do they work together?
Let's go ahead and start at the top here. Let's talk about your background, Michal, how you started as an accountant and got your CPA. Then somehow, you went from there to becoming a quant. Can we talk about how that happened?
MICHAL LEVITZKY
Sure, I got my CPA in Israel. You need to go through two years of internship to get your CPA certificate. I worked in the finance group of a large VC fund in Israel, a very complex group, reporting to a Singaporean company. I found myself on a quarterly process of creating financial reports. In 2006 we moved to the US. I got my MBA. My goal was to never again look at financial statements, and I actually meant that.
DAVE COLE
Why is that?
MICHAL LEVITZKY
I had already met that goal by then. I got my MBA with a finance focus. I knew I wanted to do something in the capital market but I didn't know exactly what that was. Then I got to interview with Wellington Management, one of the largest global asset management companies worldwide. There was a small group that was just forming. It was around 2006, the asset location team. Like I said, I didn't want to look at the financial statements. I wasn't looking for a typical analyst role. The asset allocation team looks at the top down on indices and governments and more economics in the different asset classes.
DAVE COLE
Micro trends.
MICHAL LEVITZKY
Yes, and they create models. That's where I was introduced to the quant world. I had a great manager and went through very robust statistics processes. I got my CFA, which is very heavy in statistics, and that's how I made that unique jump. It's less unique today, though. I hear about a lot of accountants that are looking to move towards data and the data science world today.
DAVE COLE
How do you go from looking at financial statements, having that accounting background, to learning the stats to be able to get your CFA? Did you take classes? Did you learn on your own? Did you learn on the job?
MICHAL LEVITZKY
I think the MBA is the one program that helped me go through that. When I finished my CPA exams, I said, "Never again am I going to take such huge exams." In my mind that was anything that required more than two or three weeks of studies. Then there I was: wanting to go into the capital market in the US.
Slowly and sincerely I realized the value of the CFA. It consisted of three huge exams in over three years. You went through a mix of deep and broad topics on financial markets, many of which were statistics. That's kind of what got me into the theory, but then you also need someone to hold your hand as you apply what you have actually studied. How do you implement it in an actual world, with actual model-building, looking at QA of a model building, time series models, etc.?. I think many of today’s young data scientists need support in understanding how to progress from very clean datasets, that they study in different Python classes, into the real world. In reality the data is messy. Some will be missing. It's not normalized.
DAVE COLE
Right. So, yes, the real world for a data scientist is not like what you learn in class. So, you got an opportunity at Wellington. It sounds like you had a strong mentor, a boss who helped you make that transition from your traditional financial background. The CFA was a forcing function for you to learn statistics as well. Then you started heading down that path of really becoming a data science leader. I’m guessing it was then that maybe there was a subtle transition from being a quant, right, to moving more firmly into the world of data and analytics. What made you realize that this path was for you, and that you really wanted to stay on the data science side?
MICHAL LEVITZKY
After a couple of years of building and refining models, looking at different asset classes, I also did some risk management on the capital market within the asset allocation team. It’s more technical work, to the point that, after eight years, I was ready to admit to myself that, more than the capital market, I was really in love with the data itself. I asked myself, "Okay, so what do I do with that?" At that point, I wanted to do something which is more pure data analytics. I didn’t just want to look at building and refining models. Back then, around 2013, 2014, data science used to be split into statistics, data mining, and then data science.
I combined the quant work with the statistics. My CFA brought everything together for me when I joined John Hancock, the US arm of Manulife, a global financial services company. I was involved mainly in insurance to build, from scratch, a data analytic function for one of their risk groups. Their risk and audit project did not get to the point that they really utilized looking at and screening the data, getting information in a robust way wherever there was a business process built upon data. The challenge was that, again, this was 2014. I found myself going through that same pattern I had throughout my career. I was forming a different way to think about things. The industry just realized that maybe data analytics teams are required in these risk and audit groups as well.
How does it look? How do we formulate? What is the strategy? What is the roadmap? How do we change processes? How do we work with the internal team of the group, with the external clients or even internal clients within the company? How do we get the data? What infrastructure do we use? Do we get the data on our infrastructure or work on the client application? But then, nobody knew how to connect everything. It was like building a small new company within that small group, which is not actually that small. At the time, we supported about 250 people globally, so we had a global team. Part of the conversation or the consideration was about where and how we would build that team. How do we support the different groups in Boston, Canada, and in 11 other countries in Asia? In each location, we hired people to support the local team, but how do you create a team environment where we can speak the language, support and learn from each other and use each other's learning curves within the team?
It needed a lot of strategy and change management because it could have thrown people off. We introduced something totally new to the group and to Manulife, to the point that sometimes I was even working with the actuarial team to set up cloud infrastructure for the group. He told me that it was his first time executing the process and it hit me: time and time again. Manulife was going through that whole data analytics transformation. I was part of the leadership group of the whole organization so, for me, it was a huge benefit. I felt like I got the best seat on a huge flight, getting an enterprise like Manulife to shift towards data analytics. It was fascinating.
DAVE COLE
I want to talk about that next. To cap off your background: it's a fascinating story, how you went from the world of accounting all the way to the world of data science. Now you're firmly in the world of data science and I don’t think you're alone. There are many other data scientists and data science leaders who have followed a similar path. I assume that if I were to look at your team, it's not just going to all be people who started as statisticians. You had a strong mentor. Am I correct in assuming that you also hire people with varied backgrounds, who potentially are trying to make a change? I assume that they maybe have a strong staff background, but are just getting introduced to working in data, becoming data scientists. Is that fair to say?
MICHAL LEVITZKY
Absolutely, yes, and I think that's the beauty of it. At John Hancock, the group team members were people who came from IT, computer science, ex-Deloitte consultants who worked on data groups. It was great that an actuary could build a career in data science. When I left, we were really formalizing a rotation program within Manulife. Actuaries, data analysts, and advanced analytics folks could rotate within the group, because a lot of knowledge is captured within this group that works across different units, and you're not just focusing on one specific unit.
I like that about working in groups like that: you look at different units across functions and borders to really understand the context every time you need to adjust to a new project, team, dataset, process, etc. You accumulate a lot of knowledge like that. That was the kind of diverse team that I managed, who came from different career paths and countries. We were very international. That was great.
DAVE COLE
That's awesome. We have been talking about the next topic already, which is change management within the world of data science.
You mentioned your experience at John Hancock. My understanding is that at the Migdal Group, it's somewhat similar. You’re sort of spearheading things, introducing the world of data analytics to a company that maybe traditionally hasn't relied on models or data to make their decisions. What sort of advice would you have for a data science leader who faces that same predicament? They’re trying to build out a team and get buy-in from the business, to actually effect change about how decisions are made.
MICHAL LEVITZKY
I'm smiling because there are so many challenges for getting into the role. In change management, I used to refer to that triangle that people use. I myself use it to present the combination of the people, tools, and skills to build a function. I have always said that there is something missing within that triangle, which is obviously the change management process.
First of all, it's hard. It's hard and it's really different from place to place. One piece of advice that I can share about all of the places is to first acknowledge that this is a change management process. There are places and groups that can help you with that. Acknowledge that you're going to disturb whatever people used to do up until that point, and learn how to do it differently, share information differently, look at things differently, use data differently. In some areas, they’ve not had any processes before, so you need to help them understand how to apply it from scratch. In other areas, like where it’s obvious that, say, we’re an insurance company and we work with data, it may not be clear to everybody where that happens, or how. Maybe we're not using it the right way: clean and efficient. Maybe you can do more of that. Maybe it can help you. There is a really wide range of changing people's mindset and approach to what you're trying to do.
DAVE COLE
“It's hard,” is the headline for sure.
MICHAL LEVITZKY
The second piece of advice I have is to acknowledge it yourself and communicate to the top management then the rest of the company that it's not only about resources, hiring, and tools. It’s going to take time and support and people don't like change.
DAVE COLE
It’s disruptive.
MICHAL LEVITZKY
Yeah.
DAVE COLE
One technique that I've seen companies use is do this under the banner of digital transformation. Right? I've always wondered, "Well, what on earth does that mean?" I think it's a way for everyone to acknowledge that we are transforming. We are going to change the way in which we operate. We're going to use data and technology to fundamentally change how we make decisions. I think it can be helpful to plant the seed by saying, "Hey, we're doing something really hard. Everyone’s jobs are going to change a little bit, potentially. Your day-to-day jobs are going to change. Some of you will transition into completely new roles through this process and we’re going to support everyone through this.”
Did you do something similar? It sounds like that. How did you get management to acknowledge this big change?
MICHAL LEVITZKY
You mentioned a point that people make that connection between data and digital. I think the digital change is perhaps an easier one because people see the results. You understand you need to clean the data, organize it and bring some data governance in. You need to map the data and stick to the same language of the data. These are protocols and changes that have a less direct effect on the risk outcome. Suddenly there are new processes that we can use digitally or there’s a new application. Sometimes it is easier to present the end result. In data when you get into data governance for a project, suddenly you need to distill exactly who that client is and how to define that.
You also no longer just rely on one single person who defined it five years ago. You spend weeks researching between actuaries, IT, data analysts, the business, etc. and then you realize that maybe they forgot some of the data along the way. Then you need to have a difficult conversation because you might be presenting data which contradicts whatever was presented up until that point and you need to defend it. That's why I find the change to be sudden and more in people's faces. They’re likely to retort, “What do you mean? That's what we've been doing forever.”
DAVE COLE
I'm hearing you say you sort of start with the data in change management. You work toward getting people to acknowledge that maybe, historically, teams were using different datasets and there needs to be some form of standardization. The result of that could have been that people fundamentally misunderstood data,historically; how well or how poorly teams were doing because the data was maybe not organized correctly, for example having duplicate customer records or what have you. If you start with cleaning up the data, you can begin building trust. Right? You get everyone on the same page, understanding the data in the same way. Then you can start to build on the analytics and then build out models. Does that sound about right?
MICHAL LEVITZKY
So, that's one way, yeah.
DAVE COLE
All right. Okay.
MICHAL LEVITZKY
So that's one way you can really show the robustness of the process that took much longer than the business thought it should take, because they're used to something else. You start building trust with them. Another experience I had is when we worked in an internal group, working on an internal client's data. There was resistance at some point, the head of the risk group said, “Listen, that's the way we’ve got to do it. You can like it or not but that's the right way to do it and we expect you to align your practices with our new requirements.” You need really strong people and strong management support for that. That's another way I've seen it happen.
The third piece of advice that I'll give people on change management: don't jump into it as if you’re suddenly going to shuffle everything. Take months to learn, study the dynamics, the people, the resistance. Many times I have found that management are really happy with the data analytics and changes, analysis, and models. It gets stuck somewhere at the level of maybe directors or just below. The person that needs to start doing something differently than what they have been doing up until now is where your big challenge is.
DAVE COLE
That's a really interesting observation that sometimes management can be more accepting of the change and they’re sort of ready for it. It’s probably because they've been involved in the decision-making process. They know why you're there. They realize that you're there to effect change and they're looking forward to it. The people who actually have to change, if their jobs are fundamentally changing, the data they're working with, maybe there's a new skill they have to learn—that's where there could be some friction.
MICHAL LEVITZKY
Yeah, and sometimes they really know the data.
DAVE COLE
Yeah, yeah.
MICHAL LEVITZKY
Sometimes it's maybe much more complicated than what management actually realizes. That's another gap.
DAVE COLE
So I imagine that when you're going through this process, getting buy-in at all levels is obviously very important. The takeaway for me is to not forget the people who are actually going to be the ones whose jobs are fundamentally potentially changing. Work with them to get them bought in on the process; finding a champion there can be really helpful.
MICHAL LEVITZKY
It doesn't have to be a sense of huge change. I don't even think about people who lose their job or anything. It's just a matter of understanding that we've been sending that report that way forever. For me to start sending it or doing the change in a different way, change the methodology or even touch the reports on legacy systems, etc.
The one sentence that I keep hearing, which is amazing, is, "What do you mean? That's how we do it." Our response: "Okay, well, maybe we need to start doing it differently."
DAVE COLE
“That's the way we've always done it,” is usually not an acceptable reason for continuing the way that you do things.
MICHAL LEVITZKY
Maybe because of that, we need to change it.
DAVE COLE
Exactly. So let's switch gears a little bit here and dive into our last topic: the world of business intelligence, sometimes called analytics. In the world of data science, I think that there are schools of thought where both of those teams potentially fall under one umbrella with one leader. In other cases, I've seen them be completely separate teams. What is your opinion on how these teams should be organized, and then maybe how they should work together?
MICHAL LEVITZKY
That's a great point. I think it's important to define when we say BI, what exactly we mean by that.
DAVE COLE
Absolutely.
MICHAL LEVITZKY
I'm on the business side, so when I talk about BI I'm talking more about descriptive analysis and sometimes building the dashboard to visualize it, or to share with the client and make it interactive. I think the engineering side could more naturally live with IT. I've seen places where it makes sense to have them within the business. I haven't personally reached that point, to be honest, but I do at least have data engineering support on the data science side.
At the end of the day, both analysts and data scientists use a lot of their time to do exactly that: data engineering. For that reason, you want an expert on that. It creates some clashes with IT sometimes because it's kind of a pure IT function that sits within a business function, but we'll leave that for another discussion.
I've been in a place where I've seen groups that said, "You know what, we only do data science. We just do the model. The big things. The AI. The next phase of the business, insurance, and we don't do BI." I’ve thought about there being a miss there because both sides are often dealing with understanding the data. Where is the data? Cleaning the data. What is the data? Data dictionary. Data governance, right?
DAVE COLE
Yes, understanding the data model, data cleanliness, governance, etc.
MICHAL LEVITZKY
Creating some datasets and so on.
DAVE COLE
Yep.
MICHAL LEVITZKY
So, for me, it makes more sense to have them sit together and collaborate 100%.
Today at Migdal I have those two building blocks under me. One side is data science. The other side is the business analytics and BI. There is a BI group on the IT side that does more of the data management. They build management dashboards. Wherever you need a broad management dashboard that runs every day that management and the C-Suite open in the morning, use for reporting on previous-day information, I think it really belongs there. The process needs to be robust and organized and built with the right UX and UI, etc. when it comes to analysis and analytics, looking at the data.
Throughout that line from descriptive to up to the point of even predictive, I definitely see the benefit of having that group within a centralized center for excellence, working with the data scientists. In our case, data scientists worked on a broad panel for a client segmentation project. The next day one of the analysts will have a project on clients and will be able to speak to the next guy in the next table, about where to take the data, what it means, how they created it, etc. One analyst created a dataset for another project, so that when data scientists started working on churn models, they had a discussion with them. There was a mutual conversation and the value for the business grew.
You create higher value when you have that conversation under one umbrella, as opposed to another group, which just does models and then gets stuck when they need to work with data and figure things out. All of that also depends on the data architecture, of course. I think that the business analytics and the BI then has more pros than cons to sit together with the data scientist.
DAVE COLE
I totally agree. I think you make a number of good points. The common thread between the two teams is a really deep understanding of the underlying data; how the BI teams can potentially create customer segments and actual datasets that the data science team can leverage. It also goes the other way. I can imagine a dashboard of historical trends, which also predicts and forecasts the next two quarters, that leverages a model that the data science team has put together for that forecasting model. There are some synergies there.
Another thing that I've seen, and I don't know if you agree with this, is that some data science teams can struggle when it comes to actually telling stories about the data. I don’t mean that in a negative way. If you build a model, try to explain which features influence the dependent variable within the model, like explaining how the business can potentially learn something from the model itself. Some data scientists might not be the best at doing that and telling that story, translating that into something that the business can understand. I think that your analytics or BI team can be helpful in that storytelling process. I don't know if you've seen the same thing, but I certainly have.
MICHAL LEVITZKY
Yes, absolutely, not only telling the story, but also their discussion with the business with the different systems and implementation. Right? It really depends on the group. I was fortunate to bring into the group, someone who has been in the company for many years. Before she moved to manage the analytics NBI team, she came from the marketing side. She really helped to facilitate all the business discussions. In terms of telling a story from the models, it really depends who the audience is because sometimes I find that they are senior VPs who love to go into the details, but maybe this is just the nature of people working in insurance. They love to understand the many nuances of how the models are created. Sometimes we'll even have a good conversation and add a lot of value to how they define the model or the population.
But it's hard. That's why I think you need someone to manage those two functions to help identify and define that gap, so when that data scientist or head of data presents to the CEO or other people of the management, you can go into that level of detail. That's not what matters to them. I usually joke with my head of data science to leave the polygraph aside; you won't be tested for telling the truth or not, like if you didn't add that apostrophe about the disclaimer that you used about which model does what.
DAVE COLE
Yeah. You don't need to go into such detail that you feel like you're sort of lying by omission. Just because you left something out for brevity's sake, that's okay. You don't need to have a super detailed slide with all of your assumptions and all the caveats, and everything else.
MICHAL LEVITZKY
Yeah.
DAVE COLE
That's definitely good advice.
MICHAL LEVITZKY
Yeah, and it goes the other way as well. Explaining the business, having the business understand models with all the hype around it, is not an easy task at all. First of all, it's not magic. Prediction has errors, so why should I use a model that will produce errors to start with? Then, for example, many financial people use simple regression models. They understand. They know it very well but then, when you move to explaining the decision tree, for example, you need to have a conversation about a set of parameters with coefficients.
You need to discuss how to see who is the bigger contributor to the model. Sometimes you can have that conversation with someone who is a little bit more, not necessarily technical, but went through some statistics and can understand it. Sometimes it's way over people's heads to try to understand. That's another thing for data scientists, to be able to explain what models do in a business manner. I usually tell my folks, "Okay. Now tell me that in business words. I don't want to hear any statistical language in your explanation. Try to say a sentence without the statistics." It's hard. It's really hard for them. You can see it in many data scientists.
DAVE COLE
We talk about that a lot in the Data Science Leaders podcast. I think the role of a data science leader at times can be just that translator. Be someone who can explain the models in a way that the business understands and gets on board with. That makes a lot of sense. I'm with you. I think having the analytics team and the data science team all under one umbrella makes a ton of sense to me.
We went into a lot of great topics today, hearing a lot about your background, how you've effected change in a number of companies and introduced data science and ideas on how to do that the right way. Also, you were explaining that it's just hard to do. We also talked about BI and analytics, where it should sit in an organization and how that team can potentially be additive to your data science team, help them out and vice versa.
I really enjoyed the conversation. If people want to get in touch with you. Can they reach out to you on LinkedIn?
MICHAL LEVITZKY
Oh yes, absolutely.
DAVE COLE
Great. Well, I really appreciate you taking the time. Enjoy the rest of your week.
MICHAL LEVITZKY
Thank you, thanks for having me.
New episodes
What It Takes to Productize Next-Gen AI on a Global Scale
Help Me Help You: Forging Productive Partnerships with Business...
A Hybrid Approach to Accelerating the Model Lifecycle
Listen how you want
Use another app? Just search for Data Science Leaders to subscribe.About the show
Data Science Leaders is a podcast for data science teams that are pushing the limits of what machine learning models can do at the world’s most impactful companies.
In each episode, host Dave Cole interviews a leader in data science. We’ll discuss how to build and enable data science teams, create scalable processes, collaborate cross-functionality, communicate with business stakeholders, and more.
Our conversations will be full of real stories, breakthrough strategies, and critical insights—all data points to build your own model for enterprise data science success.