At last weekend's RubyNation conference, I had the pleasure of attending a talk by Danny Blitz. Danny's personality came close to stealing the show - if you ever have a chance to hear him speak - or better yet sit down and have a one-on-one conversation with him, do it. He is quite a presence. He's a fantastic manager too - given the opportunity, I'd love to work on a team he put together.
One of the key points of his presentation on successful management was "rewarding failure". When he said this, he got a combination of enthusiastic applause and quizzical looks (as well as a woop woop from Aaron Bedra). His point can be summed up with the old saying, "If you want to bake a cake, you need to break a few eggs". The crux of his point: If you don't fail occasionally, you aren't taking the risks you need to have a big success.
I thought of a story I tell at NFJS conferences - "The Naive Manager and the Case of the Broken Builds".
I once worked with a manager who knew very little about software - he managed the paperwork of the processes, and at that he was very thorough. Once I was putting a really good employee through their annual review process. When I turned in the review paperwork, the manager said, "I don't know about this... I see from the team's emails he occasionally breaks the build..."
You see, we had set up a continuous integration server. Every 15 minutes, the server would wake up, build the code, and send out a success or failure email. Occasionally, in the course of doing our jobs, we would occasionally forget to check in a new file, have to update the build system to use a new library, etc. The manager had noticed that over the course of the last year, this employee had broken the builds a few times.
These are the kinds of failures that happen *all the time* on a software project... A good project will have a continuous integration server to catch them as early as possible, before there is a stack of problems on top of it to solve. This manager seemed to think that breaking the build was bad, but in reality, its not a problem at all when it is caught and fixed immediately. A *continuously* broken build is bad, which is a story for another time. Risk: good. Failure: allowed. Just fix it when you screw up.
Take the chances you need to succeed big - but do it with a net. The conclusion Danny left us with is that good management and development practices comprise that net.
Comments