Today I’m chatting with Iván Herrero Bartolomé, Chief Data Officer at Grupo Intercorp. Iván describes how he was prompted to write his new article in CDO Magazine, “CDOs, Let’s Get Out of Our Comfort Zone” as he recognized the importance of driving cultural change within organizations in order to optimize the use of data. Listen in to find out how Iván is leveraging the role of the analytics translator to drive this cultural shift, as well as the challenges and benefits he sees data leaders encounter as they move from tactical to strategic objectives. Iván also reveals the number one piece of advice he’d give CDOs who are struggling with adoption. 

Highlights / Skip to:

• Iván explains what prompted him to write his new article, “CDOs, Let’s Get Out of Our Comfort Zone” (01:08)
• What Iván feels is necessary for data leaders to close the gap between data and the rest of the business and why (03:44)
• Iván dives into who he feels really owns delivery of value when taking on new data science and analytics projects (09:50)
• How Iván’s team went from managing technical projects that often didn’t make it to production to working on strategic projects that almost always make it to production (13:06)
• The framework Iván has developed to upskill technical and business roles to be effective data / analytics translators (16:32)
• The challenge Iván sees data leaders face as they move from setting and measuring tactical goals to moving towards strategic goals and initiatives (24:12)
• Iván explains how the C-Suite’s attitude impacts the cross-functional role of data & analytics leadership (28:55)
• The number one piece of advice Iván would give new CDO’s struggling with low adoption of their data products and solutions (31:45)

Quotes from Today’s Episode

• “We’re going to do all our best to ensure that [...] everything that is expected from us is done in the best possible way. But that’s not going to be enough. We need a sponsorship and we need someone accountable for the project and someone who will be pushing and enabling the use of the solution once we are gone. Because we cannot stay forever in every company.” – Iván Herrero Bartolomé (10:52)

• “We are trying to upskill people from the business to become data translators, but that’s going to take time. Especially what we try to do is to take product owners and give them a high-level immersion on the state-of-the-art and the possibilities that data analytics bring to the table. But as we can’t rely on our companies having this kind of talent and these data translators, they are one of the profiles that we bring in for every project that we work on.” – Iván Herrero Bartolomé (13:51)
  
• “There’s a lot to do, not just between data and analytics and the other areas of the company, but aligning the incentives of all the organization towards the same goals in a way that there’s no friction between the goals of the different areas, the people, [...]  and the final goals of the organization. – Iván Herrero Bartolomé (23:13)
• “Deciding which goals are you going to be co-responsible for, I think that is a sophisticated process that it’s not mastered by many companies nowadays. That probably is one of the main blockers keeping data analytics areas working far from their business counterparts” – Iván Herrero Bartolomé (26:05)
  
• “When the C-suite looks at data and analytics, if they think these are just technical skills, then the data analytics team are just going to behave as technical people. And many, many data analytics teams are set up as part of the IT organization. So, I think it all begins somehow with how the C-suite of our companies look at us.” – Iván Herrero Bartolomé (28:55)
• “For me, [digital] means much more than the technical development of solutions; it should also be part of the transformation of the company, both in how companies develop relationships with their customers, but also inside how every process in the companies becomes more nimble and can react faster to the changes in the market.” – Iván Herrero Bartolomé (30:49)
• “When you feel that everyone else not doing what you think they should be doing, think twice about whether it is they who are not doing what they should be doing or if it’s something that you are not doing properly.” – Iván Herrero Bartolomé (31:45)

Links

• “CDOs, Let’s Get Out of Our Comfort Zone”: https://www.cdomagazine.tech/cdo_magazine/topics/opinion/cdos-lets-get-out-of-our-comfort-zone/article_dce87fce-2479-11ed-a0f4-03b95765b4dc.html
• LinkedIn: https://www.linkedin.com/in/ivan-herrero-bartolome/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Iván Herrero Bartolomé, who is the Chief Data Officer of Grupo Intercorp out of Peru, correct?

Iván: Yeah, that’s right. I’m now living in Lima in Peru. But I’m actually from Spain, although I’ve been living here in Latin America for the last ten years. So, it’s quite a journey now. [laugh].

Brian: Excellent. I love it down there. It’s been too long. So. But we’re not talking about travel today. We’re going to—[laugh], we’re talking about—

