Benjamin Rogojan says data science teams often learn to make models work without learning how to deploy them into systems.
2
Agile practices can organize data science work, but research needs room for uncertain outcomes and failed experiments.
3
Data teams should document their work, connect models to business metrics, and build solutions that the current team can maintain.
Summary
Benjamin Rogojan discusses the gap between building a data science project and putting it into use. Early in his career, he could write an R program that worked, but there was no clear next step for deployment. He compares this with software engineering, where deployment processes are usually more established. The conversation then covers agile planning, research risk, and the value of spending time on data checks before model development. Rogojan recommends a flexible data science process with tangible outputs such as a short report, saved queries, charts, and documented conclusions. He also explains how simple business dashboards can show whether a model affects the metric it was meant to change. For communication, he asks technical teams to explain conclusions and business value rather than only describing implementation details. He closes by arguing that someone must take ownership when several teams or companies share a process.
Data scientists need a path from working code to deployed systems
Benjamin Rogojan recalls reaching the point where he had written an R program that did what he wanted, then asking, "now what." He saw a gap between research and analysis on one side and software systems that people actually use on the other. New data scientists often learn how to make a model work, but they do not learn how to deploy it. Rogojan contrasts this with software engineering, where companies tend to have a defined deployment process, whether it is automated or manual. He says the data science field has since gained more tools and techniques for this part of the work.
Mentorship can prevent avoidable production mistakes
Rogojan says his first mentor left after two weeks, leaving him to learn without an experienced technical person around. He made mistakes and wrote poor code. At his next company, seeing better infrastructure and code helped him understand how he should have approached the work. He describes a mentor as someone who can challenge bad ideas and point out poor code, either through tough feedback or a gentler approach. The hosts add that production systems contain domain-specific details and many moving parts that school cannot fully prepare people for. Rogojan agrees that engineers learn through getting into the code, fixing things, and sometimes breaking them.
Agile planning needs to account for research uncertainty
Rogojan argues that technology work is often grouped together too quickly, as if practices that work for coding will work in data science. Software tasks usually have a clear input, output, and expected result. Data science research can involve long projects where failure is a real possibility and no useful model may emerge. He still sees value in agile practices because they help organize work. A data scientist can treat data analysis, an initial investigation, or a baseline comparison as a defined piece of work without promising a production model. He says spending a week checking whether data is useful can prevent six weeks of model development based on bad or manually entered data.
A lightweight process gives research a tangible finish
Rogojan prefers guidelines over a rigid process, but says a team needs a general sequence for deciding when work is complete. After looking at data and finding insights, a data scientist can write a short conclusion, save queries and code, and package the work into a small deliverable. This gives managers something concrete to review and lets the team say where a project stands. He mentions the Microsoft data science process as an example of documenting the data set, features, infrastructure, and steps taken. Even when a model performs worse than a baseline, the result can be recorded and reused. Rogojan says this documentation helps with future work, career discussions, and personal confidence about what was accomplished.
Business metrics should be chosen before a model is evaluated
When discussing model impact, Rogojan says a team does not always need an advanced observability product. A simple dashboard can track a business metric that should change if the model works. For price optimization, that might be average sale price. A sales organization might track how often deals close, while social media companies may watch engagement. He warns against choosing metrics after the change has been made, because teams can then find an improved metric and treat it as proof of success even when the movement was luck. The team should decide what to watch in advance and then track whether the model affects that measure.
Technical communication has to explain the conclusion and business value
Rogojan says senior leaders sometimes receive reports full of analysis and numbers without a conclusion that explains why the work matters. He recommends ending research with a clear point of view or conclusion. Technical people also need to move beyond explaining how a model works. Accuracy alone does not tell a business owner whether the work will improve customer satisfaction, increase sales, or reduce costs. Rogojan describes this as listening to what the business owner needs and explaining the work from that perspective. He says business analysts often fill this communication gap because they understand both the business context and enough of the technical work to connect the two sides.
Solutions should match the team's skills and maintenance capacity
Before recommending machine learning, Rogojan asks what data exists, what the business wants to achieve, which tools are already available, and what skills the team has. A company may need a basic KPI or analytics rather than a machine learning model. A solution also has to fit the people who will maintain it. He warns against building a Python system for a team that works in Java, or for analysts who cannot support the software. Engineering includes ongoing maintenance because APIs change, migrations happen, and systems break. He says teams should account for that work before choosing a technical approach.
Rogojan describes ownership as a personal lesson from a project involving several companies. He says the work would have gone more smoothly if he had been more direct and taken responsibility for the process, even when every task was not formally his. When several people are involved, nobody may clearly own the overall workflow. In that situation, tasks can deteriorate because no one is accountable for moving them forward. He also recommends writing a concise summary after analysis so that a non-technical person can understand the value of the work. The summary records what happened and makes it easier for someone else to continue.
"There's a gap here where data scientists think about, 'Oh, we'll do this research and we'll analyze this thing,' but how does it go from here to actually touching people and working with and interacting in systems?"03:58
Who should watch
You are a data scientist who can build analyses or models but does not have a clear path for deployment and handoff.
Your team needs a practical way to document exploratory work, explain failed experiments, and show managers where a project stands.
You are advising a small company and need to decide whether it needs machine learning, basic analytics, or a simpler solution that its team can maintain.
