Right Ways of Working with the Left Brain

"The Heart of Innovation" is the blog for Idea Champions, the highly-respected consulting and training company specializing in creativity, innovation, team building, and leadership. A recent post titled "Right Ways of Working with the Left Brain" offered some valuable suggestions for helping to lead left-brained people (like most of us) through creative activities. The article opens with:

"If your job requires you to lead meetings, brainstorming sessions, or problem solving gatherings of any kind, chances are good that most of the people you come in contact with are left-brain dominant: analytical, logical, linear folks with a passion for results and a gnawing fear that the meeting you are about to lead will end with a rousing chorus of kumbaya."

I can relate.

The 10 practices are listed here, but check out the article for details - and fine-tune your ability to provide leadership throughout the creative process. As discussed in Architect as Advocate of the Business and The Proactive Architect, these sorts of leadership skills help distinguish world-class architects.

Ten Tips for Leading Creative Activities:

1. Diffuse the fear of ambiguity by continually clarifying the process
2. Get people talking about AHAS! they've had in their own lives
3. Identify (and transform) limiting assumptions
4. Encourage idea fluency
5. Invite humor
6. Do the right brain/ left brain two-step
7. Periodically mention that chaos precedes creative breakthroughs
8. Establish criteria for evaluation
9. Be a referee when you have to
10. Consult with the tough people on the breaks

Check out the full article here: Right Ways of Working with the Left Brain

Think Bigger!

Jeff had a very nice post recently about the all too common problem of Engineers becoming inappropriately fixated with things that are important to Engineers (as opposed to things important to the business and to the users). He points out that he gets "frustrated with the depth of our obsession" over things that are very important and necessary (such as unit tests that are absolutely foundational to professional development) but are sometimes allowed to overshadow the things that are MOST important. Jeff remarks, "the ultimate unit test is whether or not users want to use your application" and continues with, "I want to run up to my fellow programmers and physically shake them: think bigger!" And I want to shout, Amen!

But then something odd happens. In response to his post, developers (apparently suffering from precisely the ailment Jeff just described) completely validate his entire premise (that sometimes we fail to see the forest for the trees). One after another weighs in with a comment such as, "unit testing has nothing to do with usability" (boldly paraphrasing).

Finally, Kyle pipes up with the voice of reason:

"While [it's true] Engineers should be concerned with whether they are building the product right (verification), their overriding concern should be whether they are building the right product (validation).

It is important for engineers to get their head above the water and see the bigger picture sometimes."

Kudos to Jeff, Kyle, and all of you who remind us to "think bigger", "get [our] head above water", and remember that our real mission is (as Jeff concludes):

"The ultimate unit test is whether or not users want to use your application. All the other tests you write are totally irrelevant until you can get that one to pass."

Building the product right is very important. Building the right product is essential!