13 Essential Questions for Managers

We think of managers making decisions, setting priorities, organizing work, keeping budgets, and mentoring people.

What we’ve overlooked or ignored is a manager’s role as designer. Managers are designers of the experience of work and of systems to produce valuable products.

As designers, we need to answer 13 essential questions.

1. How does the work really work?

2. What information and tools do people need to do their work?

3. How can we build feedback into the work so that people can find and fix their own mistakes quickly, and learn from them?

4. How do we know when a chunk of work is done?

5. What is the capacity of the team?

6. How long does it take us to know if we are off track?

7. How do structures affect people’s ability to accomplish their work?

8. What message does our reward system send?

9. What message do our policies and procedures send?

10. What happens when people bring unwelcome news?

11. How do my management actions affect people and work?

12. What do I “know” that ain’t so?

13. What do I know that I forget at work?

Performance without Appraisal: Build Feedback into the System

At the start of my series on Performance without Appraisal, I listed the goals that organizations hope to achieve with annual performance appraisals and so-called performance management systems:

improve individual performance
improve organizational results
determine pay/promotion

These are legitimate concerns.

The data shows, and my experience tells me, that annual appraisals fail miserably with the first two goals. The ratings and rankings that come out of reviews may provide justification (or cover) for so-called merit pay and bonuses--but merit pay has its own problems.

In the next series of posts, I'll discuss ways to meet those goals.

In order to improve performance, we need to look at both the person and the environment. P = f (p,e).

People need information in order to improve their performance. Receiving that information at the end of the year (or even at mid-year) isn't timely. Worse, ratings and rankings are evaluations, not the sort of concrete examples of results/behavior and their impact that people need to improve.

If you really want people to have information when it will do the most good, build feedback and opportunities for improvement into the system.

Agile (when it is done properly) does this quite well. Some examples:

Programmer tests

Continuous integration and build with automated tests

Testers on the team

All of these agile practices provide information that allows individuals to find errors early.

The following agile practices provide information that allows not only individual level improvement, but team-level improvement as well.

Pair programming (especially with frequent pair changes)

Daily stand-up (whether done sitting or standing)

Task boards

Information radiators

Retrospectives

Product demos

On site or near customer

Feedback from the system may allow people to work more effectively within their current process (single-loop learning). But if you add reflective processes (e.g., effective retrospectives) teams can examine the process and the assumptions behind the way they work. That's an opportunity for double-loop learning.

If you really want individuals and your organization to do better, you need both. And you need them more than once a year.

Next: Make interpersonal feedback about work and working relationships business as usual, not an annual or semi-annual event.

Why Group Dynamics and Interpersonal Skills Matter

You think group dynamics and interpersonal skills are just fluffy stuff?

Wrong-o. They are an essential element of competitive advantage.

High-tech companies succeed by out learning and out innovating the competition. Group dynamics directly the affect the ability of a team to think, learn, and innovate together.

Groups that avoid conflict won't be able to face tough issues or handle the creative conflict that generates new ideas.

Groups that are highly competitive won't share ideas and build on other's ideas. People won't share the credit for success, further decreasing the chance for creative collaboration.

Groups that defer to a person of higher status will miss many good ideas, and fail to tap and develop the talents of the entire group.

Groups that haven't learned to work well together will take the first workable solution to avoid unsatisfying and uncomfortable interactions.

It takes more than smart people to succeed. It takes smart people who have the interpersonal skills for creative collaboration.

(If you want to learn and practice collaboration skills, come to Secrets of Agile Teamwork July 21-23, 2009 in Redmond, WA.)

Five Reasons to Hire a Coach for Agile Teams

I run into managers who think that they can coach the team as the team adopts Agile methods. In my experience, this usually doesn't work out very well.

So managers, support the team as they learn Agile methods by hiring a coach! It's a investment in success.

Here are five reasons that coach cannot be you.

1. The team needs someone skilled in XP engineering practices and current on the latest testing tools. If you haven't written code in more than three years, or you've never worked on a team that used all the XP practices you don't have the knowledge to coach the team. Sorry. Doesn't make you a bad person or cancel out your value to the organization. Does mean you are not the right person to coach on XP.

2. You may have a conflict of interest. If you are being measured on delivery dates, its possible that you'll ask the team to cut corners, work extra hours, or drop practices to meet a date. That would be bad. The team needs someone who will hold the process in place and help them hold firm when someone is worried about making a date. That can't be you, if you're the one worried about making the date.

