Dr. Warren Reed: You are managing the timeline, the budget, and the stakeholders. But deep down, you know the real action is happening inside the data pipelines and the AI models. How do you cross that chasm from managing the project to mastering the technology? Today, we are unpacking Jacqueline Nolis's book, Build a Career in Data Science, through a very specific lens: how to pivot from Tech Project Management to a Technical Program Manager in Data and AI. We will tackle this from three angles. First, we will demystify the data landscape to find your specific niche. Second, we will outline how to build technical credibility on the job without starting from scratch. And third, we will map out the exact blueprint to execute the TPM pivot. I am Dr. Warren Reed, and joining me is Ayubu, a tech project manager with a keen eye for strategy and a deep curiosity about the future of AI. Ayubu, welcome.

Ayubu: Thanks, Warren. It is great to be here. You know, that opening really resonates with me. As a project manager, I often find myself standing at the edge of the data science sandbox, looking in. I see the incredible impact these data models have on our products, and I want to do more than just facilitate the meetings. I want to understand the underlying mechanics, speak the language of the engineers, and ultimately help shape the technical direction of these AI initiatives. But the data field can feel incredibly fragmented and, honestly, a bit overwhelming from the outside. Nolis's book feels like a map for exactly this journey.

Dr. Warren Reed: It is a map. But you need to know how to read it. Let us start with a hard truth. Data science is not a single job. It is an umbrella term. People get confused because companies use the titles interchangeably. They hire a data scientist when they actually need a data engineer. Or they hire a data analyst and expect them to build deep learning models. If you want to pivot, you must first understand the terrain. Nolis breaks it down into three core areas. One: Data Analysis. This is about looking backward. Finding insights in existing data to drive decisions. Two: Data Science. This is about building models. Predicting the future using machine learning. Three: Data Engineering. This is the plumbing. Building the infrastructure to move and store data. Ayubu, when you look at those three, where does your PM brain naturally gravitate?

Ayubu: That is a fascinating breakdown, Warren. Looking at those three pillars, I think many project managers naturally lean toward the Data Analysis side initially because we are already used to looking at metrics, tracking KPIs, and trying to understand project health through data. But for me, the real curiosity lies in the intersection of Data Science and Data Engineering. I want to understand how the models are built, yes, but also how they are integrated into the larger product ecosystem. As an INFJ, I tend to look at systems holistically. I want to see how the data flows from the raw pipeline, through the model, and into a feature that actually solves a human problem. But Nolis makes a great point in the book about not trying to learn everything at once. She talks about finding your specific entry point. If I want to transition toward a Technical Program Manager role in AI, do I need to become an expert in all three, or should I specialize first?

Dr. Warren Reed: Specialize first. Absolutely. Trying to master all three at once is a recipe for burnout. Bottom line: a Technical Program Manager does not need to write production-grade machine learning code. But you must understand the constraints of each role. Think of it as a spectrum. On one end, you have the data engineer who cares about latency, databases, and pipeline stability. On the other end, you have the business stakeholder who cares about revenue and user experience. The TPM sits right in the middle. You are the translator. To be a good translator, you do not need to be a native poet in Python, but you must speak the language fluently enough to negotiate. Nolis talks about the concept of Type A versus Type B data science. Type A is for Analysis. Type B is for Building. As a future TPM, you need to decide which side of that fence your target projects sit on.

Ayubu: That Type A versus Type B distinction is incredibly helpful. If I am managing a project that is Type B, where we are building a recommendation engine into an app, the technical challenges are vastly different than a Type A project, which might just be analyzing user behavior to write a strategy report. In a Type B scenario, the engineering constraints are massive. I need to understand things like model deployment, API latency, and data drift. Nolis shares a great case study in the book about a company that hired a brilliant academic data scientist to build a predictive model. The scientist built this incredibly complex, highly accurate model in a Jupyter notebook. But when it came time to put it into production, the engineering team realized it took three seconds to run a single prediction. In a real-time app, three seconds is an eternity. The project stalled for months. That feels like a classic failure of technical program management.

