Do you have a mole undermining the work of your team? Someone who constantly complains privately to any teammate who will listen but refuses to bring that same complaint publicly to the team? Someone whose actions are destroying teamwork?

A mole erodes productivity. Stop that mole now.

A team is like a garden. A good gardener manages pests –

Bambi, a deer, can kill a portion of your garden by eating your produce’s leaves. His attacks can be seen so they can be managed by the non-specialist, by using such means as scaring him; erecting a fence; planting produce that he doesn’t like; and using chemicals that make your plants smell or taste yucky.

Buck, a mole, undermines the roots of your garden killing your produce. But unlike Bambi, you can’t see Buck in action so his attacks are almost impossible to mange by the non-specialist. For instance, scaring him won’t work because you can’t see him; erecting a fence won’t stop him because he does his work under the surface; planting different produce won’t stop him because his food source is the worms, insects and grubs beneath your garden; and using chemicals to kill the insects and grubs won’t stop him because his primary food source is the worms.

Bambi’s behavior can be managed so that it is an annoyance. Buck’s behavior is much different — it’s destructive.

Real moles aren’t malicious. Their intention is to eat rather than destroy the garden. I admire them for their single mindedness and work ethic. I, however, disdain a mole on my team.

I believe the Bucks of the world think their actions are helpful. But unlike my ability to manage the Bambis, I don’t have the special skills necessary to consistently manage or turnaround the Bucks. And in my experience, I estimate that there are only 0.1% of all managers who have that special management (therapy) skill.

What’s to be done? Confirm you are dealing with a sibling of Buck’s by — bringing the tunneling behavior to the person’s attention, telling them it’s unacceptable, and determining whether the tunneling continues. If it does, work with HR to immediately rid yourself of them.

Once they’re gone, the team will feel like the weight of the world was lifted from their shoulders. Productivity will skyrocket. Stop that mole. Now.

convert this post to pdf.

Janice strode down the hall and made a sharp right at a cubicle decorated with dragons. “Hey, Steve, got a minute? I need your help with a problem.”

“Janice, the last time you asked me for my help, I got stuck in that installation mess. I appreciate being one of your team leads, but I get worried when you ask for help with problems. What’s going on now?”

“We have a problem with customizations for Big Customer2. The good news is that we do these customizations, right?” Steve nodded. “But the bad news is that we have to port them from release to release.”

“We did that last month.”

“Well, you did. Then tech support decided to add the extra piece of the reports we discussed last month.”

“What? Why did they do that? Not to this product-they can’t.”

“Well, Big Customer2 paid us a pile of money for not too much work. And that’s where you come in. I need you to add that new report to the point release you’re working on now.”

“How much money? I bet tech support has no idea how much this piece of the report will cost us to support or how much time it will take away from our next release. We can’t just think of this report as a pile of money; it’s a headache. We were never going to put that functionality into the product. We were going to put it in the new reporting system, remember? Now we’re going to have to support that report forever. Big Customer2 is never going to want to change.”

Steve put his head in his hands. Finally, he looked up and said, “OK. I’ll do it. But on one condition: We decide what we’re doing as a development group once and for all. You asked me to be a team lead, right?” Janice nodded. “Well, I don’t know what I’m leading. Let’s decide what our mission is-whether it’s to support any crazy thing our customers want, or make products, or support installations, or what. Let’s define our mission and write our mission statement. Then we’ll have a basis on which to say no to new work if it doesn’t support our mission. From now on, we will have a reason for the work.”

A week later, Steve and Janice met to develop their mission. “Steve, I invited Chris so we have all you technical leads in one room. Since you prompted me to think about the mission for our group, I decided to ask my boss for his mission, as well. He doesn’t have one yet, so we may have to revise ours later. But at least we’ll know where we’re going.”

Janice placed two lists on the table. “Here’s all the work we’re doing in development. One list is a month-by-month portfolio of all of our projects and all the extra things I’m supposed to do as a manager. This other list is the work other people would like us to do that we’re not doing. Now, do you two have work you’d like to be doing that’s not on this list?”

Chris and Steve nodded.

Janice handed them a stack of index cards and said, “OK, let’s write all the work we’re doing and the work we’d like to be doing, one project to a card. We’ll organize them on the table into these buckets: work that seems to make sense for our group; work that needs to get done, but maybe not by us; and work that we are doing but we don’t understand why.”

After a few minutes, Janice, Chris, and Steve had their cards sorted. Chris said, “Wait a minute. Why are we looking at the work? Why don’t we decide on our mission first and then manage the work?”

“Good question,” Janice said. “Since my manager doesn’t know his mission, yet, I’m not sure we can finalize ours beyond the work we do. Clearly someone in the company values our work, so we have to make sure we continue to do work the company values but that also makes sense for us to do. By starting with an analysis of our work, we’ll have a basis for our decisions-especially when we start looking at the work we’d like to be doing that we never have time to start.”

Janice, Chris, and Steve discussed their work, bucket by bucket, starting with work it made sense for them to do.

Next, they discussed the work that they thought the company needed to have done-but not necessarily by them-and put a sticky on the card with the name of the group that they thought should do the work.

Finally, the trio discussed the work they didn’t understand why they were doing. Janice wrote a sticky with the name of the person she was going to talk to about those projects.

“Now that we understand our work and the reasons why we have it, let’s discuss our mission. A good mission explains what we do and don’t do. It establishes the boundaries of our work and explains how our development group fits into the organization. A great mission will provide reasonable and measurable objectives for our work so other groups can see what we are responsible for-and not responsible for,” Janice explained.

“Oh, so I don’t have to add something impossible such as, ‘Respond to all requests in twenty-four-hours’?” Chris asked.

“No, that’s how we got into trouble with Big Customer1 last quarter, remember?” Steve said.

“You know, if we were a custom development group, responding to all requests in twenty-four hours might make sense. But we’re not!” Janice said. “Let’s develop a mission that makes sense for us, and I’ll talk it over with my boss. I’ll convince him our mission is on target.” Janice grinned. “But if he doesn’t agree, at least I’ll understand what he wants us to do differently.”

The three of them worked for a while, until they were satisfied. Janice said, “Read the mission out loud, Steve so we can hear it.”

“We will enable our customers to organize and see their data by creating products that our company can sell. We will continue to extend each product and family of products so the products provide a cost-effective solution to our customers’ needs.”

“OK, with this emphasis on products and product families, as well as cost-effectiveness, I now have ammunition to say no to more of these customizations,” Janice said. “Maybe my boss will think about his mission instead of just saying yes to everything that he sees. But if not, we can use our mission to set some boundaries for what we do and what the company does. Thanks, guys.”

Story Lines

1. Without a mission, you can’t define the work that belongs in your group and the work that doesn’t belong.
2. A mission should say what you will do and help you explain what you won’t do.
3. Beware of missions that promise immediate response or continuous response to the organization unless you do have a 24/7/365 organization and the staff to support that service level.
4. It’s easier if your manager has a mission, but if your manager doesn’t, start with the work you do (and want to do) to generate your mission. Be ready to revise your mission when your manager develops his.

Acknowledgments:

I thank Dwayne Phillips and Esther Derby for their review.

convert this post to pdf.

Engelbert watched Pam nervously chew on her knuckle as she stood in the door of his office, answering his call. “Come in and close the door.”

He motioned her to a seat, then stood and pointed an accusing finger down at her. “We need to decide how you’re going to explain what happened with the UDCRM release”, he said. “You’ve managed to upset everyone. Sharkey told the CEO the customers are screaming because we can’t ship on time. This makes the entire development staff look bad.” He paused for emphasis. “It makes me look bad.”

Pam started to respond, but Engelbert shushed her with an open-palm gesture. “I don’t need excuses from you. Or apologies. What I need is a memo accepting full responsibility for missing the schedule.” He reached for a sheet of paper on his desk, then held it out to her. “I’ve drafted something appropriate to make it easier for you. All you have to do is sign it.”

Pam’s eyes fell to the floor, avoiding the paper. She knew she wasn’t responsible. If anyone was responsible, it was Engelbert. She tried to think of a way to refuse, but Engelbert interrupted her thoughts, thrusting the paper close to her face.

“Pam, don’t even think NOT signing this memo. If you refuse to sign, I’ll have no choice but to let you go.”

Pam struggled to keep from crying. Engelbert sat down next to her and put an avuncular hand on her back. “Don’t make me do this,” he said, his voice turning soft and empathetic. “Have you looked at the job market lately? This isn’t the boom time it used to be. There hasn’t been a decent job in the paper in months for someone with your background.”

He took a handkerchief from his pocket and dabbed at her tears. “I’ll do my best for you in the meeting,” he said gently, putting away his handkerchief and handing her his pen. “After a little time this will all blow over. They’ll probably forget about how poorly you did, and you can try again.”

The Tangled Web

It seems that the Software Engineering VP,Engelbert, has a problem. The problem started in the Liar’s Contest when he agreed to play, and thereby lost. By not planning for a disaster (No Exit) he ensured one would happen. This lead to Pam becoming the Identified Patient. The project didn’t succeed, and all Pam has to do is the sign the document accepting the responsibility (blame) for missing the schedule.

In her distraught state,Engelbert suspected that Pam wouldn’t think clearly. He helped make the experience easier by having her confession already typed and ready to sign. When Pam balked at signing he extorted her. Extortion occurs when a person obtains money, behavior, or other goods and/or services from another by wrongfully threatening or inflicting harm to this person, their reputation, or property.

We can see in the following diagram that Engelbert had at least three options available to him. He could:

• Respond negatively, looking for reasons, usually blaming someone else) for the results.
• Decide no difference exists by ignoring the results and do nothing.
• Respond constructively, learning from what happened and improving at getting the results we desire.

Choices for a poorly ending project.

Of the three choices, only the bottom loop, Improve Software Development, reduces the likelihood that the next project won’t fail. Improving software development will involve training for such things as the development method (changing from waterfall to iterative) or support (version control systems, development tools) and time, making it the least likely choice in this environment. Ignoring the failure (or declaring the results a ?success?) leaves the existing system structure in place, and pretty well assures the next project will unfold like this one. Choosing to blame someone for the failure creates new and different problems.

Let the Game Begin

Blaming attempts puts the responsibility for the problem “on someone else”. If successful, the blamer becomes exonerated and the “blamee” now has to deal with being the cause of the problem. In hierarchical systems, blame (like many other activities) starts at the top, and flows down from there. Englebert may be getting heat from Sharkey and the sales organization about missing the delivery date. Englebert may be a skilled player, and is setting Pam up for the fall, being able to report, “I’ve already taken care of the problem.” Unfortunately the problem Englebert solved, him being blamed, doesn’t help solve the real problem, how to be more effective at software development and not have bad project results.

Blame affects organizations on multiple levels creating different problems.

• Employees quickly learn defensive maneuvers such as CYA. They split their time between making sure they won’t “catch the blame” and doing project work. This affects both focus (context switching between project work and dodging blame) and the time available for project work. This increases the probability the next project will fail.
• If it goes long enough, people leave. The competent employees leave first, creating a brain drain, which increases the probability the next project will fail.
• Those that remain have developed dodging skills, not development skills. Thus they’re more likely to be around longer, get promoted, and the cycle perpetuates itself.
• Attention never shifts to improving the process, so the systemic solution (improved development capabilities) never gets developed.

Results of blaming

So blame creates problems beyond the original problem. It creates negative emotions, a talent vacuum, and a downward spiral. Talented people won’t work in a blaming organization. The amount they have to pay new employees goes up. This reduces the bottom line, which puts pressure to develop faster, but without improved skills failure actually happens faster, which increases the blame, and around the blame dynamic goes once more.

Note that all three loops in the Blaming in Action diagram are reinforcing (or positive feedback) loops. This says that once these loops start working, they will continue to grow stronger until something, somewhere else in the system collapses.

An Ounce of Prevention

The best way to deal with such a situation is to not get involved in the first place. But in the excitement of a new project, and new responsibility, it’s understandable Pam didn’t see the warning signs.

The next best advice involves noticing the signs of a failing project. You can learn a lot about a project status by checking for congruence.

• Observe what’s actually happening. Are people doing what they say they’re doing?
• Listen to the language people use. Do you hear blaming?
• Does it feel like there’s an elephant in the room that no one acknowledges?

No one can come out and actually say the project looks like it’s failing. That would set them up to be blamed.

Blaming cultures reveal themselves in a variety of ways. Attitudes such as “failure’s not an option”, or “if you can’t do it, we’ll find someone who can” give one such indication. Another tipoff is hearing phrases like ?It’s not my fault.” “She/he did it”, “You didn’t tell me”, and “I didn’t make that decision” (or their inverses). When you see an exodus of employees, it’s probably a sign the blame loop is functioning at full force.

Multi-level Blame

Blaming doesn’t start at the bottom of the company. Programmers don’t hunt for someone to blame when the a project is late. They scurry for cover. Blaming starts higher in the organization. In this case, the blame occurred at the VP level, between Sharkey and Engelbert. Blame can be thrown around like a hot potato, everyone looking for someone else to throw to.

Engelbert wasn’t able to pass the blame at his organizational level, so he passed the blame one level lower by setting Pam up to receive the blame, and extorting her. If Pam chooses to play the game, she in turn could look for a team lead to blame for the late delivery. And then the team lead could hunt for someone on his team to blame.

What’s A Girl To Do?

At this time, Pam certainly feels like a “deer in headlights.” If she doesn’t get some space to breathe, and time to think, she’ll most likely sign the paper. Pam needs to do something to break the setting. A deep relaxing breath. Shifting her position in the chair. Standing and moving. Getting some space would provide time to think and distance from the problem (as in being blamed). Get a headache. Go to the bathroom. Anything to create space and gain some time.

One thing she could do is threaten, “If you fire me, I’ll tell the whole story when I’m on my way out.” This is blackmail countering extortion. Playing this card requires being ready for “on the way out”.

Confronting Engelbert in his office probably won’t work. Counter-blaming Engelbert won’t work. He has more experience playing the game and can control the flow information to higher in the organization. He’s hoping Pam will placate and sign. Blaming and placating are two of the coping stances available to Pam.

By adding the context to the discussion, other stances become available. Pam can do this by asking “What have you seen or heard that makes you think that I’m responsible for this failed project?” This opens the possibility for a congruent conversation recognizing and balancing, self, other, and context. Pam can then act congruently. While Pam can’t make Engelbert be congruent, she can demonstrate congruent behavior and work towards the best possible outcome.

convert this post to pdf.

IT professionals must be good team players, but what does that mean?

For one thing, it means they must know how to come into a situation and quickly cooperate and gain cooperation, but cooperation takes many forms. It’s not sufficient to want to cooperate. You must also know how. This column is about the technology of cooperation.

People
Most people, when they think of cooperating, think of everybody doing the same thing?like all pulling on the same rope in a tug-of-war or rowing in the same Roman galley, perhaps chained to the oar. When you consider cooperating by sharing people’s direct labor, first try to categorize the situation into one of these two:

1. The job is well understood and easy to communicate to a newcomer.

2. The job is fuzzy, or not understood at all, or complicated.

In the first situation, as in a tug-of-war, it is relatively easy to move people about from one work group to another. The amount of productivity in this situation is roughly the sum of the individual productivities. Ten people can tug ten times as hard as one. Many managers think that adding IT professionals is just like adding bodies to a tug-of-war team.

But even a tug-of-war is not so simple, for those who are experts at it. Given roughly equal weights on both sides, the team that understands and uses technique will win every time – and can even overcome substantial weight deficits. Adding a new member to a skilled tug-of-war team will not add proportionately to their success. Indeed, unless the new member understands their technology and system of communication, the addition of another body is likely to reduce their total tugging effectiveness.

When the job is fuzzy, and ideas are needed more than simple tugging power, the addition of a new member can be helpful if the team is ready to accept new viewpoints imported by the new member. Experienced IT professionals, however, know how hard it can be to have their better ideas heard when they’ve just started a new assignment. It can be horribly difficult to integrate a new person. Time and “wasted” effort must be allowed for in such additions, especially as the job grows more complex.

Thus, if quick addition is needed, adding people willy-nilly is not the answer. This observation was the essence of Brooks’s Law – adding people late in a project makes the project take even longer. Adding them early, however, which allows time for this “wasted” effort of integrating the new people, can, in the end, make a project go faster.

Any IT professional who is thrown into a project late and expected to make things go faster needs to be aware of Brooks’s Law and needs to communicate to the management what kinds of delays are to be expected. Moreover, each of us IT professionals needs to master the arts of quickly learning what the job is about and how the existing team communicates.

Programs
When we import a program or a piece of hardware to a project, we import technology in a form that may seem more acceptable than a new team member might be. This is the dream of reusable software. But when the team members feel that their own technology is an extension of their own egos, programs may not be portable at all. Instead, they run into the “not-invented-here” brick wall.

Of course, even when a team is willing or even eager to import software or hardware, it may prove poorly designed for portability. In general, portability of complex technology doesn’t come by accident, but by design and by testing of the design. Even for well-designed technology, there is a break-in period which may or may not be shorter than the time taken to add a new member to a team. Of course, the payoff for an imported technology can be huge, but only if it’s adopted and used.

Some IT professionals come on the job with their own tools, not anticipating the amount of difficulty they will experience getting the existing team to adopt their “superior” tools. If you feel that your tools add to your value as a IT professional, you must master the art of introducing tools – especially to people who may be insulted by the very idea that you might know something better than what they already know.

Perceptions
Ideas or ways of thinking can be the most portable of all kinds of technology, as long as the ideas or perceptions are not labeled too clearly as “belonging” to someone. The rule here is perhaps the most important that a technically-oriented IT professional can learn:

