Managing (4) - ML Teams - Full Stack Deep Learning

Managing machine-learning teams is hard largely because progress is unpredictable: early gains often don’t translate into sustained improvement, and projects can stall or even regress for weeks. A competition example shows accuracy jumping from roughly 30% to 70% in the first week, yet over the following months performance barely improves. Participation patterns reinforce the lesson—teams keep joining rather than quitting after early success—suggesting that “we made big progress this week” is not a reliable predictor of “we’ll finish next week.” In practice, ML work frequently behaves nonlinearly: teams hit a plateau, try multiple approaches that fail to move the needle, then get stuck behind technical debt that forces refactors and can leave performance worse than before the detour.

A second management challenge comes from culture clashes inside ML organizations, where research and engineering often collaborate. Researchers tend to prioritize novelty—new model ideas, experiments, and polished write-ups—while engineers prioritize clean, scalable systems and maintainability. When these value sets don’t align, organizations fall into a familiar failure mode: researchers see engineering as trivial, engineers see research as impractical, and neither side fully respects the other’s constraints. The result is friction over what “good work” looks like and what timelines should assume.

Third, leadership frequently lacks ML fluency, making it difficult to set realistic expectations, interpret results, or understand why ML differs from traditional software delivery. That gap matters because ML planning and reporting require different mental models than standard engineering project management.

To manage better, ML project planning should be probabilistic rather than deterministic. Traditional waterfall planning assumes tasks have known durations and dependencies; ML planning must explicitly account for uncertainty in which ideas will work. Instead of committing to a single path, teams should run parallel hypotheses that all map to the same objective, acknowledging that some approaches may have only a 50% chance of success. As weeks pass, the plan should change based on what becomes impossible (e.g., data quality undermines an approach) or what fails to deliver expected performance (e.g., a model underperforms until a new architecture is tried).

A corollary is to avoid “path-critical” research where one fragile assumption blocks the objective. Good teams often run multiple hypotheses in parallel as a friendly competition of ideas, but they need a culture focused on reaching the right answer—not rewarding who guessed correctly. Progress measurement should reflect inputs and execution quality (what was attempted, how well it was executed) rather than only whether an individual idea ultimately worked.

Operationally, getting end-to-end ML pipelines into production quickly helps create a data flywheel and ties model behavior to business value, making progress easier to communicate credibly. Finally, status updates to leadership should be business-specific and cautious about forward-looking promises. Reporting “cat detection accuracy from 60% to 80%” without translating it into business impact, or projecting that “next week we’ll solve it,” can mislead stakeholders because ML progress can stall or reverse. The broader takeaway: ML teams need probabilistic planning, aligned research-engineering culture, production feedback loops, and leadership education to manage expectations and communicate progress responsibly.