Why you should let your employees fail(s-fbi.com)
s-fbi.com
Why you should let your employees fail
http://www.s-fbi.com/2015/08/18/why-you-should-let-your-employees-fail/
10 comments
I guess if you have a big enough runway, this could work out. For most startups, letting your employees fail means letting your company fail when you run out of money. Nobody is going to give you more money when the stuff your employees were working on failed. Especially when they're trusting your resume to get the job done and you should have known better.
If those are your options, you shouldn't have employees, you should outsource the work.
And I'm not one usually in favor of outsourcing, but having employees is a whole different ballgame. If you can't let them fail, you're not building a team that will add value over outsourcing, so you're better off not taking on all of the complications that come with having employees.
And I'm not one usually in favor of outsourcing, but having employees is a whole different ballgame. If you can't let them fail, you're not building a team that will add value over outsourcing, so you're better off not taking on all of the complications that come with having employees.
I've spent most of my career as a full time employee, and recently I've become a 'consultant', which is a fancy term for contractor who works for a middle man. I've really become interested lately in the strategies behind using full time employees, when to outsource, why companies use contractors/consultants, etc.
Are there any good books/blogs on the subject matter that anyone knows about?
Are there any good books/blogs on the subject matter that anyone knows about?
You can't usually outsource work for share options, and most startups can't afford pure cash compensation for all work. And they can't afford to have their employees fail as all work in a brand new startup is usually critical.
EDIT: Just to make it clear: obviously employees and everyone else are going to fail sometimes, and you need to try have as much in place to survive that. However, failing on purpose for learning experiences is never the correct approach. You will have more than enough chance to fail in areas you don't have solutions for. Make sure you never fail in an area that you had the information to prevent.
EDIT: Just to make it clear: obviously employees and everyone else are going to fail sometimes, and you need to try have as much in place to survive that. However, failing on purpose for learning experiences is never the correct approach. You will have more than enough chance to fail in areas you don't have solutions for. Make sure you never fail in an area that you had the information to prevent.
That's exactly what I was thinking. Letting them fail is going to be expensive.
Not letting them fail when the fallout can be contained and managed will increase the risk that they fail in a way that you can't contain or manage further down the road.
I think both points of view are reasonable. You would have to evaluate each situation individually whether the benefits outweigh the risks.
One time, as a first-time techlead/manager struggling to get my team to deliver, I tried to let them play with the problem for a bit then give a few nudges in the right direction / the direction I wanted them to go. With some team members it was extremely effective. Others got tunnel vision on the wrong path and I was unable to reach a consensus with them on what a good solution looked like, which snowballed into an inconsistent codebase, and a divided team with morale problems. I probably wasn't the right person to manage this team, or maybe I don't have the same innate manager talents that this author has.
Not saying that my solution is always right, but i definitely think my inability to sell a cohesive technical direction to the entire team hurt the schedule/quality. I think hand-picking people whose opinions align with mine would have really helped the outcome, whether or not my solution was best. Perhaps detaching my ego from the outcome would have helped too. I wouldn't take another high pressure delivery responsibility role without hire/fire power.
Not saying that my solution is always right, but i definitely think my inability to sell a cohesive technical direction to the entire team hurt the schedule/quality. I think hand-picking people whose opinions align with mine would have really helped the outcome, whether or not my solution was best. Perhaps detaching my ego from the outcome would have helped too. I wouldn't take another high pressure delivery responsibility role without hire/fire power.
IMO this approach is definitely not one-size-fits-all. It's usually best to provide strong leadership up front in the form of clear expectations, but let people experiment in areas outside their comfort zone. This could mean putting some of the more junior team members underneath a senior developer -- the senior developer gets to experiment with management, and the junior developers benefit from some guidance.
Overall, you have to use techniques like this in the context of a situational leadership framework. There's a ton of reading material on situational leadership, but basically it comes down to recognizing the areas where people are knowledgeable and/or confident and providing the right kind of support. The "let 'em fail" tactic is great for people who are confident but not knowledgeable -- they learn something about the topic, and they learn about their own (lack of) understanding of said topic. There are many situations (when people are neither knowledgeable nor confident) that require you to do more hands-on management of your team -- and that's ok, since your goal is to help them move up the knowledge/confidence curve.
Very rarely do managers in our time have hire/fire power; in my experience it's very difficult to fire anyone for performance-related issues. Usually the best you can do is offer to swap your "problem children" with another manager and hope they do better in a new environment.
Overall, you have to use techniques like this in the context of a situational leadership framework. There's a ton of reading material on situational leadership, but basically it comes down to recognizing the areas where people are knowledgeable and/or confident and providing the right kind of support. The "let 'em fail" tactic is great for people who are confident but not knowledgeable -- they learn something about the topic, and they learn about their own (lack of) understanding of said topic. There are many situations (when people are neither knowledgeable nor confident) that require you to do more hands-on management of your team -- and that's ok, since your goal is to help them move up the knowledge/confidence curve.
Very rarely do managers in our time have hire/fire power; in my experience it's very difficult to fire anyone for performance-related issues. Usually the best you can do is offer to swap your "problem children" with another manager and hope they do better in a new environment.
Aah, the old "nudge them in a direction so when they figure it out they think it was their idea" trick. Very effective; but it takes a degree of trust in your subordinates (namely that they're smart enough to figure it out given enough time).
Anyway, if you take your primary job as a manager to be building your team's skills, it's absolutely the right way to go. People tend to remember lessons they learned the hard way, so I like to let my people fail in small ways because it's instructive.
Anyway, if you take your primary job as a manager to be building your team's skills, it's absolutely the right way to go. People tend to remember lessons they learned the hard way, so I like to let my people fail in small ways because it's instructive.
[deleted]
"Nage" is technique, and the person who applies a technique against an attacker is "tori". If the author can't get this right, I would suspect their understanding of the martial art is somewhat shallow.
Wait, you shouldn't tell him this, he should have learned that all by himself!
I don't agree with the author's view at all. If anything, it angers me when I trust a mentor to guide me and he lets me waste a week before I figure out by myself that the path was wrong from the start. Why do I need him then?
There are many ways one can learn. One is by trying, one is by listening to others. The latter is usually much cheaper in terms of time and resources. The major problem is that we sometimes can't find a suitable person to give us advice in a form we can hear. And now there is someone who preaches that one shouldn't help even when he knows how? Great. </rant>
I don't agree with the author's view at all. If anything, it angers me when I trust a mentor to guide me and he lets me waste a week before I figure out by myself that the path was wrong from the start. Why do I need him then?
There are many ways one can learn. One is by trying, one is by listening to others. The latter is usually much cheaper in terms of time and resources. The major problem is that we sometimes can't find a suitable person to give us advice in a form we can hear. And now there is someone who preaches that one shouldn't help even when he knows how? Great. </rant>
I think the key word you use here is "guide" - I completely agree that a mentor shouldn't _guide_ you down the wrong path.
...but maybe the mentor wasn't _guiding_ you, but enabling you (by answering your questions) to follow a path _you_chose_ and that turned out to be wrong.
This is important because if you always see yourself as following the mentor's path, you'll never take ownership and become a leader yourself.
As an experienced developer and personnel manager, I find it particularly frustrating when someone comes to me and says "you told me to do it this way, and now it doesn't work - fix it" because it shows that they're not taking any ownership.
Instead, I try to ask questions and make observations about their proposed approach to guide them to what I think is the best solution but, ultimately, they may choose an alternative route... and this might fail. At that point, they normally come back with "I've hit this problem, and it's mine to overcome, but can you help?"
...and I do, gladly. ;)
...but maybe the mentor wasn't _guiding_ you, but enabling you (by answering your questions) to follow a path _you_chose_ and that turned out to be wrong.
This is important because if you always see yourself as following the mentor's path, you'll never take ownership and become a leader yourself.
As an experienced developer and personnel manager, I find it particularly frustrating when someone comes to me and says "you told me to do it this way, and now it doesn't work - fix it" because it shows that they're not taking any ownership.
Instead, I try to ask questions and make observations about their proposed approach to guide them to what I think is the best solution but, ultimately, they may choose an alternative route... and this might fail. At that point, they normally come back with "I've hit this problem, and it's mine to overcome, but can you help?"
...and I do, gladly. ;)
In the end it is about knowledge sharing. You either tell someone that he might be headed in the wrong direction (he doesn't need to listen to you though) or you don't. If you tell him, he has more information on which he can base his decision. If you don't, you deprive him of the chance. I agree however that the decision is up to each individual.
There is also another view - I think it is good to let developers influence the decisions about technology used, but only up to a point. In the end it will be leader's problem if technology that some novice developer wanted to use fails to deliver (as it so happens).
EDIT: I do agree with you that developers need to own up to their challenges though. :)
There is also another view - I think it is good to let developers influence the decisions about technology used, but only up to a point. In the end it will be leader's problem if technology that some novice developer wanted to use fails to deliver (as it so happens).
EDIT: I do agree with you that developers need to own up to their challenges though. :)
I agree with you.
One of my largest pet peeves is when a new technical person comes and asks me how to do something without even googling it first. I don't mind guiding, I don't even mind giving hints and verbal cues to get you to the starting blocks. But if you're asking me to tell you how to do something without even developing questions to ask me, I'm annoyed.
I don't want to sound like a grumpy old man, but some of the new generation of thinkers seem to lack some intellectual curiosity that those of us without the internet had to endure in our early career stages.
Next, I'd like to introduce you to the 20 year old ruby developer who will set me straight in the follow up reply to my comment:
One of my largest pet peeves is when a new technical person comes and asks me how to do something without even googling it first. I don't mind guiding, I don't even mind giving hints and verbal cues to get you to the starting blocks. But if you're asking me to tell you how to do something without even developing questions to ask me, I'm annoyed.
I don't want to sound like a grumpy old man, but some of the new generation of thinkers seem to lack some intellectual curiosity that those of us without the internet had to endure in our early career stages.
Next, I'd like to introduce you to the 20 year old ruby developer who will set me straight in the follow up reply to my comment:
In the same vein, I get annoyed when older engineers expect me to ask how to implement something. You don't learn anything if you don't spend some time groping blindly in the dark.
Exploration, trial and error, deep diving into a problem are all better ways to learn than listening. Perhaps a combination of the two is best.
Well, you don't need a mentor.
> When you are the “Uke” you are taught not to give feedback to your partner.
Maybe in aikido, as I've never done it, but in the martial art I practiced for a while uke was feedback. The attacker sets the tempo for the technique, reacts to the tori's strikes, and while they're not supposed to apply the movement for them - they can lead the tori in the correct movement and suggest openings by being strong in some areas and weak in others.
While sharpening a movement, after both sides have some level of skill, they can provide feedback as to weak points in the technique - "I can stand up here, you don't have enough pressure or you haven't moved me off balance enough".
None of this feedback has to be verbal, but you can learn the techniques on both sides. Similarly, while people should learn from small failures, you don't want a catastrophic failure where you go and break uke's arm because someone didn't tell you that you were doing the wrong technique.
Maybe in aikido, as I've never done it, but in the martial art I practiced for a while uke was feedback. The attacker sets the tempo for the technique, reacts to the tori's strikes, and while they're not supposed to apply the movement for them - they can lead the tori in the correct movement and suggest openings by being strong in some areas and weak in others.
While sharpening a movement, after both sides have some level of skill, they can provide feedback as to weak points in the technique - "I can stand up here, you don't have enough pressure or you haven't moved me off balance enough".
None of this feedback has to be verbal, but you can learn the techniques on both sides. Similarly, while people should learn from small failures, you don't want a catastrophic failure where you go and break uke's arm because someone didn't tell you that you were doing the wrong technique.
When you are the “Uke” you are taught not to give feedback to your partner.
This is wrong. Both sides constantly learn from each other. Even the true Shihan learn from their senior students. Don't get me wrong the students are never like "hey sensei you should try this" but they do adjust and refine their skills just like everyone else (if you watch the right videos you can see it if you know what to look for).
The biggest problem I have with the article is this, he states, "he knows his employee will fail." That's not the Aikido way really. His approach should be something more like "I will let him try, so that we may both learn from this experience." Even the masters admit they don't know everything and that they can be surprised by the most novice of people at times. This is demonstrated through many of the samurai's approach to fighting (they avoid it when possible, because they know they might lose).
In my opinion this is a much better approach to management also. I know how to accomplish things, but I may not know the best way (or even the right way at times), and I won't know any more until I learn from someone else, even someone junior to me.
This is wrong. Both sides constantly learn from each other. Even the true Shihan learn from their senior students. Don't get me wrong the students are never like "hey sensei you should try this" but they do adjust and refine their skills just like everyone else (if you watch the right videos you can see it if you know what to look for).
The biggest problem I have with the article is this, he states, "he knows his employee will fail." That's not the Aikido way really. His approach should be something more like "I will let him try, so that we may both learn from this experience." Even the masters admit they don't know everything and that they can be surprised by the most novice of people at times. This is demonstrated through many of the samurai's approach to fighting (they avoid it when possible, because they know they might lose).
In my opinion this is a much better approach to management also. I know how to accomplish things, but I may not know the best way (or even the right way at times), and I won't know any more until I learn from someone else, even someone junior to me.
When I trained in aikido, "nage" was the thrower/defender. See, for example, http://aikido-west.org/handbook/uke_nage.html
Error establishing a database connection
Did some admin employee fail? We can't tell whether they were being let fail or failed all on their own, but I'd rate the failure as successful.
Did some admin employee fail? We can't tell whether they were being let fail or failed all on their own, but I'd rate the failure as successful.
"Error establishing a database connection"
Maybe you should rethink that rule when it comes to your sysadmins and database admins.
Maybe you should rethink that rule when it comes to your sysadmins and database admins.
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.
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.
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.)
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.)
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.
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.
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.
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.
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.
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.
> 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.
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.
>>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.
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.
> It seems self-centered to think that the best way to learn is to make the same mistakes that you did yourself
This wasn't assumed in the premise, though the mentored may for sure have some experiences that the mentor did.
Learning and internalization happen after we synthesize stories and narratives into lessons that we can deeply connect with.
If a junior teammate comes to me with a solution and I say "I tried it that way once and it didn't work because xyz," that teammate will change their execution and, from my experience, not really internalize the xyz. This means they'll come back to me in the future with the same problem and we'll go through that again, because they didn't learn.
The critical action in both success and failure is reflection. Discovering the lessons through discussion is the way for us both to learn, and to ensure the experience is meaningful and sticks.
This wasn't assumed in the premise, though the mentored may for sure have some experiences that the mentor did.
Learning and internalization happen after we synthesize stories and narratives into lessons that we can deeply connect with.
If a junior teammate comes to me with a solution and I say "I tried it that way once and it didn't work because xyz," that teammate will change their execution and, from my experience, not really internalize the xyz. This means they'll come back to me in the future with the same problem and we'll go through that again, because they didn't learn.
The critical action in both success and failure is reflection. Discovering the lessons through discussion is the way for us both to learn, and to ensure the experience is meaningful and sticks.
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.
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.
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.
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.
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.
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]
developers at s-fbi.com have failed at making this article live :P
like your server?