Not only is being able to get to the raw data not micromanaging, it's good management. Richard Feynman spoke about how he stopped trusting values simply becaus

Not only is being able to get to the raw data not micromanaging, it's good management. Richard Feynman spoke about how he stopped trusting values simply because they came from some authoritative source after getting burned once. After that he calculated things himself. That lesson relates to the "global telecommunications giant" in the story, whose "critical network software upgrade" was turning into a disaster. In fact, I recently went through a similar situation myself at a job; well before I got there, technical leadership had planned out an overly-ambitious, complex and time-consuming whole-scale rewrite of a critical service, and when I arrived, they were chest-deep in shit creek. As the team sunk lower and lower, I felt compelled to reach out to higher-ups. That's how I lost my head. I hear their collective hair is still on fire. Is the lesson there that I should have kept more quiet? I'm still not sure. But what is clear to me is that non-technical leadership need to be able to properly assess the risks of technical decisions. As the story mentions, one of the best ways to do that is to get someone from outside the team to analyze the process and the progress. Because even someone half-competent will be able to tell you when some major upgrade creates a major risk, and the best way to mitigate that risk is to divide-and-conquer the major task into minor ones. Another key smell is how "the program managers' key performance indicator dashboards showed nothing alarmingly unusual". I would dare say that those dashboards are then fundamentally broken. One fix: edw519 has written about the need for task progress to either be 100% or 0%, as a way to flush issues out of the woodwork. Fred Brooks is right: we're still stuck in the tar-pits. Maybe we'll find our way out in the next 45 years...