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?

The Power of Questions

Success or failure hangs on the questions managers and technical people ask when planning releases, making decisions, considering strategy alternatives or looking for improvements.

Yet we don't often stop to consider the questions we ask. Every question contains assumptions and while the question opens one avenue of inquiry, it closes others.

The question you ask determines the answers you will receive. The assumptions that are implicit in the question constrain the inquiry. So let's look at some of the questions I've heard managers ask when things aren't going as they'd like and make the assumptions explicit.

In one large corporation, the executives weren't satisfied with the service or speed with which the IT department delivered projects. The sacked the VP of the IT department and brought in a new one with a reputation for a no-nonsense approach to management.

Here are some of the questions she asked:

Where is the dead wood?

How can we get them to work harder?

Who are A/B/C players?

How can we trim the fat?

How can we make them (the developers and testers) go faster?

How can we cut costs?

I suspect this is a fairly typical set of questions for someone brought into turn around a struggling organization.

And there's an interesting set of assumptions.

Where is the dead wood?

Presumably, all the employees in this department are still alive, and had been live wood when they were hired. The assumption is that there are people in the organization who are not doing anything the contributes to the vitality and productivity of the department.

The unspoken part of the sentence relates to what gardeners do with dead wood--they don't revive it but coaxing in nutrients and restoring productivity, they cut it out. The implication is that, once the deadwood people were found, they'd be fired. Because obviously, becoming deadwood is the fault of the individual. The question doesn't allow for the fact that sometimes--perhaps most of the time--when employees disengage from the work it's a result of the nature of the work and their attachment to the company, which is nurtured through relationships with managers.


How can we get them (developers and testers) to work harder?

The obvious assumption here is that people are not working hard now. The secondary assumption is that inducing other people to work harder is the way to improve results.

Who are our A/B/C players?

This is a ranking question, and assumes that people can be sorted into buckets based on some criteria. The next step of this question is the assumption that eliminating C players will improve results. The meta assumption is that individual effort is the main source of department results and that work isn't interdependent or accomplished through social networks.

How can we make them (developers and testers) go faster?

Like the question about working harder, this assume that developers and testers are not going as fast as they can now. It assumes that speed is a matter of will, and the terrain has no impact on speed. It also assumes that the role of management is to whip other people to go faster.

How can we cut costs?

The assumption is that spending less will improve the economic equation.

The VPs questions led to predictable actions.

Managers applied more pressure to the technical staff. People cut corners to go faster (now, and slower later).

People who were confident in finding new jobs left. The people who were afraid they didn't have the skills to face the job market hung tight. There were rumors of layoffs. Fear lead to people to choose CYA over do the right work the right way. Competition undercut cooperation and collaboration.

The VP to an ax to department budgets. The balance sheet looked better (in the short term), but costs went up.

If the VP had questioned her assumptions, she might have asked different questions. And with different questions, she would have seen different possibilities for action.

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.

Perfomance without Appraisal Part III

In my previous two posts on Performance without Appraisal, I addressed two of the basic assumptions behind rating, ranking, evaluations, and so-called performance management systems.

Here's the third assumption: Improving individual skills is the best way to improve organizational performance.

Fact:

As we've seen in the first two installments, rating, ranking, and evaluations can damage teamwork, erode trust, and lead to disengagement.

None of those are good for individual or organizational performance.

But it's worse that that.

Kurt Lewin put it this way:

P= f(p,e)

Performance is a function of the person and the environment.

Of course, we need people with the skills and desire to do the jobs they are hired for. Of course, managers need to invest in developing people.

Now, we really really attached to the idea of individual achievement in the US. We love heroic efforts. We tend to attribute too much of both success and failure to individuals (the Fundamental Attribution Error).

Performance appraisals, ratings, and rankings focus solely on the individual. They ignore the environment. When you ignore the environment, you miss the system contribution to performance.

Sadly, the system contribution often does not support productivity and results.

Let me tell you a story from a real company.

Like many companies, they had some problems. They didn't have a clear vision for their main product. Management continued to spin out new product ideas and forced multitasking. Their release process took three months. They substituted tools for real communication. Managers re-formed working teams every few months...but let teams that were floundering continue to flop around. I could go on.

Senior management decided that they needed to do something in order to achieve better business results. So they took decisive management action. They stack ranked everyone (except managers) in the technical organization, and then culled the bottom 10%.

I doubt they noticed that organizational performance did not improve. If they did, I suspect they concluded that they needed to cut another 10% before things would get better. Had the managers addressed even one of the problems with the work system, they could have realized improved productivity and results.

