All Posts in Organizational Effectiveness

|In: Leadership|Last Updated:

Leaders are supposed to motivate employees.

Regular readers, and especially those who have read Leading IT: <Still> the Toughest Job in the World, might recall that I’ve become a strong proponent of autonomy, mastery, and purpose (AMP from here on in), Daniel Pink’s formulation for maximizing employee performance.

Pink’s book on the subject is Drive. Its subtitle promises, “The Surprising Truth About What Motivates Us.” What’s tricky is defining “motivate.”

When I hear the word, I think in terms of what gets me pumped up, full of energy, ready to take on tough challenges. I’m motivated.

Merriam-Webster.com’s definition is more tepid: “to give (someone) a reason for doing something.” It’s way too left-brain. Motivation is, to my way of thinking at least, an emotional thing. Reasons are … the word speaks for itself. They’re appeals to one’s reason.

“Studies show that soldiers who dig foxholes in 37 seconds or less have a 13.4% higher survival rate than those who don’t,” provides a reason to dig foxholes more quickly. “Dig fast or you’re gonna die!” motivates.

Which brings us to the curious case of AMP.

While AMP might or might not be the perfect formulation, the evidence is pretty solid that when a person finds the task itself intrinsically rewarding, that person’s performance exceeds what you’ll get from someone whose motivation comes from promised rewards like money.

It goes beyond that: The promise of an external reward interferes with the motivation that would otherwise come from inside. Promise a reward and performance is worse than when motivation is intrinsic.

We explored this effect in KJR some time ago, and concluded that when offered a reward for accomplishing something, those receiving the offer immediately deposit it in their psychological bank account. As it’s already theirs, the best possible outcome is that the person offering the reward doesn’t take it back.

Which means the motivation that comes from a promised reward is the fear of losing it, not the gratification of receiving it.

And as fear, while it does result in enormous energy, generally makes people stupid, this explains why the net effect of any promised external rewards is poorer performance, not better.

There’s also this odd bit: In conversations about motivation, when I bring up AMP as motivator, very few people find the promise of these to be energizing. The reaction is more along the lines of, “Yeah, that would be nice.”

All of which leads to a conclusion:

Motivating employees isn’t the same as getting better performance from them.

Most of us, as leaders, think of motivating employees as action and reaction: If I do this, employees will be more motivated than before.

But AMP doesn’t work as a way to motivate employees. If, in a staff meeting, you tell everyone, “From here on in, you’ll have more autonomy, mastery, and purpose,” you might expect great things as a result, but you won’t get great things as a result.

Try this and you’re offering AMP as a reward — the exact approach we just found doesn’t work.

AMP only works if you use it to guide how you set up the work environment and management culture, while never actually presenting in terms of your hoped for causes and effects.

Motivation isn’t the result of your actions. It’s the result of your reactions.

Praise is a motivational workhorse. Among the reasons it’s so useful is that there’s no way to make the mistake of offering it as a reward.

Not directly, at least.

“Do a good job and I’ll give you a public pat on the back” is so ludicrous a promise that it’s hard to imagine any manager uttering it, no matter how pointy-haired or naïve. But there is a risk — that praising someone creates an expectation of future praise — praise becomes an implicitly promised reward. See above.

Praise only works as a response to something praiseworthy. Your standards have to be high enough that earning your praise means something.

It has to be, that is, an accomplishment.

Which is the common thread that connects AMP to praise.

With AMP, an employee has improved his or her skills and achieved something important. Check.

With praise, an employee must have accomplished something important (check), and as a result has received your not-too-easily-given recognition of it — an accomplishment in its own right (double-check).

Whether the employee was more motivated really doesn’t matter. What does matter: the employee has accomplished something important, and is likely to accomplish something else important tomorrow.

Comments

|In: Organizational Effectiveness|Last Updated:

Promote the importance of using standard templates and styles in Word, and your personal brand will closely resemble that of a last-century librarian.

In the last century, librarians had the thankless but important task of making sure a book, once put on a bookshelf, could be found again when needed. But their image, like yours, is that of persnickety individuals who magnify trivia because they don’t have any important problems to work on.

Which is why, should you decide to try for standardization anyway, you’ll do well to remember the first rule of persuasion: Sell the problem (or opportunity), not the solution.

Last week’s KJR was an attempt to sell the problem, namely, that even when a business organizes work as a practice rather than as a process, failing to standardize on some of the basics can cause quite a lot of friction in the gears of getting things done, by creating completely unnecessary work whose prevention is almost entirely free.

And by the way, there are also situations where trying to institute standards would cost a great deal while being a hopeless cause. My daughter the programmer tells me GitHub illustrates the point well. While GitHub does publish style guides, the nature of the beast means there’s no way to enforce them, nor should there be. The result, though, is that making sense of what’s out there takes more work than if everyone followed the same coding standards.

Leaving this “And by the way” by the way, let’s get back to last week’s entirely prosaic example of a team that, in addition to coding, has to write documentation together. What’s the best way to get everyone on board? Put it differently, what does everyone have to understand about using Microsoft Word so standardizing on styles makes sense, rather than just being an act of resentful obedience?

MS Word styles are usually explained entirely wrong. They’re usually presented as ways to keep formatting consistent throughout a document.

They do achieve that, but it’s a happy byproduct, not the main event. Here’s what everyone on your team needs to understand about a style in Word: It identifies a specific part of a document.

Which in turn means that in order to use styles correctly, writers need to think about how they’re structuring what they’re writing. If you’ve ever been on the receiving end of someone who thinks their job is done if the information they’re supposed to convey is in there somewhere or other, you’ll understand the value of taking a writer through this thought process.

Documentation writers aren’t (or shouldn’t be) budding James Joyces. Their readers are more likely to be waiting for the project to be finished than for Godot, so there isn’t much justification for stream-of-consciousness expression in the documentation they write.

Authors of documentation should recognize when what they’re writing right now is the document title, subtitle, a section heading, body copy, one bullet in a bulleted list, a sidebar, a table column heading, table text, or something else.

They should, that is, understand the structural nature of what they’re writing as a document part. As author, they’re responsible for identifying this. Someone else can decide what a heading, sidebar, or list bullet should look like.

What’s strange about all this is that programming teams seem particularly resistant to adhering to the principles of document architecture in their writing, and this in spite of their being better-equipped to understand these principles than just about anyone else in the company. There’s no important difference, after all, between styles in MS Word and what developers do when coding cascading style sheets — the programs (yes, they’re programs — give them proper respect) that explain to a web browser how to render every HTML tag that’s included in a downloading stream of text.

One more point: As is so often the case, the all-too-frequent response to programmers who violate the rules … whether of documentation architecture or, more importantly, of software architecture and coding standards … is enforcement.

As a last, desperate alternative to receiving bad code and junky documentation, enforcement is better than nothing.

But if your goal is a high-performance software development practice (and this applies, by extension, to any business practice), enforcement isn’t what will get you there. Enforcement takes too much managerial effort to overcome too much team friction.

High performance comes, not from oversight, but from education and culture — making it how we do things around here.

Otherwise it won’t be how we do things around here.

Comments