esther derby's "insights you can use"

Moving to a new location

2010-03-02T09:21:00.002-06:00

This blog is moving.

Two factors came together: I decided to move to Word Press and Blogger decided to discontinue support for non-hosted blogs. Done deal.

New Location: http://www.estherderby.com/category/insights

New Feed: feed://www.estherderby.com/feed

13 Essential Questions for Managers

2010-02-18T13:32:00.000-06:00

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?

Workshops for People Who Work with Humans

2010-01-19T13:51:00.002-06:00

Problem Solving Leadership (PSL) with Jerry Weinberg and Johanna Rothman. This is the gold standard for people who want to lead from any level of the organization. May 2-7, in Albuquerque, NM. Email me for info.

Secrets of Agile Teamwork with Diana Larsen. Core collaboration skills for people who work interdependently with others.
June 22-24, in Portland, OR. Registration via Agile University.

The Power of Questions

2010-01-11T09:01:00.005-06:00

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

2009-09-15T06:43:00.004-05:00

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

2009-09-10T15:52:00.004-05:00

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 w/o Appraisal II

2009-09-02T14:14:00.002-05:00

As I said in yesterday's post, one of the hoped-for outcomes of annual appraisals is improved individual performance. The assumption is that ranking and rating people will provide the impetus for improved performance.

Fact:

Evaluation does not provide what people need in order to improve. In order to improve, people need information--specific examples of behavior or results, along with the impact of the behavior or result.

Examples from months ago aren't helpful. Either the person won't remember the incident, or they'll wonder why the manager waited so long to bring it up. A reasonable person might conclude that his manager doesn't want him to be successful. After all, if there was something he needed to do differently, why did the boss wait until the rating period to tell him?

Bell curves, ratings, and rankings do not improve organizational performance. In fact, they can damage performance.

Most people believe their work is above average. It's called the Enhancement Effect. Telling someone he is below average results in a defense response, so he won't be really hearing the rest of the message.

Stack ranking drives competition, diminishes sharing relevant information and sets people against each other. So one persons performance might improve, but at the expense of overall results.

Anonymous feedback destroys trust. People will try to guess where the feedback came from... and much of the time they'll guess wrong, resulting in damaged relationships.

People accept feedback when these four things are true:

The source is reliable

The receivers trusts the givers intentions

