Recently I sat in a QA team meeting where half of the QA staff was questioning the “usefulness” of the QA Test Plan, which was a more generic long term plan, and suggesting a plan geared toward the current phase of the company which is in a start-up “get a few key customers interested” phase. Half of the QA team wanted to be more involved in hearing and learning about the key customers’ issues. They wanted to develop the test plan more around the current “key customers” and worry about the future once these customers were satisfied. The other half of the team was pretty quiet – neither agreeing or disagreeing with the manager who felt that it was best to start developing the QA department in a way that is geared toward long-term plans, and let project managers and tech support deal with the current key customers.
Both arguments are valid, but unfortunately, the manager missed the boat on why. I think the manager believed that the QA team was concerned about the fact that bugs were found by the current key customers and that QA would be blamed for this. The manager made a point of saying that the company had never played the blame game and that QA would not be held accountable for these issues. (The company does not have any formal accountability requirements.) Therefore, the manager was comfortable with continuing on the current path of worrying about the more generic future and letting go of the current key customer specifics.
Being blamed was not even remotely the concern of the team-members who questioned the current plan. Meeting their personal accountability standards was what they were concerned about – or in a nut-shell, job satisfaction.
Some people are motivated by a personal work ethic that is a standard so high noone can live up to it. I’ve met a lot of these types in the Quality Assurance field. I believe that a strong sense of personal work standards is a trait that most successful career QA people hold. If they didn’t, then their job would drive them insane. These people want to continuously learn about technology, learn about the products they test, and apply all the skills they have to do the best possible job. These people crave feedback. These people are mortified when bad bugs get out to customers and they want to get this feedback, incorporate it into future testing, and make sure it never happens again. This is what I call “internal accountability.”
Some people are motivated more by what I will call “external accountability.” Their priority is to keep their job which supplements areas of their lives that have higher priorities. These people do a decent job, but their accountibility at work is defined more by their direct manager’s requirements (high or low) than a personal requirement.
And, of course, there is always the ‘slacker’ who really doesn’t like accountability at all. I’m not going to talk about this group much, because it is obvious that this is an employee who needs more attention than the average person.
The “internal accountability” (IA) and “external accountability” (EA) people both have their pros and cons. IA employess don’t need much formal process in order to be motivated to do their best possible work. However, they may be tricky to manage. They may go over your head or through the “back door” to get information you can’t give them (or you don’t want them to have) if they deem that information essential to doing a great job (their personal definition of “great job.”) They may hound you with questions that “put the cart before the horse.” They may not see the big picture of the company – that you’ve got to eventually ship something, perfect or not, to make money and stay in business. The may become extremely frustrated in their job if they don’t feel that they are given the information they need to meet their own high standards or if their job isn’t utilizing all the skills they feel they have to offer. They will also have extremely high expectations of their manager.
Without a more formal accountability process, EA employees may not quite go that extra step to ensure a job is complete. They may stop at 75%. Because of this, EA employees may miss the nitty gritty problems that turn up later in customer reports, but the work they do is good enough to get a product out the door. EA people often go with whatever they are asked to do without challenging that plan too much. They are more likely to challenge only when something seems very very strange or confusing to them. They are better adjusted and likely to be less stressed-out at work. They don’t take their jobs personally.
I think it is best to have both types of personalities on a QA team. They go at their jobs in a different and complementary way. The EA folks quickly find the things that block you from shipping a product and the IA people find the one crazy thing that if any customer ran across it – it would be very very bad for them and the company. The EA people get the basics done and move on and the IA people cross all the t’s and dot all the i’s.
As a manager, having some sort of formal accountability benefits the entire team. Formal accountability can be as simple as verbal status reports held at regular meetings during the development process, written status reports that are reviewed by project managers on a regular basis, or a checklist of accountability requirements (90% of critical bugs are verified fixed, 90% of test cases pass, etc…) that have to be met before a phase of a project is deemed “done.” Any sort of process like this gives the IA’s a better understanding of what is expected of them. For the IA’s it gives them a stopping point – so that they can feel they’ve met the company’s quality goals for that release and move on. Otherwise, the IA’s will keep going forever until they are crazed and they’ve hounded you into insanity as well. For the EAs this kind of accountability gives them somthing to strive for, so they don’t sign off on something too soon.
Bugs will still go out to the customer, and your company should not ever play the blame game. At least with some sort of loosely agreed upon accountability, your QA team will have some job satisfaction. They will know that they met the agreed upon release standards of the entire product team. They will be on the same page with each-other, hound you less, and be more productive.
Accountability isn’t about covering your butt, nor is it about setting people up to take the blame. It is about agreeing, as a team, on the goal you are working towards and having the satisfaction of reaching that goal. If something goes awry, then as a team, you can re-examine your goals and improve them.