Interesting set of points; the intent to move beyond sterile dashboards and engage in deeper, more meaningful conversations about system health is very welcome, especially in a time when most leaders don't bother to read about Goodhart's law on metrics.
But still, I spot a few points of concern.
- While experienced engineers develop valuable intuition, this can also be a source of significant bias. An engineer's "feeling" might be influenced by their personal comfort with a particular technology, their resistance to change, or their own role in creating the system in question (the "IKEA effect"). Over-relying on intuition can lead to subjective decision-making that isn't backed by evidence.
- What is "simple" for a senior engineer with years of context might be overwhelmingly complex for a new team member. Furthermore, some business domains are inherently complex, and attempting to impose a simplistic model can lead to a system that fails to capture the necessary nuance and ultimately creates more problems.
- Informal discussions can be dominated by the loudest voices, the most senior people in the room, or those with the most social capital. Junior engineers or those with dissenting opinions may not feel comfortable speaking up, leading to a skewed and incomplete picture of the system's health. A more formal "safe space" approach might help here, to increase psychological safety perception of participants, for a better discussion.
- For large, legacy systems that have been in production for years, questions like "Can we explain the system's responsibility in plain English, within 5 minutes?" or "Do simple modifications you expect in hours, take many days?" can be demoralizing rather than constructive. They might highlight known, intractable problems without offering a clear path forward, leading to shame, anxiety and frustration.
But still, I spot a few points of concern.
- While experienced engineers develop valuable intuition, this can also be a source of significant bias. An engineer's "feeling" might be influenced by their personal comfort with a particular technology, their resistance to change, or their own role in creating the system in question (the "IKEA effect"). Over-relying on intuition can lead to subjective decision-making that isn't backed by evidence.
- What is "simple" for a senior engineer with years of context might be overwhelmingly complex for a new team member. Furthermore, some business domains are inherently complex, and attempting to impose a simplistic model can lead to a system that fails to capture the necessary nuance and ultimately creates more problems.
- Informal discussions can be dominated by the loudest voices, the most senior people in the room, or those with the most social capital. Junior engineers or those with dissenting opinions may not feel comfortable speaking up, leading to a skewed and incomplete picture of the system's health. A more formal "safe space" approach might help here, to increase psychological safety perception of participants, for a better discussion.
- For large, legacy systems that have been in production for years, questions like "Can we explain the system's responsibility in plain English, within 5 minutes?" or "Do simple modifications you expect in hours, take many days?" can be demoralizing rather than constructive. They might highlight known, intractable problems without offering a clear path forward, leading to shame, anxiety and frustration.