There’s nothing you can’t accomplish if you aren’t concerned who gets the credit.
If a project is successful, there’s always enough credit to pass around.

Points or Perceptions
Much of what we do on a job is to win the approval of the management, or of the customer. We call this “scoring points.” Success on a job depends very much on the ability to score points, in whatever game management happens to be playing. If they are playing a good management game, then the more points you score, the better the job you must actually be doing.

But bad managers give points for the wrong things, and if you work under such a point system, you soon become a poor performer. In any case, though, in work as in life:

Points can never be passed directly from one person to another.
To pass points, you must pass people, programs, or perceptions.

In general, sharing perceptions may be the easiest way to cooperate. Moreover, if you don’t share perceptions, it may be almost impossible to cooperate. So, when you enter a new group and want to cooperate, it’s best to start by listening?and learning how other people perceive the world.

convert this post to pdf.

Meetings are a fact of our lives. Most of the time we don’t need a facilitator to help move our meeting along; we can manage to accomplish the goals of the meeting without a formal facilitator. However, there are times when a facilitator makes sense.

Darcy is a middle manager in a startup. They have enough money for the next eight months. For the last three months, the senior managers have closeted themselves in meetings day in, day out. Darcy knows they’re trying to define the current strategy and tactics to accomplish the goal: drive enough revenue to break even. If they can break even in eight months, their investors will consider investing just a bit more to overcome the slow economy and the company will succeed. If they can’t break even, they’ll be shut down.

Darcy’s no dummy. Neither are the other people in the company. They all know what these closed-door meetings mean. Darcy is concerned that if the senior management team can’t figure out what they’re going to do soon, the meetings will turn into layoff-decision meetings.

Darcy’s management team needs a little facilitation to help them overcome their inability to come to a decision and move forward to specific tactics and action items.

Senior management teams aren’t the only groups who become stuck and need help making decisions. Sometimes, a technical group has the same problem. Desmond, a database developer has on ongoing discussion with George, the GUI developer, and Tina, the tester about how to appropriately design the database upgrade for their product. Desmond, George, and Tina all agree they need an upgrade. They can’t decide how the upgrade should work. Depending on how they choose to implement the upgrade, their work will change, as well as the work the users will have to accomplish. Each of them has different ideas, and each idea is valid. They can’t come to a decision, and they have only a week left to decide.

In both of these cases, well-meaning, intelligent people are stuck. Their normal ways of managing their disagreements are not working.

Consider choosing a facilitator under these conditions:

• When a group has trouble coming to agreement on a strategy or set of actions.
• When you want to be part of the discussion and decision-making. It’s not possible to treat the group fairly if you want to participate and facilitate.
• When you want to explore a previous project (retrospective facilitator) or explore alternatives (meeting facilitator)

You may be able to use people inside your organization as facilitators. Sometimes HR people or others are trained as facilitators. If you’re not part of the problem context or solution, you can facilitate the decision-making.

Whatever you do, choose when you require a facilitator. Don’t let the problems or conflicts escalate into no decisions, especially when you require a timely decision.

convert this post to pdf.

In a recent workshop, I described an exercise for expressing appreciation. “That won’t go over here,” stated Patty, one of the managers in the workshop. “These are engineers; they don’t want that mushy stuff. Besides, they know that we value them.” Patty didn’t notice that several of the engineers were shaking their heads in disagreement.

The engineers in Patty’s company aren’t the only ones starved for notice and appreciation. A recent Gallup Poll report quoted this statistic: “…the number-one reason people leave organizations is that they don’t feel appreciated, notes the U.S. Department of Labor.”

Given the high cost of replacing knowledge workers, reducing the number-one reason for turnover seems like a good investment. And when you consider that this investment doesn’t cost a dime, why not eliminate the appreciation gap?

An Appreciation Primer

When you offer appreciation, appreciate the person, not just the work. Most people like to hear “you did a good job.” But a comment on the quality of work is an evaluation. I like to use this form, which I learned from the work of Virginia Satir:

[Name of person] I appreciate you for [contribution, action, quality].

I might say, “Tom, I appreciate you for moderating technical reviews. It’s really making a difference in our code quality.”

I?’l admit that this felt awkward the first time I tried it. But I also noticed that these words had a very different effect than “You did a good job” or “Thank you.”

Appreciation Guidelines

Be authentic. Authenticity means that you really do believe what you are saying. Pavlov proved that it’s possible to shape canine behavior by providing rewards for a desired response. People, however are not canines, and they are quick to recognize manipulation. Going through the motions isn’t enough.

