5 ms·

It's also important to let your admins fail, and let the people and systems improve based on what you learn from the failure. Being completely risk averse crea

by bbrazil 11y ago

It's also important to let your admins fail, and let the people and systems improve based on what you learn from the failure. Being completely risk averse creates an environment where it's very difficult to improve, for fear that your good change will happen to cause a problem and you'll get blamed for it.

BrentOzar 11y ago
That's not what the article is about - the article explicitly talks about when you know the employee's approach won't work and you'll have to do their work over, let them fail anyway without telling them in advance. That's not being risk averse. That's bad management. A manager's role is also that of a mentor, helping your employees leapfrog over obstacles you've encountered in the past. (Don't get me wrong, there's a wrong way to do it - micromanagement.)
- mattlutze 11y ago
  Part of mentoring is letting the mentored fail and working through the after-action and identifying the learning opportunities. Controlling for how big or how expensive that failure is are both necessary components of the task; don't let them fail in a way that's going to torpedo the company. But only being told how to do something makes a person a good follower and does nothing for their innovative or problem-solving skills. That's also bad management. A successful professional needs a back catalog of failures and misses to understand why to do something.
  - enraged_camel 11y ago
    Yes, exactly. Mentorship is about guidance, not hand-holding. It is about asking questions the inexperienced employee may not have thought of on their own, but also letting them find the optimal solution on their own. For example, if they are designing a backup solution for the first time, asking them "what will the system do if the backup media is full?" is good. Telling them what it should do when full is bad. By asking the question, you're basically teaching them that there should be a contingency in case of failure. From there, a discussion on possible solutions can take place, where the mentor once again guides the employee to figure out the pros and cons of each approach. That said, I'd never knowingly let people fail. Even without that, any good professional will have plenty of failures anyway. If they don't, they are playing it too safe and aren't learning some important lessons, and it might be time to assign them more challenging projects.
    - rustynails 11y ago
      That's a fantastic comment and example. Know your answer. Ask the question. I also highly respect Pixar's model - encourage collaboration and feedback between peers. I'm managing a team at the moment. We are a democratic group. I mostly ask Questions to steer toward success. The team (mostly women) are empowered to own, experiment, share and collaborate. It's been a fantastic experience. Interestingly, when we started, there was a lot of sass about gender superiority - but that's gone away since I expressed several times that we are all people, no other attitude will be tolerated.
    - tveita 11y ago
      > Even without that, any good professional will have plenty of failures anyway. That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together? It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. It also assumes you can predict every problem they'll encounter well enough to precisely ration out additional obstacles.
      - enraged_camel 11y ago
        >>That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together? People learn differently from experience than they do from being told something. >>It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. That's the thing though: people rarely make the same mistakes as you did. They tend to make different mistakes, and fail differently, with different results and consequences. By serving the solution to them on a silver platter, you're robbing them of very valuable learning opportunities. A mentor's job is to use their experience to guide the employee and help them figure out how to avoid mistakes. And if they do make a mistake, then the mentor is there to help them recover. The recovery is followed by by what I call "lesson time", which is a judgment-free session where we discuss why the incident or failure happened and come up with actionable steps to prevent it from happening again. If you find yourself in situations where you absolutely have to tell someone how to do something because failure would be fatal, at that point you should do that thing yourself, and have the employee watch you do it and take notes. That's another type of mentorship that a lot of people are not comfortable with, but it can be extremely valuable.
  - jawilson2 11y ago
    When I was a professor mentoring students, my approach could vary depending on the student and situation. If a student felt strongly about doing something a certain way, I might say "I would be surprised if this worked (because of XYZ), but prove me wrong!" There have been occasions where I was wrong, and many others where they failed but learned along the way. If it is a more time-critical or important project, then I will probably provide more guidance depending on the context ("give this a try first, and check back when you have results; if you're not happy, we can try your way"). This approach has carried over to industry well for me.
- mcguire 11y ago
  Let them fail: Second best case is that they fail, learn something, and are either open to suggestions or have better ideas the next time around. Either way, you have to re-do the project. Best case, they succeed, and you learn something. Second worse case is that they fail, don't learn anything; lather, rinse, repeat. The worst case? They produce a semi-functional failure and you have a shambling horror of a monstrosity to support until you finally give up and resign. Don't let them fail: Second best case: You mentor them into a failure, but they learn something and you learn something. That's sort of good, right? The best case is that you mentor them into a success, they learn stuff and you have a functional project. The second worst case is that you beat them into submission and get a functional project, but they resent you for not letting them do things their way; they haven't learned anything. The worst case is that you mentor them into a failure, catch all the blame for it, and they're now mentoring you. (And yes, I'm explicitly assuming that you are ten times as skilled and experienced as they are; this is a very bad thing.) Now, it may just be my experience, but the best cases on either side are entirely theoretical. I've only personally experienced variations on the worst cases. But, I've also worked in government contracting (that may be redundant). There are a lot of hard-headed, not-especially-competent junior devs out there. The bottom line is that you should just do it yourself---it'll generally save you a lot of grief.
  - whatnotests 11y ago
    This exactly. I'd love to find some way to deal with the politics of the case where you end up with the shambling semi functional monstrosity. Watching someone who is clearly out of their depth trying like hell to save face while time slips past and the software doesn't improve is very frustrating.
tired_man 11y ago
There's a difference between being adverse to failing at some task and not wanting your venture to crash. For vital infrastructure, it's more important that those "failures" be more in the way of the dba or sa needing to look up how to make something work properly, than actually fry the server instance and wipe your data.
deleted 11y ago
[deleted]

