How to Work With ML Engineers and Data Scientists

Why This Module Exists

Non-technical professionals who understand how ML engineers think are dramatically more effective. Miscommunication between technical and non-technical teams is one of the largest sources of wasted effort on AI projects. This module closes that gap.

What ML Engineers and Data Scientists Actually Do

Data scientists focus on: understanding the data, building and evaluating models, designing experiments, and measuring model performance. They spend the majority of their time on data quality, feature engineering, and evaluation - not on training models.

ML engineers focus on: building the systems that take a model from experiment to production - data pipelines, serving infrastructure, monitoring, retraining workflows, CI/CD. They bridge data science and software engineering.

Applied AI engineers focus on: building products on top of AI models - LLM applications, RAG systems, evaluation pipelines, agent workflows. They often do not train models; they integrate and build on top of existing ones.

Each role needs different things from product and business collaborators.

What They Need From You

Clear problem definitions: Not "build an AI for customer support" but "build a system that classifies incoming support emails into four categories with 90% accuracy, operating on 500 emails per day, with results available within 1 minute of receipt."

Labeled data: For supervised learning, they need examples with correct answers. The clearest way to give this: "Here are 200 emails. Here is the category each one belongs to, according to this classification guide."

Acceptance criteria: How will you know if the model is good enough? What metric? What threshold? Before what deadline?

Feedback on failure modes: When the model is wrong, what matters most - missing a billing issue, misclassifying an urgent technical ticket, or routing to the wrong team? This shapes how the model is evaluated and optimized.

How to Write a Clear AI Feature Specification

The five things every AI feature spec needs:

1. Problem statement: What user problem are we solving? What does success look like for the user?
2. Input/output definition: What does the system receive as input? What should it return?
3. Quality requirements: What does acceptable performance look like? What is the minimum bar?
4. Data requirements: What data exists? What labels are available? Who can help label more?
5. Constraints: Latency requirements, cost constraints, privacy requirements.

A one-page spec with these five sections enables an ML team to begin work. A vague brief generates a week of clarification meetings.

Common Sources of Miscommunication

"The AI should understand context": ML systems do not understand context the way humans do. Be specific: "The system should use the previous two customer messages as context when classifying the current message."

"Make it smarter": What specific failure mode are you trying to fix? "Make it smarter" does not give the ML team anything actionable.

"Can't we just train it on more data?": Sometimes yes. But more data without better labels, better features, or a clearer objective does not reliably improve performance.

"The model is wrong": In what specific cases? On what input types? At what rate? Specificity converts a complaint into an improvable engineering task.

Where to Go Next

The next module teaches you to read the design documents that ML engineers produce - turning the vocabulary you now have into practical technical literacy.