I'll chime in here as a member of a 'Data Science' team at an early stage company. A lot of this really resonated with me. In particular - I think several of hi

I'll chime in here as a member of a 'Data Science' team at an early stage company. A lot of this really resonated with me. In particular - I think several of his points are consequences of the others: 1) We sit on an island, quasi-separated from engineering. We have our own processes, codebase, and tools, that are mostly different from what engineering has deployed in the wild. 2) This leads to 'throw normal engineering processes out the window,' which is good and bad . We write plenty of code, but not much of it makes it to source control. Why? so much of what you write is "throwaway code" - this, of course, is no good, but it's very tough to tell apriori what is going to work and what isn't. 3) This makes getting things deployed to production hard. Your code isn't written in the Java that the rest of the backend is. There was never the thought that there'd be a build process attached to it. Deployment? Nightmare. As far as not scaring the rest of the company with all the math - totally agree, but only to an extent. If your models are so sophisticated that they can't be explained to an engineer, or your customers, in plain (insert locale-specific spoken language), they might be too complicated. In terms of having an impact immediately - I think this goes for all engineers and data scientists. Someone should be able to put a fresh set of eyes on your problems, and be able to solve a new one with enthusiasm.