Imposter Syndrome in Tech

Part 3: Issues With Transitions

Written by Catherine Browne and Garth Gilmour

Series Overview

This is the third in a series of four articles outlining the common manifestations of Imposter Syndrome 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.

The first part dealt with relentless change and fear of being ridiculed.

The second covered fearing the career consequences of a break from coding and the fear of simply working less.

In this article we will discuss the self-esteem impacts of your career diverging away from where the industry attaches most prestige.

5) Not Being Excellent At Everything: A ‘Full Stack’ Developer

All professions naturally evolve their own specialities. A doctor might become a surgeon, and then specialise further into heart surgery. A lawyer might move into employment law, and from there focus on cases of unfair dismissal. Once an individual has found their professional niche they usually remain productive in that role for years, or even decades.

In tech the position is more complex. There are certainly many specialties within software engineering. Many more than you might imagine. For example, within Enterprise IT you will find front-end engineers, back-end engineers, testers, product designers, architects, and database folks. Beyond that you have specialists in embedded systems, real-time applications, manufacturing, telecoms, trading platforms, and of course the gaming industry.

But none of these is a safe harbour within which an engineer can limit their focus. Instead engineers are expected to retain a general level of competence and move between specialities as the occasion demands. You wouldn’t find a brain surgeon embarassed to admit they can’t remember how to perform an appendectomy, but you do find cloud computing experts embarassed they can’t build a user interface for their pet project, or remember the algorithms and data structures they learned in college.

Once again Imposter Syndrome rears its ugly head. This is similiar to some of the mechanisms we’ve explored previously. But in this case it’s not about a new platform, a hostile question, or a fear of not being good enough. It’s about gaining depth at the expense of breadth, which leaves you exposed to change. What typically happens to engineers is that, in their current project, they are pigeon-holed into one kind of development. They then face a Catch-22 situation. To succeed in their company they need to continue growing in their current speciality. But the better they become, the harder it is to switch, and the more severe the consequences on their finances and reputation.

In part this is because, as a relatively new profession with shifting boundaries, engineers need to be both specialists and generalists. Here’s a few examples:

• A company may transition projects to teams in other countries, or to a third party software house. Often this is done simply to save costs. Staff then move to whatever opportunities exist.
• Software shops that build systems for other companies typically take whatever work is going. Of course their management try to direct new work down known paths, but frequently an opportunity presented by sales is too tempting to ignore.
• Clients are frequently beguiled by hype rather than logic. An Apple/iOS mobile application may be more appealing than Android, or a Chatbot rather than a Web Application. So engineers have to shift to the New Shiny.
• A company may decide to centralise their cloud support team to one location, and reassign existing local administrators to new responsibilities.
• The keystone employer in one industry (like finance or telecoms) may pack up and leave the area. The ecosystem of subsiduary companies follows, devaluing the specialist skills of engineers from that domain.

The only individuals immune to this variety of Imposter Syndrome are ‘Full Stack Developers’. This mythical being is an archetype, a developer who is able to contribute to any layer of the application, regardless of the technologies and programming languages in use. They are as happy building an Android App as they are designing an Oracle database or deploying new features to the Azure Cloud. Of course this is an unachievable goal, since building and maintaining a Full Stack skill set would require more hours than there are in the day.

From Garth’s Experience

“It’s not unusual to find developers who love a particular kind of development, but are very aware they are trapped in a coding vortex. They know that there is a certain point beyond which they cannot progress, and that when they are asked to perform tasks outside their speciality they regress to the level of a near beginner. You can have senior developers who are greatly respected and highly skilled – but simultaneously filled with concerns about their competence.”

Catherine’s Response

While logically we know we can’t be everything at once, it’s astonishing how often we try. But we are not infinitely elastic in either time, energy or capacity. We have to narrow our focus at some point and saying ‘yes’ to one career path, or role or inevitably means saying ‘no’ to another.

Suffering from Imposter Syndrome can prevent us from recognising when we are driving ourselves to meet unhealthily, or indeed unachievably, high standards. When we relentlessly widen the minimum acceptable feature set that we believe we must offer employers. What is undone, or outside of our current expertise, often looms larger in our minds than what has been achieved, where we are comfortably competent. Even when what we can offer is exceptional in some way.

An extremely common distortion in how we assess our self worth and how we relate to others is known in Cognitive Behavioural Therapy as ‘Compare and Despair’.This is when we see only the positive aspects of other people and only the negatives in ourselves, judging ourselves harshly in contrast.  A trite example is when we feel so much less satisfied with our slightly scruffy selves and our just-about-functioning lives after seeing the agonisingly perfected and well-lit curated content purporting to be somebody’s ‘real life’ on social media. But versions of this exist in any sphere. Feeling bad that you don’t have the coding skill of a superstar colleague two desks away? You won’t be aware what other aspects of their life they may have neglected to earn it.

