You have 1 article left to read this month before you need to register a free LeadDev.com account.
Don’t overlook the importance of self-efficacy and sustaining motivation through challenges as qualities of thriving software development teams.
What do highly productive software teams, professional athletes, and valedictorians all have in common? The social science of high achievement tells us it’s not about “talent,” “never messing up,” or even “luck.” Instead, people consistently outperform when they are able to stay motivated through challenges. To do this, we use a secret weapon that cultivates motivation: a powerful sense of self-efficacy.
At Pluralsight Flow’s 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 their teams were doing on four key sociocognitive factors to measure what we call Developer Thriving. We subsequently found that this measure significantly predicts productivity. We have already delved into the impact developer agency has on productivity, now let’s move on to 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 having a high level of belief that you can solve coding problems on a daily basis. 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, from thinking more deeply about a challenge to giving up and moving on to something different.
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 to restart and reassess after being interrupted or confronting 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. It has been shown to predict successful behavior change and goal achievement in fields as diverse as learning science, health choices, and knowledge work.
What does self-efficacy look like on software teams?
Developers face new and challenging problems every day. 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, all while maintaining focus and energy for 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.
Keeping their teams motivated was also a responsibility that managers took seriously. However, managers also struggled to know how to create motivation. One manager in our focus groups said, “It’s easy to say exactly what [impact the whole group will have], but it’s really difficult to get people motivated to do [their individual task].”
Increasing self-efficacy on your team
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 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 into smaller, more familiar tasks, and celebrating those wins. Even just seeing many examples of problem-solving 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 by running learning sessions about the industry at large.
Engineering managers can become motivation champions for their teams by looking for opportunities to lift self-efficacy. Some examples are: 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 which include sharing openly about how unexpected frictions were dealt with.
Developers also told us about 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 said it was profoundly demotivating when it felt like leadership did not value or encourage knowledge sharing.
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 build belief in the skills to overcome challenges, 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 sidetracked by something that doesn’t go to plan. Across an entire engineering organization, all of these small human moments of motivational problem-solving are what create significant software velocity.
Don’t miss high-value motivation moments
Over the years, social science has learned a lot about motivation. Engineering 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 restart after a failure. 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. 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 demands that we pay attention to the moments after finishing 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 you’re always moving from project to project without spending time to celebrate the fact that you did something hard, you might be losing out on a critical way to motivate 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 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 said that moments when someone helped them develop greater self-efficacy were turning points in their paths to becoming game-changing contributors, tech leads, and stepping into engineering leadership themselves.
“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,” one developer told us.
