Failure

Many people have what I believe to be a misguided fear of failure.  Fear of public humiliation?  Losing your job?  Harming your reputation?  Perhaps you’re a perfectionist who thinks they can’t live with failure.  Fear can paralyze and hold back our most talented people and when they aren’t putting forth their most daring work due to fear of failure or the consequences thereof something must change.

In the software development space failure is usually defined quantitatively as being over budget, under featured, behind schedule, or qualitatively as having poor quality, or in some cases that it just doesn’t feel or work quite right.  The period of time over which these failures occur tend to be on the order of months or years, usually to the detriment of everyone involved.  But could this have been avoided?  Were the signs there all along?  Hopefully teams and organizations that encounter these types of long running failures have the courage to ask these questions, answer them, and act on the answers, but I suspect far too many do not.

The fact is that failure at some, and often many levels is unavoidable.  Once you realize this, you can accept it and embrace it.  That is what we all must do: stop fearing failure and embrace it.  However, as with anything there are responsible ways of going about this, and not so responsible ways.  Should we seek to fail from the beginning?  No, that’s not the point.  The point is to recognize some failure, however small, (e.g. this code didn’t work, the schedule slipped, Bob just quit, etc.) and learn from it.  An unrecognized or ignored failure means that not only have you failed, you just missed a growth opportunity and have truly wasted your time.

But how can we encourage giving our people the freedom and flexibility to bring daring ideas to life without burning everything to the ground and descending into bankruptcy and code cowboy anarchy?  If my thesis is that failure is worse if realized over a long time period, the logical thing would be to decrease the time window in which the failure occurs.  There are many things you can do to shorten this window without being overbearing or invasive in day-to-day work.

With Projects

Make sure you are capturing real-time stats of where your group is on your roadmap relative to where you think you should be.  This will allow you to have a constant pulse on the general direction of your work.  An example would be a burndown chart at the project level or a similar tracking method at the organizational level.  At the project level I’m a fan of the Greenhopper burndown chart format.

In such a format if you find yourself continually over the ‘guideline’ you will want to find out why.  Maybe the team is overoptimistic with their estimates?  Maybe the team is being so rosy because they feel the real estimates wouldn’t be accepted?  Maybe estimates are being advertised as commitments when they were never meant to be?  Maybe the team isn’t the one making the estimates?

Asking these questions will allow you to course-correct over shorter time periods while keeping everyone happy and well informed.  This frequent analysis and adjustment can help prevent long running failures.

Day-To-Day

Wouldn’t it be great if we could compress realized failures into a single day instead of over several months?  For many things we do as developers this can be done; we have the technology.

Be sure to set up productive development environments with super low friction using tools like Autotest or Watchr.  Tools like this allow you to automate your workflow using simple triggers (like saving a source file) to do things automatically that you would otherwise have to break your train of thought to do.  For example, I have my Watchr scripts set up to build the project, run the unit tests, and then for an embedded project, deploy the same unit test harness to a real device and run it there.  This type of low friction environment allows you to focus on what you’re really working on and most importantly gets you that feedback more quickly.  It might only be 10-15 seconds faster, but it adds up.

At a less technical level, if you don’t know the answer to something, ask, don’t guess. Turn to the person sitting next to you and ask.  If they don’t know, keep going until you find someone who does, even if that means contacting the customer.  Ideally the person sitting next to you is your customer, but that’s a different post.  Your customer is invested in this and you owe it to them to avoid speculation where possible.  The longer you wait to get an answer, the longer that assumption lives in your system, which can start the timer on a long running failure.

With People

Make sure that you instill a sense of purpose and pride into your teams from the beginning.  Make sure that they understand why your organization is in business and the significance of what they are working on.  They must feel like they belong and that they are contributing to something of value.  Empower them to really own their work and they will exceed your wildest expectations.  An environment like this is also likely to have lower turnover than the alternatives.

Above all, challenge them, but don’t break them.  Make sure your management knows their people, their abilities, and their limits.  Better yet, make sure your people know their own abilities and limits!  Then have them placed in a team a little above their current abilities but not beyond their limits.  Make sure they have team members who can and will act as teachers and mentors who can also help reduce that risk of long running failure.

With New Ideas

Make sure that ideas are received and evaluated on merit.  A good idea shouldn’t be overlooked simply because it came from the new guy, the old guy, or the guy with a new idea every day (enthusiasm!).  Most importantly, make sure that your people know that this is how these things will be handled.  Be active about it, prove that you’re willing to put your money where your mouth is.  Don’t just put out a suggestion box, you’re all in this together and your people want to be as big a part as they can.  Let them.

Encourage, but constrain exploration.  If these new ideas have merit, charge the person who proposed it with running it down.  Give them a couple weeks to flesh out the idea.  If they show progress, give them a couple more weeks.  If they don’t, maybe it still warrants more exploration, or maybe it gets killed dead.  Either way, two weeks lost is better than 6 months or years, you’ve all learned something, and hopefully grown a little in the process.  Ideas that show promise can can grow into a great new feature, new product, or totally new venture.  Left unknown and unevaluated it’s nothing more than a missed opportunity.

You could also constrain a new effort on budget.  I get the impression from Fred Wilson at Union Square Ventures that this is how they do it.  Start them with minimal funding on a truly ‘lean’ basis and fund them further when concept, production, and execution show positive signs.  I’m positive this is an oversimplification, but hopefully my point is made.  I’m sure that a welcome side-effect of this type of constrained environment is that the team (or company, as it would be) will know how to operate within these constraints should the need ever arise again (money isn’t infinite after all).

Have Courage!

In conclusion.  Have courage, put structure in place to recognize impending failure early, empower your people, and above all, learn from your mistakes.  Failure doesn’t have to mean that it’s over, just that you can do things better, and we can always do things better.