A machine learning project should start with the business value it is expected to create, since that determines the team and technical work required.
2
Teams need shared working practices for data access, documentation, testing, code review, delivery, and model management.
3
Production models need monitoring, transparency, explainability, and governance from the start, while scalability should match real demand rather than imagined requirements.
Summary
Simon Thompson discusses the work around machine learning that sits outside choosing and running algorithms. He argues that project managers should first understand the business value, then use that answer to decide the team, data work, infrastructure, and production requirements. Teams need a shared understanding of the problem and explicit agreements about tickets, documentation, testing, code review, and sign-off. Thompson separates scalability from governance. A model should meet known demand, but teams should not spend heavily on hypothetical traffic while neglecting manageability, transparency, explainability, and monitoring. He compares machine learning work in finance and healthcare, where the useful prediction may concern treatment or action rather than diagnosis or raw accuracy. He also explains why he wrote his book, to make practical knowledge available to people outside established communities of practice. His advice is grounded in long experience and is direct about the damage caused by poorly framed projects.
The business value should determine the machine learning team
Simon Thompson says teams should begin by asking how much money a project is expected to make. That answer shapes the size and type of team. A project involving a large data search may need data engineers and only one or two data scientists. A project that must produce 2,000 models may need many machine learning engineers because production becomes the bottleneck. He warns that projects disconnected from the business can lose their sponsor and support before delivery. Availability requirements also need a business reason. An online model should be highly available when that requirement protects or creates business value.
Project setup requires a shared understanding of the problem and the data
For Thompson, project setup means finding the right team, breaking down what the project is for, and agreeing why the work matters. He says that a team knows very little about an ML project until it has seen the data. Technical access is only the beginning. People still need to understand the fields and their meaning, and data sign-off may change after modeling reveals problems or useful patterns. The team also needs agreed expectations for tickets, documentation, code review, testing, and test-data use. These practices differ by project because the projects and their risks differ.
Industry teams need a different kind of motivation from academic researchers
Thompson describes academic motivation as mainly intrinsic and says industry teams are more often driven by external factors, including skill development and personal growth. People may leave when they feel they are no longer growing, so managers have to accept movement and create room for learning. He connects this with the need for business understanding. Data scientists and engineers must stay open, curious, and humble about what subject-matter experts tell them. An expert may sense why a model will fail without being able to state the blocker clearly. Showing the model's behavior can help that person explain what was wrong.
Including affected users is part of ethical machine learning work
Thompson says a model can harm people directly, but a team can also act unethically by failing to understand or involve the people affected by it. He gives the example of a model that may make people miserable or 'chew them up'. Treating the work as finished after getting paid is clearly irresponsible in his view. Failing to be curious about the users and people subject to the model can produce a similar result. The people using or affected by a model need to be considered during development, because their experience can reveal problems that technical evaluation misses.
Scalability should follow real requirements, while governance cannot wait
Thompson separates scalability from monitoring, governability, and management. Teams should design for known demand. If a model will run 10,000 times a day, its cost and capacity need to make sense. They should not spend heavily on an imagined requirement that never arrives. Governance has a different position. A production model must be manageable, transparent, explainable, and monitored. Without those controls, a team accumulates a serious debt that may come due when a regulator or other authority requires the system to be turned off. Thompson uses Twitter's early MySQL system to illustrate that a simple design can be replaced when actual traffic demands it.
Business evaluation matters more than a fashionable accuracy score
Thompson calls fancy algorithms and the last increment of accuracy nice-to-haves unless the business can attach real value to that improvement. Teams often optimize F1 or another score without asking whether the resulting product is useful. In healthcare, a model might achieve strong performance but still be unsafe if the application requires near-perfect results. In capital markets, predicting a price well may be less useful than deciding whether to buy or sell. The right evaluation depends on the action, the users, and the cost of errors. A false positive in surveillance may be inconvenient, while missing serious misconduct may be unacceptable.
The book makes practical project knowledge available outside established communities
Thompson wrote Managing Machine Learning Projects from Design to Deployment after spending a year at the Alan Turing Institute and speaking with people working across industries. He saw that large technology companies often have communities of practice where people share the details of running ML projects. Other teams may never have access to that accumulated experience. Their mistakes can include misunderstanding the problem, lacking suitable infrastructure, or building an unsuitable team. The book records practices that Thompson believes can help those teams. He wants readers to challenge the advice and discuss different ways of working, rather than treat the book as a final authority.
"You know nothing about an ML project until you've seen the data, nothing at all."Simon Thompson18:41
Who should watch
You are setting up an ML team and need to decide whether the project needs data engineers, data scientists, or machine learning engineers.
Your model is heading toward production and you need a practical boundary between scalability work and controls for monitoring, governance, and explanation.
You work outside a large technology company and want advice on project practices that established ML communities often share informally.
