> Handle bad results in the same way that the NTSB deals with plane crashes - find the flaws in the system instead of somebody to blame.
Definitely. I'd like to see a lot more of that, but the default often seems to be blame.
I recall a system at a place I worked where the stakeholders (native or skilled non-native English speakers) would produce requirements by holding meetings with the developer (much less skilled non-native speaker), dictate what they wanted, and have the developer take notes (which the stakeholders would not check) then immediately implement the software.
When the resulting software was built incorrectly they would blame the developer for incompetence, and hold another meeting.
> Handle bad results in the same way that the NTSB deals with plane crashes - find the flaws in the system instead of somebody to blame.
Definitely. I'd like to see a lot more of that, but the default often seems to be blame.
I recall a system at a place I worked where the stakeholders (native or skilled non-native English speakers) would produce requirements by holding meetings with the developer (much less skilled non-native speaker), dictate what they wanted, and have the developer take notes (which the stakeholders would not check) then immediately implement the software. When the resulting software was built incorrectly they would blame the developer for incompetence, and hold another meeting.