24 Aug 2024
There are often times when you’re asked to work in suboptimal conditions. There is some work that is needed faster than usual, usually meaning the Software Development Lifecycle is shortened at both ends; the discovery is rushed, the spec is incomplete, and there’s not enough time to test it to the usual extent. This clearly increases the risk that something goes wrong when we deploy. Perhaps there are edge cases we didn’t find, perhaps the feature itself doesn’t really make sense for the intended use-case.
Being responsible for the quality of the product, a quality professional will want to minimise this risk. In these cases, though, the risk cannot be adequately reduced, as we rarely have the authority to refuse to greenlight the release without first having found any issues, as the rush to release this work usually comes via upper management.
So we speak to our manager, hoping to highlight the high level of risk inherent in the lack of process and time afforded this project. This is not your stereotypical “bad manager”, I have been lucky enough to work with managers who I get on well with, and with whom I have a mutual respect. And this is not one particular manager, this is behaviour I have seen multiple people exhibit, and I am sure is not confined to the realm of Quality Assurance or even Software Development.
The conversation will go something like this:
Quality Engineer: I’m concerned about this piece of
work, we aren’t following our best practices and there’s a good chance
it won’t end well.
Accidentally Manipulative Manager: It’s not ideal, but
we’ve just got to make the best of it. That’s why we’ve asked you
specifically to do this; I believe in you.
Engineer: Of course, we’re going to do the best we can
to reduce the risk…
Manager: Great!
The manager thinks to themselves that this has been a successful conversation - the Engineer was lacking in confidence, and we have given them a confidence boost in the knowledge that they are trusted to do a good job. However, the reason for the call was not the Engineer’s lack of confidence in themselves, but their lack of confidence in the process.
The manipulation is in the flattery. It’s more difficult to press a point when the response has been so complimentary, resulting in the Engineer leaving the call feeling unheard. Moreover, we get the feeling that the company is relying on QA to catch all of the issues injected through the rushed process, and the company has confidence because of our ability. The unintended implication, of course, is that if things go wrong, our ability was not up to expectations.
The ideal outcome of the call (other than “You’re right, let’s take this project back to the drawing board”) is an acknowledgement of the risk, giving the Engineer confidence that the likely quality issues are not the fault of the testers. Something like
“It’s not ideal, but we’ve just got to make the best of it. We realise that this release is likely to come with issues, we’ve made upper management aware, but they want to proceed regardless.”
In summary, when faced with concerns about matters other than personal performance, managers should try to avoid responding with reassurances about the individual’s ability. It’s also important for the concerned party to press the point, not getting distracted by flattery, until their concerns are either accepted or refuted.