I suggest three interesting exercises: - design a QA process for a software product. How important is "blame" vs team learning? What are the tradeoffs of a bl

I suggest three interesting exercises: - design a QA process for a software product. How important is "blame" vs team learning? What are the tradeoffs of a blame-oriented approach vs a systems oriented approach? - build something using AWS or App Engine infrastructure that makes you have to work around the various constraints imposed by the system designers. Consider how to make a system reliable when building it using "unreliable" services. - consider a Marxist interpretation of the US legal system. I'd argue that it constitutes a reasonable systems oriented critique, and makes it clear how (at least for me) pre-existing biases made it at first seem absurd. I suggest this mainly to highlight how biases can impact systems thinking. The QA process example is also deeply emotionally charged for many engineers but should not be.