Iván: [laugh].

Brian: This article you wrote, or at least that’s the jumping-off point. So, you wrote an article for a CDO magazine called “CDOs, Let’s Get Out of Our Comfort Zone”, and you made some salient points in there and some things that I talk about a lot on the show so I kind of wanted to dig into that a little bit.

And one of the key things that I got out of this article that I read was how data science leaders, and even CDOs, there tends to be too much focus solely on hard technical skills. And my understanding is you feel like they’re missing other skills required to actually get value out of the data products we build for users and stakeholders. If that’s correct; if it’s not, please correct me. But if it is correct, what prompted you to write this article and why now?

Iván: In fact, it’s something that I’ve been wanting to write about for quite a long time now. But I just felt it was a right moment because three years ago, the data community wasn’t talking much about the importance of driving cultural change and changing behaviors in our business counterparts to ensure that we can optimize the use of data—or the impact by using data in our organizations. And I think that as a community have been trying to make the most of our analytics developments. I think that it’s been increasingly important to understand that we are not going to be successful just by applying—no matter how sophisticated—technical skills on top of the data. If we are not transforming our organizations, we will not behaving ourselves as change agents. I think that the impact that we can drive is very limited. And I was wondering if that could be the reason why so many companies that had invested in data and analytics within the last five or four years, are now wondering why they’re not seeing the impact on the results that were expected.

Brian: When you talk about these other skills that are needed, is there a particular description of what those are? Are you upskilling your team or hiring differently because you recognize the gap there and you’re seeing that play out in other places? Or can you talk to me about what are these other things that teams need to be able to do?

Iván: As data leaders, we are responsible to close the gap between the business and the analytics areas. And for doing so, we have to instill data fluency in the business area of our organizations, but we must also instill some business knowledge in our teams. In fact, more than knowledge. I think one of the key goals that we should be pursuing is how we can make our companies to see the data and analytics capabilities not as just another technical team and a call center, but like a business counterpart and a way to maximize the value. But that begins with a technical team, with us as data analytics leaders, understanding that we cannot survive just only being technical team.

And there has two dimensions, in my opinion. First of all, we need to convince ourselves and our teams that we are here to drive value for the business. This is not a hobby, this is not something that it’s important for our companies because it’s what they have to do, it’s what the market is doing; we actually exist to bring value for the business. That’s one of the dimensions that we have to clearly understand that and start behavioring more as any other business area does. That is, like, the mindset dimension.

And the other dimension is like the physical dimension. We have to bring people with other skills to the team, we have to bring data analytics [slash leaders 00:05:38], people who can have an end-to-end vision of the data products that we build, ensuring that everything that our teams do is properly connected to business goals, and the development keeps being aligned to those goals all the way down. Because these are not projects that we can just accomplish in a couple of weeks, as I hear sometimes. These are normally four to six months long project, and this will be managed in a very agile way, so they could very easily be changing from one sprint to another, and it’s easy for teams to lose their focus on why they’re doing what they’re doing. It’s very important to have someone accountable of the solution being actually connected to the business goals that were [unintelligible 00:06:45] at the beginning of the project.

And not only that but keeping a fluent conversation permanently with business areas that are going to use a solution and paving the way for its adoption. I also hear from some data leaders than if we do the best solutions in the market, they will come and they will use it. I don’t really think that’s going to happen overnight. I think we have to apply some change management toolkits along the way to bring the users closer to the development phase. They can feel that they are part of it and it’s something that they’re building for their own, and it’s not something that someone just came up with and put it just in front of them, to—just for them to use it. I think there’s a lot of things that we have to do on top of the actual delivery of the product.

Brian: The framing I like the best that I’ve heard in the design community is something that we talk coming at it from that perspective is designing with customers and not designing for customers. And it’s this idea that they’re involved along the way and there’s not a giant reveal at the end of the project. It’s not like in four months, you finally get to see something and then everybody starts to—now we know what the criteria for success is and—

Iván: [laugh]. Yeah.

Brian: —we usually find out it’s wrong [laugh] because, “Oh, I didn’t know that’s what you were doing.” [laugh]. So, you try to involve them early so that there’s no surprises by the time you get to the end. There’s just like, “Great. It’s in production. It’s real now. We can touch it and use it, you know, get the value out of it.” That kind of thing.

