Myth #1: Managers cannot (or should not) affect motivation When managers believe that people either have or do not have motivation, they feel powerless to affect motivation. In her book Mindset, Dr. Carol Dweck refers to this as the “fixed” mindset. The fixed mindset is the belief that people are born with unchangeable strengths and weaknesses and that people would do well to build on their strengths and avoid tasks at which they are weak. She contrasts this with the “growth” mindset, which is the belief that people grow and learn throughout their lives. In Mindset, Dweck explains how to break out of the fixed mindset and adopt the growth mindset. She also provides research supporting the belief that this change is possible (even for old guys like me!). But I digress… Another variation exists, with a moral twist. Instead of believing they motivate people, some managers feel they not. cannot should They feel it’s immoral to do so. They feel, somehow, that “good people will be motivated to do the work they are paid for.” I suspect these managers have had “motivation” applied to them in the past through punishment-reward systems and do not wish to inflict the same system on their own team. Thus, they never try and improve the motivation of their team. Why this myth appears to work Managers who don’t believe they can (or should) affect motivation become frustrated when a team member appears de-motivated, quickly losing faith in them. This leads to the person being “managed out” of the team. Soon, the only people left are those that the manager feels are self-motivated (or are too valuable to fire!). The best this type of manager can hope for is to hire motivated people, and then fire them when their motivation drops. A sad approach, indeed. Myth #2: Confusing Motivation and Movement This one is less of a “myth” and more of a “mistake.” Some managers use “motivation” tactics that produce movement and thus confuse the two concepts. In his excellent book, One More Time: How Do We Motivate Employees? Fredrick Herzberg uses the example of training a dog. Please allow me to paraphrase here, but I recommend you read this short, important book. Imagine that you want your dog to sleep on its own dog bed. You might drag it to the bed by the collar, moving the dog forward. Seeing movement, you might feel you have motivated the dog to go to bed, but in reality, you are motivated; the dog is simply moved. The next day you decide to offer the dog a treat to lie on its bed. After spending time training the dog, it lies down when you command it to. Now, you think, I have motivated the dog! You are again mistaken. You are the only one motivated — the dog has simply been conditioned to receive a reward for lying on the bed. You, the master, were the one motivated each time. The dog was moved either by your strength or by its desire to receive a treat. You were motivated — the dog was moved. Some managers make similar attempts to motivate their employees only to find that the employees are moving without motivation. Punishment-reward systems might teach people how to act, but they do not create internal motivation. Why this myth appears to work Though the manager doesn’t understand why it’s happening, the goal IS accomplished. The manager feels good about the recognition they receive, which reinforces this approach to management. The team feels exhausted and confused and is glad the project/sprint is over. However, the team may also feel a sense of accomplishment, celebrating along with their manager, often thanking them for being a “tough boss.” And so, the cycle continues. Myth #3: Motivation through Deadlines I once took over a team of Java programmers who revolted whenever I used the phrase “deadline” with a project. “Deadlines are lies managers tell,” they announced often and with great fervor. I was confused until I learned that their past manager had used the Motivation by Deadline approach, thus causing them to distrust any deadline. A past manager of mine had a sign on his wall which read: “Without a deadline, it’s not a real project.” He believed that deadlines and pressure motivated people. His reasoning was that without a deadline people wouldn’t feel any urgency about completing their work. He positioned the deadline as both a threat and a reward. If you missed the deadline, “there’d be trouble.” If you hit the deadline then you got a “gold star.” Sounds silly, right? This myth combines two common problems: ideas related to a theory called Theory X (more on this later) and infantilizing workers. Theory X proposes that some managers believe that people are inherently lazy and that motivation must thus be applied to them through threat or reward. Infantilizing workers refers to treating workers as though they were children. Think about the earliest experiences most of us have with deadlines: Your parents probably told you that you had to get X done by Y time or experience Z consequence (either a punishment or reward). When I think back on it, this approach it does remind me a bit of kindergarten. How do you feel about it? Deadlines are an important part of managing software projects, and it would be foolish to believe we should never set deadlines, targets, or release dates. Yet, it would also be foolish to believe that a deadline alone can motivate people. At best, arbitrary deadlines move people, not motivate them. Why this myth appears to work When used properly, deadlines represent a business goal that has tangible value. People are wired to create value, and most people enjoy striving to accomplish a goal. Thus, when presented with a deadline, most people assume that the deadline is a realistic goal to create real value. When arbitrary deadlines are given to motivate people, it quickly destroys their motivation. There is little as heartbreaking and demotivating to a team as realizing they worked hard to hit a deadline, only to find the deadline didn’t matter. Or, conversely, working hard but missing a deadline, only to find the deadline didn’t matter. Both are devastating to the team’s motivation and morale. Myth #4: Making work simpler Kevin was planning an important new feature for the product his team worked on. He was excited about the feature and saw what a huge impact it could have on customers. He created an epic for the feature and then decomposed it into twenty-five smaller stories. Within each story, he added the SQL queries and the calculations used. He wrote detailed requirements and acceptance criteria, as well as the function names, field names, and UI element names. He did as much of the hard work as possible to ensure the feature would be built correctly and as quickly as possible. Kevin felt good that he’d taken the time to create robust, detailed requirements. Kevin assigned the project to Bill, their Rails programmer, expecting Bill to deliver the project in record time. Yet, the project moved at a snail’s pace. Bill questioned every decision, asked obvious questions which had been answered in the documentation, and appeared completely demotivated. He appeared more interested in lower-priority projects that had been on the back burner for months, rather than delivering this high-value work. Kevin grew frustrated — after all, he had spent weeks of hard work thinking, designing, and planning the project. Bill had the easy part, he only needed to implement Kevin’s ideas and designs, which were clearly laid out. In frustration Keith exploded, “Bill, why don’t you care about this project?” “It’s not that I don’t care … but it’s just a bunch of code monkey tasks. An intern could do it. Plus, it’s decomposed beyond recognition. It’s like you’ve given me a pile of Legos and instructions to build something, but I can’t envision what we’re building. You’ve taken all the challenging parts out — there’s not much fun stuff left!” Before Henry Ford introduced the assembly line, his cars were built by groups of craftsmen who worked together to create the final product. Mechanics, electricians, upholsterers, painters, and others crafted a car together. It took a group of workers about 12 hours to build a car together. The assembly line changed all this. Ford hired specialists whose job was to simplify the work into discrete pieces that could be assigned to a large number of less-skilled, cheaper workers. This approach to work design, known as job simplification, was key to many of the advances achieved in the industrial revolution. For example, before job simplification, one of Ford’s auto mechanics might be tasked with “installing the engine.” In the new work design, they might be tasked with “tightening 12 bolts to exactly 52 foot-pounds of torque.” This was a huge shift, and craftsmen hated it. Not a big surprise, in hindsight. Why this myth appears to work Sometimes this appears to work, especially when you have inexperienced or unskilled team members. College interns, for example, might move quickly when work is pre-designed for them. People who are learning a new skill also benefit from having steps outlined for them. Yet in the end, the software often fails to achieve the design or project goals and requires significant re-work. I see a tendency for smart managers to attempt to motivate their team by creating simple work that should be “easy” for them to accomplish. I’ve made this mistake myself when I have strong opinions about how work should be done or when I believe my efforts will speed up production. However, after many years I’ve come to see that these attempts reduce motivation and job-satisfaction, thus slowing down the project and decreasing quality. Lastly, I’ve realized that it’s virtually impossible to design a complex system perfectly on paper. Small adjustments and design changes are always necessary along the way to achieve the goal. Don’t fall into the trap of thinking you can create a perfect design. Even if you did, no one would want to build it. What fun is that?

Assembly

BUNCH

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

4 Myths About Programmer Motivation

Too Long; Didn't Read

Companies Mentioned

Marcus Blankenship

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

4 Myths About Programmer Motivation

Too Long; Didn't Read

Companies Mentioned

Marcus Blankenship

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES