Reliable machine learning depends on organizational culture, management incentives, and communication across teams, not only on model and infrastructure design.
2
Machine learning makes incident response harder because a model can become worse for some users or situations without completely failing.
3
Engineers need to treat privacy, ethics, and governance as part of ordinary machine learning work rather than as a separate course or review at the end.
Summary
Niall Murphy and Todd Underwood discuss the ideas behind their book Reliable Machine Learning with David Aponte. They describe machine learning as an organizational change because data crosses team boundaries and its value depends on cooperation between groups. Todd explains why remote teams need searchable documentation alongside Slack, and describes open working sessions that give newer engineers a low-pressure way to ask questions. They argue that companies should reward mentoring instead of evaluating only code shipped and bugs fixed. The conversation then turns to staff engineers, who often need to work across technical and organizational boundaries. Incident response is especially difficult in machine learning because a model can degrade for a particular group without producing an obvious outage. The guests also discuss whether ML SRE will become a lasting job title, the spread of machine learning through ordinary software, and the need to include privacy and ethics in every stage of the work.
Remote work needs durable records alongside live chat
Niall Murphy says distributed teams often live in Slack because it creates an interactive feeling, but Slack is poor for material that people need to search and retrieve later. He recommends pairing it with a Wiki, documentation, or another information-management approach. Todd Underwood describes a weekly open working session for teams onboarding newer people. Experienced engineers work on a video call, sometimes sharing their screens, while newer employees can drop in with questions. This avoids forcing someone to schedule a formal meeting just to ask where files are or how a migration works. It also gives less experienced employees a regular way to see how the team works.
Mentoring has to count as part of engineering work
Todd Underwood argues that senior engineers become overloaded when organizations ask them to mentor without recognizing that work. During the pandemic, companies often rewarded shipping code, fixing bugs, and launching products, while mentoring and teaching were left out of formal evaluation. He says management should explicitly decide whether mentoring is part of the job and reserve a substantial part of people's time for it, even if that means trading off some delivery work. He also accepts that some people dislike interviewing or teaching and should not be forced into those roles. Niall Murphy adds that rewarding desired behavior is ordinary management, although narrow metrics can produce unwanted behavior, such as opening unnecessary bank accounts to increase an account-count target.
Machine learning spreads across organizational boundaries
Niall Murphy says machine learning is difficult to place inside a single silo because data and its effects reach throughout an organization. Todd Underwood compares this with the spread of information technology through older businesses. If an airline uses data about who buys seats, that information could help its catering group predict meal demand, but only if the groups can share the data appropriately. Staff engineers help with this work because they are expected to look beyond one team's technical or organizational boundary. Niall says machine learning helps instrumentalize data by surfacing its significance in places where it might otherwise remain local. The guests reject the idea of a perfectly centralized data lake that solves access and governance concerns.
Small companies and large companies need similar boundary-crossing behavior
Niall Murphy connects staff engineering in a large organization with working in a startup. In a large company, a staff engineer models behavior and helps set culture across a wider group. In a startup, the person who notices an important problem may simply need to take responsibility for it, regardless of formal specialization. Todd says this broad scope fits machine learning because useful data and ideas often sit between divisions. Combining them requires attention to privacy, governance, and access controls. The practical rule is that when no one else is clearly responsible for making a cross-team problem work, the staff engineer or startup engineer should step in.
Machine learning incidents can degrade without a clear outage
Todd Underwood says ordinary production failures are easier to classify when a serving layer crashes or a model cannot load. Machine learning creates harder cases because a model may still run while becoming less useful for a particular group or under particular conditions. Teams then have to decide whether the change counts as an outage, who is affected, and when the incident is over. Investigation may require the people who build the model, evaluate its quality, produce its input data, and join those data together. A missing data update or an incorrect join can make the model worse without an obvious infrastructure failure. Niall adds that on-call work is less stressful when engineers know where to find dashboards, understand the system, and can get help.
Reliability engineering may absorb machine learning skills
Todd Underwood is unsure whether ML SRE will remain a distinct job title. He expects machine learning skills to become part of ordinary production engineering because software systems will increasingly depend on machine learning. He compares this with software skills becoming a normal requirement for people who work with computers. Niall Murphy gives a more organizational explanation: once SRE has a good reputation, companies may attach the label to new roles in an attempt to gain its benefits. The discussion leaves open whether the long-term role will be called ML SRE or simply reliability engineering with machine learning knowledge. The underlying work includes distributed systems, production operations, data, and model behavior.
Trustworthy machine learning requires rules and incentives
Todd Underwood says explainability and technical governance matter, but they do not close the gap between what technical tools can explain and what society wants to know. He sees data protection rules as an example of regulation that once seemed difficult to technology companies but later appeared reasonable from a citizen's perspective. Niall Murphy expects more regional differences and regulation around machine learning, while worrying that political decision-makers may lack the detail needed to understand both its benefits and risks. Todd argues that engineers remain responsible for foreseeable uses of their systems. Niall says education in ethics alone will not remove incentives to do harmful things, so regulation, penalties, culture, and character all have a role.
Ethics and privacy belong in every machine learning chapter
Todd Underwood says Reliable Machine Learning includes a full chapter on privacy and ethics written by an independent expert, but the authors also placed those concerns throughout the rest of the book. He rejects the idea that ethics can be handled as a separate class while engineering proceeds unchanged. Engineers should be able to detect when a model reproduces bias and should not launch it after finding a harmful result. Niall Murphy agrees that practitioners need to consider the consequences of their creations, while pointing out that people often continue harmful behavior because it provides an advantage. In that situation, external rules and meaningful consequences are needed alongside professional judgment.
"If you're wondering who's supposed to figure out how that division is supposed to work with this division, if you're not talking to anybody else who's asking the same question, that's probably you."Todd Underwood32:05
Who should watch
You run distributed engineering or ML teams and need practical ways to document work, onboard people, and make mentoring part of the job.
Your models keep serving while their quality changes, and your incident process does not make ownership or escalation clear.
You are introducing machine learning into an established business and need to think through cross-team data access, privacy, incentives, and regulation.
