I have dealt with impostor syndrome quite a bit over my career. I have seen other engineers struggle with impostor syndrome. I have also seen engineers who were actually impostors who did not last long in their roles. I no longer have impostor syndrome and am embracing my success in the tech industry. These are the key learnings I came out of this experience with.

Cause #1: The Research Intensive Nature of Engineering Work

A large part of productivity in software is not doing work where you already know what you are doing. In fact, most of my best work has been on projects I entered with a knowledge deficit. I do not accomplish as much if I go in knowing the entire tech stack already, if nothing challenges me to learn while I work.

If you look around any office where people are working with code and infrastructure, the struggling engineers are probably generally working within their comfort zone on the niche they know best, and the rockstars are probably regularly working on things that they have not worked with before and don't really know. However, I have seen managers try to mitigate the productivity loss of struggling engineers by keeping them in their comfort zone and coaching them in their niche. These are the same people who think their rockstars simply know everything. They don't realize that their best engineer is actually just good at learning new things productively, building as they research. This is because research is a large part of engineering work.

Since the work is research heavy, the good engineer is often feeling like they are scraping by, barely piecing together solutions constantly researching answers to questions that come up along the way. That is what it feels like to be the rockstar in my experience. It feels like faking it, almost like pretending to be an engineer who actually knows everything. This goes away with embracing the constant research as part of the productive work - and those who do will be much more productive than anyone stubbornly relying on their own knowledge in this field.

Cause #2: Trying to Work in Ways That Always Fail

Impostor syndrome can come from a mismatch between how productivity works versus how engineers are being told by leaders it should work. The tech industry has managers who want continuous heads-down work all day every business day. However, there is a wealth of scientific research on human productivity contradicting the claim that we get more work done from exerting continuous effort. We are actually more productive taking breaks throughout the day.

When I have a document to write at work, my strategy typically involves braindumping onto a page, then taking a break preferably walking, then coming back and organizing my thoughts properly. I even used that method to write this article. I would not write as well if I tried to stubbornly brute force the effort. Why would I brute force the effort? Because some men who have never accomplished anything screamed at me about productivity being the same as constant overworking?

Many tech offices have a culture of equating time worked to productivity. For instance, the first office I worked at often put us on overtime to complete features. Code that was shipped was worse than anyone wants to imagine. I also witnessed entire quarters go by where almost all engineer work was bug fixes patching the work from past marathons. There were many blatant cases where features would have been delivered months earlier had just a few days been used for planning. The productivity of sleep deprived overworked engineers was abysmal if even existent with everything failing manual testing.

A culture of long hours produces a culture of impostor syndrome, because people try to brute force productivity with sheer work, and they always fail, which makes them feel like they aren't real engineers if they blame themselves rather than the blameworthy company. Scientifically, all humans have diminishing returns from intellectual labor. We absolutely do not accomplish twice as much in 80 hours a week as we do in 40, or twice as much in 40 as we do in 20. In fact, we don't even get more done in 40 hours a week as we do in 32 hours.

I personally lost a lot of my impostor syndrome just by embracing the ways the human brain has been scientifically verified to work and paying attention to my body and my energy. I am not offended or upset by myself needing a break after focusing for 60 or 90 minutes. I am not comparing myself to a straw man that management made that has never existed in any tech company ever. The work we do in this industry is intellectual, mentally draining work, and we have to work with the reality of the operating systems our brains run on.

Cause #3: Being There, But Not Being In

This is more nebulous cause of impostor syndrome, that I found more challenging to put my finger on even while I was feeling it. In every office I have worked in, in some ways, I have felt like I do not really belong there, or do not really fit in. This can come from not fitting into established social groups, for instance I did not understand any of the sports betting conversations happening at my first office. It is also come from being the only member of a group, like how I always manage to be the only queer representation in the vicinity. This became especially brutal for me when nobody in the office around me knew the name Alice that I went by outside of work. Maybe I will write in detail about that experience before I die.

Feeling a distinct lack of belonging can easily lead to feelings of being fake, or somehow mistakenly there. Maybe the brain is trying to grasp straws at ways to logically justify the lack of belonging, or to find a fair solution to an otherwise unfair circumstance.

Consequence #1: Anxiety Even From Praise

Fear leads to inaction, which leads to isolation, and ultimately suffering. Most anxiety in a workplace comes from engineers being socially anxious in general, and people being overly afraid to make mistakes or potentially say something incorrect. The anxiety that comes from impostor syndrome is similar to other forms of anxiety that come up in a workplace, like general social anxiety. I think it can be distinguished because impostor syndrome anxiety comes not just from making mistakes, or being afraid of making mistakes, but it even comes from praise. Even positive feedback and success becomes a source of anxiety with the feeling of being somehow at risk of having that success retracted when they are found out to be faking it.

Consequence #2: Missing Opportunities

Over time, anxiety is not just impacting the mental game of engineers, it is lowering the ceiling above their heads. They are now missing opportunities to move within a company, or to another company, to other better opportunities. It takes a lot of sheer luck, not just effort, for anyone to develop their career while they worry about faking it. This is because few opportunities fall on people's laps - that does happen - but usually a solid foundation of confidence and drive is required to reach opportunities. Anxiety from success makes it difficult to capitalize on success to grow and snowball into greater success. This is because stagnating looks like a safer option than it really is, and growth looks more dangerous than it really is.

Consequence #3: Burnout

Long term additional sources of anxiety on top of already demanding work will eventually cause perpetual burnout that is challenging to break out of. When my first job burned me out badly enough, mostly from mandatory overtime and weekends, I had to leave that company to recover. When AWS burned me out during my third year there, mosly due to being closeted while transitioning, I had do burn my PTO just to keep myself going longer. Even with no additional stress, this is a career so demanding that I see coworkers handing their children to other caretakers so they can handle working at AWS. A few people around me quit just because full return to office was an additional layer of stress for them beyond what they could handle. One does not simply add more stress to this work. Anxiety from impostor syndrome is simply unafforadble in this economy.

