Toots from 2023-03-30
In general, my preference is to reframe an increase in operational load as constructive forward l…
In general, my preference is to reframe an increase in operational load as constructive forward looking system improvements (availability, utilization, documentation, incident responsiveness, latency) that can be prioritized against feature deliverables. Moving from resolving a “why was my request slow” ticket to “improve E2E p99 performance by NN%”. (Insert me handwaving disclaimers and situational factors here…).
Mastodon Source 🐘
Reframing this way makes operations less a time tax than a peer of functional capabilities. Operations is part of design and daily work. There are usually systemic factors beneath isolated tickets. Increasing ops capacity can help drive those metrics down and the types of improvements required to affect the conditions producing those tickets often can’t be achieved in rotation windows/dealing with the tickets.
Mastodon Source 🐘
Only operations produces observable data. Functional improvements (until they are delivered and verified) have exclusively speculative impact.
Mastodon Source 🐘
“As a manager, this simplest thing you can do to avoid the bring me a rock phenomenon is to be …
“As a manager, this simplest thing you can do to avoid the bring me a rock phenomenon is to be clear on your expectations. If you aren’t sure what you want, set up the task as an experiment with rapid iterations. That way, it’s clear that the correct outcome isn’t known in advance and no one feels like they failed.”
https://jonathanbecher.com/2020/08/30/the-bring-me-a-rock-phenomenon/
Mastodon Source 🐘
“Every system is stretched to operate at its capacity. As soon as some improvement, some new te…
“Every system is stretched to operate at its capacity. As soon as some improvement, some new technology, exists, practitioners (and leaders, managers, and so on) will exploit it by achieving a new intensity and tempo of activity.”
https://ieeexplore.ieee.org/document/1392678