Thursday, March 31, 2011

Managing Yourself

This is why I wrote the book, "Managing Yourself and Others."



<https://www.smashwords.com/books/view/39685?ref=JerryWeinberg>



Mostly, it's about congruence!

Amplify’d from techcrunch.com

By far the most difficult skill for me to learn as CEO was the ability to manage my own psychology. Organizational design, process design, metrics, hiring and firing were all relatively straightforward skills to master compared to keeping my mind in check. Over the years, I’ve spoken to hundreds of CEOs all with the same experience. Nonetheless, very few people talk about it, and I have never read anything on the topic. It’s like the fight club of management: The first rule of the CEO psychological meltdown is don’t talk about the psychological meltdown.

At risk of violating the sacred rule, I will attempt to describe the condition and prescribe some techniques that helped me. In the end, this is the most personal and important battle that any CEO will face.

Read more at techcrunch.com
 

Tuesday, March 29, 2011

Knowing What to Leave Alone

I adapted this blog post from my new eBook, Becoming a Change Artist This little case example followed a number of other examples, as a kind of corrective to some peoples' ideas about how a change artist operates.


I don't want to give the impression that change artists are rushing around an organization inflicting help on everyone. Perhaps the toughest skill for a change artist to learn is the skill of knowing what people and what situations to leave alone.

For instance, there's a Vietnamese proverb that says, "While it is notable to assist a stricken elephant in rising, it is foolhardy to catch one that is falling down." Change artists need to learn how to recognize whether a person or department is willing to help themselves rise.
For instance, change artists should have lots of potentially transforming ideas on hand. Most of these ideas are on the process level—that is, processes for finding ideas. Such processes might include
  • reaching out to other organizations, departments, professional societies, libraries, consultants, or classes
  • facilitating brainstorming processes
  • keeping an inventory of sample problems, toy exercises, and simulations for right-brain exploration and left-brain investigations
  • conducting focus groups, and knowing how to recognize when the group lacks the necessary knowledge (A lens doesn't focus anything if there's no ray of light.)
  • changing the mixture of people to obtain more diversity and knowledge
  • combining ideas from several sources to produce new ideas
A good example of combining of ideas is the process of connecting what the individuals want with what the organization or the change artist wants. If the change artist thinks the elephant might be falling down, she might make her presence (what they want) conditional on their participation (what she wants). Or if management wants the group to take a risk, the change artist might negotiate some kind of insurance to give the group safety, such as extra time in the schedule, relaxed specifications, suspension of the usual measurements, or a guarantee of their old jobs back if the project flops.

Here's an example of this kind of negotiation. In an organization producing electronic equipment with embedded software, top management threw in a foreign element by mandating certain process improvements. Some of the more traditional managers were highly technical engineers, and claimed that the other managers, being service engineers, weren't sufficiently technical to do process improvement. Thelma, a change artist, was supposed to facilitate the entire group of managers working on the improvements, but she faced a problem: Who should have the job, given that the technical managers weren't doing it, and the service managers wanted to do it?

Thelma applied several change artist principles:

  • Always find the energy for change and go with it. In this case, the service managers wanted to work on change, and the technical managers didn't.
  •  Don't get hooked into negative energy. The technical managers knew dozens of reasons why these changes could not be made.
  • Talk in their terms and find out what the issues really are. It turned out that the technical managers were overloaded with assignments just getting products out the door. The service managers were overloaded, too, but they felt that their overload was due to service requests arising from faulty technical processes. They were willing to invest their time to reduce their future load.
  • Once you're prepared, go to the source. Having assembled all these facts, Thelma made a recommendation to upper management that the service managers be given the process improvement responsibility, and that the technical managers no longer be required to attend process improvement meetings. In return, the technical managers promised their full cooperation on an as-needed basis. Upper management was happy to accept her solidly-based recommendation.
  • It's perfectly all right to do nothing for a time. Dormancy periods in seeds and hibernation in animals are adaptive strategies in an environment with fluctuating opportunities for growth. In human organizations, the Zone Theory says that it sometimes makes good sense just to lie low during periods of rapid change. Knowing that Chaos is contagious, Thelma wisely decided to leave the technical managers alone. Their time would come.
In other words, just like in artistry with a canvas, paint, and a brush, sometimes the empty spaces are the most important part of the work of art.

To perfect your change artistry, you might want to participate in this year's AYE Conference.

Sunday, March 27, 2011

Are you a permission giver? Feynman was.

Read the entire article, then read Feynman's letters.

Permission Givers

By William Zinsser

