Data Scientist vs Machine Learning Engineer: Forget the Definition, Focus on the Process!
Triggered by a blog article, a colleague (who is more on the management side of things) asked me about my opinion on the role definitions of a Data Scientist and Machine Learning Engineer. Usually, I’m not interested in discussions around role definitions. However, they often contain assumptions about “how to do and divide the work to build a Machine Learning Application”; which is something I’m super interested in :). Also, I want to use this blog to write down opinions and arguments that I keep repeating in 1:1 conversations. That way, I have a source I can point to the next time the topic comes up.
The article that triggered the question contained an assumption about the application development process that goes roughly like this:
A Data Scientist will iteratively experiment and improve the model until it meets the desired outcome before handing it over to the Machine Learning Engineers.
I specifically object to the expressed view that work is (should be) divided between Data Scientists and Machine Learning Engineers in consecutive steps and that work is handed over. Here are my thoughts:
This division of labor is, for one, super inefficient and, for another, a luxury many companies cannot afford. I assume that for Big Tech like Netflix and Co, it might make sense to have a Stats/Math-Genius that squeezes out the last 0.05% from the model and then have five Machine Learning Engineers for each Stats/Math-Genius to bring it to production in a way that scales to millions of requests. But from my experience, for most companies, having any (or maybe the next) Machine Learning Model in production would be a big step forward and preferable over model improvements. Neither are the last few percent improvements in the model as relevant to the business nor are the engineering challenges as crazy as in big tech. Consequently, I’d always prefer a team without functional silos where everyone should be as full-stack as possible (of course not everyone can be equally marvelous in everything, so I’d argue that there is a skill spectrum between Stats and Engineering or a T-Shaped skill profile).
Bonus thought: This has been argued in the DevOps community for quite some time: no strict division of labor or “throwing over the fence” between Dev and Ops but integrated teams and processes that make it simple to deploy to production. I don’t know why Machine Learning went the other way in many companies. However, I have the feeling that lately ML as a discipline is coming more and more around to the DevOps approach. Especially, with the proliferation of Data Platforms (e.g. built on Kubeflow) that make the process of experimentation, testing, production deployment, scaling, and operation much simpler and less skill-intensive.
As a last thought, I have been working in both kinds of environments but I am super happy to have been mostly working in a product team without functional silos for the last 4 years. In my experience, everyone has so much more fun if the responsibility for the whole product and process is shared among all members of the team.
If you aren’t convinced yet, I highly recommended these two readings that lay out the arguments in much more detail than I did: