Mazlow’s pyramid applied to developers
Approaching the mid 40s, I have now managed a quite significant number of developers, directly or indirectly, by also observing many development organizations as an external consultant.
Every manager in the development business will also tell you that you don’t manage developers like you manage other people. There are very good articles about it on the net, and I started this article by making a simple compilation of those developer motivators, also to make sure I do not forget a key one.
At the same time, every HR consultant will also explain you that managing people is a discipline you can learn, and there are many theories and best practices about it. Then, those theories should apply to developers, as they are also human beings. So how can these two professionals be right at the same time?
The answer I came up with is that, using the same theory, it could be interesting to just consider that needs and motivators are expressed a different way for developers. This gave me the idea to apply the good old Mazlow’s pyramid to developers… by tweaking it a little bit to transpose the needs at a slightly higher abstraction level.
As a reminder, here is what the Mazlow’s pyramid is all about. It explains that motivation is a kind of hierarchy, and you can’t jump at the higher level if the needs below are not fulfilled. Please HR professionals, don’t blame me if this is too simplistic or if you are a fan of another theory, this one has the merit to be quite easily understandable.
Putting my compilation of all the key motivation elements I selected as important for the developers, here is how I would transpose it for developers.
1. Give developers the right tools to do their job
Being equipped with the proper level of hardware and tooling is as critical as breathing for a developer. If you don’t give them the right tools to do their job, not only will you lose precious hours of productivity, but don’t expect to go anywhere higher on the pyramid. Giving undersized hardware to developers or putting them in noisy open spaces is also a sign that you don’t value their job.
2. Refrain from excessive process constraint
Development is a job that requires some level of creativity (which is sometimes also an issue when not used at the right place but this is another story I will develop in another post). Being creative is not compatible with heavy process constraints. You cannot find a solution to a problem by just planning every second of your time or being disturbed by an excessive number of meetings.
3. Reduce their inherited technical constraints as much as possible
Systems live longer as expected. As a consequence, there are often some level of technical constraints in your project: an old database schema that cannot be changed, a poorly-designed legacy system that adds some rigidity or a customer that imposes usage of some specific technology. The more of this you have, the less comfortable the developer will be. Reduce those constraints as much as you can. One key to this is to really makes this a goal, even if you take a multi-step approach to make it compatible with your business. Keeping legacy constraints other time is very costly in terms of maintenance anyway.
4. Ensure the work they do will be used
It might seem obvious, but it is not. Since there is a high level of project failures in the software industry, developers that have already faced a situation where all their code was dropped might not feel safe as some issues arise on the project. And do you know of any projects where no issues popped up? The best way to do this is of course to repeatedly deliver your projects by correctly managing them. Implementing continuous delivery through agile methods is also a guarantee not to have a multi-month tunnel effect that can lead to a large drop of code base, which is not only a financial loss but a huge motivation killer.
5. Compensate them at the appropriate level
Compensation is clearly not the ultimate goal of real developers. Still, it is of course an unavoidable need as for any human being on earth. You can work much better when your personal requirements are fulfilled with some increasing level of comfort at home. Making sure there is some regular progress in compensation as the skills and the achievements grow is also very important. I personally position it at "Safety" level of the Mazlow pyramids for developers.
6. Provide reasonable career path visibility
Equally, developers will feel safe if they see their job as sustainable, and even better, as providing a path where they can climb some steps. They are not striving for career in the sense of managing more and more people, but they for sure value the titles that recognize their knowledge and expertise, as well as their ability to design complex systems or to mentor others. This is why all successful software companies have titles such as "distinguished engineers" or "technical fellows".
7. Share the big picture
Once the above needs are fulfilled, you might be able to climb at the "belonging" level of the pyramid by creating a team effect. One key element of creating the belonging feeling is by sharing the big picture of the project. Don’t expect too much from developers if you just give them the tasks one after the other without giving any meaning to what they do. It is very bad for motivating teams, not to mention the fact that you will probably lose opportunities to improve the overall design.
8. Manage them through field people
This is a very important one. A developer will not find legitimate to be managed by someone who never was a developer himself and cannot fully understand their job. Considering the nature of software development, I think it normal. It is quite impossible to understand the issues developer faces if you have not done the job before. A good development manager does not need to have developed for 20 years, but he (or she) should at least have developed for some years to make the right decisions when they become necessary.
9. Favor technical discussions between peers
The more your developers discuss about technical issues and solutions, the better. Not only it will make the team more efficient and skilled over time, but it will also contribute to this belonging feeling that increases developer satisfaction and motivation.
10. Make sure they always learn new things
This one is not always easy to achieve at every moment, depending on your business constraints. Fortunately – for this point because it can also be a real thorn in the side for your budget – technology evolves quite fast. So if you proactively work on removing the legacy constraints and provide enough guidance to developers, there is certainly room for learning new things on all projects that I have seen.
11. Recognize good work
It might seem obvious but people often forget about it. Everybody needs to be recognized. Depending on the nature of the people, you can do it publicly, or more intimately, but tell the developers you are happy when they achieved a good job or when they worked hard to meet a milestone. Simple recognition gifts or even just a few words like "Good job !" can make a difference. And there are moments that clearly need to be celebrated collectively.
12. Encourage external contribution to communities
Beyond the technical exchanges inside the group or the company, you might encourage your people to be active in the community. For younger folks, it might mean more listening than contributing, but it is always a good idea to do so, as it also gives them ‘icons’. For more senior people, if you have very good ones, give them time to contribute and get recognized in the community, especially if they have skills to write about technology or to speak at conferences. It will certainly have some positive impact on your business anyway.
13. Make them accountable from A to Z
Reaching the self-actualization level of the pyramid should be a goal for development people. It is unlikely to get reached in the early days of your career, but having the big picture in mind is a good motivation. One sign that you are getting there is that you start to be fully accountable of what you deliver. This might be high pressure but it is also the counterpart of getting maximum freedom as per next point.
14. Put them in control to use their creativity
Developers are at the highest degree of satisfaction when they can control every decision on the project. Being able to make all architecture and tooling choices is very satisfactory. It goes with the accountability of point 1, which can be dangerous if you don’t have all the skills, but this is what all senior developers should strive for. Once you get there, you can express all your creativity to find the most relevant solutions to your business scenarios. As a manager, you have to portray this target to developers to motivate them and keep your best people at this level on freedom.
15. Contribute to something big (or cool)
The ultimate level is reached when, additionally, what you have built is "big", or possibly more important for developers, "cool". Cool is hard to define as it can take several form depending on your profile and sensitivity, but it may as well be the resolution of a tricky issue as the contribution to a project that has worldwide visibility or usage.
Listing all those key elements to motivate developers, here is the developer version of Mazlow’s pyramid I was able to draw.
As usual, feel free to comment.