Motivation leads to higher performance and satisfaction in the job. But how can we motivate a team of software developers? Sadly, there are common misconceptions about motivation that do more harm than good. Fortunately, science has already discovered the motivators that work: autonomy, mastery, and purpose. This post presents these three pillars of motivation and concrete actions to implement them in software development environments.

TL;DR

• Contingent, expected, “if-then” rewards don’t work in creative, non-routine jobs like software development.
  • They kill intrinsic motivation, reduce creativity, encourage short-term thinking, shortcuts, cheating, egoistic behavior, and lead to poor performance in the long run.
  • Avoiding “if-then” rewards means that the reward should not be announced up front and therefore be expected: “If you do this, then you’ll get that”.
• The three pillars of intrinsic motivation are autonomy, mastery, and purpose.
• Autonomy: Ideally, the developer has the freedom to choose their tasks, the technique to solve the task, the time when to solve the task and the team in which they like to work. However, in reality, there should be some restrictions applied to avoid chaos.
• Mastery: The developer has the opportunity to learn something new and to constantly become better at something that matters.
• Purpose: The developer’s work has an impact and changes something for the better.
• For each pillar, there are many actions to implement them in a software development environment.
• Motivation is individual. Ask the developer about their motivation in one-on-one meetings.

External, Expected Rewards Harm Motivation

“If-Then” external motivators do more harm than good. Let’s take a look at some examples:

“Tim, if you get familiar with reactive programming and present your findings to your colleagues, you’ll receive a bonus.”

Usually, most developers like Tim have the internal drive to learn something new. What happens if you try to motivate Tim with money? You crash Tim’s internal motivation. It’s likely that he learns reactive programming only good enough to talk 30 minutes about it, which is sufficient to fulfill his goal. So the reward reduces his performance and output. Moreover, the next time, you ask Tim to learn something new, he expects a reward again. Otherwise, he won’t do it (good enough).

“Paul, you’ll get a bonus if you successfully complete the RedHat certification.”

Let’s assume that Paul’s team has an important shipping deadline. However, Paul decided to work on his RedHat certification instead of helping the team to meet the deadline, because he has only a few days left to fulfill the certification and receive the reward. His individual goal conflicted with the team goal. The external reward fostered egoistic behavior and led to conflicts in the team.

“Lea, if you ship the feature XY during the next month, you’ll receive a bonus.”

What could happen? Lea might sacrifice code quality and test coverage to meet the deadline and to get the bonus. Needless to say, that this will cost a lot in the long run as the software will be more error-prone and will be harder to understand and to maintain. The external reward has encouraged her to take shortcuts and led to short-term thinking.

Moreover, Lea’s focus might become so narrowed to the shipping deadline that she oversees other ways that might lead to a better solution for the feature. The reward curbed her creativity.

“James, if the conversion numbers of your service increase by 5 %, I’ll consider you for a promotion.”

James might be tempted to change the reporting of the conversion number in a way that makes him look better. That’s cheating.

The bottom line is that carrots and sticks don’t work well in jobs like software development that require creativity and non-routine work. They decrease the performance in the long-run, crush creativity, kill internal motivation, make addictive and encourage egoism, cheating, short-term thinking, and unethical behavior.

It’s important to state that the mentioned points have been verified by science in countless experiments and research initiatives. If you like to learn more about this, I highly recommend Daniel Pink’s TED Talk ‘The puzzle of motivation’ as a starting point and his book Drive.

At Spreadshirt, we once had individual, quarterly goals for each developer. On accomplishment, they received a monetary bonus. Although I never experienced the above situations personally, I believe that they are realistic. But I definitely felt that the goals clearly influenced the priority of me and my colleagues. Achieving the individual goals could easily become more important than the one of the team and the company. I even saw ill colleagues dragging themselves to work just to hold a presentation which was made a condition for their quarterly goal. Moreover, making up those quarterly goals has been an annoying and time-consuming task. Besides, having to come up with those tasks every quarter again and again led to pointless goals (“Do what you would do anyway”). Moreover, the personal tasks just distracted us and removed the focus from the actual work. Fortunately, we rejected those individual goals and the whole bonus system a couple of years ago.

Autonomy

Autonomy is the first pillar of motivation. First an foremost, people are motivated if they can choose their tasks and decide how to solve them. But autonomy has even more aspects. They are called the four T’s:

• Task. Decide on which task to work on.
• Technique. Decide how to solve a task.
• Time. Decide when to work on a task.
• Team. Decide with whom to work on a task.

So far so good. But how can we implement autonomy in a software development organization and team?