Appreciate privately. Most people don’t need or want their manager to gush over every accomplishment in public. In fact, public recognition is uncomfortable for many people. A word in private will let people know that you do notice and appreciate.

Appreciate weekly. “Atta boy” once a year during a performance evaluation isn’t enough. Notice and comment on a contribution every week.

Traps to Avoid

Don’t dilute the value of appreciation. Some well-intentioned person devised the “praise sandwich” as a recipe for delivering feedback. A praise sandwich surrounds criticism between two bits of praise. I suspect this person wanted to ensure that the feedback recipient was in a receptive mood by making them feel good. In reality, the praise sandwich conditions people to expect a slap after a positive stroke. If you have feedback to offer, do it! Don’t dilute the value of appreciation by only giving it along with bad news.

Token rewards anger as often as they delight. One colleague received a movie ticket from his boss after he’d worked well into the evening to fix a critical defect. His response to the reward was one of anger. “After I already spent one evening away from home, he wants me to spend another one? without my wife!” he stated in disbelief.

Don’t wait. When Sara handed in her resignation, her boss told her she was the best project manager he’d ever worked with. “Why’d he wait until I quit to tell me?” Sara fumed later. “Maybe if he’d let me know that he noticed what I did for the company I’d still be there.” A few simple words a week could have kept Sara on the job.

You may feel awkward when you first try giving appreciations–I know I did. Practice in a low-risk situation, maybe by telling a store clerk you appreciate her for helping you find just the right item. Watch what happens and practice until it feels natural. Then try out this simple practice at work.

convert this post to pdf.

(c) 2005 Johanna Rothman

This article appeared previously on stickyminds.com.

I meet many managers in the course of my work, and they all share a common complaint: They have too much work to do.

I ask how they know there’s too much work to do, and they look at me as if I’ve sprouted another head or two. “My staff and I are spread too thin–that’s how I know,” they answer.

I ask if more people would help. “Of course,” they answer. While they look at me as if I’m an idiot, I ask the question that too few managers can answer right then and there, “How many more people would you need, and for how long?”

I have sympathy for those of you trying to work in organizations with too few people and too many projects. So, I recommend you develop an answer to the “how many people” question. Once you have the answer to that question, you can then deal with the trade-off question with your managers, “If I take on this new project, which work would you like me to stop?”

Define the Universe of Work

I develop and manage a project portfolio by first defining all the work (the “universe of work”), organizing the work by seeing when each person starts and stops each project or piece of the project, and by listing the unstaffed work.

It’s not easy to define all the work, so I make sure I include these activities when defining the work:

• Project work (work toward a specific project with an end date)
• Periodic work (such as monthly reports or yearly budgets)
• In-process ad hoc work (work you are doing as the result of crises or other surprises)
• Ongoing work (support for the operation of an organization or department)
• Management work

Organizing the work this way ensures all your project work is included in the Universe of Work&msash;plus all the work you or your staff performs to maintain the lab, support a product, negotiate with another department, or to budget. When I discuss this with managers who are in charge of five to six people, it’s not uncommon for them to
list more than thirty activities. If you’re in a larger group, you may have more than thirty separate activities.

Take time to define your Universe of Work. I normally set aside one half-hour to write everything down. Once I have a first draft, I put my list away for a day. Afterward, I revisit it to see if I want to add anything. But don’t feel as if you need to complete your Universe of Work list with just one review; it’s easy to forget the periodic work or intermittent ad hoc work.

If you’re so busy you don’t have time to think, you may want to take a little time every day to review your list and add to it.

Organize the Work

Once you know what all the work is, you can make a plan of how you and your team will complete the work. I like to use a whiteboard or flipcharts for this, especially if I have more than a few people in my group. The top row of the paper lists your timetable, which begins with next week followed by consecutive weeks (January 1, January 8, January 15, and so on). Write the names of the people down the left most column. For each week, write down what each person is working on.

If you have many long projects, write the names of the months across the top of the page. Block out the projects, with their start and end dates down the page. Then take a one-month snapshot and fill in the blanks by person.

Now you have a list of what everyone is working on?and when?for the next month. And I’ll bet there’s more work from your Universe of Work list. List that work on the “unstaffed” list.

List the Unstaffed Work

Underneath the last person’s name, write “Unstaffed work.” Now, week by week, add in the unstaffed work row everything that’s in the Universe of Work that is not assigned to anyone. You should have a picture that looks something like this:

This is a portfolio for a cross-functional team. If you manage or are part of a single-function team, the tasks in the boxes would reflect that.

Estimate the People Required to Complete the Unstaffed Work

