I was at a lunch seminar about trust in the workplace and how to measure it, and while the seminar itself didnāt mention QA in any way, I of course immediately started thinking about how trust could impact quality and process efficiency. 
I tried to read up some more on the topic and summarised my thoughts in a document:
Does anyone here have any thoughts about how trust could impact quality and efficiency in software development?
Best regards,
Johan
We could talk about trusting people to be on board, to do the right thing, to make a good-faith effort and to not falsify information.
We could talk about trusting what people tell us is true, or trusting an instruction or tacit understanding.
If you want to talk about the uniqueness of the testerās perspective, we often distrust on purpose. Or, I suppose, simulate distrust in service of the truth. We listen, but do not necessarily believe. Even if we have āaffect-basedā trust in a person we often leverage ācognition-basedā distrust in them. We challenge assumptions and beliefs in things to find what those assumptions and beliefs might be hiding. Co-workers or businesses permitting testers to look for problems is itself a position of distrust - but a useful and productive one based in humility and an understanding of fallibility.
With regard to trust in general I read the last part about the need for highly formalised artefacts in low-trust environments, and that thinking mirrors my own. If thereās little trust for employees to do what we want them to do, then thereās a tendency to provide explicit instruction and dedicate observation and measurement to them to try to enforce desired behaviours. There has to be some trust in both their ability and motivation to find problems.
The article goes a bit deeper than the basic trust ideas but I can relate to the connection with testing.
Its partly linked to high levels of hierarchy and command and control management styles. Common language used primarily to tell people what to do and do it the same as everyone else.
Testing though can become a bit shallower as a result, with more waste going towards a model that overly favours evidence of testing taking people away from actual testing. It perhaps shifts testing more towards a manufactoring controlled model rather than a prototyping model that embraces discovery and experiments.
I strongly prefer trusted and empowered but I have also worked with people what wanted to to be told exactly what to do so they can get on with it. That may be a cultural element as I saw it as more common in hierarchical structures but it may still be surprising because there is often an assumption trusted is better and preferred by everyone.
Trust can take time to build particularly when you outsource testing for the first time and there is probably a model that suits that building trust level.
As you touch on, I think there is something interesting to think about that if you have āemotional trustā towards a developer will it negatively impact your ability to do your job as a tester because it biases you to think everything is working as intended, while you would have been much more critical from the start if you had low āemotional trustā towards the developer?
Obviously the optimal situation is that you have high āemotional trustā and then take into account the biases that creates and donāt let that trust affect your work.