Category Archives: Blog

Peck, peck, peck

A participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n.  Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.

This is not the first time I have heard this assertion.

It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.

This assertion rests on tired analogies from sports or the animal kingdom.

I’m not buying it.

Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches.  Groups of people developing software are people in goal oriented social units–often in teams.

Sometimes, on some teams, it appears that there is one person who is obviously the star. Maybe.

In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?

Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.

Then there are the people whose manager declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers  view them no more than average,  brown-nosers or a hindrance.

I observed a team where one person was viewed as the star by many managers.  To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing  until people caved in because it wasn’t worth the fight.

Rarely, there are people who are real standouts.  But not on every team.

What about the people at the bottom? What is the basis of the assessment?  Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at  synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.

And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?

What if people are measurably different on some dimension?  Software is a collaborative endeavor. What matters is how well the team is doing.  Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.

As a manager, don’t waste your time trying to figure out the pecking order.  Do everything you can to help the team, as a goal oriented social unit, perform to its full capability.  Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit your thinking about rewards to money).  Treat the people whose performance is obviously below par as exceptions, too.  Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company).  It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the team.

Why not velocity as an agile metric?

In response to my recent post on Agile Metrics, a reader asked, “Why did you leave out Velocity?”

Even though it’s not perfect, velocity is the best way we have to understand the capacity of teams. It’s the best way we have to bring some reality to planning for releases.  Watching velocity over time and looking at patterns in burn downs can alert coaches and managers that something is going on, and they need to investigate.

Velocity is important. But as a metric for gauging how your agile adoption is going, it’s opens a door to danger.

Here’s why.

Velocity is easy to manipulate.  Want velocity to go up?  Fudge the definition of done and you finish more stories.  Change the scale and complete more points (what once was a 2 point story is now a 5 point story).

Velocity is easy to misuse.  Managers who don’t see organizations as systems can use it to compare teams or punish teams. Neither of which is helpful.

Velocity—as an agile adoption metric—puts the focus in the wrong place. Focus on velocity implies that if velocity isn’t improving there is something wrong with the team. In some cases, that might be true. But I don’t want people to look by default. When velocity isn’t improving or is erratic, it’s often due to factors that aren’t in the team’s direct control.  There might be a problem with the way the work is flowing into the team. Or the team maybe interrupted every hour with production support calls (or what ever). Or the team may not have the tools they need to do their work.  That’s something for the team and team coach to work on or raise up as an impediment (where mangers can work on it at the system level).

For assessing the progress of an agile adoption, I choose metrics that emphasize system performance to help managers make the shift from “work harder” thinking to “optimize the whole system” thinking. Managers after all, are responsible for creating the environment (structures, policies) and enabling conditions for teams be successful. To do that, they need a way to asses how the system is functioning.  Because I presume that the point isn’t being “agile” but delivering valuable software.

For more about using velocity as a measure, see my post Working Hard or Hardly Working.

Metrics for Agile

“How can we tell how far along we are with our agile adoption?”

I heard this question again the other day.

Usually, the person who asks the question starts to answer it:

Number of teams using agile

Number of people trained in agile

Number of projects using agile

Number of certified coaches.

Metrics like these won’t tell you what you need to know. More likely, they will lead you astray. How? Let me tell you a story.

Years ago, I worked for a company that was “installing” a Big Methodology from a Big Company.  (The fact that they thought they were “installing” a methodology was probably the first warning sign.)

Every one in the department attended Big Methodology training. (This practice is sometimes called “Sheep Dip” training).

The VP mandated that all projects would use the Big Methodology.

The Installation Team audited to ensure that project managers and teams were complying and producing the required “work products” in accordance with the Required Work Products grid in the back of the very large Big Methodology binder.

Of course, there was some grumbling (from the people the Installation Team referred to as “Change Resisters.”)  Eventually, people did comply. Every one went to training. Projects managers filled out the required templates, and checked the appropriate boxes.  The metrics looked grand!

The VP declared, “Big Methodology is now business as usual!”