Leadership Lesson #1: Psychological Safety

The most important lessons about impostor syndrome I have learned are really about tackling it in the workplace as a leader. I now have experience coaching struggling engineers at AWS who dealt with social anxiety, lack of confidence, impostor syndrome, and paralyzing fear of failure. Nobody gets anything worth talking about accomplished when the percieved potential consequences of failure, rejection, or being found out as a fraud, outweigh percieved benefits of success. Everyone at the office is rational enough to act how they believe produces the best expected result. Something is wrong when they are not performing, probably psychologically, and probably caused unknowingly by others, especially leadership.

An important point here is to understand how innovation is produced. New groundbreaking solutions to unsolved problems do not come from one person. Maybe one person writes the initial proposal, but there is often several rounds of iteration from feedback and bouncing ideas off others and taking in suggestions. Generally multiple people with different perspectives and backgrounds have to look at the same problem from different angles and bounce their ideas off of each other. In this process, a lot of stupid shit gets said. That is, a lot of bad ideas get thrown out, most of which die quickly to counterarguments, but some of which turn out to actually be good ideas. Those good ideas starting as bad ideas that sounded like stupid things to say. Now, understanding how this works, how productive is it to have engineers who are afraid to vocalize stupid ideas because they are afraid of repurcussions?

By default as a leader in a workplace, you are creating an atmosphere that includes judgement and competitiveness, since leaders will be evaluating the performance of others around them, especially relative to each other. Without trying to foster psychological safety, I suspect the default anywhere is a decisive lack thereof rather than a middle ground. I believe this is why AWS insists on trying to have an inclusive culture. I say trying because I believe results are varried, but I have seen at least some managers going to great lengths to foster this, and from what I have directly seen it reflected as a positive on their performance reviews. This probably came from early days of AWS where teams doing this performed better by orders of magnitude than teams that didn't, I'm betting twenty times the productivity conservatively since AWS is constantly trying to solve some of the most challenging novel problems in the field. In order to bring up the less productive teams, they have to get their innovation engine running, which requires psychological safety to be built up, and that required writing the methods of doing this into the company culture. Leaders have to be conscious about this, or they may not even understand why they are failing.

Leadership Lesson #2: Value Delivering Results, Thinking Big

One thing I appreciate about the culture at AWS is the conscious intention of focusing on the results people delivered. Even if you are eccentric, and proposed some outlandish things that failed, and made some embarassing mistakes, you can still get a decidedly positive performance review from having delivered a significant amount of measurable business value. This creates incentives for builders and leaders to do whatever works rather than sticking to old processes and cultures. This is much more productive than judging people based on gut feeling without diving into that data, which incentivizes looking productive and befriending managers. My experience at my first office was a breeding ground for issues like impostor syndrome because of the incoherent ways people were evaluated.

The idea of "thinking big" is another aspect of AWS culture I want to shout out here. I have seen this encourage experimentation, proposing overly ambitious or potentially stupid ideas, and being an explicitly called out silver lining to failures. Fostering a culture that actively tries to think big takes away from the anxiety around bringing forward ideas that might fail. In contrast, I have seen office culture that rewards people who put it sheer hours to resolve a large number of small tasks, ignoring all the untested code they shipped causing more tasks later, while also punishing mistakes and failed proposals. Not only is this counterproductive to business goals, it fills the office with impostor syndrome since people develop warped ideas of what a real good engineer is and nobody achieves that. In fact, effort gets spent intentionally pretending to be that to look good. That effort could be going to delivering results.

Real Impostors

I have seen two real impostors in my career. Both of them were terminated soon after being hired. One of them gave me valuable life advice and free sushi.

The first impostor I saw liked me for whatever reason and talked to me quite a bit. He came from years of experience working as the only developer who developed some sort of desktop-based application. He claimed to have been paid well and to have overestimated effort to the point of having a low workload. He did not know anything about the tech stack we were working with, any of the coding languages we used, or network architecture in general. He told me about feedback he recieved regarding his inability to accomplish anything like what was expected from him, but he was quite relaxed about it, and explained that his wife made enough income. However, he also believed in his competence, at least within his expertise, and even proposed switching to a desktop-based solution. I believe he was terminated within a month, it happened so fast, and nobody was surprised, although he probably thought he had not been given a fair chance.

The second impostor I saw was younger, probably fresh out of college, although I do not remember clearly. What I do remember clearly was his struggling with basic HTML and CSS, and his argument that we should not be using Javascript because C++ has much better syntax. Every code change he made was written by other people helping him. It was so blatant, it felt like the whole office knew he was a genuine impostor. Discussions about mentoring him were depressing. I was there to see him get terminated unceremoniously on a Friday morning. He was the only one surprised.

These experiences, however awkward and random, showed me how vastly different real impostors are from engineers who simply feel like impostors. One thing both of these people had in common was not believing they were impostors. They both believed in their skills and ideas even if everyone around them could hardly believe the lack of skill on display. They acted nothing like people with impostor syndrome at all. They were not receiving positive feedback.

Some sort of conclusion so you don't find out I'm a fake writer

Feeling like I do not actually have enough skill at writing slowed down my writing. That was not a productive feeling. I need to be okay with posting whatever nonsense others have the misfortune of reading in order to rise up to being a good writer. The worst case scenario is that I learn. It is also undeniable that I am writing, even if it most of my writing is AWS confidential, which means I am actually a writer even if I am convinced that I am just an engineer who is trying to write.