Background

Machine Learning and AI are being infused into more software products than before in 2022, and there is, without a doubt, a lot of momentum around the language models, and generative machine learning for text, images, music and many other kinds of data. There is a distinct difference between the useful search, AI, ML and data algorithms being used for most use cases, and the cutting edge of advanced ML as it were, and this means there are upsides for new adopters of the more advanced models. Along with these opportunities come many risks and challenges of using ML systems or subsystems in software products. This post is an endeavor to discuss and cover some of the ground in the space of building machine learning products in general.

A New Landscape of User Needs for AI Products

The Basic Needs: Full Product and an Inviting User Experience

How does one characterize broadly the needs of the users of AI products in 2022? While it is clear that the AI product landscape is evolving and changing, some things do remain common, constant needs. A full fledged product is a requirement. Any AI product team should at the very least be able to deliver a user-facing component and other components, and have the ability to deliver and maintain the application on a frequent basis. What this means for the tech team building and developing the product, is that you need a contemporary application in the form of a service, with a front-end and a back-end to deliver the underlying software product to the end user. The nature of the consumption may change and evolve, leading to a stronger characterization of the end user interactions and requirements. However, this need to have a product end-to-end hasn’t gone away, and can’t be expected to.

Another important need in AI product development as of 2022, is to imagine the user’s experience fully and use this to drive the development process. What constitutes value for the end user, and how will AI or data capabilities deliver this? How are they inclined to obtain this value through your app or product, and what interactions would make sense in this context? Some of these fundamental questions, and some of the common guidelines on building responsive interfaces can help build a compelling experience for end-users.

Although this may not be evident to AI and Data teams at first, the user requirements and the interactions we design for them tend to drive strongly how and what we build in terms of data and AI value in the core of the product.

Evolving AI-centric Needs

Customers and end-users are more aware in 2022 than before about data and data security, the impact of good and big data on models. The tech-aware consumer’s footprint continues to grow, and many tech-aware consumers will be early adopters of AI-centric products and tools. Such end users are likely to evaluate and gauge the quality of the models they consume from the product. They may also demand transparency into how their data is used, and would want to be abreast of how regulations and standards are being followed and observed by the AI products they use. Many users are also likely to ask how the results they receive as part of a product ought to be interpreted, and why certain kinds of results are produced at certain times by their product.

This changing set of requirements has made necessary the need to build more trustworthy AI. This is a broad objective which perhaps encompasses a few different sets of capabilities:

1. Good datasets used to build the machine learning or AI models in question
2. Meaningful and regulation-adherent ways handling of user data in a manner that is transparent to the end-user and aligned with regulation
3. Explainable results from AI models, which implies the ability to interpret the results (inferences) from machine learning models

Let’s break these down even further.

Data quality and Data Management

Outcomes in machine learning and data science are heavily dependent on the quality of the data used to perform statistical inference, or analysis leading up to model training and deployment. If we’re unable to understand the data in question, we’re unable to be effective in building machine learning and data science models effectively. This may sound simple, but is hard to put into practice. Data collection can become a messy process, especially in processes that don’t have rigorous measurement processes defined. Measurement system analysis, a common enough set of approaches in traditional industries such as manufacturing, or in engineering processes, tend to not be well-established for industries such as technology where data from people, processes and business systems is hard to instrument and hard to measure. KPIs may in some cases be tangible – in industries such as logistics, e-commerce and other domains – but even in these cases, there may be substantial ambiguity in how the data are stratified, how they’re counted and measured, and what the implications of variability are for measurement systems.

Another related consideration is how the data is handled and managed – especially where the data concerns the end-user. Some user data needs to be stored and managed to provide a good experience to users, but where does one draw the line? Additionally, how do the data that get stored, get managed over long periods of time? It is good to have a plan in place as a product team way before the product iterations begin, and certainly well before any release of the product.

Explainable results for end users

There is greater user awareness in 2022 than ever before about the importance of being able to explain the results of AI/ML models. To the end user, these considerations may come up as specific product features, because machine learning systems are being implemented in code as software product features. For example, a loan application app, job-candidate matching app, may invite a certain kinds of scrutiny from end users. The end user may ask, “why did X get matched to a certain job while I didn’t?”, or “why is the interest rate on my loan so high despite the prevalent rates for such loans in my area?”. Many users of social networking applications have asked what is being done with their data – we’ve seen broad and strong debate on this topic as well. Especially where machine learning models are used in a user and recommendations context, we invite such questions. Over the few years that I’ve followed this topic, my own understanding of the space of explainable AI has been challenged by Zach Lipton’s paper on model interpretability, which has invited this recent rejoinder on the communications of the ACM.

The practical experiences I have had indicate a preference on the part of end-users to have case based explanations for the interpretability of the results of their entire product. The reasons for this are two-fold, a) the specific context of the end-user and the data they submit is paramount in importance to the inference or result in question, and b) Even if the model’s explainability can be understood by treating the model alone a black box, there are many business rules and validations that are implied in the process of model deployment.

Implications for Data Scientists, Engineers, Architects and Product Managers

