I’ve been a software developer professionally for four years now. My journey hasn’t been an easy one. I struggled during my time as a computer science undergrad; I thought many times about quitting. My mental health problems wreaked havoc on my concentration, memory, and learning abilities.
My intention for sharing my story here is to show you how I leverage my weaknesses for the greater good. Suffering is an inherent part of life so I hope my personal story will be relevant for many.
My Junior Developer Years
I joined my current position as a software developer at Nulogy immediately after I finished my undergraduate degree in December of 2013. I was ecstatic to join a team that valued collaboration and software craftsmanship. However, given how much I struggled in undergrad with learning, I was worried about ramping up on our supply chain domain and software technologies. I was right. It turned out to be challenging.
For the first couple of years I tried my best to hide my learning difficulties. At times I felt like an imposter. On the days when I’d stare at the screen and nothing would make sense, I would have thoughts like: “Maybe I’ve just fooled everyone into thinking I’m smart.”
I wanted to contribute to my team’s outcomes but during my mental health flare ups I would be ineffective. I’d feel like I was letting everyone down. I just wanted to have a conversation about what I was going through so that I could hear my team say, “Don’t worry Shah. Everything is okay. You don’t have to suffer alone.” I needed their empathy but since these conversations were in my head, I wasn’t getting any. Through their empathy I imagined I would get their support. I needed their support so that together we could come up with experiments to help me cope with my challenges and continue to learn because ultimately:
I felt significant discomfort because my teammates are compassionate and friendly yet I couldn’t muster the courage to be transparent. This discomfort kept me preoccupied and the resulting psychological impact significantly reduced my performance. Here is a visualization of what I mean:
Importance of Bringing My Whole Self
Last year, Nulogy started a 1-on-1 developer coaching program. I was assigned to Jason as my coach (though everyone calls him Chunky). In one of our first sessions, I confessed I was struggling to come clean with my team about my learning challenges. That I didn’t know how to communicate when I felt ineffective or to reach for their support. Chunky explained to me that I was having difficulty bringing my whole self to work as a consequence of not feeling enough psychological safety. I asked “How do I know if there is enough psychological safety?” He replied, “You get to decide how much psychological safety there is.”
I wanted to contribute more to my team’s outcomes. To do that, I needed to experiment freely with my team without fear of failure. Especially experiments with things that I felt shame about, like my mental health. To experiment freely without shame, I needed to have candid, honest, and transparent conversations which meant bringing my whole self. All my strengths. All my weaknesses. And, as Chunky explained, that meant I had to establish psychological safety because:
So Chunky and I set a goal to help me bring my whole self and started experimenting with ways to increase my experience of psychological safety.
Exposing My Ignorance
My first successful experiment was one morning before our team’s daily standup meeting. I was with my developer teammates, who I respect highly for their technical skills, when I asked them:
“Is there anything you feel the team depends on you to do but you can’t do and feel stupid as a result? What makes you feel like an idiot? What makes you feel dumb?”
I couldn’t imagine what would make them feel dumb, since they were some of the sharpest developers I’ve worked with. But their answers that morning, I will never forget. They told me candidly how they felt inadequate at whiteboard-based collaboration or feared on-call support requests. Their openness created a deeper bond between us.
I didn’t want to just tell them it was a safe place to feel inadequate or dumb. I wanted to show them that it was. So I decided to Expose My Ignorance by writing a list of things that made me feel dumb. Then I put it up in a location where everyone on the team could see. It was scary as hell every time I walked by and looked at that list! It was up there for the whole world to see.
Brené Brown, an esteemed psychology research professor at the University of Houston, says vulnerability is uncertainty, risk, and emotional exposure. Through exposing my ignorance, I was being vulnerable with my team. And by putting myself out there, I demonstrated to others it was safe. I contributed to the psychological safety of the team. This is the defining moment when I understood the connection between vulnerability and psychological safety:
Empowered with this newfound insight, I started being more vulnerable with my team and creating opportunities for everyone to do so as well. Over the next few months, my team actually put aside work for me that would help me Confront My Ignorance that I listed in the photo above. During planning meetings, we’d openly talk about which gaps were the highest priority for me to close and how I could leverage the current features we were building to close them.
This type of openness is now the new norm on our team. At our daily stand ups we express ourselves if we feel like we are under-performing and need support. If we haven’t been able to uphold a certain commitment like number of pomodoros per week, we say so. We debate more passionately than before. In retrospective meetings we discuss our physical health, satisfaction with our work environment, comfort giving direct feedback, etc. and come up with experiments to help us work more sustainably. Most importantly, we are constantly affirming that this is a fail friendly space. That we’re doing the best we can and that is enough.
Waiting for Safety
When I learned about the Google study code-named Project Aristotle from my colleague Cam, everything fell into place. It was Google’s largest initiative to research which factors make a high performing team. Cam and I discussed the findings of the study at length — that psychological safety is the most important factor for high performing teams. I’m going to go one step further and say for me vulnerability is the most important factor for high performing teams.
I’m no longer waiting around for psychological safety to emerge. I am trying to selflessly leverage every failure, every discomfort, every weakness, every opportunity to be vulnerable so that everyone can bring their whole selves — today. I want to lean into it and make my environment safer even if it is at the expense of my ego. I want to:
I believe this is how we will cultivate an environment where we can solve the most difficult problems.
If you’re interested in becoming a vulnerability paragon on your team, here are some tips I’ve gathered through my journey.
Use Radically Transparent Phrases
Whenever I’m in a situation that makes me uncomfortable and I want to say something but feel embarrassed to, I try to use radically transparent phrases such as:
- “I feel embarrassed to ask this since I’ve been professionally coding for four years but…”
- “I’m going to be completely honest and transparent with you/with you all and say …”
- “I’ve been feeling ashamed about this lately and want to share it with you all because I feel this is an environment where I’ll feel safe and heard…”
I think of it this way: every time I speak honestly and transparently, I’m contributing to the psychological safety.
During my junior developer years, I wish I had empathized with others more and made them feel heard. Through hindsight, I can see the difficulties that others faced. Empathy requires vulnerability, and so given what we established earlier, an opportunity to empathize with someone’s suffering is then an opportunity to build trust and psychological safety. One of the phrases that I started using from Krista Tippet’s interview with Sheryl Sandberg is:
“I know you don’t know if you’re going to get through this, and I don’t know either. But you’re not going to go through it alone. I’m here to help you. I’m here to do it with you.”
Believing is Seeing
This year was eventful for me. I have grown tremendously due to my vulnerability experiments. I look back now and can’t help but remember the first time I heard Sean Stephenson explain “believing is seeing”. Most people think “seeing is believing” but the reality couldn’t be further from the truth. “Believing is seeing” is a succinct way to summarize how I approach psychological safety. If I believe strongly enough that there is psychological safety on my team, I will act accordingly. This will cause me to see psychological safety. And others will too.