Even if you'd never do that, on some level, the team may not believe that yet, especially if you've ever done so in the past. And if they think you'll cave in the face of a date, they'll cave before you even ask them to. It just works that way.

3. A coach will help the team stick to the process, and guide them away from making adjustments that nibble away at iterative incremental development until they are back in a mini-waterfall.

Agile really does involve a shift in the mental model of software development, and until you have an intuitive grasp of the principles and values, the nibbles will make sense to you, too. You've got to live it for a while before you can coach it.

4. As long as you are there to solve problems and tell people what to do, it will be easy for the team to remain dependent on you. It may feel good to be needed, but in the long run, it doesn't help the team, doesn't help the company, and doesn't help you.

5. You've got a ton of other stuff to do supporting the team, removing obstacles, running organizational interference, and working on the work system. Plus you have to do the budget.

Of course, you don't have to be dependent on outside coaches forever. Once you've established a few Agile teams, you can develop a cadre of coaches made up of your own experienced people.

Pfeffer's Six Dangerous Myths About Pay

A few days ago, I had a little twitter conversation with Dave Rooney, Ben Simo, and Elisabeth Hendrickson about rate vs. cost.

Which reminded me of Jeffrey Pfeffer's excellent article, Six Dangerous Myths About Pay (originally in HBR May/June 1998).

This article should be required reading for all managers.

The Myths are:

Myth #1: labor rates are the same as labor costs.

Myth #2: cutting labor rates will lower labor costs.

Myth #3: labor costs represent a large portion of a company's total costs.

Myth #4: keeping labor costs low creates a potent and sustainable competitive edge.

Myth #5: individual incentive pay improves performance.

Myth #6: people work primarily for the money.

Ain't none of 'em so.

When managers confuse labor rate with labor cost, they make decisions that usually end up costing lots of money.

Labor is an easy to count cost. It's much harder to count the costs of multi-tasking, poor decision-making, ineffective and demotivating work systems, communication latency and other wastes. But the later factors have a big effect on productivity, and therefore, labor cost.

When to stand back, when to step in

Part of my definition of a successful team is that the members of the team increase their knowledge and capacity as a result of their work on the team. That means that giving the team the opportunity to learn is part of the job.

One of challenges I see when managers first start working with agile teams is knowing when to step back, and when to step in. Swinging too far in either direction hampers team learning.

Helicopter Managers step in too soon. They swoop in at the first whiff of a problem to "rescue" the team. They deprive the team of the chance to think, solve problems, and decide together. These managers may believe they are doing the team a favor; what they really do is hamper the team's development.

Absentee Managers throw up their hands and say "you figure it out," no matter what the issue, or whether the team has the skill and authority to solve the problem. These mangers let the team flail and churn, wasting time and building frustration. People do learn from mistakes; but when people feel frustrated, hopeless or abandoned by their manager, increased capability is not the likely learning outcome.

Self-organizing teams still need managers. But those manager need to know when to step in, and when to stand back.

Here are three guidelines to help managers gauge their actions with self-organizing teams.

#1. If the team has the skills to solve the problem--or they are on the verge of having the skills--give them space to solve the problem. If they're stuck or don't see how to use the skills they have, ask questions to help them get unstuck. They will learn much more from wrestling with the problem than having the manager fix it. (Assuming it's not a management problem. Then it's managements job to fix it.)

#2. When time is not of the essence give the team time to work the issue. If it takes a day or two to solve the problem, will it bring the company to it's knees? (If the answer is yes, you've got bigger problems than working with a self-organizing teams.) Keep in mind that many companies live in permanent fire-fighting mode and believe that everything is urgent. Or the manager believe that people won't actually apply sufficient effort unless they believe the issue is urgent. Again, that's a bigger problem. OTOH, if there's information that will help the team solve the problem give the information. Withholding the information is just plain wrong. Likewise, if there's a very simple solution that the team is overlooking, ask questions to help them discover it.

#3. If the solution space is limited in scope and impact, or the decision is reversible, give the team space to solve the problem, even it there's a good chance they'll get it wrong the first time. If the solution space isn't bounded, then there's something amiss with the way the problem or decision authority has been delegated. Bound the issue so that the team is involved and there's appropriate fiscal and management oversight.

There's always a trade off between expediency and a learning opportunity. Self-organizing teams can outperform manager-let teams....but only if the managers are willing to navigate the balance.

Shifting from a manager-led team to a self-organizing team is a little tricky. It calls on a different set of skills, and brings up questions about value and identify for many managers.

But there's still plenty of work for managers to do. It just doesn't involve task management and having all the answers.

Shocking Survey Results about Performance Appraisal

The landed in my inbox this morning:

In a famous Leadership IQ study, we surveyed 48,012 CEOs, Managers & Employees about their performance appraisals. Here's the shocking results: Only 13% of Managers & Employees thought their performance appraisals were effective. And only 6% of CEOs thought their appraisals were effective. We also discovered that only 14% of employees say their performance appraisal conversation offered meaningful and relevant feedback.

Actually, I'm not shocked by these results. Not even surprised.

What is shocking is that many organization continue to add layers of process, systems, and training, in an effort to make a fundamentally broken concept work.

I'm not saying we don't need feedback. We do need information about results and behavior. That information needs to be relevant, timely, and actionable. For ideas on how to make feedback useful look here.

I'm not saying that we don't need to have conversations about performance.

I'm not saying managers don't need to make decisions about whether a person's performance matches the needs of the job.

But the typical performance appraisal process fails to give useful feedback, fails to promote meaningful conversation, and seldom leads to decisions about fit for job.

FAIL.

When there's disagreement on feedback data

In my previous post, I described a framework for offering feedback on work results and work relationships.

Step 2 is Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Karen asks:

.... in the case of, "If the person doesn't recognize himself in the description or agree with the data, the conversation is over", what is the manager's next step?

I don't know the specifics of Karen's situation; here's my general advice

First, check your own language.

Adults almost always reject negative labels. (Unless they've been hearing them since they were tiny children, in which case their self-perception has probably become a self-fulfilling prophecy. But that's another story.) So a label such as, inconsiderate, unassertive, sloppy, is not likely to move the conversation forward and achieve change.

Descriptions that are vague can have the same effect. I met a woman who was told in her annual review, "You are too nice." Her manage didn't provide any examples of behavior or impact. That left the feedback receiver struggling to figure out what her manager was talking about. She was reviewing past events trying to sift out what event could possibly have triggered the comment. When people are left to do this, they often pick an incident completely unconnected to the genesis of the feedback, with predictable consequences.

Absolutes invite people to find the one counter example to your statement. If you tell some one he is always late, he will find the one instance where he was on time.

Labels work against perceptions that the feedback is fair, and that the feedback giver has good intentions. (Point 1 and 2 on conditions for effective feedback) When the feedback receiver questions the label, and the conversations devolves into yes-you-are/no-I'm-not, violating Point 3 on conditions for effective feedback. Which in turn creates the feeling neither the process for developing the feedback, nor the way it was delivered is fair (Point 4).

It's really hard to break the labels habit and eliminated loaded words. Really hard.

Even when your language is clear and neutral, it could be that the person needs time to process what you've said. That not unusual, especially when the new information conflicts with their own self-perception. People are generally more receptive if they've heard something about that area of behavior more before. Pushing some one to acknowledge your point of view during the initial conversation will fuel the defense dynamic.

Some options:

• offer some time to process with an agreement to revisit the feedback in a few days.

• suggest that the person talk to a handful of trusted peers to see if they have noticed the behavior

• ask the person to monitor his own behavior for a period of time and see if he notices himself doing what you've described


All this assumes that the organization can tolerate the behavior for a short time longer as the person works through his process. And it assumes that you have a generally positive relationship with the person. The timeframe you set depends on the impact of the behavior.

In a hierarchy, there’s always “the Big Game” of who get to tell who what to do. Playing that game is a loosing strategy.

You might shift your approach and focus on the desired outcome rather than the current behavior. If the behavior is getting in the way of that person doing his job, you can shift the conversation to “You’ll be more successful when you do ________. Here’s why.”

If it's something like claiming to be unaware that he's pinching another person's arm (or other body parts...believe me, I’ve seen all sorts of astonishing behavior in the workplace), it's time for that person to go. In such a case, or if it's a legal or ethical violation, have your ducks lined up with HR or the company lawyer before you go into the conversation.

There's another sort of case, where other people are reporting behavior that the person denies. It could be a conspiracy, but that's not too likely. In this case, your data is second hand, so you have to avoid the tattle tale trap. Rather than report what other people have said, which puts you squarely in the trap, report your data.

