My name is Alex Kreig, Head of Data Science at Numerator, and I have a secret to tell you: most of the time I feel like I don’t know enough. While “enough” is admittedly an arbitrary measure of competency, the chasm between what I think I’m capable of and what I regularly do inhibits my professional self-worth. Those who have experienced this know it can feel debilitating at times. I am lucky to be surrounded by some of the brightest individuals in the data science industry on a daily basis, and value the opportunities I have to learn from and contribute amongst them. That said, I still regularly encounter feelings of self-doubt. “Simple” daily responsibilities like submitting a pull request for review, discussing ML architecture, or suggesting a statistical approach, can feel like they carry career-derailing consequences if done “wrong”. In previous roles, these thoughts have escalated to the point where I would briefly convince myself I needed to find a new job before someone “found me out”. Since joining the workforce, I’ve periodically worried that my peers, team, or clients would call my bluff and label me as an impostor. Fortuitous experiences throughout my career have afforded me opportunities to build a strong network of mentors along the way, for which I am forever grateful. This group has helped me develop tactics for successfully mitigating effects of my Impostor Syndrome (IS) and leverage its foundational attributes as a positive force.
I was drawn to moving my career to Numerator due to the privilege of getting to lead the integration of federated Data Scientists and Machine Learning into a single functional group (Also, not going to gloss over the fact that Numerator data is some of the most interesting I have come across). Coupled with the expanding internal mandate of leveraging DS/ML across the whole organization, the team is growing and moving fast. (Yes, you should read that as we are hiring, check here for more information). While an environment like this is extremely exciting, my personal experience and, more importantly, countless research studies, highlight that this type of environmental combination is ripe for inducing IS. Recognizing that not everyone has had the same experiences navigating IS, we are embedding IS mitigation behavior in the team’s foundational DNA. By enforcing an intentional team culture, Numerator is striving to eradicate some of the IS challenges uniquely imposed on those in the DS field. Like any good data science team, we are systematically breaking down IS:
Why it’s a problem
At Numerator, we are continuously working on solving hard problems that require all manners of perspective. Not only are we tackling cutting-edge problems, but problems that have never been seen before in our industry which represent entirely new factions of thought. Unfortunately, the combination of new and difficult problems often correlate with feelings of inadequacy (IS) amongst the most ambitious troops of thinkers that work on them. While IS can elicit some positive ancillary effects like drive, curiosity, and ambition--all of which are important to impacting cutting-edge fields like data science (DS)--its adverse consequences can cause major problems. The fear of being “found out” imposes undue caution over how people work. In this way, IS effectively mutes people, preventing them from taking the necessary exploratory steps and risks to solve a never-before encountered challenge. IS becomes an obstruction to innovation, ultimately forming a tangible roadblock to progress. It can personally harm the individual, impeding confidence and realization of potential, which inevitably harms the progress made by the team and larger org. I’ve considered it my fiducial responsibility to the company to mitigate IS within my org. Thus, one of my first personal responsibilities at Numerator was to create an environment where we identify and mitigate any controllable sources of IS within my team.
Identify the unique DS/ML IS triggers
The first step toward assuaging IS effects is pinpointing the scenarios that provoke it. While there is arguably an indeterminate number of IS-inducing factors, I’ve summarized the most common IS triggers I’ve observed in the DS/ML arena below.
DS/ML is ambiguous
It is not uncommon for IS to surface in those entrenched in rapidly changing, highly competitive fields like data science (DS). A simple Google search for the terms “DS,” “ML,” or “AI” rapidly reveals that no one has universally defined each area, nor has the industry markedly defined the distinctions between them. The vast ambiguity that DS imposes simply by nature of being a pioneering field, can often invoke rampant IS in the high-achieving individuals who contribute to the space.
The field attracts some of the most intelligent, driven people in the world
I have had the privilege of working with a spectrum of individuals from 20-year veterans who’ve practiced DS long before the label existed, to freshly minted graduates who worked with the academics driving the next big breakthrough. In all cases, I have yet to sit down with a peer, regardless of tenure, and not identify an entire topic area in which he or she is an expert, and in which I can barely scratch the surface. In a forecastable fashion, experiences like this have repeatedly invoked my IS. I’ve also observed others dwelling on what they perceive as newly surfaced shortcomings after similar encounters. But the truth is, those feelings are normal, and more importantly, they don’t have to be bad. Being surrounded by others who are more skilled in one school of thought--while sometimes artificially calling your own expertise into question--can inspire more curiosity and drive collective progress. DS is an active field; it’s going to feel like every week something potentially groundbreaking can happen.
High-stakes environments are par for the course
The dynamic nature of DS technology requires frequent engagement amongst those that contribute to it. Whether it be a conference, tech meetup, or client pitch, DS’s are faced with frequent opportunities to share their work. Often times these high-stakes venues can induce IS on the spot. In DS, we are trained to be extremely critical of our work and are regularly required to discuss its shortcomings in public environments. While this criticality can generate new advancements when well-managed, it can also trigger spiralling behavior of acting as your own judge, jury, and executioner. Naturally, this is counterproductive for the individual, and restricts collective progress.
Invoke a multifaceted approach
Because IS can manifest in so many different ways, we don’t expect any single broad strokes effort to eliminate the problem. At Numerator, we aim to curb its effects with ongoing, multi-modal tactics that are best positioned to outlast the recurring symptoms of IS.
Establish what success looks like
Recognizing that ambiguity in technical domains can diminish confidence and consequently augment IS symptoms, clearly establishing what success in your field means has become increasingly important. At Numerator, we strive to maintain clearly defined expectations of roles (known internally as our DS IC Career Ladder). Our career ladder offers a concise list of direct technology requirements. The career ladder succinctly outlines the skills that enable strong data scientists and machine learning engineers. Technology will inevitably change, and the DS field will continue to look different, but we believe that the traits highlighted in the ladder represent calcified requirements for success in the field. Institutionalizing a unified path to progress may help provide a consistent benchmark upon which our dedicated teams can honestly and objectively track their contributions.
Emphasize execution, learning, and then knowledge
A common misnomer that I’ve observed is that bulletproof domain knowledge should precede--or even replace--the raw, iterative process of technology development. But the fear of “not knowing” that sometimes accompanies IS doesn’t have to permeate the workplace. Innovation is predicated on continuous experimentation, collecting learnings along the way. At Numerator, we care about efficient execution first, followed by a clearly displayed affinity to learn, and, finally, expansive knowledge. We frequently acknowledge amongst the teams that a fast, simple solution (which may likely require further revision) is to be praised.
Establish a publicly known “competence litmus test”
We take hiring seriously. Yes, we want to find great people to work with us, but an adjacent goal is to establish a foundational asset that can not be questioned. Our interview is unquestionably open-ended and challenging. This can sometimes feel intimidating, but executing on the tasks--regardless of your chosen approach--signals that you are talented, and you are qualified. We aim to actively acknowledge this amongst the team, and especially amongst new-hires. While your IS may manufacture a belief that you just fooled a large panel, you didn’t.
Normalize mistakes and eliminate failures
As you may have read in a previous post, our environment at Numerator is accepting of mistakes. To a certain extent, we blatantly invite them. And that’s because we vehemently believe that mistakes make us better, faster. I find this to be particularly true in the wildly-dynamic field of DS. No one knows all the answers in a field that is evolving so rapidly, and any answers that exist today will become antiquated in a short matter of time. My promise to the team is that mistakes will not cascade into project failures. Our leadership attributes any team failures directly to its leadership. To help sustain these values, we’ve constructed the following guide rails to mitigate project shortcomings: early, evaluative exercises with end users to scope projects prior to initiation; definition of early project exits if success criteria are not feasible; and reserved DS seat at the Product team table.
Creating and Maintaining the Right Environment
Numerator’s focus on difficult, nuanced problems forces everyone to push their own and the company’s boundaries. This often leads our team to the intersection of product and engineering orgs. This only works due to the creation of an environment where anyone can communicate frankly, openly, and without fear of reprisal. Previous first hand experience has highlighted that it only takes one person to bring down a purposefully manicured Data Science culture, thus we protect it vigorously. Simply put, the smartest person in the world would not be welcome on our team if he or she was quick to spot the shortcomings of others without being able to recognize their own. That kind of elitism mentality kills open communication and learning, and would destroy the environment we have purposely built. Please don't interpret this as you will not not be challenged by your peers; you certainly will. That said, you can count on challenges raised respectfully, with good intentions, and via the appropriate venue.
Managing IS is an ongoing effort. And, speaking from experience, there's no single recipe that will universally defend against the symptoms it brings with it. However, with some effort and the right environment, IS doesn't have to antagonize you at work. At Numerator, we recognize the value of a collaborative culture that both encourages teams to stretch their limits, and supports them when bringing new ideas forward. The highly-dynamic DS industry demands an efficient use of resources to solve its most revolutionary problems, and the diverse, sustainable workforce to drive it. We constantly strive to uphold that standard at Numerator, and are actively growing our team. If you're interested in learning more about opportunities to work on cutting-edge DS problems in a highly-supportive environment, please visit our careers page. In the right environment, we can harness the positivity embedded in IS--the relentless drive and dedication that sets us up to achieve great things.