Hi all,
Today's post is about motivating engineers and keeping them engaged and productive. The key is tapping into their natural inclination to solve problems. Assuming you've Started with Why and you have a clear, emotionally resonant mission to convey to the team, the next most important thing is making sure engineers have actually seen the customer problem.
I can't emphasize enough the importance of making this a "show, don't tell" situation. I mean this very literally. It means creating an opportunity for a customer to show the engineers how they use the product today. Or better yet, show them what they do without the product. I try to ensure this happens at least once a quarter for each engineer.
I also can't emphasize enough how effective this is. It works so well because engineers are Natural Born Problem Solvers. It's in their nature to want to fix things and make things better.
There's a joke about a rabbi, a priest and engineer that I think best illustrates the point.
It's the French revolution, and a rabbi, a priest, and an engineer are about to face execution via Guillotine. The rabbi is up first, they put his head in the machine, and he asks to be turned over so he can face heaven and say a prayer. They indulge him, the blade drops, and miraculously, it stops an inch from his neck and he's saved. Not to be ones to argue with a sign from God, the revolutionaries spare the rabbi and he's released.
The priest is next, and he too, asks to face heaven and say a prayer. Same thing happens. The blade stops an inch from his neck, he's saved, and they let him go too.
The engineer is up, and he figures, why not, it worked for the other two guys, he'd like to go face up as well. They pull the trigger, the blade drops, comes rushing down, and miraculously stops an inch from his neck. The engineer says, "Hey, I think I see what the problem is here!"
In other words, seeing a problem creates an itch for engineers that they can't help but to want to solve.
I also have a theory that it's so important for engineers to see, rather than be told, because engineers don't trust the messenger. It's like going through a troubleshooting session. They ask you if you turned it off and on. You roll your eyes and say "of course." Then they insist on doing it themselves, and it still doesn't work. Then they go "huh, that's weird" and suddenly they're really into it. Meanwhile, you're saying to yourself they could have skipped that step. But at this point, they're hooked, so it doesn't matter.
Finally, engineers can be prideful. They don't like to be told that their work is wrong, or not good enough. But when they see the outcome for themselves, it can actually create space to save their egos and they'll find an excuse to transfer the blame. They'll say things like "well, you didn't capture the requirement properly" or "why didn't you say this was the problem?" Then they'll fix the problem, and willingly.
This is also an incredible tool for motivating engineers to fix bugs or improve user flows. I remember inviting an engineer to observe a customer working through a form submission. An error message was appearing, but the error text was scrolled out of view. The input box was turning red. It was non-sensical and confusing for the customer. The engineer knew exactly what was happening and why. He had a fix pushed within 30 minutes, without being asked.
Putting this into practice
Putting this into practice is simple. I set up a rotation and every time I meet with a customer, I invite one of the engineers to attend. I won't pressure an engineer to participate in discussion. I'm just asking that they join and observe. Then I'll ask the customer to walk through their experiences and show us what they do. If it's truly impossible or un-scalable for the engineers to attend, I'll arrange to show the engineers video recordings.
Beyond that, I try to expose engineers to a regular drip of customer feedback, interview and research notes, and anecdotes. These can be shared over team chat or in a recurring team meeting.
It helps the engineers keep in mind why they're there. And when they actually solve problems, seeing the customer impact is incredibly rewarding, creating a positive feedback loop. Repeated behaviors like this are what develop motivation and culture on the team.
What if the project timeline is long or the team is too big?
Sometimes project timelines can be long, especially with hardware products. There aren't necessarily weekly opportunities to speak with customers and might not be significant change or new information to be gleaned from a new meeting. In these cases, I'd still advocate for showing engineers the customer problem, but I'd lean more heavily into sharing a video once a quarter with a wider audience.
In these situations, it's also important to keep teams motivated by celebrating continuous progress and small wins, which I'll talk about more in later posts.
What if it's an internal backend service, or just a small subsystem?
I'll caveat that on large systems, thinking of your peer system teams as a customer can be challenging, but internal services and subsystems have customers, too! In this case, it means seeing both the big picture and the end customer, as well as understanding the developer or partner experience of your internal customers. Similar techniques still apply.
That's all for today!
Best regards,
Sam
aka THE Awkward Engineer