Here's an example from my days as a manager.

My group worked on investment accounting software for a big financial services firm. The system included an overnight cycle. When we put new code into production that affected the overnight cycle, the group rotated on-call responsibility, just in case something went wrong. When something did go wrong, the operations people would phone the person on call to fix the problem.

One of the group members, Joni was more than cranky when she was awakened from her sleep. She yelled, she swore, she told the ops people they were stupid.

Obviously, the ops people weren’t about to put up with Joni's abuse. So they skipped Joni's name when she was first the call list and dialed the person who was second on the list. That's when I heard about the problem.

My first step was to support people to speak directly to Joni. Feedback is almost always most effective when it comes directly from the person who is affected by the behavior. Plus, it avoids the emotional escalation of kicking the problem up the hierarchy.

Sad to say, Joni she yelled at the people who spoke to her directly.

I hand not observed her abusive behavior directly, so I wasn't going to get any where with second hand reports. I had seen enough of Joni in action to know she was sometimes impatient and brusque with her peers even when I was in the room, and I'd coached her on that.

So, I talked about the data I did have related to her abusive manner with the ops folks:

I had one person who was upset that his "first call" rotation was essentially doubled, since he got called when he was first and when Joni was first.

I had three ops people who were feeling abused.

I talked about the impact it was having on our relationship with ops, the team and our ability to get work done.

I acknowledged that I hadn't seen the behavior first hand. I asked her for her perspective.

She denied yelling or swearing, and asserted that the ops people were stupid and incompetent.

My response was, "That may be your perception. Whether you think they are competent or not, it's not acceptable to yell and swear at people."

I talked about consequences. I told Joni that I wasn’t going to get into a he said/she said argument, but that it seemed clear that something was amiss since several people were upset by their interactions with her.

And I let her know what would happen if there were more complaints about her swearing and yelling at people.

I’d reviewed the HR policy, so I knew that the next time someone complained, I could ask for a formal HR inquiry.

I didn't hear about Joni abusing people again, probably because she quit a short time after this conversation.

Consequences do sometimes focus the mind.

If you think my approach seems harsh, consider the No Asshole Rule.

Praise Sandwich Tastes Icky, II

Art Petty posted Why I Hate the Praise Sandwich.

Praise sandwich, as you recall, involves buttering someone up with a compliment or praise, stating a criticism, and then fluffing them back up with another bit of praise.

Sounds icky, too, doesn't it?

Art offers:

5 Reasons Why the Sandwich Technique is a Truly Bad Practice:

It is a crutch that is solely for the benefit of the giver, not the receiver.

It obfuscates the real message.

It confuses the receiver by watering down the key message.

It destroys the value of positive feedback by linking it with the negative. Don't forget that positive feedback is a powerful tool for reinforcing the right behaviors and the sandwich technique devalues this tool.

It is insulting to the receiver and borderline deceitful. "Bob, you did a great job on XYZ, but… ." It's like a pat on the back followed by a sucker punch followed by another pat on the back.

I agree. Been sayin' so for years.

I commented on Art's post:

I find that many people (including managers) don't know how to offer feedback in a direct and respectful way. I teach people to use this framework:

Create an opening so you are sure it's a good time for the person to hear you… not when he's getting ready for a big meeting or rushing to pick up his kid.

Describe behavior or results. Use neutral language and examples. If the person doesn't recognize himself in the description or agree with the data, the conversation is over. Labels, comparatives, and absolutes raise defenses.

Describe the impact. If there's no impact, why are you having the conversation?

Make a request. You may have a specific behavior in mind, or you may want to engage in problem solving. It depends on the situation.

Finally, don't sell past the close. If the person gets the point after you describe the behavior, zip it. Otherwise, it feels like you are beating a dead horse.

My experience is that people are likely to accept critical feedback when:

1) the giver or source is believed to be reliable

2) the receiver trusts the intentions of the giver

3) the receiver has a chance provide clarifications

4) the process is fair--both the way the feedback was developed and the way the feedback was communicated

Praise sandwich tends to erode trust in the feedback givers intentions, and once that's gone, there's not much chance any useful information will get through.

Year-over-year improvement is what matters

I just heard that a group of people is working on a CMMi-like framework for Agile Product Management. And of course there's the Agile Maturity Model. And various surveys to assess Agility.

