A good bugmaster has a number of important qualities. Among them:
| is an enabler- always subverts his own agenda to the project's agenda, and knows his biggest role is to make the jobs of others easier by providing them with the best information possible. |
| is a pattern-finder- can quickly draw good conclusions from scattered data points. |
| promotes consistency, defining standards and terms that help everyone find what they need. |
| Has the confidence and willpower to stand up to developers- NOTABUG sometimes means 'I don't want to fix it', and a good bugmaster knows the difference and acts on it. |
| understands his co-workers- is willing to listen very hard, particularly to hackers/developers. They do know what they're doing most of the time, and the bugmaster must learn from them. |
| advocates for users- users are all too easy to forget about in the heat of the development moment. A good bugmaster stands up for them on the daily basis that PM typically does not. |
| is not afraid of volunteers/QA- you will be told 'no one will use this product if this bug is in a release', and you have to be willing to tell them 'you're on crack' if that's the case. |
| understands the business/game plan (what's our target user/market? when a bug filer says 'no one will ever deploy this if it still has this bug', which they will say, are they right? do the hackers care?) |
| is willing to get hands very dirty- will need to do unpleasant, repetitive gruntwork. |
| has a fairly good technical background- doesn't have to be perfect or even a particularly good programmer, but must be able to quickly analyze and understand the general nature of a bug report. |