arrow_backward Back to blog

Grease for Squeaky Products – Tips from QA Land

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:


  • 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.


  • 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.โ€


New Project Request