When Richard P. Feynman, one of the giants of 20th-century physics, was awarded the Nobel Prize in 1965, he received hundreds of congratulatory letters from friends and admirers, including one from a former student named Koichi Mano. Acknowledging the letter, Feynman asked the young scientist what he working on. Koichi sent a doleful reply, regretting that he wasn’t working on fundamental problems of science, but only on “a humble and down-to-earth type of problem.”

“Your letter made me unhappy,” Feynman wrote back, “for you seem to be truly sad. No problem is too small or too trivial if we can really do something about it. It seemed that the influence of your teacher has been to give you a false idea of what are worthwhile problems.” In his own career, Feynman pointed out, he had “worked on innumerable problems that you would call humble, but which I enjoyed and felt very good about because I sometimes could partially succeed.” He went on to describe a dozen of those experiments, some of which failed, including one on the theory of turbulence that he “spent several years on without success.”

Read more at www.theamericanscholar.org
 

Sunday, March 20, 2011

How to Manage Teams Congruently

Typical crisis-provoking events in the life of a programming team are machine malperformance, machine overload, unyielding bugs in critical sections, difficulties in system testing of two unit-tested programs, schedule changes, arrival of new equipment, changes in higher-level management, and changes in specifications. No wonder it seems that crisis is the normal situation in the life of a programming team.


Two general social-psychological observations about group behavior are especially relevant to the crisis-ridden programming team. First of all, it has been observed that in a crisis, members of a group more readily accept relatively strong leadership attempts. At the same time, however, the group becomes less patient with would-be leaders if their direction does not produce effective solutions to group problems rather quickly. Thus, in a programming team—which is possibly in a continual crisis—leadership patterns may be in constant flux. Because of this reshuffling, the more difficult the task is, the more the team comes to follow those leaders who can actually steer the team most effectively.


We can see, then, why the democratic—or perhaps we should say "technocratic"—organization is such a natural one for a programming team. When selecting programmers for teams, we should try to choose people who will fit well within such a self-shifting structure—neither too dominant nor too passive. In training our programmers, we should try to teach them how to follow able leaders and how to grasp leadership opportunities when they themselves are the most qualified in the group. And during the life of a team, we should try—if we are on the outside—not to interfere in those democratic processes which, though seemingly traumatic for the team and its members, will in the long run lead to most effective team functioning.


Indeed, once the team is selected and operating, the wise manager placed above it will adopt a "hands-off" policy with regard to its internal structure and structure change. When, as so often happens, team members come to him to lend an authoritative opinion on their side of some argument, he would do well to follow the pattern of the old rabbi who was sitting in his study one day when an obviously agitated man came to see him. The man told him a long story about an argument just concluded with his wife. When he finished his story, he insisted that the rabbi tell him whether he or his wife had been right.


"You're right," said the rabbi, and the man left the house beaming. Soon, however, the man's wife appeared—even more distraught than the man had been.


"What do you mean," she insisted, "saying that my husband was right? You haven't heard my side of the story." And she proceeded to relate her side, finishing with a demand for a new judgment.


"You're right," said the rabbi, and the wife left satisfied. The rabbi's own wife, however, was not satisfied, for she had overheard both stories and both answers.


"How can you do that?" she demanded. "You told the husband that he was right and the wife that she was right. They can't both be right."


"You're right," said the rabbi.

[This little tale is adapted from my books: The Psychology of Computer Programming and Managing Teams Congruently.]

Friday, March 04, 2011

A fine article, but only a sample

I chose just one of the many fine entries on the TESTHEAD blog. Read this one, then try some of the others. Michael can write--but most of all, he can think!

Amplify’d from mkl-testhead.blogspot.com

Army of One: Pairing With an Expert






One of the challenges being a lone gun tester is the fact that, often, you don’t have someone else to ask questions with. Sure you can talk to developers about issues and areas you have concerns about, but that’s not what I mean. It’s rare that time will allow a person to consistently sit down with a developer and just ask broad and open-ended questions about a product, a technique or an idea. Larger test organizations allow testers to have this opportunity. Frequently, the Army of One tester ends up doing most of their thinking or brainstorming alone… but they don’t have to.





Today I had a cool experience. One of our domain knowledge experts had some time today and asked if we could set up a pair testing session, with the idea of “asking the product some questions”. The domain expert in this case is an Attorney very well versed in Immigration Law. There are a lot of layers to testing software that services the legal profession, which my company does. While I know a fair amount about Immigration and Employment Law just by virtue of repeatedly testing and looking at the challenges our products are meant to address, I will not have the same level of experience or expertise that a dedicated attorney would have.

Read more at mkl-testhead.blogspot.com