Several years ago, when I was just an engineer, I found myself being assigned the task to run some 640 tests to verify a design. As I recall, I had the Friday and the weekend to do this and we had a release dateline to meet come the following Monday. These 640 tests will need a good part of the weekend to complete and we are not expecting any problem. Come the following Monday, we had a clean results (i.e., it passed all the 640 tests) but i realized when I checked everything just to be sure, I had ran some tests with incorrect parameters. Worried that this mistake may delay the release and not wanting to be the person to cause the delay, I lied and declared that all was fine and that we are good to go. While my colleagues prepare to release the design, I worked franticly to re-run those affected tests with the correct parameters. I was very lucky that the design did pass all the 640 tests passed when ran against the correct parameter settings.
About a year after that, I became the project leader for a very similar work but at another company. In the first meeting I had with my team, I told everyone that it is absolutely OK to declare their mistake(s) in my team. Everyone were either puzzled and/or poking fun at what I said. I explained that only by doing so, will the team have the necessary information to know how best to channel resources when something goes wrong and that will allow the team to meet it datelines in the most effective way without impact on quality. The idea here is as follows. If you are the project leader/manager, you will want to know if there is anything that can have an impact on the project. And the easiest most effective way to know about it is to make it safe for your colleagues to tell you about it. It is better to know about these problem(s) earlier where you can channel your resources to rectify them than to allow them to stay hidden where they can bite you at the most embarrassing moment.
To be honest, a strict review or quality gating process to validate the test results of the 640 tests could have done the job as well. However, neither of these approaches on their own is 100% fool proof. I will employ both if I were to find myself in the same position again. Creating a safe environment for people work and even to declare their mistake, free them from having to spend time looking over their shoulder and to focus on doing what adds/creates value.
As usual, this is a real story, but the identity of the person may have been altered and I may not have remembered all the details correctly.