The framing that I’ve been trying to evangelize is really taking the skills of product management—or specifically data product management—and design because design talks about the human experience, the user experience piece, which is a requisite to getting to business value. Because if they’re not willing to use it, you’re definitely not going to get any business value. And then product management has this job to make sure there’s actually some business value that comes out of it. So, I’m curious, what are the titles of the people, or the skills in your team that own the downstream value part, the outcome, and not just the technology outputs that need to be made? Because there’s always plenty of plumbing and modeling and interfaces and all engineering; it’s very easy to get stuck, just thinking every two weeks, we’re going to ship out some more stuff.

That becomes the focus of a lot of teams is just feature factories and output generation; we got to show that we did some work and here it is, and we shipped it out. But this outcome thing is vague at best and it’s not clear who owns it. So, who does own it? Like, especially if you’re building this thing for a business stakeholder, but maybe you see it as a platform or it’s like, it’s a personalization data product, but it fits into all these business solutions, so who really owns the delivery of the value? How do you frame that?

Iván: It’s even harder for us because we are at the corporate level in the [holding 00:09:55], so we’re not inside the operation. We’re not part of the business unit, so that makes it even harder to properly set up the team and everyone involved around the project to ensure that there is a strong alignment about what is expected and how to achieve it. But the first thing that we like to do is to, when we talk to the people that are going to be part of the project, especially from the business areas, is stating very clearly that this is not our project. This is their project and if they’re not willing to do it, okay, we can think of any other thing, but this is not a data officer’s project; is it the company’s project? And if the project succeeds, okay, it’s on them, but if the project fails, it is also on them.

We’re going to do all our best to ensure that the technical part—not just the technical part, but everything that is expected from us is done in the best possible way. But that’s not going to be enough. We need a sponsorship and we need someone accountable for the project and someone who will be pushing and enabling the use of the solution once we are gone. Because we cannot stay forever in every company. In Intercorp, we have more than thirty companies, so it is not possible for us to stay very long for each product.

So, we have to ensure that our counterparts have the capability to adopt the use of the solution and how to maintain the solution. So, they’re responsible of every single piece of the solution once that—okay the goals are achieved, at least at the MVP level. From that point on, they can keep on evolving their solution and bringing more value for the business. But I think that one of the first key points that we’ve learned so far—and we rely very strongly in this, what we call data translators. And we have different flavors of data translators, and these are people with backgrounds in business, in design, in innovation, and product management.

And of course, it is almost impossible to find someone who can bring expertise in all those fields at the same time to the table, but we try to bring people from different perspectives, helping them sit together around the same table and share their expertise, so each of them can upskill that knowledge field that they are not experts on working together, try to fulfill all the areas that we believe.

Brian: Do you call these data translators or analytics translators, are these the de facto data product owner, then? They own that downstream value delivery for the business? I mean—and I understand your framing that the business is ultimately responsible for it, but someone has to translate the technology work into something that can enable that, right? And most of the time, the business doesn’t know how to do that. They don’t know what are all the pot—like, what are all the ingredients in the kitchen, let alone what could we make with all those ingredients, they don’t know that, so we have to provide that. So, I’m curious, are they really that last mile and the value delivery? It kind of falls on them? Or who’s accountable, I guess?

Iván: Yeah, somehow because normally our companies don’t have this kind of data translators. We are trying to upskill people from the business to become data translators, but that’s going to take time. Especially what we try to do is to take product owners and give them, like, a high-level immersion on the state-of-the-art and the possibilities that data analytics bring to the table. But as we can’t rely on our companies having this kind of talent and this kind of data translators, that’s one of the profiles that we bring for it in every project that we work on. The system was to hire the first data translator, the senior data translator, in late 2020 because we felt that we were missing something in the project that we worked on during 2019.

I think that was one of the key decisions we made that helped us move from some very tactical projects, not many of them reaching production, working in more strategic projects, almost all of them making to production. So, we started with one of them. Now, we have, like, six data translators at the corporate level. And as I said before, we try to develop more data translators, at least junior translator at the different companies. But we always take one of our senior data translators and bring them to the project because it is such a key role that we can’t rely on the quality of the data translator or the product owner that the company is able to bring to the team.

