Skip to main content
Commonmark migration
Source Link

###Now

Now

I can't give you perfect advice on how to solve the current problem.

David and thursdaygeek seem to have covered this well enough, and I agree with thursdaygeek that getting your report involved in fixing their own mistake will be rewarding for everyone involved.

But I'd definitely shield them during and after the process, and take the mistake upon myself. The best managers create a bubble in which their reports can succeed.

###Going forward

Going forward

A favorite adage of a good dev manager in our company is:

Ask for forgiveness, not for permission

It is good to foster this, as it quells analysis paralysis, and when people have frequent victory, it will greatly boost their morale and productivity.

It sounds like your report is succeeding at that. I'd try to beef up their knowledge of the unknowns that caused this SNAFU, and make sure to set them up in similar more guided and hands-on situations so you can re-enforce the correct behaviors. Give them more chances to fail or succeed at similar scenarios.

A bad way to respond to this is to try to re-enforce the missing process knowledge group-wide. It ends up being the equivalent of public shaming (due to the always-present rumor mill), and I've seen it drive people to stall-out and eventually quit. If you feel a strong enough need to make sure it doesn't happen again, I wouldn't send out e-mails. I'd talk with each person one-on-one.

###Now

I can't give you perfect advice on how to solve the current problem.

David and thursdaygeek seem to have covered this well enough, and I agree with thursdaygeek that getting your report involved in fixing their own mistake will be rewarding for everyone involved.

But I'd definitely shield them during and after the process, and take the mistake upon myself. The best managers create a bubble in which their reports can succeed.

###Going forward

A favorite adage of a good dev manager in our company is:

Ask for forgiveness, not for permission

It is good to foster this, as it quells analysis paralysis, and when people have frequent victory, it will greatly boost their morale and productivity.

It sounds like your report is succeeding at that. I'd try to beef up their knowledge of the unknowns that caused this SNAFU, and make sure to set them up in similar more guided and hands-on situations so you can re-enforce the correct behaviors. Give them more chances to fail or succeed at similar scenarios.

A bad way to respond to this is to try to re-enforce the missing process knowledge group-wide. It ends up being the equivalent of public shaming (due to the always-present rumor mill), and I've seen it drive people to stall-out and eventually quit. If you feel a strong enough need to make sure it doesn't happen again, I wouldn't send out e-mails. I'd talk with each person one-on-one.

Now

I can't give you perfect advice on how to solve the current problem.

David and thursdaygeek seem to have covered this well enough, and I agree with thursdaygeek that getting your report involved in fixing their own mistake will be rewarding for everyone involved.

But I'd definitely shield them during and after the process, and take the mistake upon myself. The best managers create a bubble in which their reports can succeed.

Going forward

A favorite adage of a good dev manager in our company is:

Ask for forgiveness, not for permission

It is good to foster this, as it quells analysis paralysis, and when people have frequent victory, it will greatly boost their morale and productivity.

It sounds like your report is succeeding at that. I'd try to beef up their knowledge of the unknowns that caused this SNAFU, and make sure to set them up in similar more guided and hands-on situations so you can re-enforce the correct behaviors. Give them more chances to fail or succeed at similar scenarios.

A bad way to respond to this is to try to re-enforce the missing process knowledge group-wide. It ends up being the equivalent of public shaming (due to the always-present rumor mill), and I've seen it drive people to stall-out and eventually quit. If you feel a strong enough need to make sure it doesn't happen again, I wouldn't send out e-mails. I'd talk with each person one-on-one.

Source Link

###Now

I can't give you perfect advice on how to solve the current problem.

David and thursdaygeek seem to have covered this well enough, and I agree with thursdaygeek that getting your report involved in fixing their own mistake will be rewarding for everyone involved.

But I'd definitely shield them during and after the process, and take the mistake upon myself. The best managers create a bubble in which their reports can succeed.

###Going forward

A favorite adage of a good dev manager in our company is:

Ask for forgiveness, not for permission

It is good to foster this, as it quells analysis paralysis, and when people have frequent victory, it will greatly boost their morale and productivity.

It sounds like your report is succeeding at that. I'd try to beef up their knowledge of the unknowns that caused this SNAFU, and make sure to set them up in similar more guided and hands-on situations so you can re-enforce the correct behaviors. Give them more chances to fail or succeed at similar scenarios.

A bad way to respond to this is to try to re-enforce the missing process knowledge group-wide. It ends up being the equivalent of public shaming (due to the always-present rumor mill), and I've seen it drive people to stall-out and eventually quit. If you feel a strong enough need to make sure it doesn't happen again, I wouldn't send out e-mails. I'd talk with each person one-on-one.