Wednesday, 9 May 2018

Should you hire data scientists on gigs or as FTEs (Full Time Employees)?


Recently a conversation with a client caused me to re-think this situation. Yes, I fundamentally believe analytics/”Data science” is a comparative advantage an organisation can possess. However this need not mean an FTE (Full Time Employee) army, or does it?

As in most such questions, the answer is… "it depends".
To make things simple, I’ll consider 3 points of view:
A "Data Scientist"'s point of view
B Hiring Manager's point of view
C Organisation's point of view

Of course the ideal situation is where all 3 parties’ interests are in agreement.

I simplify the issue by measuring the status on 2 axes:
X.               Number of “data science” projects undertaken in a year
This is an indication of how often the skills of the “data scientist” are being used. This had to be projects that go beyond BI, need to have a predictive component. A “data scientist” is an expensive resource and it is a waste from all parties point of view to utilise a “data scientist” to build dashboards most of the time for example. There are other people much more skilled at this than “data scientists”.
Y.               Variety of projects undertaken in a year
The variety of projects is an indication of how far down the path of utilising “data science” or how broad the adoption or experimentation with “data science” is an organisation.

These 2 axes can be thought as components of analytical maturity – necessary but not sufficient conditions (I will discuss about analytical maturity in a subsequent blog). The more “data science’ projects you undertake in a year, the more likely you are to be using them. More importantly, the more varied they type of problems you are trying to solve using “data science”, the more likely it is that the adoption of “data science’ or the attempts at adoption permeate the organisation.

However, this looks at only the production side of things, not the consumption. There are many organisations out there who adopt a “if you build it…” and end up with white elephants.

At the end of this blog, I’ll describe an Occam’s Razor, but for now let’s look at things a bit more management school style.

A             “Data Scientist”'s Point of view


The top right is a sweet spot for the “Data Scientist”; he/she gets to continually learn things and use the skills in a variety of projects. This is a happily tired “Data Scientist” where it’s not work, just play.


The bottom right is where the “Data Scientist” is kept busy on projects that require his/her skills and knowledge, but these projects are repetitive. This can lead to boredom, and the palliative situation is to build strong feedback loops to keep improving and challenging the “Data Scientist”. Else it might make sense to rotate “data scientists’ and bring in new pairs of eyes to try and bring quantum improvements rather than continual polishing.

The top left is where the “Data scientist” gets a variety of projects but is under-utilised, a stop-start adventure. This is likely the case of an organisation who is starting with data science operationalisation, or is not mature enough to exploit “data science” fully. In this case, it might be better to hire specialist “data scientist” on a as-needed basis. This would be much better use of resources and make better use of “data scientists’” skills.

The bottom left is where no “data scientist” would want to tread; apparently he/she did not ask the right questions in the interview.

B             Hiring Manager's Point of View:

I was going to write an analysis of a hiring manager’s point of view, but I think it is enough to say that if they are not aligned to that of the organisation (principal agent problem) then it doesn’t matter what is really going on, all that matters is the impression you can give; it is an ego or resume padding trip and no reasoning can be applied.

C             Organisation’s point of view
The top-right is the sweet spot for the organisation; the “data scientist” is involved in many projects (well utilised) and a variety of projects (organisational analytical maturity), chances are organisations in this quadrant are able to generate sufficient RoI (Returns on Investment) from their “data scientist”. But does that mean that organisations in this quadrant should not hire data scientists on gigs? The answer depends what the “data scientist” can bring.

The bottom right is where the “data scientist” keeps doing the same things. Basically, at every iteration of a model, unless there have been structural changes, there will be incremental improvements. The question is whether this generates sufficient RoI for an FTE.

One of the questions clients (both when I was FTE and on gigs) often ask me is when they know a model needs to be relooked at. My usual answer is all to do with metrics. In the same way as I insist of proper performance metrics of models to be agreed at the start of a project (to ensure RoI), I also encourage clients to have acceptable variability in results. It’s a bit like having a point estimate and a band of acceptable intervals (CI). So only if the results degrade below an acceptable level would it be worth looking at (you cannot assume that the degradation is due to random fluctuations and the impact on returns is too negative).

So chances are, unless each application of the model generates huge returns, it might make more sense not to have a “data scientist” on the payroll but to use a “data scientist” on gigs (1).

The top left is where the “data scientist” is engaged on a variety of projects but not many projects. This is a clear case that a “data scientist” by gig is better. Not only do you utilise resources only when you need them, but you can ensure you get the best resource for the project.

The bottom left shows and organisation that has no use for a full time data scientist, but should explore “data science” via gigs.

Conclusion:

It is quite clear that the best case scenario for both the “data scientist” and the organisation  is when the “Data scientist” is fully engaged, building a variety of models/algorithms to solve different business use cases and generating RoI.

In the rest of the cases, the situation is unlikely to last. In cases where there is either variety or quantity but not both, the “data scientist” is likely to feel lack of growth and leave, causing the organisation to go through the expensive hiring process again and again, further impacting RoI.

In the case when there is neither quantity nor variety, there is no point engaging a full time “data scientist”. This is a very clear-cut case for having “data scientists” on a gig basis. The approach should be one of proof of concept, prove the RoI that can be obtained, using “data scientists” on gigs; not only is the cost overall lower, but the organisation can get specialists.

Simlarly, when there is variety but lack of quantity, “data scientists” on gigs offer the possibility of specialist help, and help only when needed. When you do not have projects requiring skills of a “data scientist” then why pay someone?

When there is no variety, the challenge is different. It is likely that this is the case when the analytical development of the organisation has stalled; for example, “data science” is used only in one area of the organisation, hence a lack of variety. Here again it might make more sense to only get “data scientists” on gig basis, to try and expand the variety and increase RoI by opening new avenues for returns. Also, another way of increasing RoI in this case if to hire “data scientists” for prototyping, but leaving maintenance to less expensive resources (2).

Finally, does that mean that if you have both variety and quantity you do not need “data scientists” on gigs? Well, it depends how well your RoI is doing. In the corporate world, where performance has to increase over time, using specialist help for prototyping, having a “different set of eyes” looking at business issues can be a solution. Of course you may choose to rotate your “data scientists” to ensure that freshness, but if could come at the cost of returns.

In a nutshell:

In a nutshell it all depends on the RoI. When I first took up a contract, it was very exciting as someone in the analytics field. My headcount was directly funded by the business and I had to justify my existence every year, I had specific RoI targets. That made me so alive. I guess that’s why I am believe strongly in RoI.

Apart of vanity and bragging rights on the part of management, why would an organisation spend on a resource that is generating low or no RoI?

Organisations have to measure the returns on their investments; that includes human capital. As long as the RoI is met, then hiring a FTE “data scientist” makes sense. Else, at the least, until the organisation matures enough to be able to allow the “data scientist” to generate that RoI, it should stick to “data scientists” on gigs.


1 There have been cases when clients want to put data scientists on a gig but also pay a retainer. This is sort of a compromise between the 2 models. However, retainers may not work. From the organisations perspective there will be an incentive to use the “data scientist” for non-“data science” work.
2 Another question I often get is “when do I need to review my models?”. I believe that the model metrics should not be decided just for a one time use, but also for on-going performance. For example, a targeted response rate of 15%, where review will take place if the response rate dips below say 12% for 2 consecutive runs.

No comments:

Post a Comment