Some pundits proclaim that leadership rests on charisma, the ability to create a vision, or “presence.” Teams do need a vision and a compelling goal.  But do teams need one charismatic leader? No.Teams need leaders of a different sort. Teams need leaders who don’t need to be out in front, who are able to work quietly, creating an environment where everyone on the team is empowered. Such leaders–empowering leaders—may not get the glory. They do help teams get work done, invite creativity, and build capacity.  How do they work? Not by rousing speeches, through followers or by exuding some magical stuff. Empowering leaders create an environment where everyone is empowered. The act on observation, not gut feel or random action.

As Yogi Berra pointed out, you can observe a lot just by watching.  But what should you watch? How do you make meaning of what you see?

We are bombarded with sensory input, and our brains are built to find patterns. They are also build to filter out data.  Empowering leaders can’t rely on innate observation abilities.  They need to hone their awareness to make their interpretations reliable guides for action. Empowering leaders hone awareness in three areas:

• Self-awareness. They know their own strengths, patterns, blind spots.
• Team Awareness. They understand group dynamics and understand that teams are goal oriented social units.
• System Awareness. They grasp that the team exists within a larger system, which includes the organization as a whole, other teams, customers, work flows, and policies.

The average person knows quite a bit about him or herself.  He knows what he likes, and what he doesn’t like. He probably knows whether he likes to decide quickly, shoot from the hip, or examine all the options before choosing. He probably knows whether he is mad, sad or glad at any given moment. He probably thinks he knows what he’s good at.

Average self-knowledge isn’t good enough for leaders.  Empowering leaders observe their own thoughts and feelings, so they can manage their emotional responses. They separate the data from the interpretations they make of data. They understand their thought patterns, and how they respond to stress. They understand how that not everyone sees the world the same way (and that’s a good thing).

Empowering leaders learn to observe the team and discern patterns of behavior on the group level that effect that ability of the group to get work done. They notice who offers ideas, who challenges ideas. They notice when one person consistently interrupts another team member. Leaders hone their ability to notice the roles people take in group discussions, and pick up on non-verbal cues. This is the information that allows them to determine what is happening, and what (if anything) is needed to adjust the environment so everyone is empowered and able to work. Empowering leaders notice how the physical arrangements affect work, how information is flowing (or not), and when the constraints on the team are too few or too many.

Finally, empowering leaders pay attention to the context, the world the team works in.  How does work flow into the team? What are the relationships with other parts of the organization? Are their policies and procedure that are hindering the team? An empowering leader on a team may not be able to eliminate such factors himself. But he knows how modify the team environment to lessen harm, and to influence out side the team to achieve change.

Awareness gives leaders the ability to make sense of the data. Then, they can choose from a variety of responses that will influence the environment to empower all members of the team to contribute.

(c) 2001-2010 Esther Derby

Let me tell you a little story, a true story, about how our beliefs influence what we see in the world and affect our ability to solve problems.

Two years ago my friend Julia, who was forty-four and a bit portly at the time, starting experiencing troubling physical symptoms. She was fatigued, depressed, and generally uncomfortable. After several weeks, she went to the doctor. The doctor didn’t find anything specifically wrong.

Julia was sent home with a vague diagnosis and a prescription for Prozac. After a while her mood lifted and she felt less tired, but the discomfort continued. Finally, after several months and several more visits, her doctor determined she had a fibroid tumor that was increasing in size. He decided to remove the tumor.

Julia wasn’t happy to be facing surgery, but was relieved that after seven months of discomfort there was a diagnosis and a concrete plan. Two days before surgery, Julia went in for an ultrasound to precisely locate the tumor.

Based on the ultrasound results, Julia’s surgery was cancelled. Julia was sent home to prepare for the birth of her daughter—who arrived, full-term, two months later.

Now I’m willing to bet that you guessed the end of this story by the middle of the second paragraph. It’s obvious…if you don’t already have any particular beliefs about Julia.

Julia and her doctor, however, did have a belief, built up over years, that Julia would never become pregnant. And over the course of six months of office visits and medical exams, no one ever suggested pregnancy as the cause of Julia’s symptoms.

We could say that the medical staff were incompetent, but I would say they suffered from a belief problem. Their belief caused them to overlook information that was readily available—and also limited their application of the information they were using as they diagnosed the cause of Julia’s symptoms.

What does this have to do with software?

We all have beliefs about the world and other filters that affect what information we take in. Our beliefs, built up through education and experience, form the internal maps that help navigate the world we live in. Our internal maps can enable us recognize and categorize the vast flood of sensory inputs and think quickly. And often they are very helpful as general models of how the world works.

Other times, our beliefs keep us from seeing what is blindingly obvious to someone with a different set of eyes. It’s “as plain as the nose on your face” to someone looking at it without our particular set of blinders.

Take Tom the test manager, for instance, assigned to a team that had always operated on participative and consensus-based decision making. Tom’s framework for managing relied on his belief that, as a manager, he should entertain input from the group but make all final decisions on his own.

Soon after Tom was assigned to the group, the team was assigned to finish an evaluation of testing tools. Tom read the reports and listened to the group discussion, then closed his office door and decided which tool he favored. At the next team meeting, as he discussed his decision, he reminded the group that “we decided this at our last meeting.” Tom didn’t notice that most of the other heads in the room were shaking back and forth, indicating “no, we didn’t.”

Was Tom a bad manager? Maybe, but it’s hard to say based on one incident. What we can see is that because of his belief about how decisions should be made, Tom didn’t ask questions that might have given him direct information about how the group operated, and he also filtered out valuable non-verbal information that would have given him additional clues. As a result, he was far less than effective in working with the team…at least until he became aware that his map didn’t match the territory.

We often don’t consciously account for the existence of our internal maps, which makes them more likely to trip us up—just as Julia and her doctor, and Tom, our test manager, stumbled when their maps didn’t show all the ups and downs of the territory.

Our thinking process happens so fast that it’s extremely difficult to pause the process in the middle and ask, “What unconscious beliefs, filters or maps are influencing me right now?” The challenge is to pause between the time we reach an initial conclusion and the time we act on that conclusion…kind of like how we test a piece of software before we ship it to understand the quality of the product and the risk associated with releasing it in its current state. I have four questions I use for this pause in the mental process:

1. What have I seen or heard that led me to this belief?

This question reminds me to really look at what data my response is based on. If I hear myself saying something like “because its always been like that…” I send up a tiny little internal red flag.

2. Am I willing to consider that my belief or conclusion may be mistaken?

If I’m not willing to consider that I might be wrong, it’s a sign that I’m reacting out of a belief I’m pretty attached to…and it’s a clear sign I need to go to the next question.

3. What are three other possible interpretations of this situation?

If I can’t think of any other interpretations, it’s time to get some help shaking up my assumptions. I find a colleague I trust and we brainstorm as many different interpretations as we can.

4. What would I do differently if one of these other interpretations were true?

This gives me a wider range of responses to choose from, and increases the chance I’ll choose one that will help solve the problem.

When I start to test my conclusions, I can surface and examine my beliefs—my assumptions—about the situation. If I’m willing to admit that my initial interpretation might be inadequate, I can gather more information and represent the situation more accurately. And when I do that I open up the possibility of making better decisions, working more effectively with people, and—coincidentally—building better software.

This column originally appeared in STQE magazine in 2001.