As I wrote in the previous article, you are not just a coder, you are a whole person. So do take pride in being good at X, learning which has taken the time that could have been devoted to learning Y. Which is why you aren’t so magnificent at Y. X could be emotional intelligence, volunteering, being a good dad; Y could be a programming language.

Imposter Syndrome can also make it really hard to risk what may be seen as exposure as a fraud. Being willing to be a beginner, in a new programming domain, can trigger stress that we will be judged as average, as an amateur, losing all our previously hard won kudos.

However, if it is time to break away from a professionally valuable but personally unrewarding specialism and into a new sphere, be proud of, and kind to, yourself. It can be truly daunting to make that leap but it is also a potential route to morale boosting, and career boosting, renewal and growth.  If it feels like the right thing for you right now (and, for many reasons, it legitimately may not) then congratulate yourself for doing the brave thing that expands your horizons even if you also feel uncertain and apprehensive. Once you’ve shifted gears, allow yourself to be a beginner without ‘shoulds’ blighting your confidence and adding unhelpful pressure to progress unrealistically rapidly. You already have proven your ability to learn and excel so try to be patient with yourself and a new domain will open up.

6) Not Being Excellent At Any Type of Coding: Fear of ‘Ageing Out’

Ageism is a very real problem in software engineering, which is not to deny or ignore the lack of representation in other areas, but ageism seems to be waiting for us all.

Partially this is because software engineering is a rapidly expanding profession, with an influx of graduates every year swelling the ranks and decreasing the average age. But there is also the assumption that coding excellence is a perishable skill requiring intense dedication and therefore time to acquire and your peak period comes in your late twenties or early thirties.

Of course this doesn’t have to be true. Many developers improve over decades as they consciously and continually work to become better coders. But it is a harsh reality that the demands of many projects, combined with the need to self-educate, works against folks as they mature and want to raise families, care for relatives, or pursue hobbies. Basically when they feel the need to spend their evenings living life away from a screen of code.

So, as we mature physically as well as professionally, more generic management skills become a larger part, or the whole part, of our roles. Things like emotional intelligence and the ability to inspire, organise and lead teams become increasingly important. The ability to crank out code correspondingly less so. Instead of recognising this as an essential contribution, without which no large group would achieve anything, there is a perception that this is a loss. That you ‘don’t have it’ any more. You’ve lost your edge.

From Garth’s Experience

“As a professional trainer it’s easy to start feeling very old very quickly. Every year the trainees get younger and more fresh faced. But soon the team leaders and managers are folks you trained 5-10 years previously. It is a positive aspect of the industry that you can be quickly rewarded for effort and dedication. But developers just looking for their day job to pay the bills often find themselves isolated and marginalised.”

Catherine’s Response

Pivoting your career away from coding into broader business skills that are a better match for your real talents can be a conscious choice at any age. I was about 28 when I did it but vocational programmers might naturally be later in life and, thus attract the pejorative ‘ageing out’. The dismissive interpretation that you’re recoiling from where the real action is because you are no longer fit enough and can’t keep up the pace.

In the final article of our series, we’ll be talking about the unhelpful and unmerited glamour that certain career paths in tech attract, and this is a version of that mindset: the assumption that coding is cool and management is boring. But they are both equally necessary: a bunch of coders does not equal an IT company. (When I was working in developing IT consultancy propositions for clients I recall hearing about a superstar salesman bragging that he’d secured our jobs because of the sales he’d brought in. It had not apparently occurred to him that we had secured his job by creating something he could sell.)

But diversifying away from coding is not inevitable either. Even with the demands of outside interests, it can also be a self-limiting belief that those who’ve racked up a few decades can’t choose to learn new platforms and languages and do so just as quickly as those much younger. There is no inevitable decline in memory or cognitive ability in mid-life that would prevent this so if you want to get back to, or stay in coding, you have the right to believe you can succeed in it at any age.

So the IT industry can exert a perpetual downward push on self-worth for some people and that takes conscious self-reinforcement to resist. There’s an inherent bias in favour of coders being young, which nobody is for long, or long enough. The New Shinys continue to emerge at a dizzying pace. That is why investing in a robust sense of yourself as a whole person, including your personal life, as well as a positive mental filter that emphasises what you can do well, rather than what you can’t, are essential kit in your mental health resilience toolbox.

More in the series…

These are just two common manifestations of Imposter Syndrome in tech. Keep reading for our thoughts on the impact when engineers:

• Struggle with fear of ridicule and being unable to cope with the pace of change (part 1)
• Feel unsafe making a career move that will take them away from coding (part 2)
• Have internalised shame for having the ‘wrong’ history with some final thoughts on beating Imposter Syndrome (part 4)

About The Authors