Sunday, June 17, 2007

Great Reading: Patterns

I'm reading a book that software executives can use to understand Design Patterns. After going through this book you'll be able to ask better questions about the architecture of your OO software. So far I've only gone through the Strategy, Observer, and Decorator patterns... but suddenly I understand them and can talk at a much higher level of design than ever before. The book is well written and engaging, it is called:

Head First Design Patterns

by Eric and Elizabeth Freeman. The style is credited to Kathy Sierra and Bert Bates, creators of the Head First series. Good stuff.


I was discussing Arrogance last week with a colleague; we noted some really smart people who have changed professions, who think they know so much more than those who have studied the profession for decades.

Peter Drucker wrote, in an article entitled "Managing Oneself":
Far too many people—especially people with great expertise in one area—are contemptuous of knowledge in other areas or believe that being bright is a substitute for knowledge. First-rate engineers, for instance, tend to take pride in not knowing anything about people. Human beings, they believe, are much too disorderly for the good engineering mind.
For some reason I assumed Arrogance was on the list of "seven deadly sins"; Wikipedia says it is not. Generally, Arrogance is something you lose with maturity; in particular with a successful management career comes an understanding that you need the views and analysis of others to be successful. But I have observed in others that the reverse is true - they have developed Arrogance as a consequence of their success.

This to me is the ultimate failure of management; if you enable or tolerate the increase of Arrogance in your employee, you have failed. It is our job to teach, by example and by coaching, that others have something to offer and it is the employee's job to seek out and discover that offering. I believe this can be taught without damage to the ego. Humor works - and is a good teaching tool.

My assumption is that many potential teachers overlook this sin if the sinner is a high performer. I suggest you never do that. We don't have that luxury if we are to stay competitive. The world is different, incredibly complex, and changing; we must respect and learn from others. Creating leaders who don't have this property can only lead to failure.

Tuesday, June 05, 2007

Problems and Solutions

Dr. Arthur D. Levinson, CEO of Genentech, is quoted in the Wall Street Journal today:

I have a philosophy -- I invite criticism. But don't ever come to me with a complaint without saying, here is what we might do to make it better. I am happy to hear Part A if I hear Part B.

I have tremendous respect for the man; he's built a successful business in an industry he describes as the "biggest money losing industry of call time". But I think that the philosophy he describes is one that will lead to trouble, and in any case is not my philosophy.

First off, let's distinguish between problems and complaints. A problem is a situation deemed potentially harmful. A complaint is a statement about dissatisfaction with a situation.

I contend that all leaders want to hear about problems in their business; complaints are one way a leader will hear about them. If a leader requires that a person bring a solution to any problem, that means team members will be working on solutions that individuals perceive as problems. The leader wants to be able to distinguish between real problems that are worthy of finding solutions, perceived problems that are not problems at all but perception and communication issues, and problems that are real but not worth working on. If you adopt a policy like Dr. Levinson's, you don't get to make that distinction. Moreover if it becomes part of your culture, it gets pushed down to the next level and now management in general doesn't get to understand and make that decision.

I certainly understand where Dr. Levinson is trying to go with this; it might be a necessary policy in a company where people don't step up to find solutions. Given what he says about Genentech, though, I find it hard to believe that is the case. I can see adopting the policy on an individual basis when you have an employee who wants to put monkeys on other's backs instead of solving problems; but as a general policy, I don't get it.