Tod1d's Thought Process

Someone recently sent me an article from the August 17th edition of Early to Rise which espoused the virtues of board meetings where everyone is told to come with 2 great ideas on increasing sales, profits, or productivity. The founder of the company credits the simple technique with sparking a $100 million dollar growth spurt in just 5 years.

Apparently this method of brainstorming also saves marriages and decreases the amount of smog that hangs over Phoenix, AZ. Check out this excerpt:

"And listen to this unexpected benefit: Before Boardroom started the system, the
number of divorces among employees was about average for a company of its size.
But in the eight years since then, there has not been a single divorce among
Boardroom's workforce of almost 100! Clearly, when people get in the habit of
coming up with ideas (rather than focusing on problems or results), it can
affect every aspect of their lives."

This may work well in board meetings, but I am not so sure about how well this translates to other department's meetings.

A software development team (project managers, software developers, QA guy, etc…) I worked with did something similar. Every Friday we had a “creative” meeting, where everyone had to bring a creative idea, or just do something creative (like play the guitar). Some of the ideas brought to the meeting were implemented, many were not. It worked well for about a year, but petered out towards the end of my tenure.

Eventually "creative" meetings turned into an excuse to have a 1 hour social event / bitch session. I attribute some of this to a sense of isolationism. Each developer worked on an independent project and new projects were slightly different takes on old projects. By the time “creative” Friday rolled around, I had implemented my creative idea and realized it wouldn’t be that beneficial to anyone else’s project.

This is the where code reviews came to the rescue. Each week the developers would meet to show off some of the code they created. It gave the person, demoing the application, a chance to share new methodologies, technologies, etc. with his peers. In addition, the demo gave his peers a chance to offer suggestions and creative criticism. I felt like code reviews had a great sense of purpose and, at the end, a greater sense of accomplishment.