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.

Are there any good books/blogs on the subject matter that anyone knows about?

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.

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.

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.

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.

Such class

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>

...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. ;)

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. :)

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:

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.

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.

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.

Maybe you should rethink that rule when it comes to your sysadmins and database admins.

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

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.

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

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.

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.

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.

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.

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.