If you’re looking for reasons to doubt the quality of your own work, you’ll find them.

At one client, I was managing a team of five testers and working with an agile development team overseas. There was no time of day where the developers and testers were online at the same time. Our primary modes of communication were emails and defect comments.

When the Programme Manager called me into his office and said that my team was adding no value to his project, I was dismayed. All I could think of was that I’d just returned to the workforce after a year-long maternity break, and my first project was an epic failure after just six weeks. My role was to provide information about product quality to the PM, and he had just given me the worst feedback that I could ever imagine giving a team:

It will be better if you do nothing, because you’re distracting the development team with all of your questions. They’re very busy, they’ve got a lot of work to get through for this sprint, and you’re wasting their time.

I was so surprised and upset by this that I excused myself and thought about where I could have gone so wrong on this project.
For about the next 40 minutes, I found plenty of reasons to doubt the quality of my work.

I was working with a new cloud application, and having some trouble completely understanding the backend structure.
The questions we were asking development made sense to me, but maybe we should have added more detail to avoid misunderstandings, in the absence of face-to-face or at least real-time conversations.
I’d been asking for feedback every two weeks and it had all been positive, how could I have missed something this big?
I’d just been off work for a year, and maybe all my instincts were off.

At about that point, I wondered why no one from my team had questioned me on our approach, and whether they’d also been doing anything wrong.

My team had been doing all that they could with the information available during the day.
They’d been sending through a single email of concise questions daily, when our team couldn’t work out the answers amongst ourselves.
They’d been notifying me daily about issues blocking their main priority tasks, and finding other things to test in the meantime.

I came to the conclusion that my team had done nothing wrong, and had been adding as much value as they could given that they were usually blocked for at least half of each day on testing the highest priority product areas.

Then I finally realised, I had been adding value too. Quite a lot of value actually. Perhaps if I’d been at the top of my game, I would have come to this conclusion during the meeting, rather than 40 minutes later.

I had been uncovering major oversights in terms of product development and deployment planning, some of which had a large impact on the project budget.
I’d worked hard to develop solid test plans in the face of ever-changing information.
My decision to use a visual coverage map approach to test planning had provided thousands of dollars in savings, from the effort we saved when changing the plans as often as was necessary.
I had worked closely with the Training Department, to ensure they had early access to the system.
We were regularly blocked by lack of real-time access to the development team, and sent them daily summary emails with lists of questions and requests for clarifications.

I’ve taken away a few lessons from this unpleasant experience. Some are lessons that I’ve learned before, like ‘Get everything in writing’ and ‘Seriously, get it all in writing’.
And that when a team say they are ‘agile’, that can mean just about anything.
And that some people interpret my questions about project gaps as blaming, rather than genuine interest and concern in taking corrective actions, which is their problem and not mine.
But those lessons are off-topic for this post.

A new lesson I’ve learned is to criticise my own work instead of relying on feedback, and not wait to be criticised by someone else. This will improve my confidence in my own work, and give me some practise at promoting and/or defending my test approach. Here’s hoping that next time I hear statements as ridiculous as the ones above, I will react with appropriate confidence and indignation.

UPDATE: Writing this blog helped me a lot. The next time my work was called into question, I responded appropriately with confidence, evidence, indignation and pride.
If I’m ever in a similar situation with a manager who buckles under the immense stress placed on them by stakeholders, and that manager decides to lash out at the team in a moment of weakness, I will defend myself and my team.