At the time, I scoffed at that statement. It was clear to me that people were not using Big Methodology, and that the promised benefits were nowhere in sight. The only things that had really changed were some check boxes and some names (documents became “work products” or “job aids,”).

But, now, I realize that the VP’s statement was TRUE!

We had Big Methodology, and things went on as they had–business as usual! Well, maybe a little worse because people were spending time producing the many documents specified on the Required Work Products grid.

The metrics the VP tracked were easy to count. But they only revealed surface compliance. They didn’t say anything about whether the organization was achieving the improvements promised by Big Methodology and hoped for by the VP.

So when you think about assessing how far along you are in your agile transformation, consider what you are trying to achieve.

I often suggest that managers track three metrics to understand how well their organization is functioning, and whether they are trending in the right direction.

The ratio of fixing work to feature work. How much time are people spending developing valuable new features vs. fixing stuff that wasn’t done right the first time? If you can figure out the sources of fixing work and make some progress there, you have a boost to productivity. Agile methods can address some of the sources of fixing work…but not all of them.

 Cycle time. How long does it take to go from an idea to a valuable product in the hands of a customer? Again agile methods can help with delivery. But if it’s the upstream process–planning for products and releases–is broken, you may not see improvement until you address those issues, as well as the development process.

Number of defects escaping to production. This is a category of fixing-work that is a direct indicator that the quality of the development process is improving.

For each of these metrics, it is the trend that is important, not an absolute number.  The trend will tell you if your attempts at improvement are having an effect. Remember, most changes take time to take hold. If the trend doesn’t move in a month, it may not mean you have taken the wrong action and need to change direction. If the trend isn’t moving over time, then, examine what is happening in the development area. But also look at other aspects of the system. There are few one-to-one cause and effect relationships in complex systems and the trend you see may or may not be directly related to your change. One company I worked with was alarmed to see that defects released to production went up after they started using agile methods. It turned out that prior to the effort to measure defects released to production, no one paid much attention unless the defect brought down a customer site. The increase in the defects trend was related to reporting, not a failure to improve quality.

I find that the three metrics above are generally useful for understanding how a software development organization is functioning as a system. But your reasons for adopting agile methods may be different.  Consider the goals you are trying to achieve.  What signals would tell you that you are moving in the right direction?  How might you measure those?  When you think about measures, be wary of target numbers. Measuring against targets almost always causes distortion. That means that people will behave so as to reach the target, perhaps in ways that are counter to the actual goal behind the target. Distortion will keep you from seeing the real picture, and may also cause real harm to your organization.

Useful metrics give you a window into how the system is functioning, and whether your change is having an effect. The numbers themselves are neither good nor bad. They are information that signals you to go and find out, investigate and reason about the system.

Real Coaches or Hierarchical Control in Coaches Clothing

I recently met with a group of managers who work in organizations adopting agile methods. Several of them asked whether functional managers should become ScrumMasters or coaches.

That’s a risky road.

One manager was adamant. In his view, making managers ScrumMasters was the best course of action. According to this fellow, managers already know people’s strengths and weaknesses. They know the domain, and the organization. So, he reasoned, the managers are already equipped to tell people what to do.

Errr. Not so much.  Coaches and Scrum Masters rarely tell people what to do. Usually, they work by different means–modeling, coaching, teaching.

But it begs the question, can a manager be an agile coach or ScrumMaster?

Here’s what I look for in an agile coach/ ScrumMaster.

Experience. If your company has used serial life cycles or ad hoc methods changing to agile methods is not a trivial matter. Nor is it simply a matter of adopting a few engineering practices or using time boxes.  Succeeding with agile does require engineering practices and time boxes. But the real change happens between peoples ears. It’s a shift in thinking–and not just by the development team. Some people change the way they work by changing their thinking. But many more change their thinking by changing the way they work.  Book learning and training is good, and it’s no substitute for experience in the agile way of working.

