As a developer, designer or other direct contributor to the product creation process, there’s a single principle that drives morale, productivity and motivation:
I feel that I am effectively working on something I find interesting and meaningful in a safe environment.
If these conditions are not at least mostly satisfied, other perks like team lunches, hack days or remote working options become less relevant. Annoyances like noisy open plan offices, frequent interruptions or a long commute have a greater effect.
It is not possible to completely satisfy all of these conditions for all contributors. Some of the items mentioned in the conditions are part of a healthy development process: I don’t recommend allowing every contributor to work on whatever technology they want or ignore QA or code reviews because it means they can work quicker! However, these conditions will help you understand and evaluate the consequences of policy & process decisions you make as a leader.
The Pillars
Let’s break this down:
Effective
The contributor must be able to work without having to frequently pause or context-switch. Things that could cause the contributor to pause include:
- Slow tooling or development environment
- Needing to always ask others for help on a complicated or confusing system
- Lack of direction as to the thing the contributor is trying to change or implement
- Unreliable test environments
- Mandatory process (eg QA) that requires frequent interruptions
When working on a long, complicated or even tedious task, personal momentum is critical to keep the contributor on task. Pauses interrupt that momentum and it becomes very easy to become distracted by unrelated tasks when having to wait for five minutes or more for a process to complete.
An effective contributor is one that feels that the time they spend leads to them making continuous progress on a task.
Interesting
I’ve found this condition to vary significantly between contributors. For some, “interesting” can mean working with the same technology for years, as long as the work is varied, and for others the inverse is true.
The contributor should feel that they are being intellectually challenged by the work they’re doing. This doesn’t need to be a constant: there’s always drudge work, and it’s up to you to make sure it’s spread relatively evenly.
“Bored People Quit” by Rands is a great article on this topic, detailing how to detect whether people are interested in their work and how to effectively manage it.
Meaningful
The contributor should feel that the work they’re doing is going to somehow have a positive effect, somewhere.
This “somewhere” varies, but can include:
- making it easier for people in the company to do their jobs
- increasing the company’s cashflow
- making the world a better place
It is very demoralising to spend weeks or months on a task to have it cancelled or have it be a commercial failure.
Safe
In my opinion this condition is the most critical of the four.
The contributor should feel that they’re working in a place of safety without risk of attack. They should feel that their position is secure, that their contributions aren’t going to be unfairly criticised, and that they’re not going to be personally attacked.
A lack of safety activates something deep in our lizard brains: it becomes almost impossible to remain focused or motivated.
Note that this doesn’t preclude structured criticism or healthy competition, but it’s up to you as a leader to guide your team to do this in a positive way.
An Example
Let’s talk about Bob. Bob’s working on a task to change a button colour from green to blue.
Bob’s spent two weeks on this task because there’s an overcomplicated theming framework underpinning the site’s colours which makes a simple task like this very difficult. Therefore, Bob does not feel effective. The theming framework is a mess of spaghetti code written by a previous developer. It is not interesting to work with. This is the second time Bob has been asked to make a colour change to this component, and he expects that the person asking for the change is going to change their mind again. He does not feel that his work is meaningful. Finally, Bob is being passive-aggressively pestered by his line manager, because how could a simple colour change take two weeks?! Bob does not feel safe.
Bob is unmotivated, unproductive and right now his morale is suffering. How you deal with this depends on the likelihood of this particular situation reoccuring and how difficult it would be to affect change. If this is an isolated incident it might be better to let Bob know about some more interesting & relevant upcoming work. If its a continual problem, you’d need to attack this from two directions: inwards, devoting time to improving the themeing framework, and outwards, setting expectations with managers & product owners regarding the difficulty of making colour changes.
Autonomy
One last thing I’d like to touch on is autonomy. Contributors must feel that they can improve their own environments such that these conditions are better met. For example, a contributor should be able to improve CI reliability & speed to remove a blocker (to improve effectiveness), there should be some capacity for self-selection of interesting or meaningful work, and contributors should be able to move to a team that better fits their personality, allowing them to feel safer.
In conclusion, what I’ve detailed above isn’t a solution — it’s a mechanism for framing morale and motivation issues within your team, allowing you as a leader to make better decisions.