Dr. Warren Reed: Spot on. That is a classic failure. The academic scientist optimized for accuracy. The engineering team optimized for speed. Nobody optimized for the system. That is where the TPM comes in. A strong TPM would have set the non-functional requirements on day one. They would have said, the model must return a prediction in under fifty milliseconds. That constraint changes how the data scientist builds the model. It forces them to choose a simpler, faster algorithm. This is why you do not need to know how to write the algorithm itself, Ayubu. You need to know how to ask the questions that expose these constraints. Nolis emphasizes that communication is the most underrated skill in data science. PMs already have this skill. You just need to point it at technical architecture.

Ayubu: It is about asking the right questions at the right time. But to ask those questions, you need a baseline of technical credibility. If I walk into a room of data scientists and machine learning engineers, and I start asking about latency without understanding how a model is deployed, they might write me off as just another project manager chasing buzzwords. Nolis talks about this hurdle in the book. She mentions that one of the hardest parts of entering the field is overcoming the credibility gap. For someone in my position, who has a business and project management background, how do we start building that technical credibility without spending four years getting a computer science degree?

Dr. Warren Reed: You build it through micro-contributions. Do not try to build a neural network on day one. Start with SQL. Structured Query Language is the bedrock of all data work. If you can write your own SQL queries to pull data for your projects, you immediately stop being a burden on the data team. You stop asking them for basic reports. That builds massive goodwill. Second, learn the vocabulary of machine learning pipelines. Understand what training data, validation data, and test data actually mean. Understand the difference between supervised and unsupervised learning. When you use these terms correctly in a meeting, the engineers notice. They realize they do not have to dumb down the conversation for you.

Ayubu: That makes complete sense. It is about reducing the friction for them. I actually had an experience recently where our team was waiting on a data analyst to pull some basic user retention metrics for a project status report. The analyst was swamped, and the report was delayed. If I had known basic SQL, I could have run that query myself in five minutes. Not only would that have saved the analyst time, but it would have given me a direct, hands-on relationship with our database schema. It is a perfect example of a micro-contribution. Nolis also suggests building a portfolio project, even if you are not planning to be a full-time data scientist. For a PM, what would a portfolio project look like? It probably shouldn't be a standard Kaggle competition dataset, right?

Dr. Warren Reed: Correct. Avoid Kaggle. Kaggle datasets are clean, curated, and unrealistic. Real-world data is messy, incomplete, and frustrating. Nolis advises building a project that solves a real, messy problem. For you, as a PM, your portfolio project should focus on the end-to-end lifecycle. Find a public dataset, or scrape some data. Clean it. That is eighty percent of the work anyway. Analyze it to find an interesting insight. Then, build a simple web app using something like Streamlit to display your findings. The goal is not to show you are a master coder. The goal is to show you understand the process. You understand how hard it is to clean dirty data. You understand how to structure a data pipeline. When you can talk about the pain of cleaning data, you instantly connect with engineers on an empathetic level.

Ayubu: I love that idea of empathy through shared pain. There is a real psychological shift that happens when you actually try to clean a dataset yourself. You realize that missing values, inconsistent formatting, and duplicate entries are not just minor annoyances—they are major roadblocks that can completely skew your model's results. In my current role, I often see project timelines slip because we underestimated the time needed for data preparation. We assume the data is ready to go, but the engineers spend weeks just wrangling it into a usable format. If I have personally experienced that wrangling process, I can build more realistic project schedules. I can advocate for the data engineers when stakeholders are pushing for quick results. This brings us to the core of the TPM role: bridging that gap between the technical reality and the business expectation.

Dr. Warren Reed: Exactly. You are bridging the gap. Let us look at a concrete case study from Nolis's book that illustrates this. She describes a project where a retail company wanted to predict customer churn. The business team wanted a model that could predict with ninety-nine percent accuracy which customers would leave. The data science team knew that was mathematically impossible with the available data. The project was at a standstill. The business team thought the data scientists were incompetent. The data scientists thought the business team was unrealistic. A TPM with data fluency steps into that gap. They translate. They explain to the business team that a model with seventy percent accuracy, deployed quickly, is infinitely more valuable than waiting for a ninety-nine percent accurate model that will never exist. They help the business understand the concept of expected value.

Ayubu: That is a classic conflict. The business wants certainty, but data science is inherently probabilistic. As a PM transitioning to a TPM, I see my role as managing that uncertainty. In traditional project management, we love predictability. We want to know exactly when task A will finish so task B can start. But in data science and AI, you are running experiments. You do not know if a model will work until you try it. This means the traditional waterfall, or even standard agile frameworks, can sometimes fail when applied to data science. Nolis talks about how to manage data science projects differently. How does a TPM adapt their management style to accommodate the experimental nature of AI?