The modern data scientist, data engineer and ML engineer tend to be much more cross functional than before, requiring awareness and the ability to implement models of different kinds, and take some of the more complex models to production. In my observation, some of the common tasks have become a lot easier because of improved tooling and the availability of high-level frameworks for implementing some of these more advanced features.

Data Science and ML Model Development Implications

ML model training, development and iteration is commonly understood process in 2022 at the software and code level, but the questions around whether we have used good data or merely big data still remain. There should be more questions asked around what the business problem is, what the data and hypotheses are, and what models to build. It is easy to train models, but hard to undo the results of bad models once deployed especially in production. The availability of powerful frameworks and tools makes life better for those who can carefully think through, hypothesize and execute their model training process in more deliberate ways. This is the differentiating factor in 2022 between teams of data scientists that merely train models, and teams that are able to deliver truly differentiated value to end-users, based on soundly constructed hypotheses. Exploratory data analysis never gets old – it is always important to check assumptions, understand the underlying statistical properties of the data we use, and go back even further to where and how the data was collected, and how it needs to be processed. The availability of foundational models has created a gulf between teams building narrow AI at scale (like an AI/ML startup that may be building a product for processing invoices), teams building specialized narrow AI (like the teams building Alpha Fold or Google’s or Meta’s billion-parameter model teams), and teams researching broad AI (like the teams researching reinforcement learning like with Gato). The achievements of teams that are building narrow AI in highly specialized areas is quite staggering. Teams building more boring AI for routine, run-of-the-mill use cases in banks, telecom companies or manufacturing firms are likely to be doing equally impactful, if less glamorous work, and often have the same hierarchy of needs such as good data, assumptions checking and a rigorous process to train and validate models before deployment. The truth of the matter is that in 2022, not all AI model problem statements are equal – you can get outsize impact for the AI models you’re building if you’re building the right model for the right industry.

Data and ML Engineering Implications

Data and ML engineering in 2022 is a more sorted landscape than it was a few years ago. The changing user needs described above do have implications on how data and ML engineers execute their work. Data engineers are familiar now with tools to prepare, automate and implement data workflows such as ETL and ELT. All big cloud providers have such capabilities baked into their respective ecosystems as well. The focus has probably shifted today in data engineering to the careful management and versioning of datasets required for training machine learning models. Additionally, Data governance, data profiling and quality are the important talking points today, and rightly so, because the mere transfer of data from some source into your data lake doesn’t constitute business value anymore. In some cases, that may even mean the addition of cost and effort for business teams who have to manage, maintain and interpret this data.

On the ML engineering front, there are many opportunities and challenges for engineers who need to build applications which scale. Kubernetes and scalable deployments of endpoints have become common, but the complexity of managing distributed systems like Kubernetes, and doing so with a significant-sized DevOps effort involving infrastructure-as-code is a learning curve for most organizations. Managed services for handling Kubernetes deployments are helpful. There is an evolving discussion on the security of ML APIs that transcends common considerations around APIs such as HTTPS endpoints, or the tradeoff between synchronous and asynchronous endpoints.

While often not discussed, the QA function has become more important in data science than ever before, at least in my experience. It has always been important to write well-tested code, arguably, and the time for doing so and doing so well is now, as far as AI products are concerned. Not only is there a need for data science and ML engineering teams to have good strategies to test their code and ensure good coverage, but there is a strong need for user-focused testing and end-user testing.

Implications for Data and AI Architects

From an architecture perspective, there is certainly a trend towards event-driven systems in the machine learning product landscape. Using event-based architectures centered on technologies like Kafka or other message queues simplifies some of the orchestration around product workflows, and better enables on-demand provisioning and use of resources, in a cost-effective manner. I personally think that architectural decisions need to be made more deliberately and more frequently. The use of event-based architectures can simplify some of the workflows around user data, model inference and logging and observability, which are all parallel considerations alongside the changing user needs discussed above, such as data quality, model explainability, and so on. I recollect an insight from an earlier job when Terraform and infrastructure-as-code were gaining ground in the telecommunications AI space, that it is possible to rearchitect systems more frequently with IaC. This is perhaps an important insight for Data/AI product teams in 2022 on the architecture front – that it is possible and often necessary to iterate often even at the architecture level, as we build up from the basic product needs to more advanced and nuanced needs of end-users.

Implications for Product Managers

Product Managers in AI have a harder time in 2022, compared to earlier years, because of the dual pronged effect of greater regulation and evolving and changing user requirements from AI products. The landscape of the product features has shifted to more pragmatic performance needs, and feature prioritization seems to follow this trend. If there’s one piece of advice I have for product managers in 2022, it is to understand the capabilities and limitations of the underlying technologies behind data and AI systems. Most product managers are not technical and don’t understand the hierarchy of needs ranging from data, models and engineering to DevOps and MLOps as well. These are important for PMs to grok in 2022 and beyond if they’re to be effective at planning and delivering world class AI products.