"Maturity" and "agility" are the wrong things to measure.

Level doesn't matter.

Results matter. Year-over-year improvement matters.

I've seen plenty of companies that assessed at some vaunted level, but still produce crappy results and still grind engagement and creativity out of their employees.

"Maturity" and "Agility" are proxy measures have the same risks as all measures: they focus attention on the wrong things and often drive behavior that's counter-productive.

Focus on doing better every day. Practices help you do that. Removing organizational impediments helps you do that. Improving skills does that. Improving the quality of management does that. Improving team capability does that.

Visibly Valuable

In these unsettled times, you can spend time worrying about things you can't control, or you can take action on things that are within your control.

Here are 10 things you can do as a developer to make yourself more visibly valuable, which may keep you off the RIF list.

1. Understand what is most important to work on. List those items in rank order. Work on the most important thing until it is done, or until you are stuck. Move to item two. Repeat.

How will you know what is most important? Ask your manager. Do not accept “everything is important” or “they are all number one priorities” as an answer. Those are not answers, they are signs that your manager is pressured, stressed, and isn’t taking time to think clearly.

Ask your boss some questions that will help him think.

• If you were doing this work, which would you work on first?

• Which has to be done soonest?

• Which one will bring in/save the most money?

• Which one will help you most?

2. Get more done by doing fewer things at once. Finish one task or project before you start the next (in priority order, of course). I currently have 4 handcraft projects in progress. I work on the green sweater for awhile, then I switch to the gold quilt, until I want to work on the blue hat, and then I skitter off to the purple quilt. I’m having a great time, I’m busy, and ain’t none of my projects getting done.

It’s quite clear to most people (including me) that I could get one of these project finished faster if I concentrated my effort on that project rather than switching back and forth. Some how, many managers forget this when they go to work and hope that multitasking will actually work. But it doesn't, so don’t even try to do everything at once. It doesn’t work, and actually slows down progress.

3. Understand your own capacity before you commit. Track where your time goes for a couple of weeks. How much time do you spend checking email, answering questions, going to meetings? Look for ways to reduce interruptions and reduce the biggest unproductive use of your time. (Taking breaks is not an unnecessary use of your time. We all know that we do better if we take a little breather from time to time.)

4. Review all the meeting you attend on a regular basis. Notice which meetings have stated goals (that match what actually happens) and which have a published agenda (that’s actually followed). Decline to attend meetings that don’t have a real purpose and a plausible agenda. They will waste your time.

5. Make commitments based on your known capacity, rather than on an ideal 40 hour week. You will become known as some one who meets her commitments, rather than some one who is always late or overly optimistic in her estimates.

6. Work in inch pebbles. Break down projects into tasks that you can complete in a day or two. When you do this, you can report tangible progress at least twice every week. You will become known as someone who gets work done.

7. Test as you go. Check in code at the very least once a day, and run all your tests for that piece of code each time you check in. That way, you will avoid having a false assessment of progress by deferring knowledge of problems until the (false) end of the task.

8. Peer review all fixes. A defect is a clue that the code is difficult to understand or poorly written. So you will avoid breaking something else by having another set of eyes look at the fix.

9. Write tests for the defect fix, and then write a half-dozen tests (at least) in the code around the defect. Defects tend to cluster, so you will be strengthening your code and your feedback system by writing additional tests.

10. Work at a sustainable pace. Tired people make mistakes and write or miss defects. You don’t want to be known as someone who makes mistakes. For most people, a sustainable pace is somewhere between 40-50 hours a week.

I'll write a list for managers, perhaps next week.

Three Pillars of Executive Support

I hear people talk about getting executive support for Agile adoptions (or other organizational changes). But I seldom hear people talk about what that support looks like. It's more than money and speeches.

Want to know how to really help your organization change? Three Pillars of Executive Support for Agile Adoption on AgileJournal.com.

Meeting Madness

Seth Godin blogs about Three Kinds of Meetings:

There are only three kinds of classic meetings:

Information. This is a meeting where attendees are informed about what is happening (with or without their blessing). While there may be a facade of conversation, it's primarily designed to inform.

Discussion. This is a meeting where the leader actually wants feedback or direction or connections. You can use this meeting to come up with an action plan, or develop a new idea, for example.

Permission. This is a meeting where the other side is supposed to say yes but has the power to say no.

