Getting in before the pedants: the droid's name was R5-D4. So he wasn't an R2 unit... but Luke says R2 in the scene. Yes, it grates on me every time like fingernails on a chalkboard.
This throwaway line in Star Wars has carried me through so many things I didn't feel like doing but needed to!
Same, R5, same.
But this blog isn't about Star Wars... here on the Adventures of Blink my topic of choice is the community of Software Developers! So what we're focusing on today is the diagnosis of R5's problems: Bad Motivators.
Highly Motivated
I don't know how many devs you've met in your travels. Personally, I've met quite a lot! And it would be fair to generalize and say that this is one of the most motivated groups of people I know - devs are the kind of folks who just go get things done. They have opinions and they have the tools and talent to inject those opinions into reality.
So when a group is generalized... maybe even stereotyped... as being highly motivated, it should sound many, many alarm bells if you find them listless and disengaged. Following my last post's look at Developer Experience, I thought it would be good to look at some things that might cause devs to have a "bad motivator".
Excessive Approval Gates
Imagine designing and building a complex system that's going to be a primary revenue driver for your company.
Now imagine that it malfunctions, and everyone's in panic mode trying to get it fixed. We're losing money by the second! We need this thing back online YESTERDAY, if not sooner!
Now imagine you've fixed it, but you can't find the VP of ThumbTwiddling or whatever to sign off on an emergency change to Production.
A software engineer is likely to be outright offended by this. I built this system. I know everything about how it works. I know the risks, I know the costs of not acting, I know how easy it is to get back to a working state. But I have to wait for this VP (who, if they've ever written code before, probably did so 25 years ago) to "bless" my move so I can solve the problem and get the money flowing again. It's absurd, and nothing will suck the joy out of developing software faster than this.
Corollary: "Approvals for Awareness"
I've heard this debated in management circles: "This platform team needs awareness that someone's making a change to a device on their platform. They should have to approve all changes!"
No. No, they shouldn't. "Awareness" is not a reason to stop the flow of work and wait for someone to click a button to sign off. Send them a text, or an email, or a Slack message... but DON'T force an approval gate for this.
Let's talk for just a second about why you think that approval gate needs to be there...
- If they approve it, we have documented evidence they were aware of the change.
- We want that evidence documented for political purposes, in the event of an error in the change process. It's about "providing air cover".
- Besides all that, you're also actively slowing the ability to get a change made.
So to summarize: we are actively discouraging psychological safety by making our team slower to market. I don't know what management books you've been reading, but... somebody gave you some BAD advice, bruh.
(Unexplained) Rules
"It's company policy to do $THING".
My friends: This is not an explanation.
Software Engineers function well in an environment where there are rules. Heck, they spend a lot of their time and energy building places where rules are rigidly defined and followed.
So it's not that they hate to follow rules... it's that they're accustomed to understanding the why. When you present a rule or policy, you absolutely MUST be prepared to explain why the rule exists... or at least be able to direct them to someone who can.
If you can't, your enforcement of a company policy is going to feel punitive and petty.
Oh, and remember: In the moment, you think you can soften the blow by expressing your distaste for the policy as you enforce it. It's a highly-risky roll of the dice... because "explaining that you hate this while simultaneously enforcing it" can show your own lack of empowerment. If you want your team's autonomy and sense of ownership and empowerment to grow, be decisive. Either enforce the policy with no waffling, or actively go and get some "why" to share with the team.
Meeting Culture
There's an immense amount of research available on the negative effects of disruption on productivity. Software engineers often have work that requires deep focus to complete... and then we ask them to attend meeting after meeting after meeting... and then we want to know why they don't get the work done.
I have personally attended standups with dev teams where every single person on the team stated "I feel like I accomplished nothing yesterday because of the meetings that trickled into the schedule." These are folks who are passionate about their work. They're high performers. They're doing critical work that they're excited about. And guess what? They feel like they didn't contribute because they kept getting interrupted.
Do you know what happens to a highly motivated person who's denied the ability to focus? BURNOUT. They become a listless zombie, just shambling through their day and hoping it all ends soon. You took a high performer and turned them into an empty chair. PROTECT THEIR SCHEDULES.
Insincere Acknowledgement
Now hear this: It is possible to reward your team incorrectly, and it will backfire on you.
The shorthand version of this is the team that pulls all-nighters and weekend work for a month and gets rewarded with a pizza party... but it can take other forms too. We could debate all the whithertos and whyfores, but the summary of it all is really simple: lead with sincerity. If you're rewarding the team, be genuine about it. Do what you can to ensure your team feels appreciated and they'll naturally exceed expectations.
Feeling "Managed"
Scenario:
Your high-performing team has an idea that could really help the company. They come together as a team, build out their idea, and launch it.
Management comes in and does what's (unaffectionately) known as the "swoop-and-poop". The new solution has to be made to look like our other solutions, so modifications are made that more or less completely eliminate the benefits of the team's new idea. In the name of "making it operational", management has completely gutted the new idea and it's now devoid of any additional value.
Management then celebrates the "new innovation", while the team who built it goes into mourning because they made something that really helped and then had it mangled so that it would "fit the process".
If you want your Devs to stop bringing innovative ideas to you, a couple of swoop-and-poop experiences will cure them of the desire to ever give more than the bare minimum.
Wrapping up
A lack of motivation isn't a problem: it's a symptom of a problem. So if you find that your dev team is suffering from a lack of motivation, look for some of these signs... and then FIX THEM! Your team expects you as a leader to remove these obstacles... yes, even the ones that are hurdles to their own motivations.
Beware however that just fixing them won't instantly motivate your staff. Each of these demotivators will behave like a breach of trust - you will lose their motivation instantly but in most cases you'll earn it back gradually.
Top comments (0)