There are implications for profitability from AI applications and products from these new and changing needs. As AI infused products are built more often and served up to end users, the bottom line is going to be influenced by the architecture and the optimizations of the product, while the top-line is going to be influenced by the scale of the product. Product managers will have to gauge user needs and build products to the appropriate scale for the phase of the product that’s being built – this is crucial, because the developmental costs of AI/data models and products is significant, and there’s a leverage that comes with these, which if used well can help build significant product impact.

Concluding Remarks

We’ve discussed both the evolving and new sets of requirements from end-users of AI products as of 2022, and the implications this has for different sets of stakeholders. From a product envisioning and development perspective, these changes surely imply a maturation of the needs of the market for AI and data infused products. From an inchoate market with aspirational ideas on making data, AI and machine learning work for end-users even just a few years ago, we see a greater tendency in AI product teams to want to build on-point and focused products for end-customers. More product teams are building end-to-end software applications which infuse AI/data capabilities in specific features or as a core feature, but this has come with implications for the end user, who is now more aware and more demanding than before. The resulting challenge for product managers is to characterize these changing needs of the product and incorporate such needs into their product plan. For engineers, this means building new kinds of value in the form of data and model provenance. For data scientists, it means prioritizing good data rather than merely big data.

In the 1950s, Isaac Asimov imagined a world where robots lived and worked in human society, and in one of his short science fiction stories, he discusses the travails and tribulations of a robot “Cal“, who serves a human writer, and “wishes” to be a writer himself, after Cal discovers that he cannot be considered helpful for performing his master’s work – writing. This heartwarming and profound story is a benign example of the future previous generations imagined (perhaps erroneously although charmingly enough).

An Asymptote to the Asimovian Atelier

In recent years, developments in AI and Machine Learning techniques have encompassed generative modeling and algorithms used to generate art, to send control signals to self-driving vehicles to correct themselves on the highway, or to generate music and text for artists and writers alike. There have been forays into AI-based authoring, AI-based composition of music, and AI-based writing of novels. While these algorithms are incipient in their scope and capability, some generative algorithms such as GPT-3 show huge promise. Some years ago in 2016, I was part of a session conducted by Google’s Tensorflow team where we performed simple style transfer tasks using deep learning on convolutional neural networks. The advanced algorithms we have access to in 2020 make these tasks quite trivial and the current state of research makes the possibility of even more advanced algorithms acute. A good technical summary of how to build some of these algorithms – including the DCGANs and CycleGANs that have become so popular is the book embedded below. There is lots of literature for the technically minded and Github has scores of repositories on the subject of generative AI, not to mention other kinds of AI models.

Despite this creeping progress that AI researchers today are making towards the world imagined by Isaac Asimov several decades ago, certain key elements of AI and its impact on our society are likely to be up for discussion and debate well into future decades.

The problem of accountability and blame (or credit) assignment in AI systems is one of these important ongoing discussions, and it promises to upend some of our existing notions about how people and human and natural systems function. We are guaranteed to peer more into the underlying chain of causation in AI-based systems and the cause effect chains that arise due to their interactions with human society at large – in all spheres from science and medicine to engineering and technology, to art and creativity.

Yes, but is it art?

This discussion promises to shine new light on agency, free will, decision making and other aspects of societal functioning. Starting with relatively innocuous questions such as the one posed in this fantastic paper – “Who gets credit for AI generated art?”, which is a discussion on Edmond De Belamy. Additionally, it serves as a broader swath of exploration veritably covering our mental models of what reasonable causes and effects are, what phenomena can be considered indivisible or black boxes, and what the meaning and extent of human agency is, – all these will be explored. Let’s start with the obvious – how our media (and by extension most of society) see artificial intelligence – this is the example of the art discussed in the aforementioned paper.

Operational Domains, System Definitions and Moral Crumple Zones

To understand some elements of how AI based systems can be handled in society, we need (but may not necessarily get) the following:

1. Acceptable boundaries and a definition of what constitutes an AI agent’s field of operation (domain)
2. A range of effects and first order characteristics of such effects that are a direct consequence of the agent’s action
3. An understanding of how second, third and higher order effects may be ascribed to the agent, or to broader systems at play.

In addition to the above, a clear operational definition or description of the AI system in question is important in any discussions that ascribe blame or credit to the system in question. We will see how this is important in a further section of the post.

At the outset, it may seem as though a self-driving car that has killed a person may deserve blame, or its manufacturer may be liable to legal action. It may seem that the person using the DGCAN algorithm in the aforementioned link on AI generated art would be liable to collect the proceeds from the sale of art produced by the algorithm. It may also seem as though the external environment plays no tangible role in the outcomes of the AI systems, since they are “AI systems” after all.

However, things get much more complex when we start looking at the details of such real-world interactions. The acceptable boundaries of an AI agent’s field of operation are not always well defined. For instance, would a self-driving car be to blame, if there was an unexpected event (such as a human-caused accident, or an oil tanker spill) on the road ahead, and because of a limitation of the system, the system flies out of control in this environment, and ends up killing its occupants? Would the creator of the DCGAN algorithm have to be penalized in case the art doesn’t fetch some anticipated price at an auction? One of these questions may sound more serious and the other more innocuous than the other, but in fact, they both tie back to the same boundaries and domain of operation we discussed earlier, and what we accept as the first order effects or characteristics of an AI agent, and what we don’t.

