(c) 2002-2010 Esther Derby

This column originally appeared in STQE magazine, July/August 2002

ac-count-a-ble adj. 1. Subject to the obligation to report, explain, or justify something; responsible; answerable. 2. Capable of being explained; explicable.

(The Random House College Dictionary, Revised Edition, 1988.)

Did you know that’s what accountable means?

I never would have guessed that from listening to how people use the word. And I hear people use it a lot lately. It seems like the one of those management buzzwords that pops up from time to time, like “leadership” and “nimble” a few years back. When I ask, most people who use the word can’t give me a precise definition. They trail off saying, “Accountable means . . . well, you know . . . accountable!”

I suspect that accountable is used as a surrogate for other, less palatable, expressions. I’ve got my decoder ring right here, so let’s figure out what’s really behind this word.

False Definition 1: To be pressured

When you hear someone say, “You must hold him accountable,” pay attention to the emphasis the speaker puts on the words. When the there isn’t any particular emphasis and the statement is followed by some examples of what the staff members are expected to do, and the tools they have to do the job, the speaker is probably talking about setting achievable goals and tracking progress.

But if you hear particular stress on one or more words (“You must hold him accountable,” for example), the speaker may have a mental model of management that says, “people are basically lazy, and if you don’t push them, they will take their own sweet time getting anything done.” Listen, too, for what comes after the statement. If you hear that colorful phrase “hold his feet to the fire,” or the word “disappointed,” then accountableis a code word for pressure. And the speaker really means, “You must pressure him to perform.”

False Definition 2: To be blamed

Take for example, “The project manager is accountable for project success.” If you read this according to the dictionary definition, it might mean, “The project manager is responsible for reporting on the current state of the project, explaining the situation, and justifying the need for resources that will provide a reasonable chance of success.” It might also mean, “The project manager is responsible for explaining and justifying plans to achieve the project goals.” Or even, “If something goes wrong, the project manager must explain why.”

Unfortunately, I often hear “The project manager is accountable for project success,” (or it’s more obvious evil twin, “You are accountable for project success”) in situations where the chances for project success given the current situation are slim to none (and none just left town). Then it really means, “I will blame you if this project fails.”

False Definitions one and two are forms of pressure: a threat of unpleasant future consequences. Will that pressure really help? Or just make the blamer feel better?

False Definition 3: To be responsible for someone else’s mess

Ever heard this one? “The problem around here is that no one is accountable.” I usually hear this variant in organizations where the measurement or reward system is driving behavior that makes life “downstream” a misery. The problem isn’t really that people aren’t being held accountable; it is they are being held accountable for goals that are in conflict. For example, a certain project manager was held accountable for meeting a schedule. He’s now in the Bahamas enjoying his bonus for getting the project out on time. Meanwhile, the support manager is working overtime dealing with irate customers whose software is crashing. He is being held accountable for a goal (perhaps maintaining a certain customer satisfaction rating) that is nearly impossible to achieve, because the project manager had a goal to meet a delivery date, but did not have a goal to meet a quality standard. When someone says, “no one is accountable,” it probably means, “Because of the way someone else did his job, it is very hard to do the job I am accountable for. I feel like I’ve been left holding the bag.”

Say what you mean. Mean what you say.

Why am I making such a big deal about this? After all, accountable is only a word. And I do believe that people should be accountable for their actions. But when there’s a coded meaning involved through context or emphasis, then no one is well served. I believe that the vast majority of people want to do a good job. They may not always know how or have what they need to get the job done, but their intention is to do good work.

We will all be more accountable if we remember the true definition: The first part “subject to the obligation to report,” reminds us to report on our understanding of the task and our ability to get it done with the current resources. The second part, “capable of being explained; explicable,” reminds us to check that the task can be credibly described. When we remember the real meaning of accountable, we can stop talking in code words and get on with building solid software.

Came across this quote today–seems a propros the discussion of management and leadership.

It seems to me that whereas power usually means power-over, the power of some person or group over some other person or group, it is possible to develop the conception of power-with, a jointly developed power, a co-active, not coercive power.

If leadership does not mean coercion in any form, if it does not mean controlling, protecting or exploiting, what does it mean? It means, I think, freeing.  The greatest service [one person] can render another is to increase his freedom–his free range of activity and thought and his power of control.