Pfeffer and Sutton (Hard Facts) reference many studies done across several industries--including software--that indicate that even the most talented individual cannot perform competently within a bad system. They call it "The Law of Crappy Systems." If you hire talented people and they fail to produce results it's a sign you have a crappy system.

So managers, we need to start seeing the system and improving the system, so that everyone can do a better job, and the organization sees better results.

You know the final irony? I've talked to several HR professionals who tell me that they have to put appraisal processes in place to force manager to give feedback at least once a year. That is so wrong on so many levels (as I have said many times before).

We can do better.

And in my next post, I'll start telling you how.

Performance without Appraisal Part I

At the start of my talk, Performance without Appraisals at Agile2009, I asked the people there how many worked for companies that had some form of annual performance appraisal with ratings or rankings. All but a couple of people raised their hands.

So I asked what the goals of the appraisal systems were. I got the typical answers: improve individual performance, improve organizational results, determine pay.

Then I asked how many were satisfied with the results achieved by performance appraisals relative to those goals. Three or four hands went up. That's typical, too.

Most companies do some form of annual or semi-annual appraisal with ranking or ratings. If everyone is doing it, it must be a good idea, right? Not so much (see the phenomena of Social Proof). Far from improving results, performance appraisals do enormous harm.

I'll acknowledge from the start that we in the US are brought up to believe in success through individual effort. Chances are pretty good that some people will find my ideas challenging...though the evidence to support the efficacy of performance evaluations to improve individual or organizational results is slim to none.

