|
|
|
|
|
by srndsnd
975 days ago
|
|
While what happened itself was less than ideal, I'd be curious if there are any more detailed explanations other than this account of what exactly happened, and how the issue was resolved. I'll certainly be on the lookout for more posts in this series. It's like a little bit like engineering "competency porn", but I enjoy stories like this. I read The Phoenix Project a few years ago, and while it was fictionalized and a heavy handed introduction to Agile and DevOps (I'm a data analyst so it was new to me), I liked it, and would like to read anything similar, if anyone has any recommendations. |
|
Here's one good excerpt:
Dickerson quickly established the rules, which he posted on a wall just outside the control center.
Rule 1: “The war room and the meetings are for solving problems. There are plenty of other venues where people devote their creative energies to shifting blame.”
Rule 2: “The ones who should be doing the talking are the people who know the most about an issue, not the ones with the highest rank. If anyone finds themselves sitting passively while managers and executives talk over them with less accurate information, we have gone off the rails, and I would like to know about it.” (Explained Dickerson later: “If you can get the managers out of the way, the engineers will want to solve things.”)
Rule 3: “We need to stay focused on the most urgent issues, like things that will hurt us in the next 24–48 hours.”