Almost everyone I have talked to who works or has worked in the tech industry has experienced some form of imposter syndrome. It is an industry filled with bravado, inside jokes, and niche knowledge that also thrives on throwing people into roles they don’t necessarily feel qualified for and hoping they will learn as they go.
On engineering and development teams I think it is especially difficult to escape imposter syndrome — new engineering jobs almost always require learning new technical skills and each new team has its own culture around best practices and processes. You have to be willing to adapt and ask lots of questions.
Unfortunately, more often than not, after a short period of time on your new team it can feel like your questions are wasting people’s time and that really you should know these things by now. As you become less of the new kid, you become terrified of making mistakes and revealing your ignorance to co-workers. The mild feelings of imposter syndrome you feel at the very beginning can deepen over time on engineering teams that do not actively promote a culture of constant learning and a safe space for asking questions, no matter how new (or not new) you are.
Engineering teams that can foster a culture of constant learning and growing have the best chance of lessening imposter syndrome on their team and making everyone feel welcome. Creating a “good culture” is a very abstract concept, but there are key moments when a team can take actions to learn and grow together.
Learning from mistakes
When mistakes inevitably happen or something doesn’t go according to plan, that is the moment you find out what kind of (engineering) team you are really on. Do individuals get blamed? Processes? Or does your company mostly ignore failures until all of a sudden there are people leaving for unexplained reasons?
When things go wrong, teams can and should take a moment to reflect (see the section on postmortems for how). It is a chance to talk openly as a group, address questions and concerns, and discuss steps that the team or individuals can take to make sure similar mistakes do not happen again.
Looking at mistakes as opportunities to learn and grow as a team is sometimes difficult, but so important in creating a culture of trust. I have been part of teams that do not openly discuss failures and this can make imposter syndrome and the general stress of an engineering job much worse. Without transparency it can feel like everything you do is high stakes because you have no idea what will happen if you mess up. In the mind of someone suffering imposter syndrome, a mistake seems likely to be devastating.
My Current Team (Desmos)
The engineering team at Desmos is one of the best I have ever seen. Everyone is individually talented and brilliant, but more importantly we are transparent about mistakes and open with our questions.
Like every other job I have had in tech, when I first joined the engineering team at Desmos there were a whole pile of things that made me feel like I didn’t quite belong — I hadn’t written code for production software in over a year, I was the only woman on the team, I had never been on an engineering team that cared about testing before, and so much more.
Desmos hired me to both design and build UI for the site, so I had to get used to the idea of being an engineer again and learn as much as possible as quickly as possible. I asked a lot of questions when I first started and everyone I worked with was welcoming and encouraging, but still at the back of my mind I felt imposter syndrome pulling me down.
Then we had our first engineering team postmortem.
When things go wrong at Desmos we spend some time in our weekly engineering meeting reflecting and discussing what went wrong in a process we call a postmortem. I don’t remember when the first postmortem was — we have had many in my two years here — but I do remember that it changed how I thought of our engineering team and my job. I remember being really struck by how open and honest the other engineers were about mistakes they made. The most senior people on the team would lead these postmortems saying things like “I did … and it caused …” and instead of focusing on how the individual had made a mistake, the meeting centered around what everyone could do to help prevent it in the future. It was an open and respectful conversation that greatly reduced my anxiety about making mistakes or talking about them with the broader team. We talked about and learned how to be better engineers together, and I felt less and less like an imposter with every one of these discussions.
I wanted to share that process with the world in hopes that some team out there, engineering or otherwise, can use this to learn and grow and reduce some of the anxieties individuals on the team may be feeling.
How to Have a Respectful Postmortem
The first step to help your team have these discussions is to explicitly set expectations that whenever something goes wrong at a large enough scale (e.g. site downtime) the team will talk about it. Emphasize that this is an opportunity to learn and not something to be feared.
When we do postmortems the process starts with the people who have the most knowledge about whatever happened. Note that we always phrase it like that — it’s not the people who “caused the problem” who start the discussion, instead it is whoever has the most information to bring to the table. It is important to try as much as possible to have a blameless postmortem.
Going around the room, the people with the most knowledge discuss:
- The timeline of events, especially who knew what and when
- Technology and processes used to identify the problem
- How the problem was eventually fixed
- What could have gone better in steps 1–3
In the process of discussing these facts, we also implement a form of the 5 Whys in trying to get to the root cause of the problem. For example, in the timeline discussion we can ask: “Why did it take so long to be notified of the issue?” and “Why is our monitoring system set up in that way?”, digging deeper with each question. Everyone is merely human, we all make mistakes, and as such it’s our responsibility as a team to help people avoid them.
This discussion gives everyone on the team a clear understanding of what happened and allows everyone to contribute to the next part of the postmortem: What could we change to prevent this in the future?
Some simple examples of engineering changes we have made:
- Changing monitoring so that warning signs don’t slip through the cracks.
- Figuring out who should be notified first when specific things like this occur.
- Improving how quickly we communicate with our partners during a service outage.
- Changing our deployment processes so that the person who wrote the code is always the one monitoring the deployment of that code.
All of these changes have improved our processes and communication. The postmortem allows us to reflect on current procedures with honesty, thinking about what is working well for us and what has not been working. Our structured process of finding the root cause of issues also emphasizes the fact that we are all human, we all make mistakes, and it is our responsibility as a team to help people avoid them.
Being open to change, respectful of each other’s suggestions, and as blameless as possible when it comes to mistakes can help immensely with feelings of imposter syndrome.
Respectful postmortems are just one concrete way of creating a great culture where everyone feels like their questions are heard and mistakes aren’t the end of the world, a culture that can be hard to find in engineering teams in Silicon Valley. I am lucky to be on a team at Desmos that understands this and has taught me through example that you can learn and grow as a team when mistakes happen. Hopefully this post will be helpful to other engineering teams out there who are working through how to best handle mistakes and learn from them.