As a QA Manager who often oversees more than a dozen projects at a time across both client/services and internal/product development I get an inside look at what helps projects succeed. Today I’m pulling my head out of the depths of QA Land to give you an important tip that’s been rattling around my brain cage for the last couple of weeks:
The squeaky wheel gets the grease
In other words, speak up. And keep speaking up until something is fixed.
Now I know that proverbs are silly to use since many of them are so contradictory: “good things come to those who wait”, right? Listen up folks — in the world of software development, good things do not come to those who wait. In fact, waiting around does absolutely nothing except tank your chances for successful delivery and implementation.
People have all different kinds of reasons for not speaking up: they’re too busy, they don’t want someone to think they’re complaining, they don’t want to feel like they’re a burden to the person who will have to make the fix, they don’t want to appear to be negative, etc.
Whether you’re a developer, a designer, or just someone who happens to be clicking around in an application it’s vital to speak up when you encounter things you aren’t expecting, or bugs, or undesired behavior from the application. The people that are working with the project are usually so deeply involved that it’s easy to miss surface-level mistakes that might seem so apparent to someone else. And if you don’t raise your voice about it, it might not ever get “greased”.
Here are some basic tips for “squeaking up” and getting heard:
Do:
- Contact someone on the project and politely let them know what sort of ugly bug you’ve uncovered.
- Be as specific as possible about the problem – give information about what browser (and version) you were using at the time, which OS, etc.
- Take a screenshot if possible and annotate it, conveying the issue as clearly as possible.
- Be proactive and create a ticket, including all of this helpful info about the bug in the ticket notes. This saves QA a step and ensures it gets (and stays) on their radar.
- If the issue isn’t resolved, be sure to follow up with someone about it (politely, of course).
- Explain the reasons you don’t agree with a certain type of functionality, citing helpful examples.
Don’t:
- Yell about the problem from across the room, which will inevitably make the QA and dev team feel like you’re making a long-ranged attack.
- Contact someone higher up in the chain than you need to – just report the issue to the person(s) that is working with the code daily and can help take care of the problem. Going above their head is an adversarial move.
- Get angry if people disagree with your insights about a type of functionality – maybe you don’t see the reason for it, but the dev team insists, even after open discussions about it, that that particular functionality has to remain as-is.
In short, your product won’t be a great product if it’s chock full of holes, nasty bugs, odd functionality, and so forth. It’s everyone’s job to report the wonky things they come across, even if you don’t want to “bother” people. You can be “squeaky” without be “squawky.”