One could group the ambiguities around disproportionate responses by human systems to the results of AI systems, as “moral crumple zones”. Indeed, in the context of the human interaction with the natural world (because the two domains of beasts and men intersect there), we could term these “ecological crumple zones” – where human interest in extracting value of a specific kind from natural systems makes us amenable to cause widespread and disproportionate imbalances in the world – as can be seen in over-fishing or over-whaling, the hunting of animals to extinction and the destruction of the rainforests. In the context of the AI-human interaction question, moral crumple zones (as defined by Epstein et al) constitutes disproportionate responses directed at one facet of an AI system due to agony caused to a human or a group of humans due to an AI’s action.

Our task then, is to reduce the span of these “moral crumple zones” – and a key to this is the operational definition of the AI system mentioned above. This isn’t necessarily a direct or even useful answer to the dilemma posed by the art sale or the self-driving car’s blame assignment problem, but does take us in that general direction.

A Submarine by Any Other Name: Narrow and Broad AI

It is helpful sometimes to think of agents in natural systems in terms of synthetic equivalents, although this may be a form of shoehorning their relevance, value and significance. For instance, one could call a fish, “a natural submersible agent” – although this may capture an aspect of the fish, i.e., its locomotion, it doesn’t necessarily do justice to the role of the fish in the context of the broader ecosystem, as an organism that’s part of the grand natural dance and as a complex organism in its own right, given to a physiological homeostasis of its own. In the same way, we could refer to birds and aircraft as analogues in the natural and synthetic spheres, and although you could argue that both are “evolved” (one by nature, another by the human hand), it is clear that the same limitations of the analogy as discussed earlier apply to this situation too.

Clearly, anthromorphic AI is a long way off. Whatever stories the media spin around us about the coming strong AI, or the fact that “An AI beat Lee Sedol at the Game of Go“, it remains that these are engineered systems, and are not to be confused with agents with human level intelligence. Surely, much of this AI hyperbole exists despite qualifications to the contrary, because it is a sign of our times to ascribe undue credit or undue intelligence to things that are not especially intelligent of their own accord. A DCGAN algorithm, for instance, consists of a generator neural network, and a discriminator neural network which are trained in lock-step in alternative training cycles, seeking to create a generator which just barely manages to fox the discriminator in a generation task. This doesn’t constitute broad intelligence.

Broad AI, in the words of Gary Marcus, is a phenomenon that is the converse of the narrow AI capabilities we have begun to see in the world today – essentially, narrow AI like the DCGAN alluded to above, or the deep learning network that guides a self-driving car, are simplistic, purpose-built decision making systems, which have come to be conflated with the capability of a human over time. Lee Sedol lost to a reinforcement learning model – I’ll admit this is a model of significant complexity, but it is a model nevertheless, and not a full fledged intelligent agent in any sense other than in the narrow domain. While Lee Sedol retains the ability to gaze at the stars, wonder, appreciate art and a good cup of tea, and still pontificate on the ramifications of move #37 made by Alpha Go, Alpha Go itself remains a narrow construct, excellent at taking decisions in a specific domain and a specific context, with no clue of how to solve broader problems in human society.

The broader point here, then, is the fact that anthropomorphicity in terminology used to describe AI can be a hurdle to truly understanding what the AI system is doing in the first place. Just as a submarine and a fish aren’t one and the same thing. Even though they use the principles of hydrodynamics for accomplishing locomotion tasks, one of these is a machine with a limited specification set and clearly defined system and operational parameters, while the other is a complex, evolving lifeform with broad influence and ramifications for the ecosystem it inhabits. The moral crumple zone for an evolving lifeform is different than that for an anthropomorphic robot. The moral crumple zone for the fish is likely to be smaller, and that for the AI agent is likely to be larger, especially if used as a tool by sophisticated creatures such as human beings. The latter is likely (given the nature of progress we’re making in AI systems) to be of far more influence and may wield much more power than the former, which is playing a part in a whole harmoniously and will either be predator or prey in a vast ecological chain of cause and effect. The cyclical nature of the ecological homeostasis of the lifeform lends to itself a termination point, whereas artificial intelligence agents may not function in the same way, and may have much more longevity and influence, especially given that they are tools and ultimately are human means to a human end.

AGI and Alexander the God: A Shift in Agency

It isn’t unfair to suggest, in light of this discussion on narrow and broad AI, that an artificial general intelligence (AGI) may be subject to far more scrutiny than are the narrow intelligence of today. I posit that there is a shift in the agency of a system that extends broadly enough, to the point that while initially, an individual or team may have been culpable for the undesirable side effects of the system (such as blaming the lack of seat belts in a car to a specific individual upon failure of the car to secure a passenger), to a systemic problem that expands to include the whole system itself (a great example of this being the fraudulent, stupid and self-serving financial system that gave us the sub-prime crisis in the late 2000s).

