Why am I an automation engineer? The answer became starkly clear to me one Tuesday morning that should have been like any other. At that time, I was a “Software Quality Engineer” on the QA Framework team of a fairly small software company. I arrived at the office at my normal time around 9am. The following two hours I spent in my daily groove with my headphones on, blissfully unaware as our director started escorting engineers out the door with boxes in hand. After an interrupted 11am standup, I found myself, heart racing, in a conference room with my manager and the VP of engineering who had flown in from our other site. On the table, I saw a pile of key fobs and bejeweled company phones. By this point, anyone who knows the software industry could predict what would happen next: the dreaded layoff. However, that’s where the story becomes more interesting.

I wasn’t laid off. Surprise!

In a daring reorganization, the VP eliminated all QA positions in the company. The justification given was to make teams purely Agile with no silos of division between development and quality. Everybody would own quality. Manual testers would be removed in order to prioritize automation. I also suspected that company finances may have encouraged the re-org. As a result, people lost their jobs. However, a few QA engineers, myself included, were spared the layoff and rebranded as regular “software engineers.” In that conference room, as the adrenaline rush subsided, the VP outlined a high-level plan in which I would move to a product development team that desperately needed automation help. Apparently, this team didn’t even have unit tests, and their product was weeks behind schedule. Once they got it going, I would become a regular web developer with the others.

So, why me? The survivor’s guilt bothered me, but the answer, apart from God’s grace, was pretty obvious: automation skill. I was the company’s automation champion, and everybody knew it. I consulted with each team to help improve their testing efforts. I gave a lunch-and-learn on behavior-driven development. I wrote several wiki pages and even example projects. Now, that’s not to brag on myself or belittle the skills of others, since many of the engineers who were cut also had automation talent, but my skills had been made highly visible to the people in power. And my skills continued to afford me great opportunity.

However, the last part of the VP’s new plan disconcerted me – did I want to become a standard web UI developer? I pondered the question deeply, but my gut answer never changed: no. Test automation was my specialty. It was the product I made, and I made it well. I knew the ins and outs, the frameworks, the best practices, the fundamental problem of test automation and the lowercase problems that derive. And I loved doing automation because it gave me the opportunity to set things right: to find an eliminate bugs, to protect the code line, and to make it look damn good. I could indeed switch over to web dev, but why? I didn’t have interest in web dev. That would be like making a hardwood floor installer do painting instead. With automation, I had both a specialty and an opportunity.

To conclude the story, I didn’t stick around much longer at that company. I quickly found a better opportunity as a senior-level automation engineer on an exciting new project at a different company. That’s the software industry – so it goes! Ironically, that layoff may have impacted me just as much as if I had actually lost my job. It forced me to make a choice. I definitively chose to be a software quality engineer. Automation was no longer merely a skill set but a career identity.