PLEASE don't confuse them. Confused meeting types are the number one source of meeting ennui. One source of confusion is that a meeting starts as one sort of meeting and then magically morphs into another kind. The reason this is frightening is that one side or the other might not realize that's actually occurring.

Indeed.

People waste countless hours in meetings with murky goals. Worse, each person may come out of such a meeting with different conclusions, spreading the confusion further in the organization.

Even when a meeting has a clear purpose, if there's no clear way to achieve that purpose, the meeting will not be as effective (or short) as it could be. Another waste of time.

People, people, people.

Improving the quality of meetings is a small intervention that can bring significant improvements to an organization. So don't overlook it even if improving meetings isn't shiny or sexy. Be a master of the obvious. Get the basics right, and you'll have a stronger foundation for the fancy stuff.

More ideas on how to improve meetings:

How to Improve Meetings When You are Not in Charge

The ROTI Method of Gauging Meeting Effectiveness

15 Things Bob Sutton Believes

From Bob Sutton's Work Matters blog:

15 THINGS I (Bob Sutton) BELIEVE

1. Sometimes the best management is no management at all -- first do no harm!

2. Indifference is as important as passion.

3. In organizational life, you can have influence over others or you can have freedom from others, but you can't have both at the same time.

4. Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.

5. Learn how to fight as if you are right and listen as if you are wrong: It helps you develop strong opinions that are weakly held.

6. You get what you expect from people. This is especially true when it comes to selfish behavior; unvarnished self-interest is a learned social norm, not an unwavering feature of human behavior.

7. Getting a little power can turn you into an insensitive self-centered jerk.

8. Avoid pompous jerks whenever possible. They not only can make you feel bad about yourself, chances are that you will eventually start acting like them.

9. The best test of a person's character is how he or she treats those with less power.

10. The best single question for testing an organization’s character is: What happens when people make mistakes?

11. The best people and organizations have the attitude of wisdom: The courage to act on what they know right now and the humility to change course when they find better evidence.

12. The quest for management magic and breakthrough ideas is overrated; being a master of the obvious is underrated.

13. Err on the side of optimism and positive energy in all things.

14. It is good to ask yourself, do I have enough? Do you really need more money, power, prestige, or stuff?

15. Jim Maloney is right: Work is an overrated activity

A fine list. What do you believe?

The Pay Off in Merit Pay (Not)

If you've been reading this blog for a while, you know how I feel about compensation systems that claim to motivate better performance with differential pay.

For example,

A Compensation Story in 2006,

It's What We Know That Ain't So and

Pay for Performance and Why it Doesn't Really Work in 2007

So of course, I was interested when I came across Where's the Merit-Pay Payoff? by Fay Hansen on WorkforceWeek.com. (requires free registration).

A few snippets:

The seemingly self-evident premise underlying merit pay and other individual performance-based pay plans is that they produce higher employee and organizational performance. Most companies, however, do not test the actual impact of performance-based rewards on employee behaviors and financial results. The most comprehensive empirical studies flow from the academic world, where evidence is mounting that the assumptions underlying individual performance-based pay programs are wrong.

"The evidence is overwhelming that individual pay for performance does not improve organizational performance except in very limited cases."
—Jeffrey Pfeffer, professor, Stanford University Graduate School of Business

"Effective management is a system, not a pay plan. The mistake is that companies try to solve all their problems with pay."
—Jeffrey Pfeffer. professor, Stanford University Graduate School of Business

Pfeffer notes the existing evidence points to group bonuses, profit sharing and gain sharing, which is a form of profit sharing, as more effective forms of performance-based pay than merit pay or individual incentives. "Group plans are more collective and recognize the interdependent nature of work today," he says. "Most employees look at their total compensation and want to see that they share in the success of the organization."

This is particularly germane to organizations that are asking people to work collaboratively in teams. Yes, we do pay individuals. There are rational ways to do that without so-called merit raises. I'm glad to see that group bonuses and profit sharing are starting to come up in the conversation.

----------------------------------------------------------------------------------
I will address the top concerns that come up when I write/talk about this topic preemptively.

1. I am not suggesting that everyone be paid the same salary. Skills, experience, domain knowledge and the current market are all considerations in setting salary. The key is to pay people equitably (which is very different from "pay equally").

2. I am not suggesting that everyone's skills and performance are equal. Of course people have different skill levels and perform differently. Most companies recognize this with salary bands.

