Hindsight is 20/20, as "they" say.
"They" also say you have to make mistakes to learn from them. I say, learn from MY mistake so you don't have to make this one. Because some mistakes are really hard to recover from.
I was hired to develop automation frameworks and had been given the title "Software Engineer". To be honest, I didn't have the confidence to believe I deserved it. I even appended my own qualifier to the title in my online profiles, calling myself "Software Engineer (in Test)".
Fast forward a few months and I've been asked to lead a team of people doing the same job, developing and maintaining automation frameworks. So I set to work developing role descriptions and career growth plans - for the position I'd like to give people on my team: Software Development Engineer in Test (SDET).
I had used this title for automation related positions I helped create in the past, as well as having the title of Quality Assurance Developer earlier in my career. So when it came time to decide how to title the team members of my new automation focused team, I didn't put much thought to it. I completely glossed over the benefit I was being extended when I myself was given a Software Engineer title. Ooops.
In retrospect, after many conversations with industry professionals I respect, I realize that development is development regardless of what your focus area is. By tacking on a qualifier such as "in test", it opens up the discussion that these team members are not as skilled or deserving as team members with a "real" developer title. How often do we hear about developers being "good enough" to be in an SDET role? Or how about when development teams pass on junior applicants but recommend them for the automation role? And then you have to engage in discussions like where the SDET role fits in the pay scale of the organization (hint: in my experience, it's almost always been below developer, but above QA).
Simon Stewart made the claim (in a talk of his I attended at STPCon Spring 2018...and I hope he doesn't mind me attributing this to him) that finding good Automation Engineers (or SDETs, or SETIs, or Test Engineers, etc...) is actually very hard. Anyone who's been a hiring manager for this role will more than likely agree. And if this role is truly a hard one to fill, would that not warrant that position being worth more? Simon's claim was that there's plenty of developers in the candidate pool looking for positions, but we have to actively go out and hunt for months to find good SDETs.
So, back to my 20/20 hindsight. I've been reflecting on this a lot lately and I've come to realize that my new opinion on the matter is that anyone developing in code should have a developer role and be treated like a developer. That is, held to the same standards, paid the same wages, etc. The bonus to this? The people focused on your test frameworks can float between automation development and feature development as required. You're finding the people with the test and automation skills and putting them on the development team. This doesn't mean other developers can't contribute to automation, and vice versa. It's about getting right skills in the door and making them available to assist the wider team.
I never gave much focus to titles in past. But take it from me: take the time and think carefully about it. Once in place, they can be quite hard to change.
No comments:
Post a Comment