Imposter Syndrome in Tech

Part 1: Never Being Enough

Written by Catherine Browne and Garth Gilmour

Series Overview

Ask a software engineer to name the principal mental health hazard associated with their profession and they will undoubtedly say Imposter Syndrome.  That is, the sense of being only one drop-off away from being revealed as a pretender, a fake and the humiliation that seems to inevitably follow.

Imposter Syndrome identified by a software engineer has a particular expression that people outside of the industry might find hard to grasp but those within find exquisitely palpable. It is used by engineers as an umbrella term, which encompasses a suite of related concerns and afflictions.

What follows is the first in a series of four articles outlining the common manifestations in the world of tech. In each we will give both the software engineer’s perspective, then the psychotherapist’s response with some ways to tackle it, both cognitive and practical. Of course, these articles are only for general interest and anybody really struggling is advised to seek more specific, professional help.

1) Running to Stand Still: The Relentless Pace of Platform Change

The pleasure and pain of being a software engineer is how the industry reinvents itself every 5-10 years. Over the past 50 years we have gone from mainframe apps (aka ‘green screens’) to desktop apps to browser apps to mobile apps to wearables. That’s self-evident even to consumers of IT systems.

But underneath the bonnet there are revolutions within the revolutions. To give two examples:

• The way a developer builds a mobile application for an Android or iPhone device is utterly different from how it was 10 years ago. To the extent of using completely different programming languages.
• The business logic that was once hosted on a company’s own servers now resides in the Cloud. Depending on which cloud platform you use (typically AWS, GCP or Azure) there will be different terminology, architecture and ways of working.

Of course, it is not the case that an established platform becomes outdated overnight. But it can feel like that the evolution is nearly constant as over time we ‘lift and shift’ applications from one platform to another. This progression means the ones that we’re most familiar with become legacy, then archaic, then retired. It can feel like perhaps we’re becoming irrelevant too. Meanwhile the new shiny thing we don’t yet understand has all the glamour.

This continuous evolution within the software industry also creates career opportunities which literally rejuvenates the industry hive-mind. Every time there is a major platform shift, knowledge of existing architectures is devalued giving junior engineers an opportunity to catch up with their elders. This is a good thing for the industry, much tougher for individual engineers.

The Strain on Engineers

As an engineer you have to move with the times, and educate yourself on these new platforms. Sometimes your employer will assist you, sometimes not. It takes a substantial effort to shake yourself out of complacency, especially when you are already working 40 hours a week on applications written in the old platform. We live in fear that if we leave it too late and our skillset is no longer economically viable.

From Garth’s Experience

“As a trainer and consultant for twenty years, the saddest thing I ever had to do was redundancy training. This is where a company is laying off entire teams and/or shutting up shop in a particular area, and staff are being laid off en masse. I was typically asked to go in and retrain the outgoing developers in modern methods, as part of their redundancy package.

It was heartbreaking to work with folks who had been maintaining the same systems for 10-20 years, and whose skills were therefore completely out of date with what contemporary projects required. There seems to be an implicit belief in the industry that you only have so many platform shifts in you. I don’t believe this is inevitable, as there is a certain type of developer who thrives on complexity, challenge and change. But there is definitely an ongoing process of reinvention that can leave any of us behind, if we’re not careful.”

Catherine’s Response

That our emotions are largely outcomes of our beliefs about any aspect of ourselves, other people or the future is a central tenet of Cognitive Behavioural Therapy, one of the most widely used counselling modalities. It asserts that by examining, and challenging, the assumptions which underpin our negative thoughts, we can radically restructure our perspective and create a seismic improvement in our emotional landscape. While some of our ‘core’ beliefs may be so deeply rooted in our subconscious that we need an objective third person, such as a therapist, to help us retrieve them, some will be all too painfully pressing: I’m not good enough; I can’t cope with continually adapting.

But these are just interpretations, not facts: a filtering out of what is going well, what you can do. So to flip away from this negative slant, try to focus on, and produce a list of, your strengths and positive qualities. Writing these down is important to make them feel more factual than they would as ideas in your head. Aim for at least 25. This seems like a huge number but we’re trying to move the dial in your self-concept and a handful won’t do that. We’re looking for overwhelming evidence that you can, and do, actually have resources and capability.

Now find all-career and in-the-last-quarter examples of your behaviour or achievements that demonstrate these qualities, particularly your successful learning, adaptation and delivery. Asking trusted people you work with for feedback will inevitably give you many more examples than you can think of yourself. Keep this list close and read it often so that, over time, your strengths become more prominent in your consciousness and increase your confidence in your resilience: that you can adapt to changing challenges, that you are good enough.

Finally, in practical terms, little-and-often learning habits, with regular horizon-scanning to understand how the industry is evolving, will probably serve you better than handbrake-turns when your current skills start to run out of road. This will take a slice of your available capacity in any given week or month but knowing you are planning for the future will go some way to helping you feel like you’re responding to change rather than reacting to it.

2) The Enemy in The Audience: Fear of Being Ridiculed

The relentless pace of change creates pervasive paranoia and insecurity. It is very hard, especially near the start of your career, to feel robustly competent. Someone out to belittle you (and one-upmanship in tech often takes this form) only needs to be 1% smarter or know 1% more to put you on the defensive which is an insecure place to be.

It’s easy to ambush and fluster someone in a meeting or conference talk, by pushing them onto unfamiliar ground. Senior engineers and speakers know how to handle this, but it’s a considerable worry for junior developers and first time speakers.

From Garth’s Experience

“When I started coaching and presenting I spent huge amounts of time going over all my code examples and comments. I knew there would always be at least one person in the audience who would want to argue every aspect of the syntax and every decision in the design. I had seen it happen many times to other educators and didn’t want to be caught out.”

Catherine’s Response

This is a tough one but you need to be on your own side and recognise that a troll is going to be a troll and try not to take an obvious attempt to undermine you personally. At best they’re an unhappy individual poor at reading the room, at worst they’re an out-and-out bully that you may need to take action against. If you suspect such a person is poised on the edge of their seat waiting with a zinger, then practice a dignified deflection to get yourself back on comfortable territory.

However, a question may be genuine and sincerely intended but you just can’t answer it. Everybody has finite knowledge. Everybody has those days when their brain goes dead and all the relevant points seem to escape out of our ears just as they would have been useful in a response. Again, try not to take this personally, as a failing in you. Offer to come back to the enquirer later, and move on.

Next in the series…

These are just two common manifestations of Imposter Syndrome in tech. The upcoming parts of this series will be published at weekly week and will discuss the problems that arise when engineers:

• Feel unsafe making a career move that will take them away from coding (part 2)
• Worry their skills are neither specialist enough to be exceptional nor general enough to be transferable (part 3)
• Have internalised shame for having the ‘wrong’ career or educational history (part 4)

We hope you find them helpful!

---

About The Authors