A deep understanding of agile practices and methods. Coaches need to know the why and when, as well as the how. They need to understand how practices fit together, the intent behind practices. People do need to adapt methods to local conditions.  Without understanding, adaptation is risky. I’ve seen teams and companies “adapt” themselves right back into the situation they were trying to fix because they didn’t fully understand the “why” behind some agile practices. An agile coach needs to be able to think through what adjustments maintain the essence of a practice, and which adaptations sustain the current pattern.

Coaching skills.  Seems obvious. An agile coach should know something about coaching. That means helping people learn skills through practice and feedback. It means helping people think through issues and see new alternatives.  It may mean providing answers, facilitating, or acting as a mirror. If often means helping people think about the way they are thinking, and helping teams get unstuck.  (It does not necessarily include “life coaching.”)

Coaching is tricky when a person also has the responsibility to rate and rank individuals. Coaching requires openness and trust. When people fear that revealing lack of knowledge or skill will show up on their annual review, they are less likely to ask for help. I know of several companies where managers are now “coaches” (and managers). Its confusing for the team members.  They don’t know who they are talking to–the person who helps, or the the one who will hand out a rating at year end.

Understanding of teams and team dynamics. Another skill that would seem obvious, but is often overlooked. When the job is coaching a team, the coach needs to understand something about how people behave in goal-oriented social units. He needs to know the foundations and enabling conditions that allow teams to form and thrive. He needs to recognize when problems are related to the design of the team, when they are system patterns, and when there are individual problems.

Interpersonal and collaboration skills. Coaching is about enabling other people to be more effective. The zeroth step is to make contact with people. If a coach cannot do that, he won’t be able to build relationships and trust. I do sometimes meet coaches who are all about “me.” Doesn’t work. Coaches need to be able to work with others, share credit, and let others shine.

Influence and organizational smarts.  It is silly (or worse) to expect a ScrumMaster to remove significant organizational impediments and drive organizational change–even though that’s often the hype. Coaches need to be savvy about the organization and to have influencing skills, so they can help managers understand the costs of impediments.

If you want empowered teams, you need to change the dynamic between managers and teams.  Slapping a new tittle on a manager (or project manager) will not change the dynamic unless the manager’s mindset and actions also change.

Of course, some managers do have all the qualities and skills to make the transition.  And some teams have the gumption to call out their former managers when they slip back into command and control thinking or acting.  Even when the mangers is willing and capable of changing the way he interacts with a team, it will take time for the new pattern of interaction to take hold.

But for many companies, calling managers “coaches” or “ScrumMasters” is really hierarchical control in coaches clothing.

Organizations still need managers.  Call them managers, and have them do management work–improving the organizational system and translating strategy into action. And get a coach to be the coach.

Essential Readings for Managers I: Pay & Evaluation

I used to make my living writing code.  I was good at it. I was really good at figuring out the problem when the symptom and causes weren’t close together. So they promoted me to manager.

As a new manager, I was sent to a two-day Basic Management Orientation, where they taught me to how to fill out staff requisition forms in quadruplicate, who got the goldenrod copy, the blue copy, the pink copy and the white copy.

I think I could have figured out how to fill out the form on my own. I suspect that was all they knew how to teach, so that was what they taught. But it wasn’t what I needed to know. I suspect there are many managers in technical organizations who have similar stories.

I set out to learn about working with people and managing in a large organization. I sought mentors with in my organization. Many of the managers had never worked any place else or had only  worked for one other company. They knew a lot about “how we do things here,” and how to work within the system. They didn’t know how to work on the system. And most of them didn’t question the system.

My best teachers were from outside the company–professors in my Masters program, Jerry Weinberg and other folks I met through him. Those people got me thinking, learning, and seeing the system.

So in the interest of helping managers learn how to see and work on the system, I am starting an occasional series on research, references, and resources on management topics. For now, I’ll focus on practices that go unquestioned, but aren’t supported by evidence. I’ll share sources and authors that have shaped my thinking about management, organizations, and teams.