• Being in a self-organizing team. This term subsumes many very important team characteristics which also affect the motivation of each developer. Some are:
  • Select one’s favorite tasks. Every developer can take the task from the task board that they like most. There is no assignment by the team lead. This leads to a sense of ownership and commitment.
  • The team is empowered to work on all aspect of their application. This includes tests, build, delivery, releasing, operations and monitoring. This relates to DevOps.
  • Freedom of Technique (including Technology).
    • A developer should have a reasonable amount of freedom on how they solve a task. First and foremost, this can mean things on the code level (class design, algorithms) or some aspects of the UI. But this can also include the used libraries, frameworks and the language. For instance, I experienced a huge motivation boost when we decided to introduce Kotlin at Spreadshirt.
    • BUT unrestricted freedom is dangerous. It can lead to a zoo of technologies and ecosystems that can’t be maintained anymore. Having a consistent technology stack improves the productivity, eases operations and employees can change the team more easily. In the end, it’s a trade-off between motivation/innovation/better solutions on the one side and productivity/maintainability/aligned operations on the other side. At Spreadshirt, we agreed on the following compromise: Each team can use their own libraries and frameworks as long as they stick to the JVM ecosystem. Greater changes in the technology stack (using a new language like Kotlin or a completely new ecosystem like Ruby, Go or Python) are possible but need to be discussed. Moreover, we run quarterly “Hacking and Innovation Days”, where the developers can try new things. This is important to satisfy everyone’s urge to try something new without affecting productive code.
    • Finally, it’s important to highlight that technology decision should be team decisions. Everyone should commit to a certain decision because potentially everyone has to maintain it.
  • No Micromanagement. The team lead should not try to control and check every detail. They should let go, delegate tasks and trust that every member will come up with good solutions on their own.
  • Everyone is Involved in Design Decisions. Every team member should be involved when it comes to decisions about design and architecture. We usually hold a meeting when we have to come up with a database schema, architecture, design decisions or bigger refactorings in our software. After my experience, the outcome of those meetings is great and much better than the solution of a single developer. Swarm intelligence impresses me every time! Some important rules for the moderator of those meetings are:
    • This meeting isn’t about the senior principal software architect presenting their solution while the others are listening reverentially. Architecture and design is everyone’s task and everyone can and should contribute.
    • Asking questions instead of presenting your solution. It’s very interesting to hear other approaches and ideas that have not been influenced by your solution. At the end, you can still propose your solution.
    • Introverts also have good and sometimes even better ideas. Ask them proactively about their opinion.
• Flexible working hours. Fortunately, this is already standard in most software development companies - for a good reason.
• Noncontrolling language. The phrasing is crucial. This applies not only for feedback in code reviews but also for the daily communication within a team. Try to avoid phrases that contain “must” or “should”. Instead, use “think about …” or “have you considered …”. Again, ask questions.

Mastery

Mastery is about getting better at something that matters.

There are several things an organization can do to support a developer’s mastery:

• Fixed Time for Hacking and Innovation. Many companies have different names for this. They call it “FedEx Day” (Atlassian), “20 % time” (Google, Atlassian), “4+1” (itemis, codecentric), “Hacking and Innovation Days” (Spreadshirt), but they mean the same: Giving the developers time to try new ideas and innovate without any restrictions. At Spreadshirt, those days are holy and much fun. We often came up with very cool ideas that make it into production. At Google, Gmail and Google News are outcomes of those hacking days. So it’s not only about mastery and motivation but can also generate great innovations with business value. The frequency of those hacking days varies from 20 % (one day of the week) to quarterly events. For the start, consider to start with two days each quarter and see how it works.
• Conferences. Allow your developers to go to conferences. At Spreadshirt, every developer is allowed to attend a conference once a year. Additionally, support them, if they like to hold a talk at a conference.
• Internships in other teams. At Spreadshirt, a developer can make an “internship” in other teams for one or two weeks. I can’t highlight enough the value of those internships: It’s so interesting to see how other teams work, what are their processes, what are their technologies and solutions and what are the social dynamics. And the knowledge exchange works in both directions. I also experienced an stronger social bond across the teams after such internships.
• Internal Conferences. Another instrument to knowledge exchange within the IT department are internal conferences. Our “conferences” are called “DevDay” and take about 5 hours and consist of 20 min talks in two parallel tracks. Every developer can contribute a talk. A collective lunch for “networking” closes the conference. Our experience is great: It’s so interesting to see what other teams are working on and what are their solutions and experience.
• Task-Shifting. Do the same stuff over and over again is boring. You stop to improve your skills. So it’s a good idea to let the task rotate within your team even if it takes longer at the beginning. Moreover, you keep capable of acting in case of absences of certain team members. An extreme form of this is shifting whole developers between the teams.
• Provide magazines and books.
• Allow attendance of online courses and webinars.

Purpose

Purpose is about working at something that matters and changes something (in the world, business, organization, community or team) for good. Doing meaningful work is motivating.

