Tester’s Diary: Working on Individual Performance as a Team

This is a guest posting by Carol Brands.

Like most employees in a corporate environment, each year I’m asked to identify some individual goals. At their best, our individual goals do two things: help the business unit meet its business needs, and help the individual increase their work skills.

As an employee, I’ve seen both successful implementations and some failures. As I begin to step into a leadership role, this year I wanted to help my team find a method that would work for us. So I did what any good leader would do: I scheduled a meeting.

Developing our Goals and Ideas

We started by taking a close look at our manager’s annual goals. We wanted to make sure that our goals helped him meet his goals, which were driven primarily by the business needs of the company. Our manager leads both the support and test teams, so some of his goals fell outside the scope of what the test team would normally do. However, we wanted to keep an open mind as we moved to our next step of identifying the goals we could help with, either directly or indirectly.

For example, one of the goals for support is to maintain a high customer satisfaction rating, and one of the goals for the test team is to create a new test lab. We know which products will be released this year, so by steering our goals for the test lab toward using it to more effectively reproduce the kinds of problems reported in customer environments, we can indirectly help with customer satisfaction.

Once we identified which goals we might be able to help with, we began brainstorming ideas for goals for our team. We wanted to come up with as many ideas as possible, without worrying about how we would accomplish the goals at first. We recognized that not all the ideas would be feasible, but we hoped to create a pool of ideas that would both satisfy our team needs and reveal projects and goals that we were personally interested in. If one person threw an idea on the table and another person iterated on the idea, we knew that there would be opportunities and energy to collaborate on meeting that goal as a team.

Once we established the pool of ideas, we identified which ones we wanted to tackle as a team and which ones we wanted to work on individually. Some topics had both individual and team goals. For example, we decided that developing the proposal for the test lab should be a team goal, because we all wanted to be involved in its development. However, Klaus in particular was interested in making sure the test lab could be used to run automated tests daily on a particular project, so he was able to make that an individual goal in support of the team goal.

This method worked out pretty well. We were even able to identify goals around learning and researching new topics that were particularly suited to our intern. However, at the end of the session, there was one topic that remained unaddressed.

Our boss’s list included adding security testing to our test strategies and team competencies. However, no one seemed particularly interested in creating a goal to meet that need. I decided that, as a leader, I needed to take one for the team, so I took on the goal of developing a security testing strategy for our next project. This time next month, I might be writing a story about how I fell in love with security testing — I guess time will tell.

Learning From the Process

Overall, I think our process of evaluating our business needs, brainstorming to develop a pool of ideas, claiming ideas from the pool, and re-evaluating to make sure all the business needs were covered was a good method. We all got some annual goals we were interested in, and because we’re taking on some goals as a team, we can check in with each other and collaborate to get things done.

In the future, I may need to find a way to deal with the goals no one is excited about, besides taking them on myself. In spite of that, this was a valuable learning experience on my path to becoming a team leader.

This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.