I think it's really important for individuals to take ownership and being accountable for things that didn't go as well as expected. At the same time, I think it's important to consider related systemic factors.
-
I think it's really important for individuals to take ownership and being accountable for things that didn't go as well as expected. At the same time, I think it's important to consider related systemic factors.
For example, if your organization is experiencing a high defect rate or many prolonged outages, then it's worth considering the ways in which the system is designed (explicitly or implicitly) to encourage these failures.
It's the only way to fix actual problems.
-
@jawnsy Conway's Law, in a nutshell
-
@vwbusguy I think it's related, but distinct. Conway's Law refers to a system architecture mapping to a team structure (e.g. two teams, two components; four teams, four components.) But I'm thinking more in the vein of Systems Thinking and Stocks & Flows. For example, you have some defect rate, and you fill the team's schedule with feature work. The defects can only be handled through heroic means or as a distraction from the feature work, for which engineers are incentivized.
-
Scott Williams 🐧replied to Jonathan Yu last edited by [email protected]
@jawnsy That was ESR's understanding of Conway's Law, but other interpretations are closer to what you're suggesting and basically how the software produced will reflect the organization/communication/culture that produced it. It's why most tech problems are actually people problems that require some kind of culture change to address.