With this picture, you can see who’s working on what?and whether those people are multi-tasking?and how much work is not staffed. Now you can estimate how many people you would require to staff the unstaffed work.

Manage the Portfolio

I find that the hardest part of this is starting. Once I have a rolling wave, four-week portfolio, I find it relatively easy to maintain.

As you complete one week, add the data for the next week at the end of the plan. If you’re not sure how long a duration portfolio you need, start with a four-week plan. If you don’t have enough insight into the future, consider adding another week or two onto the end. But I find that few people or organizations are able to maintain detailed tactical plans longer than a few weeks, so more detailed planning isn’t useful.

Once you have a detailed rolling-wave plan, you’ll be able to answer the question of how many more people you need and how you could restaff the projects to take advantage of more people.

But I find the project portfolio chart much more useful than just showing my management where we are understaffed. I use the chart when my manager assigns my group more work. I show my manager the chart and ask, “My staff are working as hard as they can. They can’t do more. What work would you like me to move to the unassigned work?” Now we can have a conversation about how much work needs to be done, the criteria for completing the work, and the relative priority of the work.

Summary

Knowing how much work you group can accomplish?and when they can finish that work?is critical to your success as a manager. With a project portfolio, you can manage the work. You can make tradeoff decisions about which projects to staff and which ones to leave unstaffed. And you’ll know how many more people you need for how long. Make sure you’re managing the project portfolio, not allowing it to manage you.

convert this post to pdf.

This column originally appeared on stickyminds.com

In a recent discussion on the state of a software company,
a programmer declared, “We don’t need managers around here,
we need leaders!”

I’m always puzzled by statements like this.

“How do you see the difference between management and
leadership?” I asked.

“Managers do things right, and leaders do the right thing,”
the programmer replied, repeating a Warren Bennis quote.

“But what do they do differently?” I pressed.

quot;Managers manage, and leaders lead,”
the programmer replied with conviction.

Here’s how leadership professor John Kotter describes the difference
between management and leadership (which I paraphrase here):

Management is:

• establishing timetables and steps for achieving needed results and allocating resources to make it happen.
• creating structure, staffing and delegating responsibility,
  and having the authority to accomplish goals.
• monitoring results, identifying
  deviations, and planning and organizing to solve problems.
• producing key results expected by various stakeholders.

Leadership is:

• establishing direction, and developing a vision for the future.
• aligning people, modeling the vision, influencing, and creating
  teams and coalitions.
• inspiring people to overcome barriers to change by satisfying
  basic human needs.
• producing useful change.

Reading these lists, it’s clear to me that organizations need both.

Here’s an example. A test manager takes a job with a new testing group.
He talks with his team, his manager, and the internal and external
customers for his unit’s work.
Based on what he hears, he articulates a mission for the group: “We
provide assessments of product quality and help product owners understand
risks.” That’s leadership?setting a direction.

He works with the team to identify all the work they’re currently
doing, work that’s in queue, and projects scheduled for the next several
months. Together, they assess what they can accomplish,
what they won’t do, and whether they have the right mix of
skills to do the work. That’s management.

He supports the team as it self-organizes to accomplish the work.
The organizing part is management (done by the team), while supporting
self-organization is leadership?meeting human needs for autonomy.

The test manager works with the team to identify the resources they
need?machines, tools, and training?and then adjusts the
budget to acquire the necessary resources. That’s management.

He’s showing leadership when he meets with members of the team to
understand their aspirations and help them articulate professional
development goals. When they work together to build skills into daily work,
that’s management.

As the team works to test its products, the manager and the team work
together to develop metrics and dash boards that show test progress and
communicate the quality of the product?management again.

He makes sure the development manager and product owner define
release criteria, leading through influence. He also brings change to
the way the company makes ship decisions. When a testing project
starts slipping, he pulls the team together to assess the issues and
replan their approach–management, according to Kotter’s definition.

And so it goes?a little management here, some leadership there.
The balance shifts, depending on the situation. The test manager combines
management and leadership activities to attend to people and accomplish
meaningful work.

I’ve worked with people who were all leadership. When they lacked
management behaviors?follow-through and attention to practical
implementation?they left chaos in their wakes
(and didn’t actually produce much useful change). I’ve also worked
with people who were mostly management, which only worked when they
had enough personal warmth to navigate human relationships.
(In accounting areas, you don’t necessarily want creative ideas or
big charisma?think Enron.)

Viewing leadership and management as dichotomous sets up a false
choice. Most positions in organizations need both, and that’s what
effective managers deliver.

convert this post to pdf.

