Justin Rohrman took on a new role in his career: test lead. He wrote down his observations about the first thirty days in this position, recording what really happened when he changed jobs, what challenges he encountered with his new team, and how he and his coworkers resolved problems. His synopsis could be useful to any project team.
Starting a new job is a little stressful but a lot exciting. Whether I left a job because of something positive or negative, there are high hopes for what I might learn and work on in my new role.
I recently started with a new company, filling a role I have never had in title: test lead. I wrote this over a thirty-day period while observing what really happens when changing jobs, not just what you’ll see in the new-hire paperwork. My goal during this month is to become as effective as possible in a short period of time without draining resources by having someone sit with me constantly.
Defining Your Role and Setting Expectations
What you see in the job listing you applied to, what you’re told you might be doing during the interview, and what you actually end up doing are all a little bit different. A typical tester job advertisement will say something about writing and executing test cases, maybe with a list of desirable skills. That doesn’t tell you a whole lot about the conditions you’ll be using that stuff in, though.
Defining your role is finding where what was written down and what you were told intersect with how you will actually work. Maybe you excel at a certain type of testing; maybe you want to work paired up with a developer; maybe you have a mind for usability and want to work with the design team a lot; maybe there is a group of developers you groove with. The first thirty days is a great time to explore where you fit and how you can be useful to the team.
My new job was described as a lead for an existing test group. I’ve never been in a lead position before and companies seem to have varying expectations for this role, so I spent a lot of time learning about and setting requirements.
To move this process along, I set up a weekly one-on-one meeting with my supervisor to talk about what I’m doing and what I plan to do and see how that matches up with his vision. This was a nice, informal chat, and the end result was both of us having a good understanding of each others expectations.
When I applied, there were actually no job specifications. A friend saw a Twitter post and generously mentioned me. I sent an email to the company giving a brief introduction along with an invitation to chat on the phone. Because there was no description of what the position required, we spent a lot of time talking and figuring out what each party wanted.
My expectation for this (or any) job is that I would get to do self-directed work on challenging projects with motivated teams, with the possibility of jumping between projects as needed because I really like variety in work. My new employer had the expectations that I would do some coaching and training and bring fresh perspectives and ideas to the organization, in addition to my normal testing work.
One potential conflict was that they were looking for someone to fill a management role. I love doing hands-on testing and was not really interested in managing people 100 percent of the time at that point. Knowing expectations on both sides saved them from being disappointed and me from being unhappy.
I had similar chats with my new test team to see how their test lives were going, what they wanted to learn about, and how I could help them be awesome. I make it a point to see how they are doing every few days, but not so often as to crowd them. These conversations are fun. The test group is two people at this point. Both of them are interested in learning about testing as a craft, so I started planting seeds of ideas like moving from traditional test cases to session notes, using mind maps to develop test ideas, and bug reporting as a skill. A culture that welcomes positive change made these talks easy.
Getting Friendly with the Team
Developing a good rapport with the folks you’ll work closely with is really important. Being on a friendly level helps your coworkers get more comfortable with your giving a critical eye to their work. It puts you in a sort of nonthreatening comfort zone and can be helpful to your credibility as a tester. I spent a good bit of time doing this.
It was important for me to get comfortable with the test group quickly, so on my third day we had an hour session where they talked about stuff they thought was going well and stuff they thought wasn’t going so well. In the end we picked a few things to do differently. Caring and doing work that affects them in a positive way helped these relationships.
Each of us is embedded on a project team, not exactly a multidisciplinary agile team, that focuses on some part of the project. I’m doing testing about 70 percent of the time. The rest of my time is spent merging code to the test environment, facilitating work for the other two testers, and the normal email, meetings, and miscellaneous stuff.
When I saw a group of developers going to lunch, I’d ask if they’d mind if I joined. This can be tough for those on the more introverted or shy side of the human scale, especially with all the other stuff going on, but it is completely worthwhile. Aside from developing a good work environment, you might get a new friend or two out of it. This social interaction pays off in the form of credibility when you are working with developers.
I’m not implying working people in the political sense or in the Gervais Principle power talk sense; I’m suggesting taking a genuine interest in the people you work with because it is beneficial for everyone. Michael Church describes this sort of behavior as that of the technocrat. This is a person who focuses on work that is mutually beneficial.
Becoming a Consultant
Part of what a consultant does when going into a new environment is closely listening to what people have to say. I framed myself as a consultant by being available to listen and offer an outsider’s perspective to anyone who was interested.
One example was the two testers I worked with telling me how they often feel pressed for time toward the end of a sprint. It turned out that they were having two-week sprints: one week of development and one week of testing. The first test build was not available until the second week even though there was testable stuff that could get merged. As an outsider, it was easy to ask why builds weren’t getting to the test phase earlier. This turned out to be a resource problem. Doing builds was a little complicated and normally done by a developer. Early in the sprint, developers’ time is highly constrained. I volunteered to learn how to merge code and get builds to test earlier so we could test with less time pressure.
Over time, I suspect this will be harder as I move from being new and different to becoming “just Justin.” It might be easier to maintain this a little longer at a larger company where you can potentially switch between completely independent groups.
Reflecting on Thirty Days
After thirty days, I’m getting pretty settled into my job and getting a better feel for the team. My current understanding of my role is a mixture of software testing (hands-on and programmatic), a little coaching on test topics, a little facilitating work, and a little risk management.
Toward the end of this thirty-day period, the person who hired me left the company and a new boss stepped in. The new boss is very proactive and scheduled meetings with everyone on the dev team. In my meeting, he asked me to describe my dream job. I detailed a role that consists of moving between projects, getting challenging testing tasks, and mentoring and coaching testers. He grinned and said he had just the project.
Everyone’s experience when changing jobs will be a little different. Maybe some of this will be ironed out for you ahead of time and you’ll have your own adventure and set of things to learn. I’d love to hear about some of your experiences!
Great article, Justin. Thanks. It really helped to put my own experiences in perspective. About nine months ago I assumed the role of Senior Test Engineer -- a first for me as well -- at a new company in a start-up development group. I can readily relate to the value of meeting frequently with one’s superior early on. On the whole it did help, though I would raise a caution to others regarding this. Out of nervousness mostly, I found myself suggesting things off the top of my head, which he jumped on with enthusiasm. Though it might have made me look smart at the time, I would pay for my momentary lack of judgment. It readily dawned on me that almost all my suggestions were in the category of "what was I thinking!" and yet I was stuck because I had been the chief instrument for getting my boss excited about them. Lesson learned here is put some thought into what you will talk about with your new boss -- maybe bring some notes with you in case nervousness makes you forgetful. If you are unsure about suggesting some course of action, don't! Wait! You can always bring it up later after you've had the chance to gather more knowledge of the context and think it through.
Thank you for taking the time to capture and share your first 30 days as a Test Lead. You highlighted the key aspects of any lead or management position: communication and collaboration. Working with people is far more important (and far more difficult) than working with software. I also like that you took time to explore and identify expectations in detail. That is hugely important to make sure what you spend your time on matches what your manager and overall team expects and needs. Identifying and adjusting an unrealistic, incomplete, or counterproductive expectation is even better than just doing what is expected.
Good luck with your new manager. It sounds like you already established a connection and have common ground established. Post an update soon :-).
@ThomasSullivan, I agree it is important to carefully review any "great ideas" before discussing them with management unless you know your manager is open to exploring and vetting ideas rather than blindly proceeding to pilot or fully adopt them. Peer mentoring is a great way to explore great new ideas safely. Ask yourself and someone else "what could possibly go wrong" and "what are the risks and costs" in addition to the potential benefits. I've had my share of "What was I thinking!" moments too :-).
@ZaphanSchroeder: Very good point about seeking early on a mentor to serve as a sounding board. I did this and it helped immensely. It doesn't have to be anything formal. I noticed that, like myself, one of the senior developers took a walk at lunch everyday so we formed a little walking club. It's great to get out for a few minutes each day and run any ideas that have occurred to me by someone who knows the basic context. This was a perfect opportunity to get the insider's scoop on the history of the group and various hidden agendas that were useful for me to be aware of. Trying to find out much of this information on my own might have taken a very long time and being ignorant of it would have been doing damage to me in the meantime. Notice here that my mentor wasn't even in a testing role. I think this indicates that most of the information I was seeking was more human-related than technical -- regrettably, we techie folk are tempted to neglect the human too often.