To start this with a corny quote, Confucius has been quoted as saying:
By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.
Last year I was asked to be both a QA engineer and an Iteration Manager. At first, I didn't understand the impact this project would have on my mindset as a professional but looking back but as the quote above infers upon reflection it impacted me greatly.
Previously I only thought of myself as a Test Engineer and not an IT Professional. It was because of this that I only touched code when it was a requirement of my role on a project. I realise now that this stunted my growth as a developer.
Performing multiple roles on a project is a highly challenging task. Below I have created a few tips to help you succeed while performing multiple roles in the workplace.
When I first took on this project I was so scared of failure that I tried to get both jobs done at 100%. Turns out there isn't enough hours in the day. I missed an update to the client. I couldn't get my framework up anywhere near as fast as I knew I could. That's when I realised that neither job was getting enough time and attention, let alone try to run both at full capacity.
I wasn't planning my time properly. I thought "Oh as a QA I could get this done in half a day" so I committed to that. Unfortunately, I also had a full day of management tasks to complete so I ended up feeling defeated because things always seemed to take longer than they should have.
This was solved when I recognised that I couldn't have both hats on at the same time, I needed to switch roles explicitly to not overwork myself.
The second lesson I had to learn was that context switching wastes time. I already knew this from my testing career but it compounds when trying to juggle two separate jobs. I found myself trying to work on my testing framework only to have to jump on an "urgent" IM task. I got my solution during my 1:1 with my manager; block out time for each role.
Seems simple enough but it escaped me. So I blocked out the morning for managing and updates and the afternoon for testing. This kind of planned context switching will allow you to avoid losing time and energy to mental overhead.
Being an IM means managing the iteration. This is a job that lends itself to distraction. It's not like being an engineer, as an engineer your IM protects you from outside interference. As a QA Engineer, your IM protects you from outside interference. As an IM you get no such protection even when you are trying to test.
You will have emails that you expected to respond to. you have slack messages that you need to respond to. Iteration management is a highly collaborative and demanding/with the expectation of responsiveness job; whereas Quality assurance has long bouts of non-collaboration while you are running your tests.
I solved this issue by communicating my "offline hours" to my stakeholders so they knew that in that period I would be focusing on testing. They could still send me messages and emails but I would be largely unresponsive in those times, as I had switched my role back to QA.
Being a tester you are generally not the driver of progress in a software development. You jump in and help assess the quality of a product and propose solutions but don't tend to have a role in the design. This is the opposite of the role of an iteration manager. Your role is to move along progress so the way that you approach problems are very different, and the way you communicate will change as well. The tester's mindset is focussed on quality so the questions and the communication are about making sure that quality is baked into the process. The IM's role is about making progress and meeting deadlines. When communicating its important to let your team know what role you are in. I used terms like "speaking as a tester" or "speaking as an IM" to make it clear how I was approaching the problem so that my team didn't misunderstand The problem I was trying to solve.
Also when your team is talking to you, it's important to filter what they are saying through both of your roles. For example, we were developing an API and when the developers said "we will have to skip the exception handling to meet the deadline" I could have instantly responded with my QA brain and objected but as an IM I was fully aware of the deadline so was able to adequately make the case to the Product Owner that this was important to pull out of the MVP and could be added later.
During all of this, the only thing that I could consistently rely on was my team. They were always there helping me out, helping me estimate, shoring up my weaknesses and all around supporting me. They were experts in their field's and helped me solve problems in both roles. They helped me estimate tickets, work with the client, and assist me with acceptance criteria. I could not have done it without my amazing team and when you are getting slammed having faith and a good relationship with your team will give you the support you need to get through it all.
A smart friend once told me: "Never ask for permission, or forgiveness. instead radiate intent". Ever since I heard that it was like a weight was lifted off my shoulders. So while I was struggling with the issues above I was in constant communication with my client and superiors about the struggles that was I having. Normally, people would shy away from telling their boss these things in fear of having their reputation affected but in my case I got the support for us to be successful in our project.
All these lessons I learnt throughout my engagement. When you want a project to succeed you wear whatever hat you can.
After I got the balance right I found the engagement very rewarding. I discovered that I liked my industry as a whole, not just my small part of it. I still have an addiction to quality assurance and my peers still roll their eyes and say "classic tester" but I know how to talk agile with my leads, I can help them plan large pieces of work and my mind expanded from just operational coding to architecture and thinking of how a solution might evolve over time.
This engagement was the ultimate reason that I decided to make this website. I wanted to learn how to branch out and quench my curiousity for other disciplines and functions touching my profession. My next blog will most likely be on how I got this site up and running. it's taken me quite a while to get it to a state where I am happy with it, but I found the journey rewarding so it never felt like work.
Most people tend to stay in their lane, and you always hear the phrase "Well that's not my job" but there is a serious benefit in trying out different roles in your industry to both gain an appreciation and skill. Who knows, you might decide you like your new role more.