I’m giving a workshop and talk at Webstock next week.

I did a little interview with them, which you can find here.  You’ll find out about my first program and my first portable computer.

I had fun with the interview, hope you enjoy reading it.

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.

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.

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.

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.