How to Motivate a Software Engineering Team Without Using Your “Boss” Card
Editor’s Note: This blog is a takeaway from our podcast, Scaling Software Teams. In our interview with Roger Deetz, VP of Engineering for Springbuk, we discussed how to motivate talented software developers without heavy-handed management tactics. For a full write-up on this episode, check out this blog. You can subscribe to our podcast on iTunes, Google Play, or wherever you get your podcasts.
‍
Roger Deetz was new to leadership. Actually, he technically wasn’t even in leadership, having neither the title nor the budget of someone in a leadership role, but was thrust into it nonetheless.
‍
His company needed to make their software more scalable to prepare the business for future growth. This required modernizing and re-inventing the entire technology stack—a tall order for any engineering team. But this project was further complicated by the fact that Roger was working for a publicly-traded company, and had a relatively small band of programmers dedicated to the rebuild.
‍
This challenge would go on to be one of the most consequential trials of Roger’s career, shaping him into the software leader he is today.
‍
“It was a fantastic technical challenge and professional leadership opportunity,” Roger told us. “Really being able to jump into something like that and not only have to chart a challenging technical course, but also having to lead and execute a project when you don’t really have a team or budget or title. It was all leading by influence and not by mandate.”
‍
How was Roger able to take an undersized group of software engineers and programmers to complete such a massive project?
Here are some lessons from his story:
(Hear our full interview here)
‍
When To Use Your “Boss Card,” And When To Stay Away
According to Stack Overflow’s Global Developer Hiring Landscape, only 12.7% of software engineers are completely satisfied with their job, and 62.1% are open to new opportunities without actively looking for them.
‍
This means that the stakes of your management decisions are incredibly high. But while many managers choose to impose their will by using their “boss card” to push teams, Roger has found his best results come when he uses this strategy sparingly.
‍
He points out that any time your direct report’s primary motivation for accomplishing a task is because you told them to, you have played your boss card. This doesn’t have to mean desk pounding and screaming; in fact, more often than not, your boss card takes the shape of a friendly request.
‍
But that doesn’t mean that’s what your direct report hears.
‍
“You can play the boss card, but you only have, like, two boss cards in your whole deck,” Roger says. “Once you play those, then people get pretty tired of it, so you need to use those sparingly.”
‍
Moments like these commonly occur in environments where priorities change overnight.
‍
Maybe the CEO makes an off-hand comment about page loading speed, and now it’s a three-alarm fire that needs to be resolved tomorrow. Maybe you promise a new feature to sales without consulting with your team first, completely changing the focus of their next sprint.
‍
But no matter the reason, if you can’t effectively explain why something is important, you’re pulling rank when you bring it to your team.
‍
For that reason, Roger recommends that you use this “boss card” as a last resort. By building action items collaboratively and transparently with his team,  he’s able to keep morale high, communication open, and employees retained.
‍
And when you do need to delegate an activity, you should be able to accomplish one of the following:
- Provide enough context to ensure understanding.
- Provide a strong enough positive vision to overcome any potential objections.
‍
If you’ve tried these methods multiple times and are still struggling to get the message across to your software engineering team, the boss card may be necessary, but it should never be a first option.
Motivate Your Software Engineering Team With a Strong Vision
Feeling in the dark about how to motivate your team without using your role power? The good news is that, if you’ve done the work to connect with your team, you likely already have a good gut feeling about what will motivate them to act.
‍
The next step, as Roger notes, is honing and refining how you present your approach.
‍
“You have to sell people on the vision. You have to sell people on the value of what you’re doing,” Roger says. “You have to get them excited about something even if they don’t really know exactly what it is.”
‍
Unfortunately, many engineering leaders struggle with this because it can be antithetical to the rational and analytical methodology by which they govern their code.
‍
Typically, programmers and engineers like to craft specific solutions for specific problems, but when they’re put in leadership positions, they often struggle to articulate the “why” behind a project.
‍
“Particularly within engineering organizations, people are often very focused on solving specific problems,” notes Roger, “so when you’re getting people excited about a vague problem, sometimes that’s a challenge.”
‍
So, how can you provide a strong vision for your team to get them excited about a project?
‍
Using Language And Framing To Provide a Strong Vision
As the boss, your language matters. By communicating well, your team will perceive you as their ally and advocate, working to ensure that they have everything they need to be successful.
‍
How you choose to discuss and frame a problem, therefore, is one of the most important factors in leading your team effectively… but it often goes overlooked.
‍
There are three primary framing tools that you can use to show your team the vision of a project, and none of them require a full view of the project outcome:
‍
How It Impacts Them
- Explain how the project will impact their day-to-day life: “You will have a lot of autonomy and freedom to guide this project in whatever direction you’d like.”
- Explain how the project will help them grow: “This project allows you to team up with Jenn, who I know you really respect. I think working with her will really help you grow your skill set.”
- Explain how the project will impact their career with the organization: “This is a high-profile project and the leadership team will be looking at the key individuals involved for potential advancement opportunities.”
- Explain how the project will impact their career outside of the organization: “This project would really make you stand out when you’re looking for your next job.”
- Explain how the project will impact their wallet: “This project is one of the key proof points I’m planning on using when I go to my boss and ask for budget approval to give you a raise at the end of the year.”
‍
How It Impacts Their Teammates
- Explain how the project will impact the engineering team: “Once we complete this project, we’ll be able to free up the team to work on a roadmap item that they’re excited about.”
- Explain how the project will impact the team most affected: “This new feature will help Jill close the large account that she has been chasing for a year.”
- Explain how the project will impact you: “Successfully completing this project will make it easier for me to advocate for our team in leadership meetings.”
‍
How It Impacts The Organization
- Explain how the project will impact your users: “This improvement is really important to helping our users get as much value out of our software as they can.”
- Explain how the project will impact your growth: “This new feature is going to be a key selling point for our team, which will have a huge impact on our growth in 2020.”
- Explain how the project will impact your bottom line: “This project is going to allow us to increase our gross margins on our sales, meaning more profits, which will ultimately increase your equity.”
‍
Conclusion: Most Software Engineers Need a Healthy Diet of Motivational Forces In Their Work
There is no one-size-fits-all solution as to what will motivate your software team. In fact, you’ll likely need to employ different framing tools from project-to-project, even with the same employee.
‍
Oftentimes, the best way to lead a team is without ever employing the “boss card.” In Roger’s case, he developed his entire management style with no role power to help him motivate his team. This was an asset, not a liability.
“I think the skills that I gained, both technically and leadership-wise, as part of that project are lessons that I’ve carried with me ever since and that I use almost daily.”
‍
If you spend your time focusing on making the members of your team successful by their definition first, they will meet your definition of success in the process.
‍
Are you planning on growing your software team this year?
‍
If so, Woven could be a great solution to help you hire better developers. Request a demo of our software to learn more, and subscribe to the Scaling Software Teams podcast to receive discussions with high-growth software leaders every Monday.
‍