
How I stopped being awful at managing: Leadership lessons from a Dev - _ketanbhatt
https://hackernoon.com/how-i-stopped-being-awful-at-managing-leadership-lessons-from-a-dev-d1bfebcb3a21
======
planck01
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.

~~~
_ketanbhatt
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.

Feedback noted :)

------
bibbitybobbity
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...

~~~
_ketanbhatt
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
:)