(Every time I say this, some one--usually from a company that provides appraisal systems--writes to inform me that performance appraisals and performance management systems work when they are done correctly. Of course, they have to say that. There may be work where performance appraisal makes sense. Knowledge work ain't it.)

Here's the first assumption behind performance appraisals:

It is possible (and useful) to discern individual contribution to interdependent work.

Fact:

For most kinds of work there are many, many factors involved in a successful outcome. Measuring one thing (or a handful of things) usually means that other important stuff gets ignored. (See Robert Austin, MMPO).

Stuff that's easy to count usually doesn't count--like lines of code, bugs found, seconds spent on a call, etc.

Observed behavior is unreliable in determining contribution. The guy who talks a lot may be adding value to the conversation...or not. The person who sits quietly, apparently staring into space, may be coming up with an important idea. The person who isn't strong technically may contribute to the team in essential ways that aren't easily understood by someone outside the team.

You can't tell who is "working hard" by looking. Last winter I ran a workshop where one of the activities involved designing and delegating a problem for another team to solve.

Team A gave an assignment to Team B, which Team B solved beautifully. A member of Team A complained that Team B were slackers--they hadn't worked hard, there was no evidence that they struggled to reach a good result.

Bosh. The truth is that a well-functioning team makes solving difficult problems look easy.

When managers do attempt to assess and rank contribution, they are often wrong, and with devastating effect. (Plus, they look foolish.)

The fundamental question is this: are managers more interested in having a team that produces valuable results or in knowing who to praise and who to blame?

None of this implies that managers shouldn't care about individual skills, and that some people don't have the necessary skills or desire to do some jobs. But that's the not the case for the majority. Performance appraisal is a poor tool to deal with exception cases.

More to come.

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.

What to do with a struggling employee

Esther Schindler recently put forward a scenario about a struggling employee named Frank, and solicited advice from her network.

Briefly, the scenario is this: Frank was a great maintenance programmer, but the company is retiring the system he worked on. Frank has moved to a new project in a new language and he's not catching on. (Full scenario is here.)

The Other Esther summarized the advice she received in When the Job Changes But the Programmer Doesn't and When the Job Changes But the Programmer Doesn't Part II: Saving Frank's Job.

My full response (excerpted in Esther Schindler's posts):

It sounds like Frank has been a valuable employee. But now he's in a position where his skills and preferences aren't a good match for what the position requires.

So first, I'd think about whether there is a way to make use of his maintenance programmer skills on the new system. Can he fix bugs? Can he contribute domain knowledge in some other way?

It's not unusual for people who are learning a new skill to follow rules rigidly. They haven't internalized the new knowledge to the extent that they can see possibilities and use the skill intuitively.

The scenario doesn't say how Frank has gone about learning the new language. Pair programming can be a great way to learn, and pairing a beginner with an expert can be enlightening for both.

I'd also look at how the work is chunked up. It may be that if Frank broke the work down into more discrete 1-2 day chunks he'd be able to make better progress.

If there's no way to use Frank's skills, then Frank's manager needs to have another forthright conversation with him, explaining his expectation and concerns, and hearing Frank's point of view, as well. Chances are pretty good that Frank is as distressed as his manager is.

But before the meeting, Frank's manager needs to decide if he's willing to give Frank another chance, or give him time to find another job within the company. If not, get the ducks lined up with HR to end Frank's employment.

If Frank wants to try once more to get up to speed, they need to agree on a plan with specific actions. They need to agree how they'll evaluate whether Frank is making the kind of progress the job requires. And the manager has to put a time limit on it--weeks not months.

If Frank recognizes that he's just not in the right job, and he's an employee that can still make a valuable contribution somewhere in the company, set a time frame for Frank to find a job internally--weeks not months. Start looking for Frank's replacement. If Frank hasn't found an internal job by then, end his employment.

If Frank isn't a good candidate to stay at the company, don't let the situation drag on forever. The current state is painful for everyone. And while firing Frank will probably be painful, it won't be as difficult as the alternative.

A couple of things to emphasize:

Allow weeks not months to turn the situation around. That means 2-6 weeks, no more.

Choose based on how big a hit you can take on the project. Look at the trade offs. Some times no body is better than a warm body. If working with Frank is taking significant productive time away from others for little potential return, 0 weeks is the right answer. As Jerry Weinberg asked, "Is this a business or a charity?"

If Frank can be valuable to the company, but not on your project, set a time frame for *Frank* to find a new job. You are not a job placement service, and not your job to find him a new assignment. It's Frank's job to find that next assignment. You can offer to introduce him to people or give a reference, but Frank needs to do the work. And set a time limit 2-6 weeks, no more, depending on your project needs. Do not wait until Frank has found a a new assignment to start looking for his replacement.

Three Myths about Teams

Myth #1: All a team needs to get them working well together is a clear goal and sufficient pressure to perform. I’ve never seen a team without a clear and compelling goal gel; but I’ve seen plenty of teams who did have a clear goal flail and fail. Until a group of people decides to work as a team and decides to agree, they won’t function well as a team.

Myth #2: A manager can discern individual contributions to team results. While a manager can tell certain things about the way a team is functioning, in most cases, it’s impossible to tease out individual contribution. And when managers try to assess who has made the biggest contributions, they are often wrong. Taking action on an incorrect assessment can have devastating effects on the team, and makes the manager look foolish.

Myth #3: If the team isn’t struggling or working long hours they aren’t working hard. Teams that are working well together make the work look easy. They work at a purposeful, yet relaxed pace. They even look like they are having fun.

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.

system blindness

One of the big problems I see in organizations is that managers who want to improve productivity pull the wrong levers.

For example, one company I know of decided to improve performance by ranking everyone in the company from 1...n, and firing the bottom 10%. Not surprisingly (to me at least), performance didn't get better. But the managers were surprised (when they noticed at all).

Individual performance is important, but it's often not the primary lever to improve organizational performance--it's the work system that needs improvement.

In the company that tried ranking to improve performance, there was no clear product direction, priorities shifted weekly, and teams where broken and reformed every few months. Improving any of those factors would have had a much bigger over all improvement effect than forced ranking and culling.

We like to believe that people succeed or fail by their own efforts. I don't discount individual effort....but focusing only on individual effort blinds us to system effects.

Applying "the simplest thing that could possibly work" principle

What problem are organizations trying to solve with incentive pay?

Is an incentive plan the simplest, most effective way to address the problem?

Most managers believe that incentive pay plans encourage the desired behavior, drive performance improvement, and reward (individual) achievement. That may be the case, with certain kinds of work.

But before looking to incentive pay to improve performance, look at the work system.

What are the organizational impediments that might be preventing desired performance?

What else might be preventing people from achieving the desired results?

Do people have a clear understanding of how their work contributes to the bottom line and the companies mission?

Do people have a clear expectation of what's expected of them day-to-day?

Do people have the tools to perform?

Do they have the skills?

Are they receiving feedback from the system and from their peers and managers?

Will individual incentives actually encourage the behavior the organization says it wants?

Will the side effects of incentive pay help or hinder the organization?

These questions need to precede the decision to use incentive pay to drive behavior and results.

As Ann Bares, writing for Workforce.com says,

Much as our management "customers" might like to believe the contrary, incentives are not a sound substitute for an effective organizational structure, good management practices or clear and regular communication.

So work on improving the system and managing well before looking to incentive pay to improve performance and results. That's the simplest thing to do. Plus, for interdependent work, incentive pay is likely the wrong level to pull.

Read Ann Bares' full article here (requires free registration).

Self-organizing Teams Interview

Bas de Baar and I had a little video chat about self-organizing teams a couple of weeks ago. Video is here. (Thanks to Andres and George for pointing out the empty link.)

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.

intake->meaning->feeling->response

Mike Cottmeyer writes about Feelings, Thoughts, and Actions.

When people have a strong response, Mike describes thoughts as the point of leverage to change behavior.

How we think can be influenced more directly... it is somehow less personal. We can learn about our environment and the people that are a part of our lives. We can gather more information about what motivates those around us and learn something about their intentions and circumstances. With new information, we can learn to think differently about what is happening to us.....By guiding thinking, we are able to broaden the perspective of our team and create the opportunity to coach behavior.

This lines up nicely with a model I use, Ingredients of an Interaction, from the work of Virginia Satir.

Intake: We take in data from the environment (filtered by our preferences, education, stress level...)

Meaning: We make an interpretation of the data (influenced by past experiences, education, stress level...)

Significance: We have a feeling, based not on the observed data, but on our interpretation of the data.

Response: We act out of our interpretation and feelings.

(Don Gray describes the Satir interaction model in more detail here.

When Mike coaches about thoughts, he's working on the level of Meaning, expanding the possible interpretations. When he talks about bringing in more information, he's working on the level of Intake.

I find this is a powerful model for untangling communication that's gone awry, and for understanding and shifting my own reactions.


***

On a related note, Mike talks about telling people their behavior is "unacceptable."

Rather than start out by telling some one his behavior is unacceptable, I find it usually works better to get agreement that the behavior happened. That usually requires neutral language...rather than "you were pounding the table in our meeting today" I might say "In our meeting, I saw you raise your fist and bring it down on the table." It's too easy for people to get into a Yes-you-did/No-I-didn't argument when there's any hint of judgment in the description. If people don't agree with the data, they aren't likely to listen to anything else you say.

Once I've got agreement on the data, I talk about the impact of the behavior. "I was startled. I noticed that Jen and Josh both pulled back from the table, and didn't say anything else for the rest of the meeting." Depending on how the other person response, I might go further. "When you hit the table, its hard for me to continue participating in the meeting. What I see is that when you bring your fist down on the table, it gets in the way of people listening to your ideas" (or something like that).

I'd rather let the person conclude that the behavior is ineffective and counter-productive and make a different choice. I find that works better with adults than having me say "That behavior is unacceptable"....especially since it may have been accepted in the person's family, or some previous context (where they learned it, and where it might have worked--on some level).

There are times when I do say "that behavior is unacceptable here," but I usually don't need to do that with reasonably well-adjusted adults.

Specialists AND Generalists

Johanna's post, projects don't need specialists (and the 19 the comments that went with it), got me thinking.

People tend to coalesce around shared interests--both in terms of what they find interesting, and what concerns them. Take the category of retired people. It's not a particularly strong category, they may have overlapping pursuits, but have a stronger set of shared concerns, such as access to health care, social security, etc.

Professional concentrations are no different.

People who specialize in data modeling are concerned about having a rational and coherent abstraction of the data in the domain.

People who specialize in process control focus on real-time issues.

People who specialize in data bases are concerned about tuning and performance.

I could go on with lots of other professional categories.

All of these are legitimate concerns.

Here's where it gets sticky. When you have a project with a lot of specialists, each has a particular (legitimate) point of view and (legitimate) set of concerns. If they haven't had experience working in other technical areas they may not consider other concerns.

Labels, titles, and functional silos reinforce categories and create an echo chamber for concerns.

So if you have a project with many specialists, you end up with lots of politics as people seek ascendancy for their particular concerns. If the specialists are acting as vendors to a project team, those specialists may not be invested in the delivery goal of the project, only in delivering their part answering their concerns.

That doesn't mean that people are bad and wrong, just acting the way people act when the coalesce around categories.



It's not that projects don't need specialized knowledge; they certainly do. But they need people who can perform specialized technical tasks and understand that there are multiple sets of technical interests involved, all of which must be, at some point, softened to the project delivery goal.

Handling the need for specialized skills isn't only a matter of scheduling constraints. It's a matter of conflicting concerns and politics.

I am in favor of specializing generalists, or generalizing specialists--people who can perform specialized tasks (as well as make a contribution outside their speciality--and see other technical concerns and focus on a project delivery goal rather than one set of concerns.

Reducing categories (having "developers" rather than many named specialists) reduces differences and helps people focus on shared goals.

A Poor Performer?

Mark Levison has an interesting post in response to a Scrum Development discussion about "bad apples" on a team.

Before applying the label, look for reasons the person might not be performing. There are lots of reasons for a temporary dip in performance. Or, it might be a problem with the tools available, or the environment. It's very common to attribute problems with the system to the individuals (and vice versa).

Our own prejudices can get in the way. My friend Jerry tells a story about when he was a grader for a college course. His job was to read essays and grade them based on criteria. When he turned the grades over to the professor, the professor challenged one of the grades, an A. "You can't give this person and A," he said, "he's a C student."

Mark offers a quote from Linda Rising:

"In many cases, a supervisor “determines” the ability of a worker in about three weeks, labelling them as either “can do” or “can’t do” workers. Once a prejudice has been formed, the supervisor views all the actions of that worker through this filter. If two workers make the same mistake, in the case of the “Can’t do” worker, the supervisor will think, “There he/she goes again, making the same mistakes,” while in the case of the “Can do” worker the supervisor will think, “Maybe he/she wasn’t feeling well.” Eventually, the supervisor can only recognize actions that affirm their prejudice."

Mark advises:

So before we rush off to action on poor performers:

Stop, let go of preconceptions
Re-examine the person's role on the team
Listen/Watch - don't measure
Only if there is a problem - then solve it.

I agree.

Also see:

George Dinwiddie's Working Hard or Hardly Working, and my response.

and...
When is it time to move someone off the team?

Non-valued added, but necessary

Hank Roark, Gerry Kirk and I have been having a chat about "non-value added but necessary" tasks over on Twitter.

It started with an assertion that any thing that doesn't add value to the customer or delays delivery of customer value is waste.

That sets up a binary decision: tasks are either provide value to the customer, or they are waste. I've noticed that when people first start mapping the value stream for software development, they tend to assert that management is all non-value added work.

In addition to value-added and non-value added work, I think there's another category, "non-value added, but necessary."

Non-value added, but necessary are tasks that don't directly add value to the customer, but enable delivering value to the customer. Sometimes these are the tasks and functions that enable the business to stay in business--like accounting, or payroll, or management.

That's not to say that there isn't waste within those functions, there certainly is.

But no one likes to hear that they are adding no value. When people hear that, they tend to feel defensive, and people who are feeling defensive are less like to be able to take an clear-eyed look at how they can best improve the system.

Having a category of "non-value added by necessary" gives a way for people to examine the work that isn't directly on the software development value stream without focusing so much on justify their existence. Then the are more likely to see where they are doing tasks that don't enable creation of value and shift their focus to work that does.

We need to look at "value" from the customer perspective, certainly. We also need to look at value from the viability of the overall organization, and at work that isn't directly related to the product but creates the conditions for creating value.

A Conversation with Glen Alleman

'twas the night before Christmas, and all through the house, not a creature was stirring, not even a mouse...

But Glen Alleman and I were chatting via his blog about the difference between self-organizing and self-directed teams, and how failing to recognize the difference gets people in trouble from time to time.

A (slightly) edited form of the conversation:

Esther: I'd agree that self-organizing teams are not the same as self-directed teams. I specifically reference self-organizing teams, not self-directed teams. Self-organizing teams exist within an organization context and serve the needs of that organization.

I agree there is still a strong role for management in organizations that have self-organizing teams.

Glen: My experience has been whenever the term "self organizing team" is used it is taken to be "self directed." In the absence of a specific statement about the differences in the first sentence of any article the listener jumps to the end with "we're going to run our team in the absence of management." The next step is usually the cancellation of the project ;>)

Esther: As often as I see teams reject guidance from management "because we are self-organizing," I see *managers* abdicate any responsibility to the team or for the team. Neither stance is very productive.

But it does take both managers and team members time to figure out new roles and how to work in a new relationship. That's part of the reason I wrote the article.

Glen: It does take both side of the "team" to understand their individual and combined roles.

I've moved back into defense system for many reasons, but one is the continuous questioning of "how can this benefit the program as a whole - the entire business operation?" Management in this environment are the leaders of the subject matter experts, rather than the "supervisors" of the labor. We are working managers, rather than observers.

The article provides a wonderful starting point for the conversation about how each role contributes to the successful completion of the project.

###

My entire article (referenced earlier in this blog) seems not to be online right now :-(

Remember This for New Years Resolutions: Good Work Habits

From a CNN article:

We've all heard the conventional wisdom about good work habits. Many of us have attended time management classes, participated in workshops and have been advised to "work smarter, not harder."


Work habits that might seem less productive will make you more effective, say experts.

Some ideas, however, appear at first glance to be unusual or even counterintuitive.

Goof off at work, read a book, ignore e-mail. (Read the article.)

Working Hard or Hardly Working

George Dinwiddie is considering a discussion about velocity as a performance measure and how to tell whether people are working hard that started on the scrumdevelopment yahoo list.

Here's the original question, posted by Graeme Matthew.

The unknown in all of this is that if a team have a velocity of 6 how do you tell if they should have a velocity of 8 i.e. they are underperforming. It gets complex. If they have a velocity of 16 are they doing well or have they estimated at the higher scale of story points.

0. Using velocity as a performance measure is wrong, wrong, wrong. Velocity just is, and you work to improve it over time by improving engineering practices, the work process, working relationships, and skills.

The assumption behind the questions is that people might be slacking off, not working as hard as they can.

I don’t want people to work as hard as they can. I want them to work hard, but at a pace where they aren’t making themselves more error prone, and aren’t exhausting themselves.

[aside]
If the team seems to lack a sense of urgency, it might be because they are missing information about why the project is urgent. The fact that a senior manager made a bet on the golf course doesn't make the project urgent. That some sales person promised the moon and stars without any knowledge of the development effort is not urgent--for the development team. Making a once-a-year sales window...that's urgent.)
[/aside]

Some managers seem to want to know who is working hard, and how isn't.

My experience is that some people have to work harder to accomplish the same results that another person can accomplish easily. Some people look like the are working mighty hard, but are not accomplishing much.

Thinking that we have to have everyone working equally hard doesn’t make sense to me…Why would you want to punish the person who gets his work done quickly by piling more on?

Further, there’s almost always someone how isn’t the best programmer, but things just go better when he/she is on the team. They may not look like they are working hard, but take them off the team, and everyone's performance goes down.

Perhaps some different questions:

Are the conditions present for every member of the team to do his or her best?

Have the managers put together people with the mix of skills and expertise needed to do the work the company needs done?

Are individuals performing to the expectations of their pay level?

If there’s a perception that people are not working hard, what might the reasons for that be? (Systems, policies, procedures that dis-incent performance; work they don’t care for; disenchantment with direct managers?)

As a manager, I'm more interested in who is struggling and/or who doesn't have the skills or interest in doing the job they've been hired to do. In a manager-led team, that pretty easy to notice if you meeting with people on a regular basis.

On a self-organizing team, it's harder, but not impossible. First, there has to be enough trust to support transparency. When there's visibility into the work, then a manager can see where things are binding up, and investigate the source of the problem. The source might be a person, but might also be the process or some other factor.

What's a Manager to Do?

When the team self-organizes, the manager needs to step back, but not too far back; she needs to step in, but not to quickly.

My article on the manager's role in self-organizing teams is on the cover of Better Software Magazine and available on-line here. (link updated 2/4/09).

Magic Chemistry of Teams

George Dinwiddie has posted his notes from one of my AYE 2008 sessions, Magic Chemistry of Teams.

During the session, I asked people to draw a time line that represented their experiences working on teams, then, working in small groups, identify the factors that were present on high-point teams and low point teams.

Here's a partial list of factors present on low-point teams (posted on George's site):

no vision
bad results around us
bad fit of skills & interests
alone
angry boss/poisonous environment
no common location
lack of appropriate tools & equipment
specialization
One Jerk/personal conflict
lack of respect amongst team members
absent leader
lack of face-to-face contact
lack of clear priorities
judgemental leader
loss of team members
blame/shame
team too big

Notice how many items on this list relate to how the team is established: vision, location, skills fit, priorities, tools and equipment, team size. These are all within management's responsibility.

If there is a clear vision, clear priorities, necessary physical environment, the right number of people with the right skills, then it's more likely that the items on the "high point" list will emerge:

common goals
clear goal/vision
clear role/expectations
new/novel/learning
presence of great skill
self-organizing
ritual
team members value each other
good humor
ate together
camaraderie
appreciation
recognition
trust
passion
friendship
flow

Too often, managers throw a group of people together and declare it a team. Calling a group a team doesn't make it so. It takes work to establish an environment where team work will emerge.

(It takes collaboration skills on the part of team members, too, as in Secrets of Agile Teamwork, coming up in February.)

Feedback Doesn't Just Roll Down Hill

Many organizations have a model that feedback rolls down hill. The VPs give feedback to the Directors that report to them. Directors give feedback to the Managers. Managers give feedback to developers. It all cascades downward.

A manager's job is to create an environment where the people who report to him/her can succeed. While it's useful to hear how the people above you in the hierarchy view your work, it's not sufficient. It's also important for managers to understand how well they are doing in supporting others to do their work.

Unfortunately, it's not that easy for managers to obtain open feedback. People aren't accustomed to giving feedback. They may fear they'll be punished if they don't stroke the bosses ego.

360 Feedback Processes are an attempt to get feedback from different points of view. In my experience, these programs don't provide much actionable information. Its too easy to lob softballs or zingers, with no way for people to follow up.

I find that it's more useful to find out what's important to people and start a conversation. I've outlined a process to do that here.

Conditions for Change

I attended an Organizational Change BoF last evening at the AYE conference. Among other things, we talked about why it is that some managers fail to act when there are many signs of big problems.


I see three conditions that are prequisites for change (at any level):

People have to recognize the situation. One person at the group told a compnay that was losing billions, but kept cancelling projects that produced revenue, and funded projects that failed. The problem was obvious to anyone who *could* see. But the senior managers had a mental model of operating as a monopoly, and updated neither their mental models nor their corporate accounting systems. So they didn't see it.

People have to believe it is possible to change the situation in some way. If people don't believe it's possible to change, they are paralyzed. THere are some things can't be changed, that are out of the sphere of influence or control. People often forget that even when they can't change external circumstances, they can change their response.

People need to have some idea of how to shift the situation. WHen people have no earthly idea how to shift the situation, they become paralyzed. So paralyzed that they don't seek help in the form of new ideas or expertise. Or they grasp at the first silver bullet that's offered (which often makes the situation worse). Or they do nothing.

So how do you create the conditions for change in your organization? Stay tuned. I'll be blogging about that in the next weeks.

Yo-yo managers break trust

Most of the time I hear people talking about trust, they are talking about trust between team members. It's equally important to have trust between managers and team members. In fact, the relationship between an employee and his/her manager consistently shows up as a key factor in retention.

One of the ways that managers in the middle of agile transitions break trust is by giving a decision to the team and then taking it away, as in Tale of a Yo-Yo Manager.

I lost interest...

...in blogging for a while and took a break.


Anders Vesterberg read Behind Closed Doors and has some nice things to say on his blog.

Simple principles

Rothman’s and Derby’s main tenet is that the principles of good management are not that difficult to understand. They discuss for example one-on-ones, portfolio management, feedback, coaching and delegation. The thing is to consistently and reliably perform these practises week after week.

Not that difficult, but not always easy. Systems drive behavior, and it's not always easy to recognize and counter act the affects when you're in the thick of it.


I'll meet Anders in person in January at PSL in Sweden. His review was an awfully nice electronic introduction :-).

Promises, Promises.

Last week I wrote about a middle manager who didn't consider renegotiating a low value project because he'd given his word to his boss.

The response to the post was consistent:

Ken Flowers said,

I have to assume that if the project doesn't make sense to the middle manager, it also wouldn't make sense to the VP. If I were the VP and found out that my manager was doing a project that he knew was ineffective, I would be really angry. I would expect him to talk to me about it first. I pay him for his judgment.

Dwayne Phillips posted:

Beware of promising things that are out of your personal control.

"I promise to look at this and get back to you"

"I promise to do what I CAN"

"I promise to investigate what this project means to you, me, my group, and our company."

On Ken's site, James Todhunter left this comment:

Concealing material information demonstrates a fundamental lack of integrity. I wouldn't want such a person on my team. I could never trust their input or judgement.

It's clear that a middle manager who continues down the wrong path because he "gave his word" is undermining how other people view his integrity.

What happens if we replace "middle manager" with "senior manager" and "boss" with "client" ?

I talked to an executive recently who promised a big client that his company would deliver a special project for them.

Unfortunately, he made a promise on the basis of incomplete information. Once he talked to his development group and ran the numbers, it turned out the work he promised will have a negative return on investment. And it's a double whammy: doing the low value work will delay doing higher value work, and cause the group to miss other targets.

But the executive refuses to consider going back to his client to explain the situation and renegotiate. He gave his word, and he feels his integrity is at stake.

How does the change in position and authority effect your response about the integrity question?

Interview with Jerry Weinberg

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you're the J.K Rowling of software development, who's Harry P then?A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear with Harry is telling him.

Focus on the individual or the system?

I've been watching a discussion on the Agile Project Management yahoo group, which poses the question, "Does everyone in agile need to be above average?"

The question behind the question is, "Does agile need extremely competent people in order for it to work?"

When I read stuff like this, I wonder "What method of building software works without competent people?" It's a puzzle.

Which brings me to this snipped from Bob Sutton (via Jason Yip):

Great systems are more important than great people. The notion that you are doomed to mediocrity if you can’t hire the very best people has little empirical support. Yes, there are big differences between the most talented people and the next level down in most occupations. But systems are more important. Toyota beats the competition as a result of a superior system; Men’s Wearhouse and McDonald’s don’t hire people that are much different from their competitors, but their systems explain their long-term dominance more than their people. As Jeff Pfeffer says, many organizations seem to have “brain vacuums” to turn people who seem to be smart into bumbling fools. Even the most brilliant person is doomed to fail in a bad system, and seemingly mediocre people can become stars in a great system.

Agile methods are a system that can help people perform better.

One agile coach I know tells a story about the first agile pilot in her organization. Someone in senior management didn't want the pilot to succeed. So he sent her all the "poor performers" for the pilot team. But they ended up outshining expectations and did a fine job of delivering valuable working software.

Further, focus on individual talent (and focus on individual performance management) takes focus off improving the system.

(I'll say this now, because someone always asks at this point "So you're saying we should hire incompetent dodos?" No, I'm not saying, "hire dodos." Hire competent individuals who are a good fit for the organization's culture. Focus on improving the system to improve results. Focus on individual performance for career development. Give feedback to help individuals become more effective.)

Pay for Performance (and why it doesn't really work)

Every so often, I share my views on pay-for-performance and annual performance appraisals on this blog. My experience is that pay-for-performance and annual performance appraisals--contrary to popular belief--actually hurt performance and results, rather than driving higher performance.

So I was interested to learn, via Bob Sutton's blog, that Jeffrey Pfeffer (co-author of Hard Facts, Dangerous Half-Truths And Total Nonsense: Profiting From Evidence-Based Management and author of several other books on management)was called to testify before Congress on the matter of pay-for-performance.

Pfeffer's testimony walks through the assumptions underlying pay-for-performance,

Money is an important motivator.

Motivation is the issue for enhancing performance.

Individual performance can be reliably and unambiguously assessed.

Individual, rather than collective, rewards are important because of the need to overcome free-riding problems.

Differentiation in individual rewards, a necessary and frequently explicit consequence of individual pay-for-performance systems, leads to higher unit performance.

....and lays out the evidence related to those assumptions. (They don't hold true when you actually look at the evidence.)

He also points out that when the explicit and implicit message is that people (and their contributions) aren't valued, tweaking the compensation system won't overcome the depressive effects on performance.

If the senior managers at a company really want to improve performance, tinkering with the pay system isn't the way to go about it. Addressing the underlying culture and quality of management is.

Although the list of high commitment or high performance work practices differs slightly among authors and studies, most such lists include: a) sustained investment in training and development, including job rotation, both formal and on-the-job training, and a tendency to promote from within as a consequence of the successful internal development of skill and people; b) an egalitarian culture in which formal status distinctions are downplayed, salary differences across levels are less than in the general economy, and in which people feel as if their contributions are important and valued; c) delegation of decision making responsibility so that skilled and developed people can actually use their gifts and skills to make real decisions; d) high pay to reduce turnover and attract the best people, coupled with rewards that share organizational success with its members; and e) employment security and a policy of mutual commitment, so that the workforce does not fear for the outcomes of events over which it has no control and instead, feels reciprocally committed to the employer.

