11 ms·

I agree, but I do wonder about the balance of delegating autonomy vs micro-managing. I've seen some developers never really grow or progress because there was a

I agree, but I do wonder about the balance of delegating autonomy vs micro-managing. I've seen some developers never really grow or progress because there was always someone holding their hand, telling them what to do, and not letting them experience the viscera of failure or fear. That's not to say you aren't on the money, but I ponder. I should have worded the question a bit differently as it wasn't completely obvious to me that production was going to break. I let the developer own their change, but my spidey sense was tingling a bit.

drpossum 2y ago
It's clear their autonomy isn't good, though. People only improve with experience and a willingness to improve and helping can be a good form of getting experience quickly. The developers that don't get better after handholding are just bad and should be let go.
- Desafinado 2y ago
  That's a good point, thank you.
  - ozzydave 2y ago
    I’d highly recommend looking up “Situational leadership” if you’re worried about coming off as micro-managing. You need to adapt how you’re mentoring based on the mentees skill and confidence.
    - Desafinado 2y ago
      That makes sense. In this situation it was a bit tricky as I didn't actually know the developer at all (different team), but I should have picked up on it.
brudgers 2y ago
Mentoring is not micro-managing. It is not managing at all.
solardev 2y ago
Sure, blowing something up can be a great teacher. At two previous jobs, I crashed prod on my first day there (and then fixed that bug, and made the sites much more resilient by the time I left). But lol, it would've also been fine if someone just told me "hey hold on, that might crash prod, let's double-check something first". Most people should respond well enough to gentle guidance genuinely delivered in the spirit of collaboration. It shouldn't take a fire on prod to make them realize their error... if that's the only way they are able to learn, it's going to very rough for their career, their team, and any org they're working for.
lostdog 2y ago
In this situation, you can macro-manage. Suggest to the junior that they test for the given edge case. Let them figure out how to write the test on their own. If they push back on doing the testing, then back off and let them deal with a prod failure. It's good to help people when they didn't notice something key, and on their first time experiencing something. The bad thing is to repeatedly help them on the same thing they should have learned the last time it came up.
- tbrownaw 2y ago
  If the app is anything actually important, I'd think there should be standards around testing. Which given the scenario, would have to either be inadequate or not have been communicated properly to the newbie (or they were communicated effectively and aren't being followed, which would be a different kind of issue).
viraptor 2y ago
There's a lot of assumption about mentoring here and they're not great. Specifically: - When mentoring you're not supposed to remove autonomy. In this case, the first contact can be just: Hi, this seems a new complex area to you. WOULD YOU LIKE me to tell you about how we make these changes safer or answer YOUR QUESTIONS? - Mentoring is not managing or micro managing. You don't need to do any hand holding. Instead it can be knowledge transfer about a concept. "I think you're going to have problems because... You can read up on XYZ or look at (example from the past) to learn more." - "not letting them experience the viscera of failure or fear" What's the point? They're adults. We don't teach people to watch out when crossing the road by hitting them with a car. I mean, all those points apply to seniors too. The only difference is that you're proactivly reaching out to say "knowledge transfer is possible and probably a good idea right now - would you like to do that?"
tbrownaw 2y ago
> I've seen some developers never really grow or progress because there was always someone holding their hand, telling them what to do Are you sure that cause and effect don't run in the opposite direction here. > and not letting them experience the viscera of failure or fear. Um, what? Being terrified of messing up is not necessary for learning.

drpossum 2y ago

It's clear their autonomy isn't good, though. People only improve with experience and a willingness to improve and helping can be a good form of getting experience quickly. The developers that don't get better after handholding are just bad and should be let go.

Desafinado 2y ago
That's a good point, thank you.
- ozzydave 2y ago
  I’d highly recommend looking up “Situational leadership” if you’re worried about coming off as micro-managing. You need to adapt how you’re mentoring based on the mentees skill and confidence.
  - Desafinado 2y ago
    That makes sense. In this situation it was a bit tricky as I didn't actually know the developer at all (different team), but I should have picked up on it.

brudgers 2y ago

Mentoring is not micro-managing. It is not managing at all.

solardev 2y ago

Sure, blowing something up can be a great teacher. At two previous jobs, I crashed prod on my first day there (and then fixed that bug, and made the sites much more resilient by the time I left). But lol, it would've also been fine if someone just told me "hey hold on, that might crash prod, let's double-check something first". Most people should respond well enough to gentle guidance genuinely delivered in the spirit of collaboration. It shouldn't take a fire on prod to make them realize their error... if that's the only way they are able to learn, it's going to very rough for their career, their team, and any org they're working for.

lostdog 2y ago

In this situation, you can macro-manage. Suggest to the junior that they test for the given edge case. Let them figure out how to write the test on their own. If they push back on doing the testing, then back off and let them deal with a prod failure. It's good to help people when they didn't notice something key, and on their first time experiencing something. The bad thing is to repeatedly help them on the same thing they should have learned the last time it came up.

tbrownaw 2y ago
If the app is anything actually important, I'd think there should be standards around testing. Which given the scenario, would have to either be inadequate or not have been communicated properly to the newbie (or they were communicated effectively and aren't being followed, which would be a different kind of issue).

viraptor 2y ago

There's a lot of assumption about mentoring here and they're not great. Specifically: - When mentoring you're not supposed to remove autonomy. In this case, the first contact can be just: Hi, this seems a new complex area to you. WOULD YOU LIKE me to tell you about how we make these changes safer or answer YOUR QUESTIONS? - Mentoring is not managing or micro managing. You don't need to do any hand holding. Instead it can be knowledge transfer about a concept. "I think you're going to have problems because... You can read up on XYZ or look at (example from the past) to learn more." - "not letting them experience the viscera of failure or fear" What's the point? They're adults. We don't teach people to watch out when crossing the road by hitting them with a car. I mean, all those points apply to seniors too. The only difference is that you're proactivly reaching out to say "knowledge transfer is possible and probably a good idea right now - would you like to do that?"

tbrownaw 2y ago

> I've seen some developers never really grow or progress because there was always someone holding their hand, telling them what to do Are you sure that cause and effect don't run in the opposite direction here. > and not letting them experience the viscera of failure or fear. Um, what? Being terrified of messing up is not necessary for learning.