Behavior-based language primer for managers: Stop using generalizations
If you manage people, one skill you need to develop is the conscious use of behavior-based language. This is also known as performance-based language. This is the first in a series discussing how to transition your language to be more behavior-based.
Behavior-based language is using language that attempts to describe specific behaviors, rather than language that makes generalizations or value judgments. In today’s post, I’ll discuss a common management mistake: Using generalizations.
Examples of generalizations (or generalized language) a manager may use:
“You always show up late for work”
“You don’t seem to know what you’re doing.”
“You’re trying really hard, but it isn’t working out.”
“Your code isn’t up to par.”
“You’re doing a great job!”
“You’re doing a terrible job!”
In these examples, the manager is trying to generalize the situation. It has the virtue of being very compressed and efficient in the time it takes to articulate, but it is useless. That’s right, I said useless. And it probably sets you in the wrong direction, creating more work later. It’s a short cut that doesn’t work.
That’s because these generalizations are, at the core, inaccurate. Let’s go through a few of these examples:
Example #1: “You always show up late for work.”
It is unlikely that the person always shows up late for work, and if the employee can demonstrate that he did show up on time for work one time, then the manager’s assessment is incorrect. What a low bar—the person shows up for work late several times in a row, and shows up on time on one day, and the employee has an advantage in an argument with his boss. So while the sentiment and trend is toward “always” being late for work, it actually isn’t true. The manager has to use alternative language. The alternative language is behavior-based language. It takes more rigor and research, but it gets the job done. Here is a more behavior-based alternative:
“Your expected arrival time is 8:30am. Last week, you arrived at 8:29, 9:00, 9:15, and 10:45. So 4 out of five times in the past week you have been late for work. In addition, I see a similar trend in prior weeks.”
Some attributes of this behavior-based language: It starts with the expected performance bar, it starts with specifics, and, when enough specifics have been covered, it allows an extrapolation to a trend (which allows for a margin of error).
Another attribute is that it allows the conversation to move past the facts, and on to the reasons behind the behaviors and possible solutions, and the plans going forward.
Let’s try a few more:
Example #2: “You don’t seem to know what you’re doing.”
This can be translated in more behavior-based language to:
“When you created the design document, you didn’t use the process that we’ve established on the team. There are some areas of the document template that are required to be filled out, and I’ve seen a few that have had these areas left blank. . .”
Example #3: “You’re trying really hard, but it isn’t working out. . .”
This can be translated to:
“The developers who are using your design document have given me feedback that there are elements that are unclear or incomplete. In some areas they tell me that sections are contradictory. They’ve talked to you a few times to get clarifications. I’d like to find a way to reduce the cycle time that is generated by your design documents.”
In this example it’s more evaluative as to what constitutes good performance. Even a situation that is mostly evaluative can be described in behavior-based terms—the manager experienced the developers with the feedback, and cites this as the issue. It also states the stated goal of the new behaviors sought (less cycle time), even though it is not perfectly clear what behaviors the employee engaged in to create the extra cycles.
Now, at the conclusion of these discussions, you will be tempted to summarize using generalized language, but only after you have firmly established specifics of the situation and gained agreement on the facts can you start using generalizations, such as “Your design documents aren’t up to par.” This is less problematic than starting with the generalization. But even then, it risks clouding the issue you’re trying to correct – that is, the employee is likely to think that there are other, undisclosed behaviors you’d like to correct, starting up arguments and mistrust that your good work has thus far avoided. So don’t bother. If there are other things about the employee’s performance, you need to specify these as well. You can assure the employee that if you observe other performance gaps, you’ll discuss it with them. Yup, a manager’s work is never done!
So don’t generalize if you can avoid it. It’s a waste of time. It doesn’t work. (I know that this is a generalization – so my challenge to you is to tell me when it does work!) Make the effort to transition to behavior-based language and be more specific about what you observed that caused you to make that generalization. It’s a hard transition to make, but if you stick with it, you’ll notice how many fewer problematic conversations you’ll have.
Have you been on the giving end or receiving end of generalized language? How did it go? What was said, and how could it have been more behavior-based?
In an upcoming post, I’ll provide an examination of value-statement language, the pitfalls it brings, and how it can be translated into behavior-based language.