So, when we talk about who’s responsible, we like to think that the sponsor and the product owner are accountable, so of the real success. Both of them must be people from the company. And from our side, then we have the data translator and the translator is responsible from the end-to-end vision of the project. So, it somehow has to manage the project from a project management perspective but also has to keep a fluid conversation with the sponsor, the product owner, and with the team, just to ensure that there’s an alignment from the strategic view and their business goals all the way down to the execution of the different tasks.

[midroll 00:16:31]

Brian: When you’re training are trying to upskill your junior people to be more senior, how are you doing that? Is it outside training or is it all like an apprenticeship model where you just learn from a more senior person? And then I would ask, well, where did the senior people learn to do this? Did you hire out of a different role? Like they had a different product management or some other skill set and you brought them in, or did you take training? Or could you tell us a little bit about developing those skills? How did you do it? Or how are you doing it?

Iván: What we’ve done is to try to gather all the learnings from the last two years manage projects and how the different roles should interact in them and what should the responsibilities be, depending on the different kinds of projects. That’s what we called framework. So, we’ve developed frameworks from the different types of projects that we work on, and now on top of those frameworks, we’ve designed—it’s more like a workshop, but it’s like a learn and growth training to 40 hours. It is intellectually tough, but it helps to upskilling both technical and business roles. But that helped us upskill those kind of roles to a junior level and initiated level.

But it is very hard for us to find senior data translators in the market. We have to find someone with the potential to become a data translator later, bring them to a team, and letting them work together with people that’s already been formed and has the this kind of expertise so they can learn by doing. But it is hard for us to find that kind of talent. I think it is also difficult to find ways to train data translators in the market. It is not courses for the translators or nothing that you can find in the formal academic fields, such as universities and so on, which has training this kind of profile. So, I think there’s a gap between the what the market needs and the academic offering related this kind of profiles.

Brian: Your article cites that you feel like there’s a general shortage of these skills. The teams don’t have it innately; it sounds like you’re saying there’s also not a lot of people whose full-time job it is to do that kind of work, yet so often we keep hearing about this low adoption problem. We hear about there’s no value coming out of the other end. We hear about the CDO tenure being so short. It’s like the same refrain, the same chorus to the song over and over again, but you don’t see the requisite skill sets.

And I think your article talks about there’s other skills required to deliver machine learning and analytics work to people that will want to use it to make better decisions. That is not just a technical problem. There’s other things that go into getting people to want to use those solutions. So, why is it that there’s still such a shortage of the talent? And it’s almost like the data community either doesn’t want to accept that other skills are required, or I don’t know, but I tend to see the same thing you do. It’s this whole data product management space, the lack of design and user experience as being anything to do with anything about how a lot of internal enterprise teams build data products.

It’s always been baffling to me. Like, and then we say, “Oh, it’s really hard to get people to use this stuff,” [laugh] you know? Or, “They don’t know what they want.” You know, that’s the other one is, like, “The business sponsor doesn’t know what they want.” And they want us to tell them what’s possible. And then we’re like, “Well, what do you need?” And they’re like, “Well, what can we do with AI?”

And we’re like, “Well, what problem you’re trying to solve?” And it’s like this ten—the data—what I call the data tennis matches; the ball just keeps getting hit back and forth. And it’s just this, like, slow rally. So, why is there such a shortage here? What do you think that reason is for this?

Iván: This is hard to do. So, it is always easier to think or to say that there’s another one to blame when things go wrong. So, if we are the data team, we can blame the business areas, business people, for not adopting what we’re doing. And if you’re the business area, you can always say, “These technical folks don’t really know how to do this and they’re [unintelligible 00:20:59] for us.” So, keeping each other blaming the other side, I think is easier than trying to make one step farther and approximate the other side with humility, asking how we can work together? How can we work together? Is there something that we can work together on to bring more value for the business? And how we’re going to measure its impact? We, as the data people, are the ones that had to make that step. But it’s not easy.

