As I mentioned in an earlier entry, I recently started managing a QA team that tested multiple products. I was glad to find I had gained a good team that needed a few adjustments to get on track. Thru meetings, both one-on-one and in groups, I got to know the members and their habits and quirks, some of which really required a change of mindset.
The QA and development teams in this product line work closely together with the developers glad to help when needed at crunch time. During a meeting with one of my team leaders on dividing up some remaining work necessary before a product release I noticed that this lead was reluctant to assign certain ‘easy’ tasks to the developers. When I inquired as to why I was told we should not be giving such tasks to them. Why not? Because they are developers and these are not for them. Too Easy.
Whoa.
To cut to the chase I had found that some had developed a “reverence” (for lack of a better term) towards the developers based on what they did. In doing this they had started to defer to them as if their position was superior. This could not stand. Yes, developers do have a position of taking ideas and implementing them into something usable but others contribute to product in their own way. Like development, it is up to QA to understand the idea also, make sure it is implemented, and to challenge the idea when and where necessary. This can be difficult in normal times and is impossible if the developers are on a pedestal. As a matter of fact in some ways the reverse should be true. I have found over the years that more developers are knowledgeable on the parts of a product they developed while QA has to be familiar with the whole nine yards. So who should be holding who in high regards?
Oops, off track a little there. The point is all members of a product (or project) team have something to contribute be it product management, developers, QA or docs. Good ideas and good people exist in all these roles. Hmmm… I have worked with developers with big egos and the one person that scared them was not another developer but a docs writer who could bring out fear in these developers like you would not believe. This person had done some development, had great comprehension and was willing to question and challenge. I can remember one meeting where a major decision was made on a product and it seemed that most of the meeting was not spent on the decision bit “who was going to talk with docs”. Thats some power.
Ok, that last point may have sounded like reverence but it is really respect. And that is what we want to have. Stop reverence when you see it. Help develop respect.
Thomas De Lora
