Make Smarter Mistakes

Determined to transform his personal blunder into a learning experience for everyone, Rosenzweig called a staff meeting. The goal was to develop a "learning plan" that would detail key negotiating points for future contracts. The following year, Rosenzweig struck a much better deal with an Australian distributor. "In fast-growing companies, where people are doing things for the first time, mistakes often get made," he says. "But if you embed the learning, you won't make the same mistake twice."

Frank Bergandi had a similar experience at Objectivity. Once he realized his engineering staff couldn't incorporate the software tool that he'd spent $150,000 to acquire, Bergandi, who had become CEO only a few months earlier, called a meeting of his top managers. "'We just spent six figures on something we're not going to use,'" he remembers telling them. "'What in the world are we doing?'"

It quickly became apparent that engineering, marketing, and sales needed a liaison to coordinate the development of new products. "High-tech companies often try to do everything informally," says Bergandi, who previously was vice president of North America for Informix, a developer of relational databases. "But some things here were falling through the cracks." About a month later, he created a new position, vice president of product marketing, to improve the information flow among departments. Since then, he reports, the company has released two new products -- fully featured and issued right on schedule.

A single mistake often generates multiple lessons. Consider the case of Mark Benerofe, 38, vice president of programming and platform development for New York City-based Sony Online Ventures. Back in 1989, when Benerofe was editorial director of Prodigy, he dispatched two of his educational producers to handle an expert appearance for the online commercial service. The San Francisco earthquake had just hit, and Prodigy's bulletin-board manager had pulled off a small coup by booking a much-sought-after Washington, DC-based psychologist who specialized in the trauma caused by natural disasters. But technical problems meant they couldn't get the expert's office PC hooked up to Prodigy. The producers, with no experience in the pressure of live news, didn't think to take some obvious next steps. Prodigy got the interview the next day, but lost its scoop.

In a moment-of-truth meeting with the producers the next day, Benerofe spelled out what everyone needed to learn from the incident. "I reminded them that they are a part of a larger enterprise," he said. "I let them know that they needed to go all the way to make sure this live event happened, even if that meant driving the guy four miles down the road and setting up the PC at his home."

Benerofe, a former CNN producer, realized there was a lesson for him too: when you're working in a young field that merges content, design, and technology, staffers have radically different skills and mindsets, which means you can't always assume that everyone operates with the same sense of urgency. "Sending out this team was like sending documentary producers to cover the outbreak of the Gulf War," he says. "That lesson has stayed with me."

V. It pays to "make" mistakes.

Sometimes the smartest mistakes are those that you "make" yourself -- simply because it's the right thing to do. Take the case of Sara Groves Hobart and her software team, which was building a new database-development tool for Oracle. The lead programmer on the project, an especially talented employee, was having a great time building and fixing the tool's all-important source-control system. But Hobart, 36, now a senior product manager at Oracle, realized that the work was taking up all of his time, which meant other high-priority assignments weren't getting done. She took a closer look at the project and discovered that Oracle had another, well-established source-control system that included all the features the new tool needed.

Hobart understood that no one would object -- or even notice -- if she simply maintained the status quo. Everyone had assumed that a new tool required a new source-control system. She also understood that stopping work on the new system meant that the entire project -- which, by conventional measures, was proceeding smoothly -- would be viewed as a mistake. If the old system worked fine, why had her lead programmer invested so much valuable time in developing a new one? She also knew the decision would generate resistance from this programmer and create worries among his colleagues. "Nobody likes change all that much," says Hobart. "And when things are chugging along fine, the feeling is, Why change anything?" Hobart made the "mistake" and took the heat.