I agree. Anecdotally, I've seen a few of companies hire large data science teams and operate them outside the context of any product management; i.e. as basically R&D arms. The problem is that most companies do not have R&D-level problems, and they do not have a good way to surface priorities to the data science team, manage delivery, etc., and the data science team ends up building a lot of stuff from scratch, or working on priorities that don't add a lot of value, or not having stakeholders really understand what they do. This isn't good for the data science team either, as it's hard for them to communicate value.

I think the pin analogy in the article is a slight straw-man and a strange choice of comparison: sure, running a data science isn't like running a factory production line. It requires experimentation and isn't deterministic. But IMO that doesn't mean it should sit outside of product management, or is completely different from building or managing a regular software engineering team: in some instances, hiring full-stack developers absolutely makes sense. In some, you will need folks who are specialised to certain problem spaces; isn't it the same in data science?

I also think that, if data science code is going from R&D into actual prod, it is helpful if it is reviewed and tested from a more software eng POV, and may end up in parts being rewritten by teams with more specialised skill sets around e.g. performance. It would put a huge onus to put on every data scientist if they had to learn this stuff (and I'm not talking like petabyte data engineering)

I've been working on a way[1] to help data scientists more easily share and run their models/code without having to spend a lot of time on the engineering side, but a big group of our users are also folks in data teams who are not experts in lots of ML or engineering (are not "full stack" in this sense), but they work with data every day and need a way to use parts of the data science ecosystem more easily. IMO upskilling these folks may be more then norm going forward than being able to hire data scientists who are also experts on the entire stack.

[1] https://nstack.com

I think this is accurate. Few businesses have the slack required to hire a speculative research division to delight and surprise the business with new capabilities :)

More typically DS will optimise . I think engagement bandits, recommendation systems and such are all examples of optimising rather than driving new capability , and to agree with you, generalist vs specialist is a straw man in this instance.

After all someone at some point is going to make a business case for a DS team member and the vast majority of businesses don’t have the luxury of doing anything other than focusing on growth.

>I work in this field and I flatly reject that the purpose of a ‘business intelligence’ team

Good job the article is about data science and not business intelligence then. Cool the feigned indignant outrage please.

It doesn't say "business intelligence" anywhere in the article.

> “one person sources the data, another models it, a third implements it, a fourth measures it”

Call it whatever you like, it is what it is.

Is succinctly stating your educated opinion considered feigned indignant outrage now? If so, society is screwed.

That illustrates the difference between a company that sees data as a function vs as a core strategy. Stitch Fix is definitely the latter.

> What the article proposes is like having a development team that has 100% time to pursue their interests and build whatever they like to show to the business to develop new business capability.

I didn't get this from the article. My interpretation was that rather than having a DS team with specialized roles sitting outside of product/engineering, companies should locate DS generalists within product teams. I.e., push data competency closest to the teams working with the problems + data, and as the DS learns where ML can be applied, the entire team can deliver. In a DS-as-specialist structure, you'd have to locate several roles on a product team to achieve results (or co-locate them and deal with overhead).

The article confuses by claiming "the goal... is not to execute", but in context, it's clear that it's a criticism of process efficiency myopia, not of product delivery.

And the word "research" only appears in the article in a negative connotation. “Develop profound new business capabilities” doesn't mean the research of new models, but instead the application of existing techniques to business processes (e.g. a model that can reasonably predict user churn based on sentiment analysis of messages sent on your platform would be profound).

The only issue with that is you sometimes develop duplication across siloes. Instead of one team building the framework/analytics engine, you have a bunch different experimental environments, datasets, etc.

>What planet are you on?

The planet that says the purpose of the business intelligence team can be whatever the company wants it to be.