The agency of a narrow AI system can more or less be easily understood and matters of legal and scientific dispute may thereby be more clearly elucidated, than in the case of a broad AI or a general intelligence. In the latter case, we essentially have parts of a whole to blame for different effects on the boundaries of the competence of the system

Another of Asimov’s sci-fi short stories discusses a young protagonist who sets out to become rich by predicting the stock market, and successfully pulls this off by getting his computer to learn how the stock market from the news, the associated changes in the stock market and is able to tailor his trades to world events and phenomena, leaving him a very rich man. This story, like many others in science fiction is saddled with the twin paradox of technical debt and innovation in a vacuum, not to mention the efficient market hypothesis – had Alexander been able to do even a fraction of what is claimed in the story, he would have run up against a wall by doing so himself, compared to if he were “standing on the shoulders of giants who came before him”. In this sense, Alexander’s project in the Asimov story may be likened to a vast, multi-generational capitalist project in a never-ending free market economy (which in turn sounds less and less realistic given the vagaries of the world economy over time, the more I think about it). Such a project would, in all likelihood have expanded its scope from merely a profit engine, to becoming one capable of influencing the world, because after a point, the shortest path to the goal of maximizing rewards would involve direct intervention. Somewhere along this trajectory, Alexander’s AI would stop being narrow AI, and start becoming a more general intelligence. So, if a rainforest disappeared last week due to Alexander’s AI’s need to deforest it for preferentially ticking the stocks up, would you blame that on the profit maximization rule built into the AI, or would you blame it on the greed of the humans who benefit from Alexander’s AI? At this scale, we all realize (as the legislators will) that the AI is a means to an end.

Coming back to the problem of ascribing credit and blame – the story in question is quintessential in how the media and the non-technical world at large see AI – as a looming, foreboding influence in the present that will enable large scale income inequality and that would somehow summon demons out of the fabric of reality. In fact, I’m not ashamed to use the hyperbole here since Stephen Hawking himself ended up using a similar metaphor. The reality, of course, is that we really have a number of narrow AI systems that are interacting with the broader human-created systems such as in trade or industry, which can have an outsize effect on how we interact with the world. How does one characterize agency in this situation? Narrow AI systems may have a specification, but can a broader system with multiple specialization areas (and by extension multiple domains, multiple interaction points with society, greater complexity and lesser interpretability) be considered an agent in its own right for legal and social / cultural / scientific purposes? The moral crumple zones in these broad AIs will also tend to have bigger moral crumple zones – so does that give society the responsibility to treat these AIs as they would treat, say, an air hostess who has to apologize on behalf of the airline to the customer, or a customer service agent who has to take the blame for a product? If yes, does the idea of humaneness become relevant in this context, and what does that entail?

Ascribing credit and blame in case of the widespread use of narrow AI in complex human systems is probably as complex if not more complex as the broader and hitherto unseen problem of legislating an artificial general intelligence.

Concluding Remarks

Credit and blame assignment in AI systems – like speculation and wonder – are innate to human responses to and characterization of phenomena, systems and forces that are beyond our full grasp, but which we perceive to be simpler to understand than they often are. And this isn’t necessarily a bad thing, but an indication of how we think. Short of upending everything we understand and know about agency and pulling us into an infinite regress of causality (“The whataboutery could indeed go all the way back to the Big Bang,” said he humorously), we can devise practical ways and means of characterizing the domains and scope of AI systems and plan for progress. This includes healthy discussions about the scope and limits of algorithms, the kinds of situations in which they may be used (and their due regulation, such as in warfare – including cyberwarfare), and keeping the human stakeholders of these systems informed in advance of the risks of using both narrow AI systems today and broader AI systems in the future. Without planning for progress in AI systems in this manner, we’re likely to inherit a future in which the admixture of human societal systems and AI capabilities will leave us befuddled as a society that cannot maximize outcomes for individuals because of the fact that it has to carry on in a manner that is convenient to the clueless bulk of society, or at the very least, to architects of the mess that it has become.

References

• Rebooting AI, by Gary Marcus: http://rebooting.ai/
• DCGAN – paper by Radford et al https://www.paperswithcode.com/method/dcgan
• CycleGAN – paper by Zhu et al https://paperswithcode.com/method/cyclegan
• The Alpha Go documentary https://www.youtube.com/watch?v=WXuK6gekU1Y
• Alpha Go article on Wired https://www.wired.com/2016/03/two-moves-alphago-lee-sedol-redefined-future/
• Really Awesome GAN by @nightrome on Github: https://github.com/nightrome/really-awesome-gan
• Who Gets Credit for AI-Generated Art? by Ziv Epstein, Sydney Levine, David G. Rand, Iyad Rahwan, iScience 2020

Further reading

• AI Ethics by Mike Coeckelbergh https://mitpress.mit.edu/books/ai-ethics
• Ethics of AI on Stanford Encyclopaedia of Philosophy https://plato.stanford.edu/entries/ethics-ai/
• US DOD AI Ethics https://www.defense.gov/Explore/News/Article/Article/2094085/dod-adopts-5-principles-of-artificial-intelligence-ethics/
• MIT – Ethics and Governance of AI https://www.media.mit.edu/groups/ethics-and-governance/overview/
• Microsoft – Responsible AI https://www.microsoft.com/en-us/ai/responsible-ai