I think there are at least two other reasons. Another one is when you have a budget and you have to decide whether you use that budget in two more data engineers or two more data scientists which are going to help you deliver more things, more artifacts, somehow, instead of bringing in someone that is not going to help you do more; it’s going to help other areas to adapt what you’re doing. Depending on how you’re measured, probably—and this is the third reason—it’s a problem of incentives. So, if you’re measured on how many projects you can deliver during the year, you’re somehow being pushed to run as fast as you can and bring as many technical capabilities as you can in order to fulfill that expectation. But if you would be measured instead on how much value you bring to the company, then probably you will prefer to bring this alternative profiles to the team, these data translators, which are not probably helping you to do more, but to do it better and to ensure that everything you do, [unintelligible 00:23:06] is actually being used by the business.

But I think it’s a matter of incentives. There’s a lot to do, not just between data and analytics and the other areas of the company, but aligning the incentives of all the organization towards the same goals in a way that there’s no friction between the goals of the different areas, and between them and between the goals of the areas and the final goals of the organization. I think there’s a lot of work to do there, a lot that we as leaders have to go through and learn to move from that kind of mistakes from the last 10 or 20 years, and start working on alignment instead of—thinking strategically, aligning the organization towards that strategic goals instead of just running, running, running, without knowing if everyone is running in the same direction or you have people running in different directions and slowing the path of the analysis.

Brian: Do you feel like a lot of CDOs are up against this idea that—or they’re approaching their work as if my value is based on how many projects we executed? Because in my feeling, no executive really wants projects done. They might say they want projects done, but that’s not actually what they’re asking for. They’re just framing it as projects because that’s how everybody talks about the delivery. But 20 projects that don’t create any value, you’re just a giant cost center, right? You just spent a ton of money and resources and there’s opportunity cost, lost opportunity, right, that you could have been working on something else. That’s not really what someone upstairs really wants, right? Do you think a lot of CDOs are actually chasing the project volume game? Like, I’m just supposed to ship models and dashb—like, “We shipped 82 dashboards this quarter.”

Iván: And it shouldn’t be so, but the problem is that it’s much easier to measure. So, when you have the conversation about your goals for the next year, it is very challenging to try to move out of those tactical goals and think of most of the goals from the data analytics perspective because you depend on what the business wants to do with the data. And if that’s not part of the strategic planning, if the data analytics areas are not part of all that thinking processes of what the company should be focusing on in the next 12 months, it is very hard for data analytics teams to just come up with some metrics that they can help move. It’s a talent because the data analytics team’s goals should be the business goals, but not every business goals because you don’t have the capability to affect every part of the business. So, deciding which goals are you going to be co-responsible of, I think that is a sophisticated process that it’s not mastered by many companies nowadays. That probably is one of the main blockers keeping data analytics areas working far from their business counterparts.

Brian: Yeah, I mean, I see this too, just in calls with prospects and stuff. A lot of times, it can be very hard for them to translate this technology initiative they have to express to me what a successful outcome looks like on the back end of that, both from what we call a user experience outcome, which is the people who are going to use it, how would their life be better when you deliver this new model or dashboard or whatever, what impact will it have on them personally? And then what’s the downstream business result you hope, now that the salesperson is happy, or the marketing person is happy, or the whoever it is that’s happy, what do you hope you get out of that? And most of the time they can’t express that to me. This is the root cause of why teams are much more at risk of building yet another output of what I call technically right, effectively wrong: the model works great, but no one cares; no one wants it.

No one wants to make a better decision that way because the old way is just fine. There’s nothing wrong with the old way, in their perception. The business might want to change, but then we find out the users don’t care because they’re not incentivized to do it a different way. This is the realm of why we do user experience research is we want to uncover the emotions, the feelings, the attitudes people have about stuff so that when we deliver a solution, it actually considers those factors. And it’s like, “This is why it’s better for you: it cuts down on your work time and allows you to do more interesting work or your risk goes down or you look better to your boss.” That’s part of using this solution is, “You will look better to your boss.” It’s framed a very different way.

I guess there’s not much of a question there. I kind of went a little bit of a soapbox there and stuff. But I wonder what it will take for this to change in the data science and analytics, particularly this kind of enterprise, non-digital native place where you don’t have some of these other skill sets that I think are just default at most of the large technology companies, even most technology startups, these are just default skills and areas that you have and you work—machine learning, data science, analytics teams work with engineering and product management and design because all four of those factors are really required to ship anything in this kind of intelligence space.