He ends his testimony with this statement:

We should implement what we know, rather than what we hope, or wish, might be true.

Read the full testimony here.

Great Managers are Made, Not Born

I came across a spate of articles lately proposing different reasons why some managers fail. The reasons ranged from rising to their level of incompetence, becoming corrupted by power, promotion by favoritism, and not being a "born leader."

I suspect the reasons are less nefarious.

I suspect managers fail because they haven't developed the skills to be a good manager.

I don't buy that successful managers are "born leaders." I believe that successful managers have skills and abilities related to both management and leadership behaviors. And, my experience is that except for those rare birds who just don't like working with other people--people can learn the skills and develop the abilities to be successful managers. (Assuming reasonable emotional adjustment, self-awareness, and the ability to inspect and adapt their own behavior.)

Of course, it's harder to learn those skills and develop those abilities when there aren't good role models, and when a new manager doesn't have coaching and support to improve.

So if you or someone you know would like to work on their management skills and abilities, consider coming to the Managing One-on-One workshop Johanna and I are offering April 23-25, right here in lovely Minnesota (the show should be gone by then).

Your Leadership Philosophy

Ken Flowers suggests answering these three questions to clarifiy your leadership philosophy (which he came across on George Ambler's blog):

What you believe about people ...
What you believe about life ...
What you believe makes groups and organizations effective ...

I'd add these questions:

How closely do my actions match what I say I believe?

If my actions don't match my beliefs, how is that working for me?

If I really believed what I wrote, how would I act?

(You can read Ken's answers to the first three questions on his blog.)

More evidence that prima donnas (and prima dons) don't help overall achievement

Bob Sutton points to more research about prima donnas, prima dons, and jerks-at-work:

Boris [Groysberg ] wrote me a pair of detailed notes about a series of case studies that he has done that track Lehman Brothers’ research department over a 20 year period. Boris reports that “the rule” [the no asshole rule] helped fuel the rise of the research department there, and then when it was abandoned, was linked to performance problems, and when it was reinstated, performance again improved.

It seems that while we love the myth of the brilliant-but-difficult star, the data doesn't support our belief. Of course, there are exceptions. There are cases where one brilliant person is the pivot point for corporate success. But mostly it's just bad behavior that supresses overall results.