It was common in the Data/AI circles to discuss or lament about the skills gap in the market for candidates, around 2015-16. This hasn’t changed in five years, inasmuch as recruiters and hiring managers still have these lamentations when asked about the hiring scene. The challenge is real for organizations, but I also believe that there are multiple reasons for this to be a subject of discussion half a decade down the line.

Perceptions and Reality

Hiring managers in large firms that want to jump start their data and AI projects after having missed the early adopter window in the early 2010s, may come to the realization that the talent pool has since been flooded with candidates – not with the quality promised by the pace of research – but with quality indicative of education and certification opportunities out there. Education in AI has its share of problems – from an emphasis on tools rather than principles, to a lack of focus on business value and operationalization, it doesn’t foster the kind of mindset often required for scalable, enterprise grade data science and AI solution development.

Education in AI also prepares incumbents for roles in research/academia and also industry, and this two-pronged objective rarely yields benefits for recruiters. A greater focus on applied AI/ML has certain disadvantages as well, since it can lead to a lack of depth. There is no silver bullet, but perhaps one approach here is to build multiple levels of skill and provide opportunities to back-fill talent into roles gradually, and build progression as a consequence.

It is also true that AI/ML lateral hires tend to be expensive to hire, especially if they have real world production scale AI/ML experience. This makes the challenge even more acute for those looking to hire, who are on a budget. Upskilling existing employees is obviously the best long term solution. For startups, attracting talent who have an upside in terms of being able to grow into advanced AI/ML roles for niche products, may be an attractive selling strategy – and even if the said startup won’t help them build deep skill in AI, it could give them a shot at success in being part of an AI product journey.

Writing effective and meaningful job descriptions and controlling the hiring and evaluation process well is the key here – without meaningful job descriptions and with ludicrous titles, it is easy to get on a slippery slope.

Overall, whether hiring from university graduate pools, or in the lateral hiring market, recruiters and hiring managers have to manage perceptions and reality for AI hiring.

Inability to Understand the Fast-Changing AI Landscape

The AI landscape changes almost on a daily basis, with ground-breaking research published almost each week. In 2020 alone, we have seen significant new research, the highlight of which has been GPT-3. In earlier years, we reached very high levels of performance in language translation tasks, and significant breakthroughs in generative modeling such as GANs. We are now seeing significant new work in reinforcement learning that promises to make agent based models easier to build and train. Despite being an industry professional and leader in the AI and ML space who’s constantly learning and upskilling, new research can even be hard for professionals like me to keep up with. This is the gap between the research world in AI and practitioners such as myself.

There is another even more worrying gap in understanding – and that is the gap between the practitioners and the managers or recruiters. Managers and recruiters who don’t understand the fundamentals of AI and machine learning, and who aren’t clued into the fast-changing AI landscape will be at a disadvantage when trying to hire good talent.

With lateral hires, the challenge is more nuanced. When bringing onboard data science candidates with prior experience, one needs to look out for a vast range of skills and capabilities that need to match with the organization’s current state and needs. There’s the additional challenge of ensuring that the lateral hire candidates are contemporary and able to solve or at the very least, reason about complex and new problems.

Impostor Syndrome and Gatekeeping

The flip side of Steve Jobs’ quote, of course is that someone would choose not to hire a smart person at all – because they may be too smart, or too capable.

Impostor syndrome (and its close cousin, the Dunning-Kruger effect) is widely seen in the AI practitioner world – where those new to the space who nevertheless have credentials in building AI solutions or products find themselves falling short of expectations because of the sheer complexity of real-world requirements on the one hand, and because of an inability to retain or sustain the knowledge they have earned credentials for. This sends a signal about their competence which is contrary to their actual skill in a subject. Naturally, this leads to problems in executing on the job for those suffering from impostor syndrome. Ultimately, I believe this stems from an attitude of credentialism (to borrow a phrase from entrepreneur and investor Balaji Srinivasan) – that earning a credential will get you to a destination – rather than a genuine interest in AI and a curiosity and open mind that enables the development of new skill and capability.

Gate-keeping in the AI/ML world is a consequence of Impostor Syndrome, and it is essentially the prevention of good talent from joining an organization in the hiring process, due to the insecurity felt by less-skilled incumbent employees who fear replacement by new, higher skilled employees. This is not new to organizations or unique to the AI/ML hiring space. In areas like data science and AI/ML hiring, it is plausible that hiring managers with limited understanding of a subject may fall prey to gate-keeping. After all, power-poisoning as is seen in a lot of management positions is a strong enabler of mono-cultures and also gate-keeping. Power poisoning is a natural impulse for anyone in management who wants to keep their jobs, especially in a time of rapid change. One way to ensure this doesn’t become a slippery slope, is to build a culture of recognition and reward those who invest time in learning new skills to stay relevant on the job. Another way for leaders to make all feel welcome is to ensure that those on the job are constantly challenged, because this is one way in which additional bandwidth can be justified, and consequently one can justify new roles, positions and new hires to fill these positions.

