
Why you should let your employees fail - frieze
http://www.s-fbi.com/2015/08/18/why-you-should-let-your-employees-fail/
======
RyanZAG
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.

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

~~~
OpenDrapery
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?

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

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

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

------
tux
Mirror: [https://archive.is/gWlZS](https://archive.is/gWlZS)

~~~
juhq
<marquee>Unavailable in your country</marquee>

Such class

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

~~~
annnnd
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>

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

~~~
god_bless_texas
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:

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

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

~~~
robin_reala
[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://www.s-fbi.com/2015/08/18/why-
you-should-let-your-employees-fail/&strip=1&vwsrc=0)

------
BrentOzar
"Error establishing a database connection"

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

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

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

------
Akashsharma
developers at s-fbi.com have failed at making this article live :P

------
stayparanoid
like your server?

------
desbo
You let whoever was in charge of your page's scrolling fail a bit too much.

~~~
ryanchartrand
lol

