The Importance of Motivation and Self-Efficacy in Thriving Software Teams

What do highly productive software teams, professional athletes, and valedictorians all have in common? You might be surprised to hear that the social science of high achievement tells us it’s not about “talent,” “never messing up,” or even “luck”: people consistently outperform when they are able to stay motivated through challenges. And to do this, we use a secret weapon that cultivates motivation: a powerful sense of self-efficacy.

At Pluralsight Developer Success Lab, we study how the most innovative software teams work, learn, and thrive. We recently asked more than 1,200 developers a series of questions about how teams were doing on four key socio cognitive factors to measure what we call Developer Thriving, and found that it significantly predicts productivity. In my first article, I shared about Developer Agency. In this article we’ll tackle another one of the key factors in our Developer Thriving framework: Motivation & Self Efficacy.

Self-efficacy is one of the most robustly-evidenced theories that psychologists have used to explain how motivational cycles work. On developer teams, we define it as

Whether developers have high levels of self-efficacy in complex work predicts both how they feel about work (confident and excited? Or worried and threatened?) and their planned behaviors (am I going to take action to think deeper when I’m challenged? Or am I switching to another task and giving up on this one?).

The importance of self-efficacy has been widely acknowledged across the social sciences: it’s a powerhouse for behavior change and action, because it helps us to restart and reassess after we get interrupted or confront a challenge. It’s also highly measurable, which is great news for engineering managers that want to ground their management in strong, evidence-based thinking. Self-efficacy has a long history in science, and has been shown to predict successful behavior change and goal achievement in fields as diverse as learning science, health choices, and knowledge work. 

Developers face new and challenging problems every day, so cultivating high self-efficacy is foundational to maintaining software velocity. In our research, developers have told us they need to use new technologies, pivot and re-examine their tasks to deal with sudden emergencies, and maintain focus and energy over projects that take weeks or months longer than expected.

In our research, developers told us that whether or not they felt motivated had a direct impact on what technical work got done. “I would be more motivated if someone said, ‘Oh wow! Nobody had gotten it done, that’s so amazing.’ I would be willing to pick up something again that was buggy or stuck because I know that I am being appreciated for it,” one individual contributor noted. And keeping their teams motivated was also something that managers took seriously as their responsibility.

However, managers also struggled to know how to create motivation. One manager in our qualitative focus groups said,

Luckily, by understanding and focusing on increasing self-efficacy, engineering managers have a science-backed way to achieve motivation. One thing that helps people is to see many examples of problem-solving happening in real time. Code reviews or pair programming sessions where developers share and explain how they worked through a blocker can be a huge lift to self-efficacy. 

Most impactfully, when developers have the chance to share and scale a previous win into new work, this can be a huge boost to their self-efficacy and their future motivation. Managers can trigger this process by encouraging developers to break down new and complex problems to smaller, more familiar, tasks, and celebrating those wins. Even just seeing many examples of problem-solving happening in real time can boost self-efficacy. Another boost to self-efficacy is getting to draw from past positive experiences to face a new challenge. Engineering managers can encourage a practice of sharing “best practices from past teams” or learning sessions about the industry at large.  

Engineering managers can become “motivation champions” for their teams by looking for opportunities like these to lift self-efficacy. In our Developer Thriving study, developers shared examples of things that increased their self-efficacy: giving junior developers thoughtful “onboarding plans” that include attainable “wins”, having unexpected problem-solving celebrated in a team setting, and building “reflection points” into a software team’s rituals that include sharing openly about how unexpected frictions were dealt with. 

From our research, developers also told us about many barriers to self-efficacy. Developers mentioned feeling derailed and demotivated when they did not have a consistent cadence of check-ins with their managers, and felt they needed to constantly “restart” explaining their work. They also shared that when it felt like leadership did not value or encourage knowledge sharing, this could be profoundly demotivating.  

One powerful skill that developers with high self-efficacy have is the ability to reflect on, rather than freeze, in the face of barriers to learning. Because self-efficacy helps us to believe we do have the skills to overcome challenge, developers with high self-efficacy are more likely to spend time finding new solutions, less likely to believe a small mistake means total failure, and don’t get side-tracked by something that doesn’t go to plan.

Over the years, social science has learned a lot about motivation. Engineering managers and leaders can use this to improve developers’ experiences, and subsequently the quality of engineering work. For example, we know that many people overestimate the cost of achieving something new, and struggle to re-start after a failure because of this. Developers may underestimate or overestimate the length of time it will take to learn a new skill and apply it to their current technology. Here, thoughtful feedback practices on developer teams can be a critical way to increase motivation and success. For example, in our research we found that developers were more productive when their teams consistently used software metrics to discuss their processes and recalibrate their own time estimates about work. As a bonus, this gives engineering managers the power to notice and celebrate when developers accomplish work faster than planned! 

Self-efficacy research in psychology also tells us that we need to pay attention to the moments after we finish tasks. In our research, we saw that many teams placed a high priority on planning at the beginning of a project, but often failed to carve out time for reflection and synthesis after a project. If we’re always moving from project to project without spending time celebrating the fact that we did something hard, we might be losing out on a critical way to motivate our teams. And while software teams often celebrate project deliveries, we hear in our research that many developers feel like their personal learning journeys are rarely celebrated on a team. This is especially meaningful when developers encounter and overcome unexpected friction. One developer in our research told us that getting feedback after something was unexpectedly difficult and challenging was even more impactful than getting feedback for something that “everyone thought was a big deal.” 

When engineering managers become “motivation champions,” it can have a lifelong impact on developers’ careers. Senior developers in our research shared that moments when someone helped them develop self-efficacy were turning points in their paths to becoming game-changing contributors, tech leads, and stepping into engineering leadership themselves. Sharing about an early career experience, one senior developer said: “The best manager I had enabled me to solve the problem my way, and that taught me that I could write code…I really credit him for my whole career.”