More and more, testers are being added to programming teams. We testers think that's great, and we're happy to be here. But we also have some concerns based on our interactions with development teams in the past. To make the transition easier, here's a letter pointing out some things you should know when managing testers on your development team.
Dear software development manager,
So, your company just put testers on your programming team. That’s no surprise. Agile teams are integrated teams: Product owners, project managers, developers, testers, designers, and technical writers all work together to create business value. And while cross-functional product teams have been the norm for some time now, more companies are aligning their organizational reporting structure to match how products are delivered.
As testers, we see the trend of our jobs moving closer to development, and we think it’s a good thing. Consider us happy to be here.
Happy … but possibly a bit concerned.
There are a few potential reasons. It could be that we’ve had a bit of conflict with your team in the past. It could be that we’re worried we won’t fit in well. We’re apprehensive that we’ll be viewed as an add-on to your team, rather than a part of it. And we might be uneasy about our relationship with you, our new boss. You might be a bit concerned, too.
To make this easier, we thought we’d point out four things you should know when managing testers on your development team.
1. Conflict resolution is now officially part of your job.
Let’s be honest: Programming and QA relationships have a rocky history. Sometimes, it’s been downright bad. We’ve all suffered.
This is one of the reasons programming and QA have been isolated in silos—not because it wasn’t necessary for them to communicate, but because of the inherent strain between our jobs. Unfortunately, there’s been a lot of finger-pointing between teams, with a shameful amount of mutual disrespect that’s hurt both sides.
You now manage two groups that have a built-in reason to enter into conflict situations. After all, they write code. We find problems. They build systems. We break systems. They translate requirements. We identify unhanded corner cases.
When bad news is delivered, it’s easy to shoot the messenger. And it’s easy for programmers to feel judged when mistakes are pointed out. This makes conflict a part of our job, and now conflict resolution is a part of your job.
When we worked for a dedicated QA team, things were pretty simple. Each manager represented a team, and upper management expected you and the other manager to resolve conflicts however was best for the company. Your boss might now assume that because everyone works on the same team, there won’t be any more conflict.
But of course, that’s not true. It just means you’re left in the middle as the final decision maker. You probably used to negotiate with the QA manager, when you had the luxury of defending your team’s position 100 percent. You no longer have that luxury. You must consider both the QA and programming teams and portray a unified face to other teams, without throwing either internal group under the bus.
The conflict that used to be external is now internal. And you can’t let it pull apart your team.
You should spend a bit of time thinking about how you’ll handle conflicts in a way that preserves everyone’s dignity and respect and still does what’s best for the company.