I’ll start some myths about pay and performance. The dominate model in the US is differential pay based on rating or ranking. It’s so pervasive, that many don’t even think to question it.  But as Jeffrey Pfeffer says,”diffusion and persistence don’t provide proof of effectiveness.”

Jeffrey Pfeffer: Six Dangerous Myths about Pay (terrible copy, but free).

Jeffrey Pfeffer:  Congressional Testimony on pay-for-performance systems.

If you are interested (and as a manager, you should be) in the effects of annual performance reviews, click “annual reviews” in the tag cloud.

If you are in middle management, you may think you can’t change HR policy. But if you band together with other managers and document the negative effects on productivity and the ability to meet the organizations goals, you might just get some traction.

 

 

 

Solving Symptoms

Recently, I attended two retrospectives.  Different teams, different states, different facilitators. I’m usually on the other side, leading retrospectives.

Both retrospectives followed the “make lists” pattern.  One made two lists  “What worked well” and “What didn’t work well.”  The other made three lists “What worked well,” “What didn’t work well,” & “Issues or questions.”

Once the lists were complete, participants voted on which issues to address and broke into small groups. These groups were called “problem-solving” groups. They were really “symptom-solving” groups.

There may be some agile coaches out there who guide the team to find patterns and underlying causes from these lists. Too often, that doesn’t happen, and the discussion never goes beyond solving symptoms. Too many people teaching Scrum or Agile short-change retrospectives–teaching new ScrumMasters and coaches to make lists, rather than help the team think, learn, and decide together.

Two lists,  three lists–even four lists–are not sufficient. Lists focus on syptoms, as seen from individual points of view. These lists do not build shared understanding. They do not reveal underlying causes, patterns, or structures that influence behavior.

When teams “solve” sypmptons, the problems come back, or the team piles on layers of rules and processes designed to change behavior (I visited one team that had over 20 working agreements–almost all aimed at the symptom level).

It is not surprising to me that teams who do this sort of retro usually find them less than useful.

I’m not saying you have to do retrospectives the way I do them. But please, design and lead your retrospectives to dig beneath the surface, analyze, search beyond symptoms. Otherwise, you are wasting your time.

Empowering Leadership II

Every team needs leadership, even self-organizing teams.

When I make this statement, some people assume I mean that every team needs a designated leader.  I can’t blame them, most people are accustomed to thinking of leadership residing in a role or a charismatic individual—a “born” leader.

On self-organizing teams, there isn’t one leader.  Agile teams may have a coach; however, the coaches job is to help the team see where they need to improve and help them learn specific skills.  The coach may lead at times, but the coach isn’t the leader.  In fact, if the team looks at the coach as the leader, they’re in trouble. Holding up one person as leader will hamper team development.

Before we go any further, let’s define leadership: leadership is creating an environment where everyone can contribute to solve the problem at hand.

On teams that function well, every member of the team leads.  Each person takes responsibility for helping the team move forward.

But acting at random or on gut feel isn’t enough. Empowering leaders can be more effective when they work out of a model that helps them make sense of what they see happening on the team.

One such model is the MOIJ model articulated by Jerry Weinberg.

1. Every team needs motivation—and I don’t mean pep talks, cheerleading and extrinsic rewards.  Teams do best when they are intrinsically motivated, when they derive satisfaction from the work and team relationships.

Team members lead when they work for appropriate harmony and consensus—and engage in constructive conflict.  Leaders pay attention to how other team members are participating, so that everyone can use their talents and creativity. Leaders pay attention to how the whole team is working together, and building a team culture that supports achievement and good working relationships.

When only one person on the team pays attention to motivation, the team doesn’t learn how to create the environment for their own success.

2. Teams need organization.  Organization is more than the boxes on an org chart.  Organization includes physical space, time, and structure.

Leaders make sure that the workspace supports the team with appropriate equipment and information. Teams need someone to lead by pay attention to commitments and the ticking clock.  They need to figure out how to allocate the work so that it gets done and there’s a balance between people expanding their skills and relying on experts who can do the work most quickly. Teams need structures that help them work effectively together, for example, working agreements or configuration management.