3. I am not saying that teams should have a team salary. Salaries are paid to individuals... though I suppose an independent team could contract jointly, and then decide how to allocate pay within their group. But that's a different topic.

4. I am not saying people don't need feedback on their performance at work. People need feedback--which is information about performance, not evaluation--on a frequent basis. The more we can design systems where the feedback comes from the work, the better (e.g., build lights, green bar/red bar test frames). Peer feedback and feedback from managers are crucial for improving performance.

5. I am not saying that people who aren't actually working should continue on the payroll. But any manager who needs a pay-for-performance system with ratings and rankings to figure this out is in big trouble.

I think these are some of the things people fear when they think about removing merit pay. There are other rational pay systems... but they aren't as wide spread, so few people know about them. More on those, later, perhaps.

Estimating hard-to-measure benefits

Last week, I wrote a post about decisions that look only at easy-to-count costs and ignore hard-to-count benefits.

Here’s one method for estimating hard-to-count benefits, subjective impact analysis:

1. Identify the proposed course of action.
2. Determine what’s important to the person who makes the decision.
3. Ask that person who they consider credible sources related to the issue.
4. Create a short interview protocol.
5. Interview the people the decision maker identified as credible.
6. Summarize and present the results.

Here’s part of a subjective impact analysis I did for a client a billion years ago (suitably scrubbed).

The client was a VP in an IT operation. The business was livid about the production problems and outages that followed when the IT group installed new functionality.

When I looked at the data about outages, it was pretty clear that the worst problems came from the hand-off between the development folks and operations folks. I poked around, and found that the two groups weren’t working together.

So I suggested a little experiment: a “readiness review” prior to installing a change where the development people and the operations people would sit down together and walk through the installation. And I created a half-page checklist for the development people to actually write down critical information for the ops folks.

Then we tried the experiment. We held a "readiness review" for a smallish update to the production systems. The meeting took about 45 minutes.

After the “readiness review,” the IT managers told the VP they were concerned about adding another meeting that took away from development time. The developers complained about the burdensome documentation (half a page).

The costs were obvious.

The benefits were not so obvious.

So I did a subjective impact analysis to show the benefits (if there were any).

Here’s what the VP valued:
• Avoiding production problems
• Improving the application
• Taking a proactive stance

I asked a cross-section of the people who participated in the review these questions:

1. What gaps and issues came up in the review that could have caused problems had they been discovered in production?

• What was the biggest problem discovered in the review?
• On a scale of 1 – 10 (1 = negligible impact, 10 = disaster), how big would that problem have been?

2. What was the team able to do to improve the application because of the review?

3. What problems did the team fix before they hit in production?


Then I summarize the data and presented it to the sponsor. Here’s the data from the first question.

Problems Discovered in the Readiness Review
(1 = negligible impact, 10 = disaster)

10 ****
9 *
8 ***
7 **
6 *
5 *
4 **
3
2 **
1

(This represents each person's assessment of only the biggest problem, so it’s a subset of the problems. For the most part, the development folks identified lower impact problems, the ops folks higher impact problems. Very interesting...)

This little data table helped people see the benefits of the readiness review, as well as the costs.

(Obviously, there were lots of other issues with this organization. This was a starting point to bring the level of conflict down enough for people to look at underlying problems.)

I did this subjective impact analysis after the fact, but you could easily adapt it to estimate benefits before making a decision.

Practicing Leadership

From an interview on Workforce.com.

Ram Charan defies traditional notions about leadership. It’s no longer enough for leaders to be charismatic and courageous to be successful, he says. Instead, they need to hone their skills to address the needs of their organizations...

Workforce Management: What is new about your perspective on leadership?

Ram Charan: In the past, most people have talked about personality when they talk about leadership. They think that leaders are born. My view is that once you are 22 or 23 years old, you have a basis of who you are, but you don’t have the skills yet to be a leader. Many leaders today are great communicators and are charismatic, but that’s not enough. If they can’t perform, they are out. To learn how to perform as a leader, they need to practice through real-life experiences.

WM: How does one "practice" leadership skills?

Charan: You practice the ability to handle diverse experiences. You move from one business to the other and develop your skills as you move along. You learn how to work in a team and how to create change.

Leadership isn't about personality or charisma. It's about understanding and skills. That means leadership can be learned, and that leadership looks different in different circumstances.