Concluding Remarks

I hope this discussion on the AI Skills Gap and the implications for AI jobs and hiring provided interesting and important insights from the frontlines in AI and ML. If you’ve faced challenges like this, whether from bosses or hiring managers who experience impostor syndrome, or from recruiters who don’t understand the landscape for AI/ML hiring, you’re likely to resonate with a lot of the ideas here. As with all things in leadership and management, there’s rarely ever one good answer. However, constantly scanning the AI landscape and being clued into the patterns and trends can help build great AI teams and sustainable Data and AI organizations, be it i product development, research, or consulting.

Given the current Covid-19 crisis that has led to massive disruptions to how we work, communicate and collaborate, there is an understandable interest in being able to do data science work remotely and effectively. In a sense, this capability has been brewing in the background, because the data science talent crunch experienced for several years before data science skill sets went mainstream, was an opportunity for companies to hire talent around the world, and work remotely.

Despite this, there have been challenges in building excellent remotely managed teams in all technology sectors, including data science and AI- and ML-centric teams. For one thing, remote work is fraught with asynchronous work, meetings and the need for over-communication. Another aspect of remote work is the need for interpersonal interactions and relationship-building between peers and team members. These are undeniable aspects of what makes remote work in itself challenging – sometimes, phone calls are not enough, and video calls done professionally and effectively require discipline and commitment on behalf of the participants. All asynchronous collaboration requires goal-orientation and timeliness in the execution of tasks. These are, of course expectations that you may have from ideal employees and team members. Based on the working style and approach of different individuals, you may have very different reactions from your team members to the same ground rules.

Making Remote Data Science Teams Effective

I can think of some ways in which we can enable better interactions and more productive data science teams across locations, time zones and in complex data science projects:

1. Knowing your team members well. This piece of advice is not about data science, it is about just being a good team player or leader. There is no substitute for actually building great interpersonal relationships. Humans are not robots – professionals are people and are driven by meaning, reason and have motivations of many kinds, both personal and professional. All of us have challenges when listening and taking feedback that requires us to change, whether we’re leading or contributing. Some of us may have quirks and oddities that make us interesting in some ways and annoying in other ways. There are some good ways to build such relationships in remote ways.
   1. Don’t skip the small talk. Ask about how they are doing when you start a video or audio call. A little small talk never goes to waste, especially at the beginning of a meeting. In these times where people may have vastly different levels of well being, whether because of being affected by Covid-19, or otherwise being impacted because of it, it never hurts to ask.
   2. Empathize and make your team feel wanted and welcome. Ensure you empathize with them in case they come out and say that they’re having a tough time. It doesn’t help to be the “strong and silent” kind of individual when the person at the other end is communicating difficulties that they’re having. Video and audio calls require us to overcommunicate.
   3. Understand your team members’ habits and quirks. Share a joke or two, and understand how your team responds. Determine what makes them tick, and what kind of work assignments interest them.
2. Setting ground rules and “team level agreements”. One of the biggest enablers of productivity in data science teams is knowing what tasks are meant for who. In real world data science teams, things may not be clear-cut, when it comes to the broad span of tasks that data science team members need to do. Ground rules ease the situation and collaborative tools enable this to happen well. Tools like Teams or Slack are great at building contextual conversations. However, you can lose sight of the bigger picture here, because you’re following along multiple threads under a specific topic. What helps here is setting up Wikis, and doing effective stand up calls.
   1. Wikis and how they can help: Team wikis help by consolidating the key information in one place. They’re great for teams who have been working a certain way in an office setting and have had to transition to remote teams, sometimes with new team members. They can provide a nice, section-wise summary of key tasks and elements of the work stream or the job in question. In the context of data science teams, Wikis can help in the following ways: a) by being project documentation, b) by instructing on specific tasks – be this environment set up for a Python task, or PEP 8 guidelines, class hierarchy for an application, a list of hypotheses to explore in statistical analysis, etc., or c) by being a repository of tribal knowledge about the solution you’re building. Wikis can be created by using documentation tools like Read The Docs, or even by Wiki servers. Where Wikis are too much work to do, simple documents (Google / Word / Confluence) can help. On Confluence, you can attract comments as well, and this can make things easier in some ways.
   2. Stand up calls and doing these effectively. Stand up meetings (typically these are 15 or 20 minutes long) are a great way to start the day and gain some momentum with respect to the features and solutions you’re building. They shouldn’t be long drawn out, but should just focus on the key accomplishments and blockers. Add in a little sugar – use video and do a nice, positive team ritual. Ensure that you do round-robin updates, because this makes sure everyone is involved. When doing data science, you may get updates on how a certain analysis went, or whether new findings were made with respect to some data, or whether a model training step failed or succeeded in some way. All of these are useful points of exploration and problem solving for the day ahead. These initial discussions in the day can be the source of a new synergy – if you are a leader, you generally respond to some of these, or perhaps you bring ideas from the previous day to share and guide the team in a specific way. If you’re a contributor, you’re likely to make key notes of things that happened during your work day and share them in the next day’s stand up call.