by bbrazil 11y ago

BrentOzar 11y ago

That's not what the article is about - the article explicitly talks about when you know the employee's approach won't work and you'll have to do their work over, let them fail anyway without telling them in advance. That's not being risk averse. That's bad management. A manager's role is also that of a mentor, helping your employees leapfrog over obstacles you've encountered in the past. (Don't get me wrong, there's a wrong way to do it - micromanagement.)

mattlutze 11y ago
Part of mentoring is letting the mentored fail and working through the after-action and identifying the learning opportunities. Controlling for how big or how expensive that failure is are both necessary components of the task; don't let them fail in a way that's going to torpedo the company. But only being told how to do something makes a person a good follower and does nothing for their innovative or problem-solving skills. That's also bad management. A successful professional needs a back catalog of failures and misses to understand why to do something.
- enraged_camel 11y ago
  Yes, exactly. Mentorship is about guidance, not hand-holding. It is about asking questions the inexperienced employee may not have thought of on their own, but also letting them find the optimal solution on their own. For example, if they are designing a backup solution for the first time, asking them "what will the system do if the backup media is full?" is good. Telling them what it should do when full is bad. By asking the question, you're basically teaching them that there should be a contingency in case of failure. From there, a discussion on possible solutions can take place, where the mentor once again guides the employee to figure out the pros and cons of each approach. That said, I'd never knowingly let people fail. Even without that, any good professional will have plenty of failures anyway. If they don't, they are playing it too safe and aren't learning some important lessons, and it might be time to assign them more challenging projects.
  - rustynails 11y ago
    That's a fantastic comment and example. Know your answer. Ask the question. I also highly respect Pixar's model - encourage collaboration and feedback between peers. I'm managing a team at the moment. We are a democratic group. I mostly ask Questions to steer toward success. The team (mostly women) are empowered to own, experiment, share and collaborate. It's been a fantastic experience. Interestingly, when we started, there was a lot of sass about gender superiority - but that's gone away since I expressed several times that we are all people, no other attitude will be tolerated.
  - tveita 11y ago
    > Even without that, any good professional will have plenty of failures anyway. That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together? It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. It also assumes you can predict every problem they'll encounter well enough to precisely ration out additional obstacles.
    - enraged_camel 11y ago
      >>That's the main thing to me. Why waste people's time on known dead ends when you can fail on things that matter, together? People learn differently from experience than they do from being told something. >>It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself. That's the thing though: people rarely make the same mistakes as you did. They tend to make different mistakes, and fail differently, with different results and consequences. By serving the solution to them on a silver platter, you're robbing them of very valuable learning opportunities. A mentor's job is to use their experience to guide the employee and help them figure out how to avoid mistakes. And if they do make a mistake, then the mentor is there to help them recover. The recovery is followed by by what I call "lesson time", which is a judgment-free session where we discuss why the incident or failure happened and come up with actionable steps to prevent it from happening again. If you find yourself in situations where you absolutely have to tell someone how to do something because failure would be fatal, at that point you should do that thing yourself, and have the employee watch you do it and take notes. That's another type of mentorship that a lot of people are not comfortable with, but it can be extremely valuable.
- jawilson2 11y ago
  When I was a professor mentoring students, my approach could vary depending on the student and situation. If a student felt strongly about doing something a certain way, I might say "I would be surprised if this worked (because of XYZ), but prove me wrong!" There have been occasions where I was wrong, and many others where they failed but learned along the way. If it is a more time-critical or important project, then I will probably provide more guidance depending on the context ("give this a try first, and check back when you have results; if you're not happy, we can try your way"). This approach has carried over to industry well for me.
mcguire 11y ago
Let them fail: Second best case is that they fail, learn something, and are either open to suggestions or have better ideas the next time around. Either way, you have to re-do the project. Best case, they succeed, and you learn something. Second worse case is that they fail, don't learn anything; lather, rinse, repeat. The worst case? They produce a semi-functional failure and you have a shambling horror of a monstrosity to support until you finally give up and resign. Don't let them fail: Second best case: You mentor them into a failure, but they learn something and you learn something. That's sort of good, right? The best case is that you mentor them into a success, they learn stuff and you have a functional project. The second worst case is that you beat them into submission and get a functional project, but they resent you for not letting them do things their way; they haven't learned anything. The worst case is that you mentor them into a failure, catch all the blame for it, and they're now mentoring you. (And yes, I'm explicitly assuming that you are ten times as skilled and experienced as they are; this is a very bad thing.) Now, it may just be my experience, but the best cases on either side are entirely theoretical. I've only personally experienced variations on the worst cases. But, I've also worked in government contracting (that may be redundant). There are a lot of hard-headed, not-especially-competent junior devs out there. The bottom line is that you should just do it yourself---it'll generally save you a lot of grief.
- whatnotests 11y ago
  This exactly. I'd love to find some way to deal with the politics of the case where you end up with the shambling semi functional monstrosity. Watching someone who is clearly out of their depth trying like hell to save face while time slips past and the software doesn't improve is very frustrating.

tired_man 11y ago

There's a difference between being adverse to failing at some task and not wanting your venture to crash. For vital infrastructure, it's more important that those "failures" be more in the way of the dba or sa needing to look up how to make something work properly, than actually fry the server instance and wipe your data.

deleted 11y ago

[deleted]