Imposter syndrome has been described as a psychological phenomenon in which people are unable to internalize their accomplishments. It’s something that has been highlighted for women in technology, because many highly intelligent women suffer from this despite their great achievements.

As a software engineer, I have taken on different roles throughout my career – Software Developer, Software Consultant, Software Tester, Software Quality Engineer, and so on. As an engineer at Salesforce, I am proud of the products my teams are delivering. It takes a team of people with varied expertise to deliver the enterprise services our customers love – Product Managers, Designers, Developers, Quality Engineers, Performance Engineers, Security, Technical Writers, Operations, and so on.

There are a lot of articles in the technology industry about how Testers/Quality engineers need to battle with different groups to do their jobs. They can feel like second class citizens in their groups or teams. Other groups, such as Product Managers or Developers, get most of the credit for the success of a product. However, testers get the blame when something goes wrong: The most popular question is, “Why wasn’t this bug found during testing?”

I always felt good about my accomplishments at Salesforce until I started reading these articles. I kept wondering why I felt good about my accomplishments at Salesforce in spite of the industry trend indicating the opposite for Testers. I started doubting my accomplishments at Salesforce and wondered whether they were related to luck. Was I under some illusion that things were great at Salesforce?

That was when I also started hearing and reading about Imposter Syndrome. It was an interesting coincidence to read about the challenges in the testing industry and women in technology communities around the same time.

I decided I had to look at the facts and understand why my accomplishments deserved the credit they received. I came up with a list based on the interactions I had with people at Salesforce:

• Product Managers included me in their planning and prioritization discussions

• Developers and Architects included me in their design and architectural discussions

• Developers worked with me to come up with an efficient testing strategy

• Developers reviewed my test plans during design or before coding so they could fix design issues earlier on

• Developers did pair-programing on certain features so product and integration test code were checked in together

• Developers were really happy if automated integration tests were available before they checked in their changes so they had higher confidence with their code and less rework

• Developers asked me to review their code

• Developers reviewed my code related to test automation

• Technical writers asked me to provide content as well as review the documentation they developed

• Developers didn’t start on new features/user stories until I was available to do the required reviews and testing

• Developers would also do test automation to support the testing efforts

• Product Managers checked in with me if we had to meet a business deadline, so we could discuss reducing feature scope

• Product Managers and Developers asked me to do product demos

• Support teams asked for help to investigate and follow up on customer issues

• Operations teams asked for help to improve monitoring of services

• All disciplines would work together to support each other to meet the business goals

I realized that Salesforce Management gave credit to all disciplines including Testers/Quality engineers for the successful products. Even before Agile and Scrum became mainstream, Salesforce had feature teams which comprised of all functional disciplines. The management knew it took a group of different experts to deliver the products our customers love. I realized that my contributions as a Quality Engineer at Salesforce mattered, and I should cherish my accomplishments.

In summary, I believe every engineering discipline has its challenges. People in those disciplines might feel differently about their accomplishments. Whether it is imposter syndrome or not, every company needs to provide an environment where every engineer’s contribution is valued and recognized, regardless of their particular discipline.

Here at Salesforce, we’re making a definite effort to recognize  all disciplines and the importance of their contributions from planning to customer support. Check out a previous post about Quality Engineering at Salesforce: https://developer.salesforce.com/blogs/engineering/2014/05/quality_engineers_and_developers_cant_we_all_just_get_along.html

We’re also hiring! Visit http://www.salesforce.com/tech to find your #dreamjob.