Leader and followers are both following the invisible leaders–the common purpose.

Mary Parker Follett

What comes up for you when you read this?

I’m uncomfortable with the manager vs. leader dichotomy that’s bandied about lately.

Most of the time, the conversation is reduced to a sound bite: “Managers do things right, leaders to the right thing” (from a Warren Bennis quote).

Cute, but not helpful.

There is no single definition of management or leadership. How you define either term depends on your view of human nature and motivation.

Some people would define management as the process of dealing with or controlling things or people. On the other hand, Drucker would say the two central tasks of management are helping workers to achieve and moving capital from less to more productive areas.

When we talk about leaders, are we talking about charismatic leaders who gather followers to support them in implementing their own vision? Or are we talking about people who help people find their own power and creativity?

How management and leadership is practiced depends on the predominant beliefs of the organization and the mental model and skills of individuals. I believe that leadership doesn’t exist only in a role. It’s in taking action that make it possible for people to bring their best thinking and creativity to bear in solving problems and creating value. And frankly, I don’t see the title (or role) of manager going away any time soon. For one thing, there are legal and financial implications of doing away with the role.

Rather than denigrating the role (and by implication the people in that role) I would find it more useful to talk about what sort of support teams need, what skills are needed to provide that support and then design roles around that.

Maybe we can start a different conversation.

Here’s one starting point to think about the skills that people in management roles and leaders at all levels need (from Welter and Egmon):

Eight Essential Skills of a Prepared Mind:

• Observing
• Reasoning
• Imagining
• Challenging
• Deciding
• Learning
• Enabling
• Reflecting

I add:

• Self-awareness
• Self-management
• Ability to see systems
• Interpersonal skills

What sort of support does your team need?

What skills and attitudes will enable that support?

What might that role look like?

What does the organization as a whole need from that role?

(c) 2003-2010 Esther Derby

This column originally appeared on Computerworld.com

Twice a week, I go to the gym and weight train with Brooke Darst, a Certified Personal Trainer. As I perform my exercises, Brooke provides a constant stream of feedback: Minor corrections, “Chin in! Lower your right shoulder. Stand up straight!” Encouragement, “Perfect!” and recognition for improvement, “You held that 10 seconds longer than last week – awesome!”

It’s obvious that if Brooke waited until the end of the month and then told me “In the first week of the month, you raised your right shoulder during some exercises,” it wouldn’t be very helpful. I might not remember the specific exercise or session, and I wouldn’t have a chance to correct the problem until the next session. I’d start looking for a new trainer.

Unfortunately, many managers act as if they think it’s best to wait until the yearly performance evaluation to provide feedback.

Delayed feedback has significant costs. If there’s been a pattern of incorrect or incomplete work, it’s too late to go back and correct the work. The opportunity to improve performance and productivity is gone forever. The feedback given long after the event may feel capricious or arbitrary. The highest price is damaged working relationships.

Jackson waited until a yearly performance review to tell Sheila that the defect density in her code was twice as high as the other programmers. Now he was going to move her onto a less challenging project.

Sheila was stunned. “Why didn’t you tell me sooner?” she asked. “The defect densities aren’t sorted to show individual differences — I had no idea. When I asked about a promotion in our one-on-one meeting, you never said anything about not being happy with my work! I could have done something differently if I’d known!”

Sheila started wondering what else Jackson wasn’t telling her. And she wondered if this was the start of Jackson pushing her off the team. She accepted the new assignment, but she didn’t really trust Jackson after that.

Feedback is necessary to achieve result and to maintain relationships.

Here are three basic guidelines for providing information to improve the work while maintaining working relationships:

Assume people don’t know. Like Sheila, people are often not aware that their performance isn’t quite up to par. When there isn’t a defined point of comparison or data from the work itself, people may not realize their work isn’t all it needs to be. Some times it’s as simple as asking a question. “Are you aware that the defect density in your code is twice as high as anyone else in the group?” A question can provide information and set the stage for problem solving.

Provide clear, specific examples. Don’t make the feedback receiver guess what to change. Suppose a manager said, “You didn’t deliver on last month’s design. I’m disappointed in you.” What does “didn’t deliver” mean? Was the design late? Was it incorrect? In the wrong form?