3. Few meetings, but effective meetings. Having spent time in big corporate and in startups, I see a tendency on the part of managers and employees who come from large organizations to gravitate towards meetings to solve problems. The reality is that meetings are rarely effective in and of themselves, and better consensus can be built asynchronously in written communication that can be read, absorbed, digested and then responded to. Something to keep in mind in remote teams:
   1. Data scientists and engineers need to write well. They should be able to articulate thoughts, ideas and complex constructs well, and should be able to respond with the appropriate amount of detail. Without this ability to think critically and express themselves in written form, the organization becomes meeting-driven, and can descend into chaos when these meetings sap team energy
   2. Meetings should have clear outcomes. These outcomes should be decided at least five minutes before the end of the meeting. The agendas for meetings need to be clear before the start of the meeting, which isn’t often enough the case. Finally, the results of the meeting should be circulated over Teams/Slack/Email with clear expectations on the part of those involved.
4. Remote-sourcing domain expertise. The availability of team members from across the world is a potential benefit from having fully remote teams that companies haven’t fully realized the benefits of yet. If you’re doing data science in the energy sector, for example, you may be interested in building a team with occasional input from an energy sector domain expert you may not have had access to before, because more people have opened up to consulting remotely. Such domain expertise is especially important in building effective teams across borders that understand the domain well enough to be effective as a data science delivery team in a specific industry. Technology, statistical analysis and communication skills together cannot solve a problem that also requires domain knowledge to solve, and this can be done effectively by sourcing such talent or expertise remotely.
5. Working effectively without borders requires planning and effective documentation. Working across time zones can be hard at times – when we work in synchrony, communication can be easier. However, asynchronous communication and work will become increasingly important in the age of Covid-19 and beyond, as more and more teams become remote and distributed. Working remotely doesn’t equate to being flexible time-wise, but being effective with your tasks. For example, you may be on a call at 9pm with your team that’s in a different time zone, and are retiring for the day soon after – this situation calls for planning your upcoming day and tasks well enough for you to be effective at solving those problems in front of you. This may be a challenge for those with small children and families, but there are probably ways to work around it all. The solution is not stretching long into the night to complete that task. This probably impedes personal health, productivity and other aspects of well-being, both personal and professional. Effective asynchronous work requires good planning and documentation.
6. Leading across borders requires planning, patience and understanding. When you have team members in other time zones and are delegating tasks to them, you probably have to curb the enthusiasm to do things yourself, or to delegate to someone closer to home – this risks isolating those who work in remote time zones. If you find yourself doing this, consider that you may need to rethink how you are structuring your project and tasks.
7. Pair programming and digital mentoring can be really effective. When your team members are trying to develop new skills and don’t have anyone to turn to for help, they can benefit greatly from pair programming sessions and digital mentoring. These are not new practices, and there are platforms available to do this across teams – but what’s important is to have regular communication to sort issues out as they happen, and help people correct course as soon as they need to do so. Pair programming enables specific and contextual feedback. Whether statistical analysis or application development, data science mentoring done remotely can be a big enabler of growth and technical accomplishment.
8. Managing work environments well. Work environments here doesn’t only refer to the physical environments, such as the work from home setup we each may use, but also the digital environment, which enables us to find the required information at the right time, or which enables us to construct new workflows as we need them. This extends to code and the virtual environments we code in. When we’re building continuous delivery pipelines that provide the required environment for running and testing code, we are enabling such a need. The tools are half the reason that highly effective teams are as effective as they are.
9. “Gitting Good” – managing asynchronous data science work effectively. Managing an asynchronously updated code base requires your team to adopt and work well, with the right ground rules, on specific development branches of your code repository. A lot of product development firms have nailed the process of managing code on git or other version control systems well, and indeed this applies to many data science teams as well, but this is as much a matter of individual and collective discipline as it is about systems and processes and Wiki pages. Sometimes, we need hard conversations to happen to bring teams on track – and in the context of code discipline, I have seen a fair few situations of this nature.
10. Taking time to document (and to “RTFD”). Documentation is one of the more tedious tasks for most developers, and it can be a chore for data scientists as well. Good data science teams, however, build their solutions on top of excellent documentation, where key questions are answered and many elements of their problem solving approaches are documented well, where required with links to papers, journals and results as appropriate. In cases where novel algorithms are written these should not only be put together in modular and reusable ways, but also documented well, so that the solution is intelligible to the broader team and to clients. As important as writing the documentation, is reading it. When new team members come in, or people change assignments on a project, it is important to keep the documentation relevant and ongoing.

Concluding Remarks

Naturally, all of these behaviors don’t happen all at once and aren’t developed in a day – excellence takes time, persistence and diligence. There are many teams out there that are doing lots of incredible work, and fully remotely, in the data science space. I hope that some of the above ideas make sense to your team and that if nothing else, this post made you think about how your team’s currently performing and how to amp up your team’s performance!