« Agile (Data)Science

April 17, 2019 • ☕️ 1 min read

Data ScienceAgileAcademiaMachine LearningScientific Method

Industry vs. Academia in Terms of Working Style

Photo by [Lucas Vasques](https://unsplash.com/@luvqs?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)
Photo by [Lucas Vasques](https://unsplash.com/@luvqs?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)

This post is about two things a (data) scientist typically comes along with: a scientific mindset, which is incredibly valuable, and an “academic working style”, which can be a major handicap.


The scientific mindset

A well-grounded scientific education equips a data scientist with important traits:

  • Analytical thinking, to discover insights deeply hidden in data
  • Healthy skepticism and rigorous hypothesis testing, to deliver high-quality results
  • Understanding concepts like statistical uncertainty or the difference between correlation and causation, thereby preventing clients or executives from drawing false conclusions

As such, a data scientist’s skills are immensely useful for digital businesses.


The “academic working style”

In academia, a typical PhD thesis goes like this:

  • Pick a narrowly defined problem
  • Focus on it for years
  • Find the best humanly possible solution
  • Finally publish, but only after extensive reviews

A large portion of data science recruits have been through this process, and it has inevitably shaped their professional behavior. Something similar is true for ”Generation Kaggle“.

However, the “academic working style” often clashes with the requirements of today’s digital economy. Especially in an agile environment, a different behavior is necessary for success:

  • Care about the product as a whole, not just the tiny modelling part you were assigned to
  • Know that “good enough” is often sufficient
  • Put working prototypes before ultimate model performance
  • Release early and often to field-test your solution — try, fail, learn, repeat

Of course, this doesn’t mean not to double-check your results, or release head over heels. Also, there’s a difference between fast-paced digital product development and e.g. working in a large company’s fundamental research department.


Personally, after transitioning from academia to industry, I had to adjust my working style in the way described above. It wasn’t particularly painful, however, I would’ve learned much faster If I had been consciously aware of the difference.


Do you miss anything? Disagree entirely? Feel free to share your opinion in the comments.