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.
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.
Feedback noted :)
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...
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 :)
