Adam Sroka argues that many data science failures come from organisational problems, including resistance to management, weak communication, and poor alignment with business needs.
2
Small companies should hire for the work they actually need, rather than filling every gap with data scientists who may be more expensive than software engineers, analysts, or BI developers.
3
People moving into MLOps should start with small practical projects, learn how models connect to software systems, and work with software engineers instead of choosing tools in isolation.
Summary
Adam Sroka discusses the organisational problems behind unsuccessful machine learning projects. He describes how inexperienced data scientists can resist management, choose solutions before understanding the problem, and struggle with business constraints such as budgets, deadlines, and stakeholders. He advises hiring people for the work the organisation actually needs, since reporting, APIs, and data cleaning may call for different specialists. For teams starting MLOps, he recommends a small project with Docker, a simple API, and a basic model before moving to harder production concerns. Adam also explains why communication and workplace politics matter. Data professionals need to build trust with finance, IT, software engineering, and business teams. They should argue clearly for technical choices, then support the final decision. His advice is candid about uncertainty, especially when teams consider emerging tools or complex production requirements.
Data scientists need to accept business constraints and management
Adam connects data science churn to the gap between academic work and business work. Some people resist management or claim that agile methods cannot apply to data science. Others arrive from academic settings where publishing and research matter more than budgets, deadlines, and stakeholders. He says this can lead to frustration when a project manager asks for progress and when deliverables do not arrive. His advice is tough love: data scientists need to accept that business teams have pressure, schedules, and financial limits. They also need enough maturity to understand that being technically capable does not remove the need to be managed.
Hiring should follow the work instead of the data science label
Adam says smaller companies should first understand what they need from data. A data scientist can be useful as a generalist who handles reporting, data cleaning, automation, and open-ended analysis, but that does not mean every role should go to a data scientist. BI developers may be better for reporting, while software engineers may be better for building APIs. He also warns that data scientists may leave when a role does not let them do the work they expected. If a company hires a PhD for research, Adam recommends giving that person support from strong data and software engineers rather than hiring many researchers for the same project.
Trust and communication matter as much as technical ability
Adam recommends that data professionals build relationships with people who control budgets and operations. One practical example is automating part of a CFO's workflow and saving a few hours each week. That creates an ally when the team later asks for investment in a longer project. He also tells his teams to make communication understandable without specialist context. If a figure needs a long explanation, he considers it poorly presented. People can become defensive when they feel excluded or made to feel unintelligent, so technical teams need to bring IT and other groups into the work instead of presenting a finished solution as a demand.
Speaking up works better when people assume others have reasons
Adam does not describe workplace politics as something professionals can simply refuse to engage with. People compete for projects, promotions, budgets, and influence, so ignoring those relationships can leave technical teams frustrated and excluded. He recommends starting from the assumption that resistant colleagues are doing the best they can. Someone who opposes a project may have been burned by an earlier initiative or may be protecting an operational responsibility. Understanding that context makes it easier to address the real concern. Adam also cites the exit, voice, loyalty, and neglect model, arguing that voice is the response most likely to improve a situation for everyone.
Productionising a model has several levels of difficulty
Adam says the move from data science into MLOps can be difficult, especially for people who learned programming through scientific work rather than software engineering. He suggests building a small model with the iris dataset, putting it behind a Flask API, and running it with Docker in a cloud service. The exercise will not qualify someone for an MLOps job, but it makes concepts such as APIs, GET and POST calls, and deployment more concrete. He also separates basic deployment from harder requirements such as drift monitoring, retraining, resilience, and operating across regions. Teams need to decide what productionisation means for their system rather than treating every deployment as the same problem.
Tools should be chosen with software engineers and with attention to uncertainty
Adam says MLOps teams should learn from software engineers, who may challenge ideas such as feature stores or new platform components based on their production experience. He suggests starting with an accessible tool such as MLflow to understand why it works the way it does. He likes Kubeflow, while warning that it is difficult to adopt without people who understand Kubernetes. When teams assess a platform, they should discuss whether they want to depend on an emerging technology, rebuild parts themselves, or use a managed service. Adam advises stating uncertainty openly instead of promising that a difficult approach is safe.
Technical teams should argue strongly, then support the decision
Adam recommends a two-stage approach to technical decisions. The people closest to the implementation should work through the detailed options with data and software teams. They should then present a small number of honest choices to business stakeholders without forcing those stakeholders into technical debates. Within the technical discussion, people should argue passionately for their preferred option. Once a decision is made, they should support it with the same commitment, even when it is not their first choice. Otherwise, teams can alienate colleagues, lose support after staff changes, and end up reverting to spreadsheets months later.
Effective data work is expressed in money and time
Adam advises data professionals to translate technical outcomes into financial value and saved time. Business stakeholders may not care about model accuracy, recall, or precision on their own. They care about what the system changes for the organisation. He gives the contrast between automating reporting or cleaning up data streams and seeking a small accuracy improvement with a neural network that nobody understands or can maintain. His point is that a simpler data improvement can create value faster than a sophisticated model. The technical metric still matters for the system, but it is not enough to explain why the work deserves funding or adoption.
"You have to build that trust, that confidence and things like that, and understand that it's something one of Brené Brown's books I read recently, and she talks about you have to assume everyone's doing the best they can."19:14
Who should watch
You lead a small data team and need to set expectations about management, business priorities, and the less glamorous work around data.
Your organisation is choosing an MLOps platform and needs a way to discuss technical options with software engineers and business stakeholders.
You are a data scientist trying to move into MLOps and want a practical first deployment project rather than a list of tools.