When only one person pays attention to organization, he comes across as a nag. After a while, people ignore nags.

3. Teams need information.  They need to see a vision, generate ideas, bring in data and analyze and connect the dots.

Along with a flow of ideas, sometimes, a teams need a Devils Advocate.  A Devil’s Advocate challenges habitual thinking, checks solutions against foundational principles and values.  Without a Devil’s Advocate, teams can slip into group think, or miss risks and weaknesses when they consider options. But like the nagging organizer, no one enjoys a habitual naysayer. When there’s only one Devil’s Advocate he’s likely to be marginalized.  Like all the other leadership activities, it’s important to spread this one around.

Team members also need to know when they have too many ideas, and it’s time to slow the flow. We usually don’t think of following as a leadership activity.  But I’ve seen teams where everyone wanted to have his or her way.  I’ve seen teams sidetracked when members keep throwing in new ideas each time they come close to a decision.  Those teams argue and debate endlessly and don’t make forward progress.  Knowing when to zip the lips and follow is leadership, too.

4. Finally, every team needs people who can recognize when they are stuck and need a jiggle.  My favorite jiggle is a paradoxical question: “How can we make the situation worse?” Simply commenting on the stuck-ness can sometimes shake a team out of their rut. Changing position—standing up if the team has been sitting–can jiggle the team into productive action, as well.

***

What happens when only one person on the team—whether a formal or informal leader—tries to do all the leadership?  I suppose there are the rare individuals who can do it all. But on most teams that aren’t sharing leadership, are missing some leadership ingredients.  When teams rely on one individual they flounder when the leader isn’t available.  Worse, they don’t develop their own capabilities and slide into dependency.

Leadership is about making sure the team is functioning well and creating an environment where everyone can do his or her best work.  And it takes a whole team of leaders to make a self-organizing team.

Misconceptions about Self-Organizing Teams

At a recent conference, I over-heard three managers talking about self-organizing teams.

“You can’t just turn people loose and let a team make all the decisions. They’ll mess things up. And with all these ScrumMasters, coaches, and self-organizing teams, sounds like I’m out of a job,” said one with resignation.

“This time boxing thing is great,” said another. “Put them in a room, turn up the heat, and they’ll perform,” said a second manager.

“Wow, this means I can move people around based on projects, and they’ll just form and self-organize. I can have rolling, ad hoc Scrum teams!” crowed a third.

Time to rectify some misconceptions.

# 1. Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

# 2. All you need to do to form a self-organizing team is provide a goal and apply pressure.

#3. Since the team is self-organizing, they can accommodate moving people on and off the team easily.

Misconception: Self-organizing teams don’t need managers.

There’s a reason we use the term “self-organizing” rather than “self-organized” or “self-managed.” That’s because it’s a process and a characteristic, not something that is done once and for all. Self-organizing, from a social systems perspective only means that the team can create new approaches and adapt to meet new challenges in their environment.

Self-organizing Agile teams do have–bounded—authority to make their own commitments, organize and assign their own work. They craft appropriate strategies to accomplish their goals, and make decisions with (again bounded) economic and organizational impact.

But they are not out there on their own, disconnected from the organization. Self-organizing teams exist to produce a product or service that is valuable to the organization and its customers. They are accountable to make their progress visible, and work within financial boundaries. Self-organizing teams may also be self-managed, to one degree or another.

Managers must create the conditions that enable teams to thrive and continue to self-organize. Manager need to work across the organization to create a work system that enables teams to deliver value to customers and the organization. And managers need to work with the team to set appropriate boundaries and constraints. Managers still act as agents for the corporation. Therefore, they still must be involved where there are legal or fiduciary responsibilities.

Misconception: Time boxing forces any group to become a team. Put a group of people together and hand them a challenge and they’ll gel.

I wouldn’t bet on it, and neither should you. Teams do need a clear and compelling work goal. Without that, there’s no reason to form a team. They also need the technical skills required by the work and interpersonal skills to work as a team. They need resources such as tools and access to information and education. They need a connection to the larger organization.

