Workshops for People Who Work with Humans

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

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

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

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

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.