• Visibility of progress, success, and impact.
  • Kanban Boards and Scrum Task Boards are great tools to visualize the progress of work. It’s a satisfying feeling to move a ticket from “In Progress” to “Done” and to see one’s contribution to the team’s work. It’s also a good feeling if all tasks are eventually end up in the “Done” column at the end of a sprint.
  • A Burndown Chart is also a great tool to visualize progress and the impact of each team member’s work.
  • Sprint Review. Presenting the development progress to the customer, stakeholders or users is also a good point where progress becomes visible.
  • Metrics, Logs. A developer put a lot of effort into optimizing the performance of a remote call or an algorithm? It’s so rewarding if there are metrics (e.g. in Grafana) showing the improvement in terms of shorter response times and higher throughput. At Spreadshirt, we have Mini-PCs with multiple monitors showing Grafana dashboards in each office.
  • Statistics, Reports, Live-Ticker. The same applies to domain-specific reports and statistics (conversion numbers, order reports, throughput). For instance, in our current project, we compare the decision quality of our application with the one of humans. It was so motivating for us to see the statistics of our applications becoming better and better over the time. Another example is our Live-Ticker, a small web app that shows the latest decisions of our application. It’s so cool to see our application doing its job.
• Appreciation. Usually, each developer is doing a good job and the team is recognizing it. But often, we don’t express our appreciation. That’s sad because praising doesn’t hurt you, but could mean a lot to the praised developer and improve the interpersonal relationships. I believe that appreciation is one of the most powerful instruments for motivation. But there are some gotchas:
  • Be precise and personal in your feedback. Don’t: “You all did a good job”. Better: “Tim, your improvements to the algorithms significantly speeds up our response times; Well done!”
  • Be situative. Give feedback right in the situation where the effort takes effect.
  • Don’t praise inflationary. This weakens the effect.
  • Don’t make praising become an award ceremony. This might lead to envy and frustrated developers. When in doubt, prefer giving feedback in private.
  • Despite the daily working time in the office and one-on-one meetings, there are other possibilities to say when something went well like the sprint retrospective meeting or the daily standup.
• Everyone is Involved in Design Decisions. This point is important for autonomy, but also for supporting purpose. In a design meeting, every team members hopefully understand why the application is developed in this or the other way.
• Redirect positive feedback to the team. Positive feedback from stakeholders, customers, users or the C-level is often expressed to the product owner or the team lead. It’s very important to redirect this rewarding feedback to the whole team: Forward E-Mails, quote a user’s praise in the daily standup or copy it into the team chat. It’s so simple but powerful. In the past, I often saw team members proudly remembering those praise.
• User Story Mapping. At the start of a new application or functionality, we use User Story Mapping to discover the user’s journey through the application and to prioritize the features. This helps all developers to get a common understanding of what needs to be done and the benefit of each feature for the user.
• Direct Contact to Users and Stakeholders. That’s a tricky one. Having too much contact with users and stakeholders can be exhausting and too time-consuming for a developer. No developer likes endless meetings with stakeholders. Usually, this is the task of the product owner. However, talking to them directly from time to time makes the developer see that their work is really easing the user’s life and is making them happy. This is a rewarding experience.
• Highlight everyone’s contribution to the team success. Every developer is contributing to the success of a team. Giving expression to this contributions doesn’t hurt you but mean a lot to the developer. There are several opportunities for this: the daily standup, the sprint review, the sprint retro or just at any time. And don’t focus on the tasks with “impressive” output like frontend tasks. Automating the delivery pipeline, increasing the test coverage or improving the code quality via refactorings are valuable efforts that ease the life of the whole team and therefore deserve praise.
• Celebrate success. Reaching an important milestone, shipping a new feature or simply having an anniversary can be good opportunities to step back and look back at what the team has achieved. Celebrations increase the awareness of achievements. So take your time, write an e-mail to all colleagues and invite them to some popcorn, beer or ice cream in your office.
• Financial Safety. If you don’t pay a developer enough, he will question the reason for going to work every day. Mind, that the highest paid developers are not the most motivated ones. Money doesn’t motivate. But lacking money can demotivate. So it’s about creating a monetary baseline to get the topic “money” off the table.
• The definition of Product/Project Vision, Sprint Goals, Milestones are a good mean to express purpose explicitly.
• Open Source Contribution is motivating as it serves a higher purpose than fulfilling business requirements. It’s about giving something back to the community and helping others. If a developer has created something cool, suggest to open-source it on GitHub. This way, others can benefit, provide feedback and praise and may even contribute. This is motivating and can improve the company’s reputation as an attractive employer.

Is My Team Motivated?

Ask them. One-on-one meetings are a good opportunity to find out what motivates a developer. Keep in mind that motivation is individual - every human has different demands and motivators. You can start with the following questions:

• Autonomy: Are you able to suggest your own ideas? Can you realize them?
• Mastery: Do you believe that you can improve your skills here (hard skills, soft skills)?
• Purpose: Do you believe that your work changes something for good?

These Findings are Proven by Science

The facts that external motivators don’t work and that autonomy, mastery, and purpose lead to motivation are proven by science a long time ago. If you like to learn more about motivation in general, I highly recommend Daniel Pink’s TED Talk ‘The puzzle of motivation’ and his book Drive.

Just to be clear: I collected the concrete actions supporting autonomy, mastery, and purpose for software development based on my experience. I haven’t scientifically proven them.

Your Experience Matters

What is your opinion about motivation in software development? What motivates and demotivates you? Does your company do a good job in motivating its staff? Drop a comment below if you like.