The pressure cooker method of team formation will more likely burn people out than result in the productivity of a real team. Calling a group a team and turning up the heat, doesn’t make it so.

Time boxing is one of the structures than can help teams succeed by providing focus. Working in time boxes creates a natural rhythm of feedback and connection to the team’s purpose. But a time box and goal, in and of themselves, don’t create a team.

Misconception: Self-organizing agile teams should be able to accommodate frequent membership changes. After all, they’re agile aren’t they?

Teams need time to develop the strategies and trust that enables high performance. They need time to understand each others strengths and weaknesses, develop shared knowledge, and learn how to learn together.

When new people constantly arrive and leave, a group may never develop the shared approaches and shared knowledge that permit them to outperform a group of individuals.

Some teams—when they’ve had time to form and create a strong team culture—do become adept at adding new members. Even then, it’s best to limit the number of new members added at any given time. Changing more than 30% of team membership causes the team to reboot. Constant turnover prevents a team from truly forming.

As a manager, you can help by keeping teams together long enough to gel, and by protecting teams from the revolving door syndrome.

Reality

Self-organizing teams are not teams gone mad. Like all teams, they need a compelling goal, skills, information, and enough time to form and perform. And they still need managers to create a supportive context, set appropriate boundaries and constraints and connect the team to the organization.

Promoting Double Loop Learning in Retrospectives

“The thinking that got us here isn’t the thinking that’s going to get us where we need to be.”  attributed to Albert Einstein

I have  this niggling concern about retrospectives.

I have no doubt that retrospectives that are too short, don’t result in action / experiment, or fail to delve beneath the surface are a waste of time. (I suspect many retrospectives fall into this category, since many people teach that an entire retrospective consists of Keep/Drop/Add or some variant there of. This is seldom sufficient for deep or creative thinking.)

But what about earnest retrospectives that focus on an area of concern, examine data, analyze underlying issues and result in action?  I worry that some of those fall short, too.  Why?  Because the thinking that got us here isn’t the thinking that will get us where we need to be.

People work out of their existing mental models. When they examine their current actions, they may achieve incremental improvements.  But they may  take a potentially useful new practice and kill it with 1000 compromises, shaping the new practice to fit the old mental model.

This can happen even when people are trying to learn a new way of working. The first OO program I wrote looked remarkably procedural– I was trying to wrap my head around the new paradigm, I hadn’t quite gotten there yet. In a retrospective, if people try to improve their agile practices, they may improve them right back to serial development.  Or, people may make a genuine effort to improve, but they only know what they know, and the possibilities for improvement they can see are within the bounds of their current thinking.

So the task, then, is to examine the thinking and expand possibilities.

Single and Double Loop Learning

Single loop learning asks, “How can we do what we are doing better.”

Double loop learning asks “Why do we think this is the right thing to do,” and involves scrutinizing values, thinking, and assumptions.single and double loop learning

Transformational improvement and significant learning come from making beliefs, assumptions, and thinking explicit, testing them, and experimenting.

Teams may need a little help to make the jump into the second learning loop, As teams are examining their practices, ask questions that help teams surface assumptions and test them.

  • What would have to be true for [a particular practice] to work?
  • [practice or action] makes sense when ___________.
  • [practice or action] will work perfectly when _________.
  • [practice or action] will work well-enough when_________.
  • [practice or action] will be harmful when__________.
  • What do we know to be true? How do we know that?
  • What do we assume is true?  Can we confirm that?
  • Why do we believe that?
  • What is untrue, based on our investigation?
  • What do we say our values are?
  • If an outsider watched us, what would he say our values are?
  • What is the gap?  How can we make the gap smaller?
  • How could we make things worse?

Chewing on a good subset of these questions usually helps a team see their assumptions, and take a different view on what has worked, what hasn’t worked as expected, and the reasons why.

Then, they are in a better position to choose a more effective action, or design an experiment that will help them learn what action to take.

Empowering Leadership

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.