Vague statements and generalizations such don’t provide information for the feedback receiver to know what to do differently. If you want to see an improvement, provide specific examples of what was wrong and what the results should be. A statement like “I found grammar and spelling errors on every page in your design. I’ve marked them here. The design itself is correct, but the number of errors in the text distract from the content,” is more likely to achieve the desired improvement.

Give feedback before you reach the boiling point. Don’t wait until you are ready to transfer, demote, or terminate. Most people want to do a good job. But they may not know what the standard is or how to do it. Give information early so people have a chance to correct the situation before you reach the end of your rope.

Managers don’t need to provide minute-by-minute feedback like my personal trainer does. They do need to provide clear, specific, and timely feedback to help people be as successful as they can be. After all, if the people who report to you aren’t successful, how can you be successful?

“Nothing is more dangerous than an idea, when it’s the only one you have.”

Emile-Auguste Chartier

There are three states in problem solving.

• Not enough ideas
• Too many ideas
• Just the right number of ideas

In the first case (stuck) the task is to generate ideas.

In the second case (stuck in churn) the task is to prune the number of ideas.

In the third, to test and refine the ideas, then implement and refine.

Stuck in Neutral

Fixing the Quick Fix

© 2003- 2010 Esther Derby

This column originally appeared in STQE, May/June 2003.

When action grows unprofitable, gather information; when information grows unprofitable, sleep. Ursula K. Le Guin, The Left Hand of Darkness

A few months ago, I began writing a “Technically Speaking” column for this issue and just couldn’t make myself finish it. I started over on another topic, but couldn’t work up much energy for it. I started yet a third time, and found myself easily distracted.

The week my column was due, I was still starting over and over and over. I began to panic: “I’ve been writing this column for three years! I should be able to do this!”

I was stuck.

As it happened, I was scheduled to have lunch with my friend, Bob King, a software architect and a writer. Eventually, our conversation turned to writing.

I explained my problem to Bob. “What should I write about?” I asked.

“Why don’t you write about not knowing what to write about?” he suggested.

“Yeah, right,” I said, dismissively.

After lunch, I though about Bob’s suggestion a bit more, wondering if “un-sticking” could make an interesting column. Then I remembered that I’d recently received an email from a colleague who needed some un-sticking with a performance issue. And I remembered another colleague who had spent an entire day stepping through every line of code, determined to root out a bug. By the end of that day, she was completely out of ideas and still hadn’t found the bug—she was stuck.

“Oh,” I thought. “I’m not the only one who feels stuck. Perhaps Bob was on to something.”

So I compiled some strategies that get me moving again when I am at a dead end.

Notice what is happening. Am I making no progress despite several attempts? Am I repeatedly telling myself, “I should be able to do this?”

Take a break. Work on something else unrelated to the problem at hand, especially something physical. Tasks that occupy your body and require concentration occupy the conscious portion of your mind and leave the unconscious parts to work on the problem.

Verbalize the problem. I can’t tell you the number of times I haven’t been halfway through the explanation of a problem when the light bulb switches on. When no one else is around, I explain the problem to my dog. He’s a good listener, and remarkably astute.

Ask for help. Sometimes another person with a different point of view or a fresh set of eyes will see what I cannot.

Sleep on it. Sleeping on a problem can allow the unconscious mind to go to work. This strategy is not suitable in all work environments.

Make a list. Write down all the known facts about the problem. You may find that you need more information; or discover new patterns in the data.

Look where the problem isn’t. Quite often, a problem is exactly where I’m sure it isn’t. It couldn’t be in the subroutine I wrote, could it? Check those places, too.

Brainstorm. Think of twenty ways to solve the problem. Don’t dismiss anything until you’ve considered it carefully.

Sometimes it takes more than one of these jiggles to get going. Looking back on my most recent stuck-experience, I see that I applied four strategies. I noticed that I wasn’t making progress, but was repeatedly telling myself I should be. I took a break by going to lunch with Bob. (And eating is sort of physical, though in general I can’t endorse eating as a problem solving strategy for all the obvious reasons.) I asked for help. At first it didn’t seem like Bob was giving me the help I wanted. Help is often like that. Finally, I considered an idea that seemed way-out long enough to see its merit.

And I arrived here: at the end of another column and unstuck.