The topic is interesting, but the story didn't contain what I was looking for. It doesn't describe how the manager was awful and how it was improved, nor how it was measured that things improved.<p>Actually, the rather non-connected tips don't really resonate with me. I am also a dev who became manager. I don't even involve myself with sprint planning and day-to-day monitoring of small tasks. I have enough devs that are capable of doing that, so I delegated those tasks. I trust them.<p>I mostly try to provide structure where needed, help my teams with escalation and solving of problems. Content wise I try to set out the grander vision about in which direction we move (of course with input from the teams) and have content wise discussion with my teams every few weeks. For the rest it is mostly developing your people and making sure they love their work, they have everything they need, listen to them when they need that and help them where possible.
I've personally experienced the "effective pause" and strongly feel against it. This assumes that software engineers always have ideas on how to fix things and are not autonomous.<p>In my opinion, it's helps much more to break down/simplify the engineer's thought and the problem they are trying to solve. And then, try to solve it together...