Log In to continue learning
Data Engineering
Intermediate
Topics
Data Engineering
Data Processing
Deep Learning
Search and Retrieval
The position of Chief Data Officer, or CDO, is a relatively new one in the business world. But with the rise of data as a key business asset, many companies are building dedicated organizations around managing and deriving as much value as possible from their data. Sol Rashidi took one of the very first C-suite data executive positions in a role as Chief Data and AI Officer at Royal Caribbean in 2016. Over the past decade, she has led data and analytics organizations as Chief Data or Data and Analytics Officer at large multinational companies, including Sony Music, Merck Pharmaceuticals, and Estée Lauder. She has received numerous awards and recognitions, including CDO of the Year, being one of the top 100 innovators in data and analytics, among the top 100 thought leaders in AI, and one of the most powerful women in tech, among many others. She's also the best-selling author of Your AI Survival Guide, Lessons Learned from Real-World AI Deployments. Sol, great to have you here. Thank you. It's wonderful to be here. So let's start with a little background on you. How did you get into data and AI? Oh, jeez. Completely by accident. I don't think anyone grows up and says, hey, I want to be a data engineer or data analyst or even a data scientist. I graduated college with a chemistry degree and I wanted nothing to do with chemistry. And so I just decided to pursue what I loved. And I played sports in college. I went to Berkeley and I ended up carrying it through afterwards. So I actually played rugby on the women's rugby team. And then age took its course. And as we get older, things just don't recover as fast. And so I had to hang up the cleats and I decided, OK, what's the one job that no one wants that I can apply for and immediately get? And oddly enough, it happened to be the data engineering role. The good news was I found my tribe. I found my people. The bad news was after six months, I told me I wasn't allowed to touch a lick of code again because everything I pushed to production was just absolute hacksawed in. And so they're like, you can't touch code one anymore at all. And I was like, all right. But I still stuck with it. It was my tribe. It was my community. We had the same jokes. We had the same styles. And then oddly enough, though, what I found out was. Really good data engineers are wonderful at what they do, but sometimes they may not be able to translate what they do into commercial terms or business terms. And one thing that I always loved studying and observing was just business lingo and their metrics and their KPIs and P&L statements. So business always fascinated me. And randomly, I just got into becoming this glorified translator because I understood the work. They just wouldn't let me touch code anymore. But I started understanding the business. And so I was able to translate all the great work that my teammates were doing to why it was relevant for the business. And then the business noticed me and they said, well, we tend to understand you more than some of your peers. So can you just be our point person for all things, data engineering, data analysis? And then the career just kind of Christmas treed its way up. I took a bunch of random positions, but the biggest pivot or two components. I became an SAP Platinum MDM consultant. Don't do that. All I did was ERP migrations. There's nothing more stressful than a migration. And then I graduated to becoming the enterprise data management lead. And then I ran a team, a practice, then a division. And I was sort of the go to gal, if you will, for all things data at IBM eventually, at least on the consulting side. And then Watson beat Ken Jennings in 2011 and IBM decided to take Watson to market. You can't do AI without data. So I had a wonderful, wonderful boss. His name was Jay Bellissimo. I said, Jay, I want in. I want in, coach. Let me in. And I remember I like gently begged for four months. And then he finally said, OK, we're ready for you. And then things took off on the AI track thereafter. And what happened after that? How did you become a C-suite? I mean, to be honest with you, I never asked for permission. I never waited till things were given to me. I just always had this knack of identifying stuff and saying, that's what I want to be able to do. I'd be graceful in my approach. It wasn't a bull in a China shop, but it was very direct, very transparent that that's where I want to get. And I was just relentless in my pursuit. I was a partner at Ernst & Young eventually when I left IBM Watson. And I was a lead partner managing tech and data for the largest client that we had at the time doing a digital transformation. This was 2015. So the word digital transformation actually meant something. And they were my client. And I think about nine months in, I had suggested that they hire a CDO because we were doing all the work and there was no knowledge transfer happening. And at the time it was in Miami and there was no tech talent in Miami. So I was even helping them interview candidates. And then four months after that, they approached me and they said, you know, you know the good, the bad, the ugly. You show up cheerfully resilient every day. You seem to love data and you can explain it to the business really, really well. So do you have any interest in joining our leadership ranks? And so I joined them as their chief data and AI officer back in 2016. Awesome. So in your experience leading data teams, you've obviously had the chance to work with data engineers. What's your experience been working with data engineers? Data engineers are brilliant and they're the backbone of everything. And I think it's a very thankless position to be in. But everything they do matters. And so I've always been overly protective of my data engineers just because of the fact that it doesn't matter if you're running marketing campaigns. It doesn't matter if you're trying to figure out a new consumer segmentation or cohort to market to. It doesn't matter if you're trying to do a new product launch. At the end of the day, all of that is dependent on information and information flowing through. And data engineers have the keys to that castle. And they their job is literally to analyze and do forensics and build the pipeline so that we can get what we need when we need it. So, one, I think data engineers are brilliant, too. I think they're an underserved community and need more time in the spotlight. Three, no business operation can run without it. They truly are the backbone of every single company. And I think we need to do a better job of protecting them, encouraging them and letting them know that what they do really, really matters. So. So what's your advice for aspiring data engineers? If you're aspiring to be a data engineer. You need to have a backbone and not a wishbone. It does require an element of resilience, but you hold the keys to the castle. The information that you're going to know and how things flow in and out of any ecosystem is so powerful. It's art and science combined. And oftentimes I think data engineers. I don't want to say they can be ignored, but they may be considered a back office function. So don't be afraid to ask to be a front office function. If you have aspirations of going into management or leadership, work on your communication skills. If you just have that fire in your belly and you want to do more than just work in your home office or your cubicle and code all day long. Get front and center. Understand the business lingo. Understand the business language. Context is everything for data engineers because you can flow information from source to target systems and it's going to show up as it appears. But without context, the business immediately is going to unvalidate it. And so I would say if this is a career path you're choosing to take on, depending on where you want to go, know that you matter, know that your function is extremely critical to every business function, whether they validate or recognize you or not. Make sure you understand the business language and what's important to them. Communication is key, not just talking, but what you speak is received as intended. I think that's where we miss with communication. And don't be afraid to ask that you want to be more front office oriented and not necessarily back office oriented if you have those aspirations. OK, great. All very valuable advice and information. So what we're doing at this point in the course is walking through the process of requirements gathering. I've emphasized that one critical piece of requirements gathering is to understand the overall goals of the business. And maybe the best way to do that is to talk to leadership. So when you were chief data officer, did you interact a lot with your data engineers? I did, but also that was my tribe. So I spoke a lot with my data engineers, my data architects, my data analysts, my data scientists. One of my favorite things to do is actually like a whiteboarding session when we were trying to problem solve. But I'm cut from that cloth. And so I think it's really important that if you are going to talk to business executives or leaders of any sorts or even middle management, you have to know your audience. So if I'm a functional leader, which means I don't understand your language whatsoever, I would never talk about semantic layers and conform layers and source of target systems and building pipelines like their eyes are going to glaze over and you're going to lose them immediately and you're not going to get a follow up meeting. So know their language before you approach them. But if they're techno functional, keep it light, meaning you could use some jargon just enough where they could follow along. But don't overwhelm them. If they're a technical executive, 100 percent show your craft, show what you're great at. It's not a problem at all. But you really do have to know the business executive that you're connecting with and how they perceive your communication. So I would say absolutely do it. If you want to be more front office oriented, just know the language they're using and align to that language. So if I'm a data engineer, what are some of the things I should look for to gauge how technical I should get with a stakeholder? So whether you're in enterprise, midsize company, small, startup, VC, private equity, you're going to immediately know. So most startup or small organizations run very, very lean. And so more than likely, it's going to be a bipolar effect in the sense that either you're going to be in amongst a crowd of technical individuals and your CEO was probably an individual contributor at some point in time who decided to become an entrepreneur and a CEO of a tech based company. That, have at it, speak your normal language. You could also get the CEO who's just a phenomenal marketer, had a great idea, and his superpower and his super strength is hiring the right individuals. In that case, you may be with a bunch of sales folks and marketing folks, and there may be three of you that understands your language. That's a CEO that's completely functional. You can't go into your language. Midsize and enterprise always take a look at the title and where they report into. So unless they're in the office of the CIO or the office of the CDO, but I even know CDOs who actually aren't technical. They're purely functional, very strategically intended. Automatically, if they're leading a brand, automatically, if they're leading a label, if they're leading a function or a service, you have to assume that they're functional in nature and in the conversation, draw out maybe what they know about your space before you get into it. So if I had to give a word of advice, look at the title, look where they report into. Always lean on them being more functionally oriented. Start the conversation functional unless they lead you down a technical path, and then you can pivot that way. So that was Sol Rashidi, who's been a data exec at many large organizations. In our conversation, Sol mentioned quite a few times that as a data engineer, when you're speaking with leadership within your organization, you need to know your audience. Do they serve a functional role or a technical role or maybe somewhere between? Depending on their comfort level with tech, you might need to adjust how you communicate with them in a language that they understand. You can also apply this advice when you're speaking with other stakeholders outside of leadership as well. So next up, let's hear from Jordan Morrow, who will give you some tips on how to have requirements gathered in conversations with different stakeholders.
