4 ms·

I work in this field and I flatly reject that the purpose of a ‘business intelligence’ team is to “develop profound new business capabilities” or ”organise the

I work in this field and I flatly reject that the purpose of a ‘business intelligence’ team is to “develop profound new business capabilities” or ”organise the data scientists such that they are optimized to learn”. What planet are you on? Such a team is absolutely not a pure research team, devoted to investigating the data and driving new capability and insights. The purpose of such a team is to facilitate the business to have operational insight into the state of the business, and serve the business as the business requires to deliver business as value. 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. There is a place for such a team, and a data science team as described, but like google X, a very specialised thing for companies that can afford to dream. ...not for everyday engineering teams. Generalists vs specialists is a straw man, obviously you have both.

spongepoc 8y ago
>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.
- stronglikedan 8y ago
  Is succinctly stating your educated opinion considered feigned indignant outrage now? If so, society is screwed.
- nerdponx 8y ago
  It doesn't say "business intelligence" anywhere in the article.
- shadowmint 8y ago
  > “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.
navigatesol 8y ago
>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.
usgroup 8y ago
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.
zeckalpha 8y ago
That illustrates the difference between a company that sees data as a function vs as a core strategy. Stitch Fix is definitely the latter.
pea 8y ago
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 https://nstack.com
deleted 8y ago
[deleted]
licyeus 8y ago
> 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).
- pmart123 8y ago
  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.

spongepoc 8y ago

>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.

stronglikedan 8y ago
Is succinctly stating your educated opinion considered feigned indignant outrage now? If so, society is screwed.
nerdponx 8y ago
It doesn't say "business intelligence" anywhere in the article.
shadowmint 8y ago
> “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.

navigatesol 8y ago

>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.

usgroup 8y ago

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.

zeckalpha 8y ago

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

pea 8y ago

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 https://nstack.com

deleted 8y ago

[deleted]

licyeus 8y ago

> 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).

pmart123 8y ago
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.