Imposter Syndrome and Senior Engineers

Having been on the journey of software engineering a couple of years (10+) now, you reach a point where you take on more responsibilities as an Individual Contributor (IC) and your team starts looking up to you for answers especially for problems that others cannot find a solution to. This puts you in a spot where you start feeling that you cannot make any mistakes lest they don't consider you an expert anymore. Sometimes your team mates find novel solutions to problems that you feel you could have never come up with, no matter how hard you try, making you wonder deep down if you are really qualified to help the team get to the next level. You also find yourself doing Google foo to find answers to questions about programming that should have come to you naturally a few years ago but now you are not too sure.

If you have been through the above as a senior engineer, then let me assure you that there are others out there who are on the same boat including me(!) who go through the same emotions / disbelief in one's abilities from time to time. Going through these feelings is not a sign of weakness but a confirmation about increased self-awareness. Letting the feeling ride through without taking an action is one way to deal with this but that does not stop it from happening again nor lower the intensity of the experience.

What I have instead found useful is to dig deeper a bit and find the trigger that caused this experience. This can be a tricky process as you may not immediately be able to remember what happened but as you revisit the experiences as part of your daily mindfulness routine or mental breaks during the day, you would be more aware of the details. This is a very personal experience for everyone and so the triggers will differ from person-to-person.

The technology landscape is changing quite rapidly with newer tools and platforms cropping up pretty much every week. It is very hard to be on top of everything all the time. New technologies are good for water cooler talk but unless you understand the basics, what may be a novel idea would distill into something quite simple on a closer look. I always stress the importance of getting to know your tools better as they help you to be more productive and open up avenues to write better code that is readable, performant and maintainable.

The common trait that I have seen with software engineers is that they prefer to bury themselves in code and nuances of how software should be developed and thus lose sight of why the software is being built in the first place. In my early years, I had trouble trying to understand the big picture as they call it, of how the work I am doing is going to impact people (clients). This was not to lack of empathy but rather not being familiar with the business domain that I was building the software for. Being able to understand and correlate the high level goal when building software goes a long way in managing expectations about how fast things can be shipped that would be useful immediately to users rather than hiding them behind an alpha release. Having early and actionable feedback is very useful for engineers to make data driven tradeoffs on how the software should be built thus aligning to the growth efforts of the organization.

Lastly, let me mention the very important aspect of psychological safety. To be able to bring your whole self to work and not be criticised for your ideas and questions, is missing in a lot of workplaces. A healthy flow of ideas opens up opportunities for cross collaboration thus improving camaraderie and encouraging failures early on so that engineers take risks without reproach. Failing fast is much better in terms of time and money rather than much later on. If you are missing this environment at work, please start conversations to bring about this change as it helps to expand your overall experience as an engineer in person skills that goes a long way in having an excellent career in technology!