Research, prototype, code, test, deploy. That’s how a usual day goes in my life as a data scientist. I work in a large traditional banking organization that is attempting to become a data-driven business. It’s been doing a legitimate attempt by implementing a data science department for the past 2 years. Few people if none understand truly what we do but they sure care about the results of our work. Yet, to most we are black box.
So far, we have been able to deploy various traditional machine learning (ML) and some deep learning (DL) models to the real world causing a positive impact in areas such as commercial and risk management. After the word of success has spread to other departments the demand for models has increased and departments across many functional areas of the organization are interested to explore how data science can help.
This situation has led functional staff from other areas of the business to seek interaction with our data science department. These functional staff are by no means experts, nor they should be, but this is not an excuse to exclude them from the algorithm development life cycle. We have noticed that in traditional organizations there is a tendency to favor model interpretability of over high abstraction (i.e. ML vs DL models). Inclusion and involvement of these functional staff is of extreme importance in situations where abstract models (e.g. DL) are in need.
So, I want to share some core values we try to uphold in our attempt to facilitate the participation of functional business areas in the algorithm development life cycle:
- Data Scientists must listen to take advantage of the huge business experience inside the organization in the form of more senior staff to build good models responsibly.
- Data Scientists must be inclusive and seek to include functional staff in the development lifecycle of an algorithm. It facilitates the deployment stage by smoothing any unnecessary friction that could arise because the model can be perceived as intrusive into the roles of other departments.
- Data Scientists must be sensible, our work usually tries to emulate (using algorithms) the intelligence of business processes that are usually performed somewhere in another department by a person. Obviously, working isolated can cause unnecessary friction at the moment of deploying a model.
- Data scientists must provide value on every algorithm that must be researched, tested and deployed. Always ask the requesting party to provide a return on investment (i.e. $) for the solution they need. This is the value of your algorithm.
- Data Scientists must build systems not algorithms just like anything that is related to computer software in general. No algorithm seats there on itself and by itself as they must be part of a systems or they will likely be shelved and forgotten. Traditional data warehousing architectures in large organization have data sources spread across different custodial domains whose patrons are always weary of anyone messing with it.
These are just a core set of values that have proven to be a requirement for me as data scientist to achieve maximum impact and drive change (i.e. a data-driven change) in my day to day. Always have in mind that an algorithm can be shelved and forgotten very easily for many reasons if it is not sold appropriately inside an organization, just at least try not let it fail because of poor soft skills strategy.
I would love to hear what other values you see helpful in pushing a data driven change in your organization. In my next article, I want to share a design thinking approach to data science that helps include other functional areas into the algorithm development life cycle.
Cheers!