Dr. Warren Reed: You shift from managing tasks to managing hypotheses. In traditional software, you build a button. The button either works or it does not. In data science, you test a hypothesis. For example: 'We believe adding user demographic data will improve our churn prediction model by five percent.' The TPM's job is to time-box that experiment. You do not let the data scientist spend six months chasing a one percent improvement. You set a threshold. You say, 'You have two weeks to test this hypothesis. If we do not see a significant lift, we move on to the next feature.' This requires a deep understanding of the scientific method and a willingness to accept failure as a valid project outcome. You are managing a portfolio of experiments, not a checklist of deliverables.

Ayubu: That is a profound shift. Managing hypotheses instead of tasks. It requires a lot of trust from leadership, and it requires the TPM to be incredibly transparent about the risks. It also plays to my strengths as an INFJ. I like to look at the deeper meaning and the long-term implications of our work. In AI, those implications are massive. We are not just building software; we are building systems that make decisions, sometimes biased decisions. A TPM in the AI space needs to be thinking about data ethics, model interpretability, and fairness. Nolis touches on the ethical responsibilities of data professionals. How does a TPM integrate these ethical considerations into the project lifecycle without slowing down innovation?

Dr. Warren Reed: You make ethics a non-functional requirement. Just like latency or security. You do not treat ethics as an afterthought. You build it into the definition of done. For example, before a model is deployed, the team must run a bias audit. They must document how the model performs across different demographic groups. If there is a significant disparity, the model does not ship. A TPM enforces this process. You create the templates, you schedule the reviews, and you protect the engineers who raise ethical concerns. This is where your INFJ personality is a superpower, Ayubu. You have the empathy to see how these models affect real people, and the strategic mind to build guardrails into the development process.

Ayubu: That is incredibly empowering, Warren. It makes me realize that transitioning to a TPM in Data and AI is not about abandoning my project management roots or trying to pretend I am a PhD statistician. It is about synthesizing my existing skills—communication, stakeholder management, systems thinking—with a solid foundation of data literacy. I can use my PM skills to structure the chaos of data science experiments, and use my data literacy to protect the integrity of the models and the teams building them. If I were to set a concrete plan for the next three months to execute this pivot, what would the immediate action items be?

Dr. Warren Reed: Here is your three-step action plan. Step one: Master SQL. Spend thirty minutes a day on it. Learn how to join tables, aggregate data, and write subqueries. Stop asking others for data; pull it yourself. Step two: Build a micro-project. Do not use Kaggle. Find a messy dataset related to your current industry. Clean it, analyze it, and build a simple dashboard. Document your struggles and your solutions. Step three: Shadow your data team. Ask to sit in on their architecture reviews. Listen to how they talk about data pipelines and model deployment. Ask questions afterward. Show them you want to learn, not micromanage. Do these three things, and you will build the credibility bridge.

Ayubu: That is incredibly direct and actionable, Warren. I love the focus on micro-contributions and shadowing. It feels very achievable. It is about taking small, consistent steps to build that technical muscle. I think many people, including myself, get paralyzed by the sheer volume of things they think they need to learn—Python, R, linear algebra, calculus, cloud computing. But breaking it down into SQL, a simple hands-on project, and active listening makes the mountain look like a series of hills. It is about starting where you are and leveraging the context you already have.

Dr. Warren Reed: Exactly. Start where you are. The tech industry does not need more people who can write code but cannot talk to humans. It needs people who can do both. The bridge is empty, Ayubu. Walk across it.

Ayubu: I am ready to take that first step. This conversation has given me a lot of clarity. It is not about changing who I am; it is about expanding my toolkit so I can lead these complex, high-impact AI projects with confidence and empathy.

Dr. Warren Reed: That is the goal. To our listeners, if you are sitting on the sidelines of the data revolution, wondering how to get in, remember: you do not need a PhD to make an impact. You need curiosity, a willingness to get your hands dirty with messy data, and the strategic vision to connect the math to the business. Grab a copy of Jacqueline Nolis's Build a Career in Data Science, start with SQL, and build your own bridge. Thanks for listening.