Learning to FailBy Ericka Chickowski | Posted 2008-05-06 Email Print
Ever fall head over heels on a technology, a functionality or a big fat budget? We know you have, and we want to help you find the right balance between what the business needs and validating professional egos.
Learning to Fail
As treacherous as project lust can be to an organization, some experts warn not to completely cut innovators off from dreaming big.
“The last thing you want to do is jump to the conclusion that you don't ever want be driven by the solution before the problem arises,” says Tom DeMarco, a fellow with Arlington, Mass.-based Cutter Consortium, an IT advisory firm well known for its project-management expertise. “The mechanism of seeing a new technology and then looking for a problem to solve with it is not generally a bad thing─it is the way we advance. If you stopped people from doing that, you would halt progress dead in its tracks.”
DeMarco points to the early pioneers in Internet systems innovations as those who had a solution and began to search for problems to solve as a prime example of IT people who changed the world through this model.
“Sure, you could point to all kinds of businesses that set up an e-commerce initiative, and it all was a total mismatch to what they were trying to do and they wasted a lot of money,” DeMarco says. “But you can’t dismiss all of the others who more or less went into the same initiatives and came out with systems that transformed the world.”
Fog Creek Software’s Spolsky agrees that falling in love with new technology and new projects is often the sign of an on-the-ball staff.
“The fact that people are falling in love with technology for technology’s sake means that they’re out there looking at the latest new tools, which is an important thing,” he says. “I would be more worried about an organization where the developers don’t even know what Ruby on Rails or Python is than I would be worried about an organization that allows them to fly off and do fun things.”
In fact, Spolsky knows of some big-name firms that purposely let programmers do fun projects in order to recruit the best developers.
“I definitely know of Wall Street banks that have a tendency to just kind of let programmers get away with murder in terms of rewriting everything every two years in the most popular language,” he says, “and to some extent, they know perfectly well that there is no business case to that, but that that’s what it takes to recruit good people.”
Companies can only overpay the best programmers a certain amount to do things that they would rather poke their eyes out than do, Spolsky explains
“So another way to overpay them is by giving them an awful lot of freedom to try out new technologies or to start new video on the Internet initiatives that are not aligned with the business,” he says.
DeMarco believes it is possible to balance the freedom to innovate with businesses’ needs. He says the trick is to build risk management into every project in order to allow IT the freedom to be creative while still pulling the plug early on the projects that don’t fit the business or are financially unfeasible.
“If you identify a risk, you have to call your shot way ahead and say, ‘This is how I know this risk can come out to bite me, and this is the tolerance I’ve got for the bite, and this is what I’m going to do if it gets beyond that tolerance,’” Demarco says.
By doing this, he believes an organization can continue to work on projects and technology in which it has fallen in love, while minimizing the risk to the business. He believes that sometimes holding on to a solutions-first model might produce failures, but it also offers the most potential for business transformation.
“We have to grow up here and understand that systems building is a failure-prone endeavor and that the systems that pay off, pay off big,” he says. “Some of the time you do something transformative, and it will be important enough to pay for all of the failures.”