The other day, I was trying to help a client (let me call them “StartupCompany”) mired in conflicts, exceptions, errors, anomalies, lapses, modifications and other deviations from the norm. These annoying exceptions were playing tricks with my blood pressure, so I had to be wired to a wearable blood pressure computer for twenty-four hours. As if StartupCompany didn’t have enough interruptions, now my wearable computer was inflating a blood pressure cuff at random intervals throughout the day.

Every time the cuff inflated, I petulantly asked myself: Why can’t they run a project like real people living run-of-the-mill, low-blood-pressure lives?

That night, I was using the Yellow Pages, and in the A categories in the Yellow Pages index, I chanced to notice a curious pattern. Here are the first few items:

Abortion Services and Alternatives. These were the first two entries in the index. I decided to skip them both, so as not to take sides in the pro-choice/pro-life conflict. I had enough conflicts within StartupCompany.

Abuse – Men, Women, Children. I decided to continue my scan of the index, and this was the next entry. The normal process of family living involves people loving and respecting each other, communicating well, and behaving appropriately according to societal norms. But when people start behaving inappropriately, they need Abuse Services. In StartupCompany, people normally respected one another, communicated well, and behaved appropriately according to societal norms. But they sometimes didn’t, and they lacked “abuse services” for coping.

Academies (including private schools and special education). When the formal education system doesn’t provide special knowledge or handle special cases, private academies and special education are called for. People within StartupCompany often needed to know things they hadn’t learned in the public schools, but StartupCompany had no provision for special education.

Accident Prevention. Accidents aren’t “supposed” to happen, StartupCompany had accidents. In order to improve, they needed processes to prevent accidents and to mitigate their consequences.

Accordions. Despite what some people think, accordions are perfectly normal, though not everybody learns to play them or appreciate them. Still, StartupCompany could have used some entertainment to lighten the mood once in a while.

Accountants. Accounting is also normal, but, if everything always went according to plan, we wouldn’t need to account for things so carefully. We have to protect our financial well-being from mistakes and misbehavior, and that’s what accountants do – and also what they should have been doing in StartupCompany.

Acetylene Welding. Some welding is normal, and some is for repairing things that are not supposed to break – but do anyway. StartupCompany lacked a “welding team” to handle lots of stuff that broke.

Acrylic Nails. Most normal people have fingernails, so why is there a nail business? Oh, yes, it’s the human interface, and StartupCompany had to cope with conflicting ideas of what made a system beautiful – but they had no special beauty experts to resolve the conflicts.

Acting Instruction. We all need to “put on an act” now and then when we’re caught by surprise. StartupCompany’s people certainly needed training in how to behave in improvisational situations, but there was no acting instruction.

Acupressure/Acupuncture. If we were all healthy all the time, we wouldn’t need medical services, and if “normal” Western medical services worked all the time, we wouldn’t need acupressure and acupuncture. So, there are not only abnormal services, but meta-abnormal services – the services when the normal abnormal services fail – certainly true in StartupCompany.

Addressing Service. Have you ever tried to maintain a mailing list? Almost all the work is not the mailing itself, but maintaining the addresses. It’s even worse for email, because email services haven’t yet evolved “normal” ways of dealing with changes. Gee, neither had StartupCompany.

Adjusters. Adjusters, of course, are an abnormal service from the get-go. Without accidents, we wouldn’t need insurance, and if things stayed on course, StartupCompany wouldn’t have needed risk analysis. But they did.

Adobe Materials and Contractors. Adobe materials may not be “normal” where you live, but here in New Mexico, adobe is a normal building method. StartupCompany, too, has its idiosyncratic processes that are not normal in other projects – and newcomers have to learn about them or pay the price. But StartupCompany had no special services to bring newcomers up to speed.

Adoption Services. Yes, sometimes people are not wanted by their parents, and StartupCompany certainly had some unwanted people. But, they lacked “adoption” services for moving unwanted people around.

Adult Supervisory Care. “Normal” adults can take care of themselves without supervision, and normal workers wouldn’t need much managing at all. But StartupCompany had two adults who could not take proper care of themselves, and the managers spent an inordinate amount of time on these two out of a hundred.

I stopped there, sobered by my reading. It was now clear to me that StartupCompany, being a startup, had an overly simplistic picture of what it takes to run a company. I needed an adjustor to adjust my blood pressure – I needed to see that my job as their consultant was to teach them that deviations are normal, and that they (and I) could do what real people do:

• stop whining and deal with them
• create systems to deal with them
• create systems to prevent them

convert this post to pdf.