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.
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.
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.
Makes sense.
1. The manager (me) was awful at all the three things mentioned in varying degree, and what is written is what I learnt from my experience.
2. Yes, could have mentioned the measuring part. Thank you for the feedback
3. The tips weren't supposed to be connected. They are just a collection of unconnected learnings.
4. Well there are different kinds of teams, and each one needs looking after differently. In our case, these teams are very small, and in some of them I was the only dev (not counting the Machine Learning Engineers). So for some teams day-to-day monitoring makes sense, while for some it won't.
5. What you described as your job is more or less what I do as well, I think it didn't come out like that in the article maybe? Except that it is not "every few weeks" in my case, but twice-thrice every week.
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.
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...
1. I do think that the kind of people we have on our team will almost always have some ideas to fix things.
2. The break-down and simplifying happens, of course. But the dev leads the breaking down, with careful guidance by the lead. And it is being solved together, don't you think? The example didn't describe the full end to end design process, but just a part of it which was relevant to explain the point. I think I could have made it more clearer. Thank you for the feedback, noted :)
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.
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.