Major Hayden is a man of considerable skill. In addition to his job at Rackspace, he spends time developing open source projects. He has a stack of certifications. Yet for all his undeniable credentials, he sometimes struggles with a feeling of I don’t belong here. It’s a feeling that’s far too common in open source projects. Yet, given enough eyeballs, maybe all impostor syndromes are shallow. Major Hayden will be presenting his talk at Texas Linux Fest this week: Be an inspiration, not an impostor.

Q&A

How did Impostor Syndrome become an important topic for you?

I’ve always struggled with it since I entered the realm of IT. I graduated from college with a degree in biology and a drawer full of over 70 rejection letters from medical schools. Some medical schools didn’t even bother to send a response. I was crushed.

Tinkering with Linux systems was a hobby of mine, and I decided to transform that hobby into a career. However, I found myself surrounded by talented people at a small start­up, and later at Rackspace, who had backgrounds in computer science, information systems, and management. Even though I kept up with most technical discussions, I felt out of place. In other words, I was quite competent at the time but I couldn’t acknowledge it.

As I’ve gained more experience and expertise, I’ve seen many other people struggle with impostor syndrome and they aren’t able to recognize their own competence and unique skills. It manifests itself in different ways, but it’s usually worst during “in person” situations like meetings, conferences, and speaking opportunities. People suffering from the syndrome often keep their opinions and experiences to themselves even though the other people in the room greatly value their insight and yearn for them to share it.

Open source communities are all about sharing. When the sharing slows, the open source community struggles. The same thing happens in the workplace. Companies struggle to come up with new products or improve existing ones when multiple viewpoints are not brought to the table.

Many of us who suffer from Impostor Syndrome are worried about going too far with fighting it and ending up in Dunning­-Kruger territory. How can you strike a balance?

Although some IT professionals actually start on the opposite end of the spectrum where they overestimate their competence, it is certainly possible for someone suffering from impostor syndrome to end up here. Either way, it’s critical for everyone to have a support structure made up of people who understand their hardships.

I’ve always leaned on my leadership and coworkers to give me solid feedback on my performance. My strategy involves proposing something new, backing it up with facts and references, and then providing that argument with an avenue for feedback. That open door for feedback is usually a phrase like “Am I on the right track?” or “Does this make sense?” at the end of an email or a meeting.

This open door for feedback has two benefits. First, if there are errors or bias in my proposal, it shows that I’m interested in the feedback and that I’ll take negative feedback without getting defensive. Second, it serves as a nudge for my coworkers that might be unsure if they should provide feedback because they’re unsure if they have the right expertise to reply. That is my way of improving my own capabilities while encouraging others to be confident with theirs.

What can open source projects do generally to minimize the impact of Impostor Syndrome?

The key is to ensure everyone’s voice is heard. However, everyone feels comfortable sharing their opinions in different ways. Some people excel at sharing their ideas in every medium: conference calls, mailing lists, IRC, and in person. Others prefer more to avoid discussions in person and would rather have time to formulate their ideas in an email.

The successful open source communities handle discussions and critical decisions carefully. For example, many meetings I’ve been involved with in IRC or via telephone will end with meeting minutes being shared via a mailing list and a request for more comments there. This gives an opportunity for those who didn’t speak up during the live meeting to put their ideas into an email with facts to back up those ideas.

By far, the most effective method to get everyone involved is mentoring. I had originally wanted to join a Linux community and begin packaging some software, but I found the process to be extremely difficult and it seemed like everyone who was already in the group was part of a club. In contrast, when I joined the Fedora Project to do some packaging and testing, I had access to a mentor who helped me around plenty of the rough edges. He also introduced me to other people, pushed me to do more, and urged me to call out quality issues when I saw them.

You’ve spent a lot of volunteer hours not only contributing to open source, but leading (for example, serving on the Fedora board). What have you most enjoyed about leadership roles?

Working on the Fedora board was a great opportunity. It was a little tough to join in the discussions because many of the people on the board worked for Red Hat. They had a history together and there were internal or hallway discussions that I missed. Once I realized they were welcome to new ideas, I felt much more comfortable pushing for changes.

It’s key to remember that behind every open source software project is people. If the people creating it and using it feel like they have a calling, the project will thrive. I enjoy taking part in the evangelism of a project and the problems it strives to solve. The best leaders are the ones who throw themselves out in front when things are not going well and avoid taking the credit when times are good.