# Leading Enterprise Data Teams Sol Rashidi, ExecutiveAI | MLOps Podcast | Episode 227 | 43:00 Hosted by Demetrios Brinkmann Source: https://www.youtube.com/watch?v=qB0AAPCu4o0 Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks. Page: https://mlopstalks.com/talks/leading-enterprise-data-teams Published: 2024-04-26 Tags: enterprise, platform-teams, product-strategy, team-adoption ## TL;DR - Sol Rashidi prioritizes AI and data projects by scoring business criticality alongside deployment complexity. - Inherited data teams need months of listening, stakeholder interviews, and skill-and-will assessment before major personnel changes. - Relationships and business language matter more to executive influence than knowing every new tool in the market. ## Summary Sol Rashidi explains how she leads large enterprise data and AI teams, especially when projects, ownership, and priorities are unclear. She rejects business value as the only way to rank use cases because nearly every request can be made to sound valuable. Her alternative scores each project on criticality and complexity, then plots the results so teams can focus on work they can realistically deploy. She also describes how she inherits teams: spending months in one-on-one conversations, collecting start-stop-continue feedback, mapping alliances, and assessing people by both skill and willingness to do the work. Rashidi is direct about accountability, scope, inflated forecasts, and the need to end projects that have passed their shelf life. Her strongest leadership advice concerns relationships. She learns how each stakeholder describes their business, then explains data work in those terms instead of using technical language. The conversation also covers the friction between data, infrastructure, security, and technology teams in large companies. ## Key ideas ### Use complexity as well as business criticality to choose projects [02:37](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=157s) Sol Rashidi stopped ranking use cases by business value alone because almost every business request has some value behind it. Her formula scores criticality, such as regulatory exposure, competitive threats, stale inventory, or a weak product launch, alongside complexity. Complexity includes infrastructure, data access and quality, deployment work, and whether the right people are available. She plots the scores on a quadrant. High complexity with low criticality is a non-starter. Low complexity with high criticality gets priority because the team can execute it with its available resources. She updates the plot every quarter and communicates what is in or out of the current priority bucket. ### Teams get stuck when they choose projects they cannot put into production [06:51](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=411s) Rashidi calls prolonged proof-of-concept work "Perpetual POC Purgatory." Teams may have an attractive use case but lack basic infrastructure, workload cost tracking, data pipelines, orchestration, or the security controls needed for production. She explains that AI systems differ from static software because they depend on live information and ongoing data operations. In one client engagement, a consulting strategy listed 12 use cases, but Rashidi judged that nine could not even be soft-launched because required foundations were missing. Her advice is to choose a use case that the organization can actually deploy. ### Projects that keep slipping need a shelf-life decision or a new forecast [09:23](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=563s) When a project keeps moving its target date, Rashidi says leaders have to decide whether to call its shelf life or redo the forecast. A realistic forecast may reveal that the needed people are unavailable, data access requires several application leads, or fragmented data will take months to aggregate. Continuing to repeat an old timeline damages credibility. She compares this decision to her college sports experience, when she stopped pursuing water polo after recognizing a physical limitation and found rugby instead. Ending or redirecting a project is not automatically failure. It can be an honest response to the conditions around the work. ### Promised business results should be traced back to their assumptions [13:02](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=782s) Rashidi does not accept projected market share, efficiency, or revenue figures at face value. She asks how the number was generated, what context and assumptions went into it, who was included, and how the result will be measured later. The original baseline and measurement method must remain clear when the team reports progress. She has experienced both sides of inflated estimates. Sometimes analysts created numbers in the hope that they would stick. At other times, executives committed to a result that the delivery team believed was impossible. Her response in those situations is to support the goal while first asking for the calculation behind it. ### Inherited teams need months of listening before restructuring [17:17](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=1037s) When Rashidi inherits a data team, she spends roughly four to five months meeting people across levels of the organization. She asks what the team should start doing, stop doing, and continue doing. She also asks what people think her job is, what the team is meant to do, and which business partners are allies or advocates. In parallel, she asks stakeholders who on the team has helped them and who they regard as a teammate. She turns those conversations into a map of team practices, relationships, and reputation. She then creates a will-and-skill map, separating people who have the ability and motivation from those who lack one or both. ### Skill gaps can be tested through useful, open-ended assignments [21:49](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=1309s) For people who show willingness but may lack skill, Rashidi assigns practical work to trusted leaders, managers, or to a chief-of-staff role. The assignments can involve shaping a strategy narrative, designing an analysis, or proposing a way to track an A/B campaign. She watches for critical thinking, common sense, resourcefulness, and the ability to ask the right people for help. Someone may not be a strong engineer but may be good at connecting a story or planning how work should be presented. In that case, Rashidi can pair that person with a strong developer inside a team led by a product manager she trusts. ### Data accountability depends on clear ownership and scope [23:52](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=1432s) Rashidi says data teams often face more accountability because poor data quality cannot be hidden as easily as a business process. When her team owns the data, she traces the problem through people, processes, tools, and outputs. When a domain is outside the team's scope, she makes that boundary explicit. She describes an organization where her team owned product and vendor data but not customer data, even though it received repeated requests to fix customer records. She used the volume of those requests to argue either for new ownership, funding, and resources or for a clear decision that the domain would remain outside the team. Undefined ownership creates recurring requests without the means to fix them. ### Relationships and the stakeholder's language matter more than tool knowledge [30:59](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=1859s) Rashidi puts relationships first when she enters an executive role. She learned this after starting an early job with technical confidence but little understanding of politics or relationship building. Instead of immediately announcing fixes, she spends months learning what people need and how they describe their business. She avoids terms such as data architecture and orchestration when speaking with business leaders. She explains what takes weeks to deliver, why it takes that long, and what the stakeholder will receive. For tool decisions, she asks several practitioners for their views rather than spending all her time researching every new product herself. This gives specialists a valued role while letting her form and communicate a considered judgment. ### Large companies struggle when executive boundaries and culture resist change [37:27](https://www.youtube.com/watch?v=qB0AAPCu4o0&t=2247s) Rashidi describes data leadership as difficult when responsibility is divided among CIO, CTO, chief data, chief analytics, and digital leaders. A data product may depend on infrastructure, DevOps, and security resources that the data leader does not control. If those dependencies are not funded or prioritized, a project planned for three months can take much longer. She also argues that older companies with long employee tenure and pension structures may have a harder time adapting because their culture was not built around disruption. Her approach is to communicate the state of work repeatedly, explain which constraints belong to other teams, and make the cost of each operating choice clear to executives and the board. ## Notable quotes - Sol Rashidi: "If it is highly complex and low criticality it's a non-starter. I'm not doing it, get it out of there." (05:55) - Sol Rashidi: "The priority is always the relationships. People don't do business with you because you have the greatest tool. They do business with you because they like you, they trust you, and you've shown them that you're interested in solving their problems." (30:59) - Sol Rashidi: "I call myself just like a glorious translator, but I get to know the words and the language and the metrics that are important to them and I use their language, not our language." (32:36) - Sol Rashidi: "I can't create change without making change and everything starts in the mindset, the mentality, and the team that I have to work with." (20:03) ## Tools & references mentioned - ExecutiveAI - MLOps Community - Your Survival Guide to AI - IBM - Royal Caribbean - Sony - Weights & Biases - Malcolm Gladwell - Ronald Reagan ## Who should watch - You lead a data, analytics, or AI team in a large company and need a practical way to rank requests that all claim business value. - An inherited team has unclear ownership, mixed performance, or weak relationships with business partners. - Your projects keep missing production dates because infrastructure, data access, or executive priorities were never included in the original plan. ## Editor's note Sol Rashidi describes teams trapped in "Perpetual POC Purgatory" because they lack the infrastructure, data pipelines, orchestration, or security controls needed to put a use case into production. ZenML lets teams define workflows as Python pipelines and run the same code on a laptop, Kubernetes, Airflow, Kubeflow, or cloud services by changing the configured stack. Written by the MLOps Talks editors (the ZenML team), not by the speaker. ## Related talks - [Building Better Data Teams](https://mlopstalks.com/talks/building-better-data-teams) (Leanne Fitzpatrick, Financial Times, 1:01:40) - [11 lessons learned from doing deployments](https://mlopstalks.com/talks/11-lessons-learned-from-doing-deployments) (Sol Rashidi, ExecutiveAI LLC, 35:59) - [What Business Stakeholders Want to See from the ML Teams](https://mlopstalks.com/talks/what-business-stakeholders-want-to-see-from-the-ml-teams) (Peter Guagenti, Tabnine, 1:21:28) - [Collaboration and Strategy](https://mlopstalks.com/talks/collaboration-and-strategy) (Vin Vashishta, V Squared, 51:54) - [Lessons on Data Teams Leadership](https://mlopstalks.com/talks/lessons-on-data-teams-leadership) (Luigi Patruno, 2U, Inc, 1:13:32)