For people to perform as well as they can, it helps if their job assignments are aligned with the strong points of their personalities, not their weak points. Methodologies name the roles that must be present on a project but don't mention the personality characteristics required for each role.
Here are three examples of a person whose personality characteristics did not match those required for the role. The Socially Minded Manager
Once, on a large multiteam project, the cross-team manager was socially minded to the extent that he did not want to offend anyone.
As a result, he would not make those hard personal and priority decisions that are exactly what the cross-team manager is hired to make.
The Non-Verbal Team Lead
The person hired as lead programmer and mentor was a stereotypical noncommunicating programmer.
Rather than coach the novice programmers on improving their programming skills, he simply changed their code when they weren't around!
The Concrete-Thinking OO Designer
One person on our OO project desperately wanted to learn object-oriented programming. He seemed unable to get his thinking to an abstract enough level to generate good OO designs, though.
After much coaching for six months, his programs still looked like the user interface or the relational database.
What could be done with these people, instead? On the first project, the person was too high on the project ladder to be replaced, and so the project continued to suffer. On the second project, the person was eventually replaced with someone who had good communication skills, who taught the novice programmers basic OO design skills.
On the third project, we were luckier. The person was spectacularly good at defining requirements, where his careful thinking and attention to detail paid off. In exchange for his working on the requirements, he continued doing OO design and programming on sections of the system where the quality of the design was not a critical issue. Everyone benefited: He had fun doing the programming, and the project was safer due to the high quality of his requirements work.
Talent
The best programmers on the team may be so much better than the rest that just a few of the best programmers can put out more than all the rest combined. eBucks.com Goes Live
The top programmer at a consortium of banks, called the First Rand Group, in South Africa managed to get the company's new eBucks system out in just three months. I asked him how he managed that feat. He said that he and one other person had personally programmed it.
I nodded as I heard this. "The old solution. Get the best two programmers to sit together and program it up rather than coordinate 20 people through a fancy methodology.” But that left an open question. I knew that he had many other duties and would have to attend so many meetings that he couldn't possibly concentrate enough to program. I asked him about that.
He answered, "I attended meetings until 5 p.m. or so and then wrote code from 6 p.m. until 2 a.m. each day."
Oh. Another far-too-obvious solution. Have the two best people work back-breaking hours for several months. Painful, but effective. This combination of talent and practiced skill I call "personal prowess." Although a manager can increase the skill of the team members by encouraging them to learn and sending them to courses, he can't change the talent level of the team. A talented designer will still outperform an average designer with good skills.
John Wooden, the famously successful college basketball coach, considers talent such a key issue that he labeled his first coaching secret, "Secret #1: The team with the best players almost always wins." (Hill 2001, p. 63)
Rewards that Preserve Joy
Inventing reward structures is tricky. I recently got tripped up on this myself, in what I thought was a simple work-reward situation: Picking Dandelions
Dandelions were beginning to clutter our back yard. Having three children aged 10 –and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we'd get rid of dandelions in a few years. The kids brought in bags of dandelions, and I paid out the cash.
On the third year, I commented to my now 12-year-old, Cameron, that it looked like we had more dandelions than the previous year. He said, "Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn't just putting them into the bag, I said, 'I'm planting money for next year!'"
If I had that much trouble with that simple situation, how much harder is it to find an appropriate reward for creating software? Should you reward
· Lines of code sent to the test department?
· Low defect rates delivered to the test department?
· Function points delivered each month?
· Number of lines reused from a corporate library? In a Dilbert cartoon, the manager offers rewards related to the number of program bugs discovered. A programmer immediately announces: "I'm writing myself a minivan this afternoon!" (How like the dandelions!)
Even if you can name an appropriate reward structure, what does the organization actually reward? Is it aligned with what is most important for the company? Lines-of-Code-Based Pay
A large company I dare not name ran an initiative to encourage reuse. Programmers' performance, however, was evaluated based on the number of lines of code sent to the test department each month. One person I knew incorporated components from the company's reuse library, as encouraged. She was, however, only given credit for the lines she wrote herself, not those she reused. As a result, she received a low evaluation for her programming performance.
Programmers detect the mismatch and sometimes find subtle ways in which to retaliate. Goldplating
A team leader in a small start-up company complained to me that one of the programmers was adding unnecessary complexity to his design—"goldplating" it—to make it more "interesting" for himself.
When we looked at the matter together, we saw that this person was earning a small, fixed salary in a high-risk position in a start-up company. His risk exposure for working there was high, his reward low. He had evidently made his own self-reward scheme, inventing "cool" code that either would make his daily life interesting or would enhance his employability for the next job.
This sort of mismatch leads to programmers behaving in ways that hurt the company, just as Cameron's "investment" view of dandelion picking hurt my plans for the back yard.
One person wrote to me that he feels stock options are a form of reward that aligns the good of the company with the programmer's behavior. He wrote that he is now working in maintenance, not because it is more fun but because it is the best way to protect his stock ownership in the company.
Reward schemes are an even more slippery subject than I have implied so far, though. Alfie Kohn (1999) writes that rewards actually reduce the intrinsic joy and output quality of an otherwise fun activity:
"Young children who are rewarded for drawing are less likely to draw on their own than are children who draw just for the fun of it. Teenagers offered rewards for playing word games enjoy the games less and do not do as well as those who play with no rewards. Employees who are praised for meeting a manager's expectations suffer a drop in motivation. ... In one study, girls in the fifth and sixth grades tutored younger children much less effectively if they were promised free movie tickets for teaching well. The study, by James Gabarino, now president of Chicago's Erikson Institute for Advanced Studies in Child Development, showed that tutors working for the reward took longer to communicate ideas, got frustrated more easily, and did a poorer job in the end than those who were not rewarded."
If rewarding intrinsically motivated behavior destroys intrinsic motivation, what rewards might retain a person's intrinsic motivation? · Pride in work
· Pride in accomplishment
· Pride in contribution
Pride in Work
Pride in work is exemplified by an ad for Scotch whiskey that I saw some years ago (sorry, it was long enough ago that I have to paraphrase this example). The ad ran something like this: "If you want a set of hand-carved golf clubs from Ian McGregor, you'll have to wait two years. There are three people ahead of you. (Good things take time)."
The ad made it clear that Ian McGregor took pride in his work, and as a result, he did an outstanding job (as did the Scotch distillery, by extension). The clientele could tell the difference and were willing to wait.
I only recently became aware of the possible role that pride-in-work might play on a project, but it wasn't long before I heard a programmer say this:
"Well, the system's OK... I mean it functions, but I can't really take any pride in my work. I'd like to go home feeling good about my program, but I don't. It's just a big mess that barely works."
He continued by saying that he wasn't really happy with his job, even though things were "working."
Pride in Accomplishment
Winning is a great reward. Completing something counts as a "small win" (Weick 2001) and is also powerful.
In software, we create an early win by delivering running, tested, useful code quickly. Using the principle of small wins as a motivating reward, a team delivers as early as possible the smallest thing that will count as a win for the team. That early delivery demonstrates to both the sponsor and the team that the team can work together and deliver. It boosts the morale of both.