As an engineering manager, how do you motivate developers?
Recently I read a textbook named Organizational Behaviors (17ed)(Referred as OB below). The book presents all the latest scientific research on two general topics: 1) how/why people in an organization behave in a certain way and 2) what it meant for managers.
The theories about employee motivation apply to software developers, too! In this article, I will talk about the application of some theories on software developers, and what are unique about developers, and what are some implications for technical managers.
Money?
Self-Determination Theory (Chapter 7, OB) is a theory “concerned with the beneficial effects of intrinsic motivation and the harmful effects of extrinsic motivation.”
The book presents a vivid example: Marcia used to work as a volunteer in an organization and felt happy, but when she was hired as full-time and got paid $11/hour, she found it less fun, even though it was still the same work.
To some extent, I can relate to that. When extrinsic rewards exist, it reduces the intrinsic interests in a task. Put it another way, when you are paid, it becomes less like something you want to do, but what you have to do.
The theory suggests, when we want to use extrinsic rewards (e.g., money) to motivate employees, we need to be extra careful. Managers don’t want to make previously enjoyable task become an obligation. If there’s an alternative to promote the intrinsic interests about the task, that’s more preferred and more self-sustaining.
For developers, what should be the right motivation?
Two kinds of developers I experienced: 1) those who simply code for money, and 2) others who do for something else, e.g., improving problem-solving skills, curiosity, personal growth.
For the 1) type of developers, as long as you pay them, they may finish the job, but they may not completely happy.
Coding is like writing. Writing good code exercises brain muscles and requires lots of energy.
For most coding tasks, you can always choose the easier path and produces a program that seemingly works. But it may not be the most elegant solution.
I am not saying developers won’t take shortcuts. Good developers take shortcuts because they are aware of them, and willing to make the trade-offs under the resource limits (time, personnel, budget).
Bad developers take shortcuts because they are lazy (mentally), and not willing to hold the delivery to a higher standard. To them, code is a way to bring bread and butter home. After work, they can forget about them. No need to overthink them.
No motivation to improve the craftmanship.
Writing code is like writing essay. It is a lonely task, and takes willpower to plan, ponder, and battle with the complexity to accomplish elegant structure, and easily-understandable code. It requires a lot of effort to learn the craftmanship.
Without strong motivation, you struggle and feel exhausted by all the brain movements.
My own experience tells me the 2) type of developers have better chances of higher achievements in the long term. They care about the software craftsmanship, keep learning new materials and reading technical articles, probably write code as hobby.
Promotion Focus vs. Prevention Focus
This topic is about how people pursue goals.
When pursuing a goal, some people regulate their behaviours and thoughts differently than others. Regulatory Focus Theory classifies the focuses into two categories: promotion vs prevention. Quote from the book:
Those with a promotion focus strive for advancement and accomplishment and approach conditions that move them closer toward desired goals…Those with a prevention focus strive to fulfill duties and obligations and avoid conditions that pull them away from desired goals.
Why are we talking about this? Because I find it applicable to developers!
When being a dev, I found myself too often being in prevention-focus mode:
- I want to avoid making all the bugs or mistakes I made before
- I don’t want to bring down production servers, so I need to be extra careful when running release tasks
- I always want to improve my design, and write more elegant code, and I kept doubting myself when I couldn’t think of better way to solve this besides an ugly hack…
- …
Being in such a prevention-focus mode is stressful.
The book says that such a mindset can help certain tasks, like safety related tasks. But the alternative, promotion focus mode, is generally considered to help achieve higher performance.
As managers, there are a few things that can help:
- Help devs in prevention mode to set attainable goals.
- Reduce distractions, so that they can focus better
- Reframe the tasks from negative, prevention-focused to more positive narratives, and place your appreciation when they accomplish the goals.
One specific thing to devs is that, issues board is depressing! I found that looking at the issue board alone can easily lower the morale, because it lists all the problems, instead of achievements.
As a tool, an issues board is useful to keep track of progress, but managers need to be aware of the downside. Not every dev is good at delivering the standup speech in an encouraging way, with all the technical details in mind. As managers, we should find the right positive spin and bring up the morale from time to time. And this is quite hard.
Unfortunately, I don’t have any suggestions on this. Currently I’m observing and learning all I can from someone else.
In this article, I only scratch the surface of developer behaviours. Hopefully, it can convince you that it’s a topic worth of thinking about, and help you become a better engineering manager or technical leader.
Thank you for your read!