It’s even harder a space than just regular software. It’s not transactional stuff. It’s even harder because you’re in this gray space, right? Here is a dashboard. And it’s like it takes some inference, and it’s—67 is the answer. It was 48 last quarter. What do we do with that? It’s a harder space to design for. And so, I think it’s good that you’re talking about this, that you’re writing about that some of these other skills are required because I think it’s very true.

Iván: The C-suite, looks at data and analytics, if they think these are just technical skills, the data analytics team are just—are going to behave as technical people. And many, many data analytics teams are set up as part of the IT organization. So, I think it all begins somehow on how the C-suite of our companies look at us. I’ve been asked several times where do I think that CDO, or the people responsible for data analytics, where these people should sit in the organization, and I always say it should be in a cross-functional area. So, not marketing, not sales.

It should be in an area which is completely transversal to the organization and it should not be in technology. So, that normally leaves you with few options. One is finance, or if you have operations, or I don’t know, if you have, like, a transformation management team, or transformation office, probably data analytics team should be part of the transformation office.

Brian: You said not technology, which I assume means not digital as well. Is that what you’re saying?

Iván: Well, it depends on how you see digital. If you see digital just as a software development team, probably not. But if you see digital just as software development team, probably you’re going to see data analysts also technical team because I think, in my opinion, another misunderstanding of what [digital 00:30:47] means. For me, it means much more than the technical development of solutions; it should also be part of the transformation of the company, both in how companies develop relationships with their customers, but also inside how every process in the companies becomes more nimble and can react faster to the changes in the market or in whatever can bring some disruption to the company.

Brian: Iván, it’s been great to chat with you. Is there one closing piece of advice you’ve had, or maybe—you’ve been a CDO for several years; is there something you wish your first-year CDO self knew that you know now [laugh]? Or any closing advice for people that are also struggling with this low adoption issue and trying to deliver data products to actually get used and actually produce some value? How would you like to leave people?

Iván: I would like to say that when you feel that everyone else not doing what you think they should be doing, think twice if it is them who are not doing what they should be doing or if it’s something that you’re not doing properly. And I’ve been there. I had this kind of enlightenment moment when we were talking with some people from my team, and we were like, “Wow, why are these people so reluctant to do—to adapt to what we—what we build if what we do is so well constructed? And why are they so unprofessional?” So, when you reach that point, or even better, before reaching that point, we have to change to our minds and think that probably it is something that we are not doing the way we should be doing. We are the ones to blame if the company doesn’t adopt what we’re building or can’t feel the value of what we’re doing. The change begins with us. The rest of the company is not going to change if we are not willing to change ourselves.

Brian: I think it’s good closing advice, especially if you frame this as we’re the new team in town. Data science and analytics is the new people. You know, expecting everyone to come over and just want to do things that way is a big change to the culture, right? I think I agree with you that most of the time, the change is going to have to come from your side and about helping them see the value of what you do. But value is always framed in their eyes; it’s not framed of what how we think it could be good for you. It’s just their subjective judgment.

And that’s all that matters because if they don’t agree it was valuable, then it isn’t. It’s just factually true; it’s not true, it’s not valuable, even though we think hypothetically it might be, it’s not. And that’s a hard thing to do because it requires empathy and it requires us to think very much from someone else’s perspective, which is really hard. Like, “How could they not want this?” [laugh].

Iván: [laugh]. Yeah.

Brian: You know? Like, “It just doesn’t make sense.” But it happens all the time, so I agree with you. I think that shift, it’s probably going to have to come from the data teams if they really want to have success pushing new things, new ways of thinking, new solutions, new technology, all this kind of stuff. The onus is on them. Or you all that are listening. Iván, it’s been great to talk to you. The Chief Data Officer Iván Herrero Bartolomé of Grupo Intercorp down in Lima. And you’re living down in Lima, Peru, these days. Where can people get in touch? Is LinkedIn—I’ll drop your LinkedIn profile into the notes. Is that the best place to get in touch with you?

Iván: Yeah, LinkedIn is a great way to stay connected. So, I’m always willing to engage in conversation like this one. I really love it, so just drop me a line there and I’ll be more than glad to [change 00:34:25] my experience and thoughts. And I hope I can have a lot of feedback on this talk, enrich myself with expertise and experiences from other data leaders around the world.

Brian: Excellent. All right. Well, thank you.

Iván: Thank you so much, Brian.