Re-imagining the ‘digital’ workforce…

Re-imagining the ‘digital’ workforce…

Re-imagining the ‘digital’ workforce… 1280 853 Administrator

While there is a lot of attention and focus on two aspects of “digital” i.e. the Technology and Use Cases (ala disruption & transformation), the third, and important, cog of the wheel hasn’t been paid too much of an attention. THE PEOPLE!!

Oh yes, there are a lot of conversations about continuous learning, upskilling, agile processes and the likes. Again, most of them are concentrated on the tech aspects of the factory model of churning out people with “those” skillsets.

If we can spend some time to understand the fundamentals of what this Digital does (now is a good time, because, now we think we know!) and how we can reimagine some of our roles, it might be worthwhile

What’s in an AI project?

Let us talk about how an AI/ML project gets delivered. (Here is where the purists need to pardon us!)

Most of the work we do in this space still is supervised. That means, we go through the typical steps – data collection, labelling, processing, running some (super) models on this data set, testing it on “hold-out” data and, viola, the model is built. Then comes of the process of exposing that model and consuming the inference part. And (thankfully) a few folks have started talking about ‘model management’ post deployment in production.

In this context, we only talk about the new breed of people; the data scientists. Today, there is a scramble to learn machine learning and AI, to become a part of this elite breed.

If we can pause and look at what skillsets are actually needed, beyond the model development (which a lot of people peg at just 20-30% of the overall work), we will see that the rest of it is data engineering. And, if we dive a little deeper, at each stage, it is about relatively simpler things like:
• Profiling the data to see if enough data and attributes are available
• Validating whether the data set that is being used is representative enough for the model / hypothesis
• Imputing or extrapolating and generating additional data

IoT project?

Let us move to a different digital implementation – IoT. This is all about huge volumes of data on a continuous basis. Again, a lot of things that we tend to underplay are what happens if there is a connectivity loss, what happens if we get corrupted data within the stream for a certain duration, what happens if there is duplicate data, and so on.

And the super cool Blockchain

Why leave Blockchain out of our discussion? Let’s take a quick look at that too. Beyond the actual SDKs, peer nodes, hashes, and immutability, there are other considerations like how much and what data do I store on the chain, what and where do I store the off-chain data, how do we manage the overall latency, how do I cater to de-duplication, and so on.

See the pattern?

Yes, there will always be specialists who are competent and capable of doing a specific piece of work. But how can the rest of the team rally around them, contribute and make it a successful implementation? While we try and upskill people from a technology standpoint and have them learn Python, Scala, Hyperledger, Spark, etc., there is a re-imagination that needs to be done in terms of their core skills and their contributions.

Let’s look at this through our traditional roles, like a Tester. This is the breed that has been on the automation journey for a while now. They constantly struggle with lack of test data, which kind of forces them to create their own data. Their very job description is about identifying multiple negative scenarios (gap in between data chunks, repeated data, performance) and test. If we can go back and look at what our AI/ML project needs today, there is a clear synergy in terms of leveraging this skillset.

Same is the case with our traditional Business Analyst. Why can’t they be the ones that call out the AI / ML hypothesis or that real Blockchain use case, and work with the developers in helping these see the light of the day?

You don’t have to look beyond our traditional DB developers / ETL Developers. They are the ones that kind of made that transition from ETL tools of the world to Spark, and are now being called Data Engineers!

To close out

Look internally, within the enterprise, at your existing team members. Maybe these are the folks, the knights in shining armor, who will finally help Digital projects launch successfully.
That is probably true re-imagination and re-alignment of our workforce.

And then a bit more…

This is an interesting and the most important aspect to follow-through. We will continue to expand on each role and see how it has and needs to transform in the current digital world. Keep watching this space.