The receiver has a chance to clarify (being permitted to put a written rebuttal in a personnel folder doesn't meet the intention of this point)

The process is fair--both how the feedback is developed and how it's delivered

Most appraisals fail on multiple points, even when managers have good intentions.

Up next: the third assumption behind performance appraisals, improving individual skills is the best way to improve organizational performance.

Performance without Appraisal Part I

2009-09-01T11:17:00.002-05:00

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.

UnTeams and Real Teams

2009-07-28T07:32:00.001-05:00

Not long ago, I worked with an organization where the managers talked about teams, even though there wasn't a real team in sight.

To these managers, any group of people who reported to one manager was a team.

All the DBAs reported to the DBA manager, all the GUI developers reported to the GUI manager, and so forth.

But these groups didn't work as teams.

They didn't have complementary skills, they all had (roughly) the same skills.

While the people within one group had a common goal (e.g., maintain the integrity and performance of the databases), the goal wasn't about creating a product.

Each person was also assigned to one or more (usually more) projects, which were also called teams.

The so-called project teams were made up of people with complementary skills, and they had a common goal of creating a software project.

That meets part of the definition of a team; but when people are assigned on a temporary or part-term basis, it's not likely that they will gel as a team.

There's no crime in having a work group. Some work is much better suited for a group than a team. And I'm not just being picky about precise use of language.

Managers who believe work groups are teams usually expect some level of cohesion and ...err...team work from that group. And they are disappointed when they don't see it. Their disappointment can come out in blame, castigations, or lower performance reviews (the dreaded "not a team player" evaluation).

Here's how I define team:

They have a common goal or purpose.

They share an approach to their work. That doesn't mean they have a rigid process that they follow in lock-step, but they do have agreement on key elements of their work.

They are jointly accountable for results. If one person finishes his tasks and the rest of the team members don't the team isn't successful, and neither is the one who finished his tasks.

They are small in size, usually between 7-9 people. Some research indicates a productivity sweet spot in the 4-6 range.

They have shared history. Teams aren't teams on the first day. They have to agree to be a team, and then develop enough trust and cohesion to function as a team. Overtime, they learn each others strengths and weaknesses. They learn how to make the best use of everyone's talents.

Finally, teams build their capacity through their work.

Why Group Dynamics and Interpersonal Skills Matter

2009-07-10T07:39:00.001-05:00

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

2009-06-30T06:25:00.003-05:00

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

2009-06-29T15:40:00.004-05:00

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

2009-06-11T19:57:00.007-05:00

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.

Tips for Retrospective Facilitators

2009-05-29T14:29:00.004-05:00

When Diana Larsen and I teach a two-day Leading Agile Retrospectives workshop, the second day is stand up facilitation practice. We create the bare bones story of an iteration, then the class works together to design a retrospective. Each participant has a chance to lead an activity. And Diana and I offer feedback and facilitation advice.

Having done this more than a few times, I've noticed that we repeat the same advice in almost every class.

My colleague Mark Kilby asked what that advice was, so here it is (at least some of it).

When you ask the group a question, give people enough time to answer. It can feel a little disconcerting to stand there in silence, but people--especially introverted people--need time to collect their thoughts before they speak.

Count to eight s-l-o-w-l-y. If no one has answered, count to eight again. If there's still no answer, move on.

Do some of the work in pairs or small groups. Not every discussion or activity needs to happen with the entire group. Doing some activities in smaller groups or pairs adds variety, makes it easier for reticent people to state their views, and limits the possibility for voluble or dominant people to own the airwaves.

Let the group do as much of the work as possible. Rather than doing all the capturing, when possible have people write their ideas on stickies (with a marker, not a regular pen) and post them. Ask one of the participants to help hang up flip charts or hand out stuff like markers, stickies, dots.

Give instructions in chunks. If you are using an activity that has multiple parts or requires movement, break up the instructions. Even if the instructions seem simple to you, people are not likely to retain them if they are hearing several steps at once and having conversations between steps.

Start by stating the purpose of the activity: For example, "We're going to do use a use a special type of diagram to help us understand which issues are causing most of our difficulties." Wait for questions.

Then give the first instruction. "Please from groups of three." Wait until people are in groups before you continue...or say "In a minute, I'm going to ask you to get into groups of three. Let me tell you what I want you to do in the small group." Give the instruction.

Once they've done than part, give them the next instruction.

Provide a key when you color code anything as part of an activity. (for example sometimes I'll do a timeline with yellow=technical issues or events, blue=team issues or events, green=organizational issues or events.

If you get lost in an activity or something happens that you don't know quite how to handle, pause and reset. No one can be perfect, so get good at recovering gracefully. It's okay to say, "This isn't going the way I thought it would. Is this useful to you?" Always have a back up activity, just in case.

Use wide chisel tip markers in dark colors for writing on flip charts or white boards. Dark blue, dark green, dark purple, green and black are easy to see. Fun colors like orange, light green, turquoise are hard to see from a distance. Red is okay for younger people, problematic for people over 40. Use those fun colors to accent, but not for text. (You can buy boxes of Mr. Sketch dark colors at www.artsuppliesonline.com.)

Write BIG, and use sentence case when writing on flip charts or white boards. It's still sort of surprising how many people stand in front of a flip chart and write letters 1/2 inch tall. Write BIG. People can read sentence case more quickly than they can read ALL CAPS. Capitals are okay for headings, as they create a visual cue.

While I'm on the subject of flip chart writing, there's something about visual field when you are writing BIG on a flip chart that makes it difficult to spell correctly. It's nothing to do with you (or me). Really. It's because your brain can't take in the entire word as it does when you write on a smaller scale. Declare a General Spelling Amnesty, or put a spell check button on your flip chart when you make a mistake--you'll probably get a laugh.

Put dying markers out of their misery. Really. Throw them away (unless they are refillable.) They are useless, worse than useless, because they make you think you are capturing something the group can see, when you aren't and they can't. Throw them away, now! (I visited a company where people held onto dead markers. When I asked why, they told me they were the only markers they had, and the secretary wouldn't order any more. So wrong, on so many levels.)

Okay, that's enough for now.

Shocking Survey Results about Performance Appraisal

2009-05-21T07:34:00.004-05:00

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

2009-05-18T06:32:00.002-05:00

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

2009-05-08T07:00:00.006-05:00

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

2009-04-30T10:04:00.006-05:00

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.

What to do with a struggling employee

2009-04-22T09:55:00.002-05:00

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.

The Benefits of Peer Feedback

2009-04-14T07:50:00.003-05:00

Peer feedback is a core skill for collaboration. It's impossible to work closely with out running into some bumps: differences, disappointments, and disagreements. Peer to peer feedback can help keep working relationships on track and improve results (and it keeps the manager out of the transaction so it doesn't be come a *big deal*).

I teach about feedback in both my team collaboration workshop and management workshops. "But does it work in the real world?" some ask. Ola Ellnestam blogs How I Learned about Feedback.

Five Ways that Team Members Build Trust with Each Other

2009-04-02T17:05:00.003-05:00

Building trust may seem mysterious... something that just happens, or grows through some unknowable process. Like many things, there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break trust down).

First, a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you'd think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, I trust that you are competent to do the work, that you'll share relevant information, and that you have good intentions towards the team. Taken broadly, that's trust about communication, commitment, and competence.

1. Address issues directly

It's inevitable that some person on the team will rub another person on the team the wrong way. Maybe it's they way he cracks his gum, or listens to voice mail on speaker phone. Maybe it's using your laptop and changing all the preferences. Maybe it's breaking the build and then leaving for lunch.

These frictions are inevitable. When a team member speaks directly to the person who is bugging him, he builds trust. Raising an issue says, "I value our working relationship, and I'm willing to have an uncomfortable conversation to make it better." It says, "You'll know where you stand with me; I won't be talking behind your back."

These conversations aren't always easy. Sometimes people delay the uncomfortable discussion until the situation becomes intolerable, letting anger and resentment build.

Sometimes people try to avoid the difficult conversation by telling their manger about the problem. And sometimes the manager falls into the trap of carrying the message. Seth had just started a new job and hadn't really made friends with anyone on the team yet, so he spent is lunch hour alone. On his second week on the job, his new manager called him in to inform him that another team member resented the amount of time he was taking for lunch, since 45 minutes was the unspoken rule.

(I do wonder why no one bothered to tell Seth this, and why no one invited him for lunch in his first week on the job, but that's another issue.)

When his coworker talked to the manager instead of talking directly to Seth, he broke
trust. When I talked to Seth, he'd been at that job for over a year, and still didn't fully trust his coworker. No one likes a tattle tale.

When people don't know how to have difficult conversations...or think it's not their job to navigate working relationship, trust erodes. And that's why people need a framework to talk about interpersonal feedback.

2. Share Relevant Information

If you don't support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)

When someone on the team withholds and opinion or concern when a topic is under discussion and then comes back later to say "I thought it was a bad idea from the start," other team members feel blindsided. That breaks trust.

Relevant information is about the task, but it's also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests and identification form solid ground that people can land on when there is friction and conflict. You don't have to share your deepest secrets, but letting other people on the team know something about life outside work makes people "real." It's hard to trust a cipher; much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.

In order for teams to function, team members need to believe that their co-workers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

3. Follow Through on Commitments or Give Early Notice When You Can't

No reasonable person expects that every person can meet every commitment all the time. We know that sometimes a piece of code turns out to be more complex than anticipated or we discover we didn't fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it's going to be late, it breaks trust. So let people know as soon as you know, and renegotiate.

4. Say No When You Mean No

Sometimes you just can't take on another task, or do a favor that someone asks for.
But most of us are programmed from an early age to please other people. If we say no, we're called selfish or "not a team player." But if you really can't do what's asked, it's more respectful to say No and let the other person get on with getting his need met elsewhere.

Saying Yes without follow-through leads others to doubt your word. If you can't say No, your Yes won't mean anything.

It may seem paradoxical, but building competence trust sometimes means admitting that you don't have all the answers.

5. Show What You Know and What You Don't Know.

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other peoples ideas, build on them, and help others shine. Admit when you don't know the answers; there's nothing worse than a know-it-all who is wrong. Ask for help. That helps other see you as a real person, and people generally like to be helpful.

Visibly Valuable

2009-03-31T14:11:00.003-05:00

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 Myths about Teams

2009-03-30T07:30:00.002-05:00

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

2009-03-11T10:22:00.002-05:00

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

2009-03-07T08:00:00.003-06:00

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.