Harnessing the Power of Developer Moments
September 01, 2024
Many developers are aware of the power of gamification. From video games to board games to even personal hobbies, there is something powerful about creating a competition or structure around leveling up or completing challenges.
This idea has even seeped into how we talk about career progression. We talk about leveling up when we want new skills or hope to get promoted, and we assign levels across corporations to our roles.
I’ve been thinking about this recently as I’ve been reading a book called The Power of Moments. It talks about how we miss out on pivotal moments in our lives, careers, and organizations that, with a little bit of effort, can increase engagement and happiness.
I’m not going to cover the entire book, but the book’s thesis has left me wondering: What moments in our development teams are we missing that would increase our teams’ engagement and happiness?
This article is my initial exploration of that idea. I haven’t experimented with this on my current team nor on past teams; I’m thinking through all of this in real-time. Just be aware of that as you read since I only have a hunch (so far) of something very powerful.
What are Developer Moments?
The starting question, of course, is: what are developer moments? What are significant moments within a dev team?
It’s a great question, and there are often few wrong answers. Each developer and team will consider some moments more significant than others. The book recommends thinking through four criteria.
- Moments of elevation: a moment that flips the script from the ordinary day
- Moments of pride: a moment where an achievement or milestone is reached
- Moments of insight: a moment when some new truth or knowledge is suddenly seen and apparent
- Moments of connection: a moment when people share something significant together
For this article, we’ll focus (though not exclusively) on moments of pride (significant accomplishment) and connection (when people share a significant moment together).
Here are some possible ideas:
- A new developer’s first day on a team
- A developer’s first feature in production
- A repository the team owns hits 100, 1000, etc., merged pull requests
- The team finishing an intense project
- A service or system processing its first request - or millionth!
- Somone’s first time breaking production (turn a negative experience into a badge of honor)
This is a short list, but I think it gets you started. Once you see a few of these, you’ll start seeing opportunities for them everywhere.
How to Harness These Moments?
Now that we have a list, how do we harness them? How can you properly recognize these moments when they happen?
Again, it will look different for each team. Some teams like the badge idea, some teams like t-shirts, and others like to focus on emojis in your Slack or Team’s channels.
Whatever the format is, the key is you need to lean into it. Go all out. Overdo it. Give some budget to it.
Why? Because you can’t celebrate moments haphazardly. Celebrating moments as an afterthought result in last-minute sheet cake retirement “celebrations” in the break room or telling someone on their first day, “Welcome,” and having nothing else to say. These “sorta celebrations” are often unexciting and sometimes even downright cringe.
To make these moments truly meaningful, you have to overdo it. If you are going to create a badge system (a classic gamification approach), you need well-designed badges, and many of them. If you are going to make T-shirts for a big release, don’t skimp on the quality, and make sure they have more than the release name in Times New Roman as the logo.
To do this requires a bit of unreasonableness both in effort and sometimes in money. But as the book states
beware the soul-sucking force of reasonableness
What does this mean? If you want to celebrate moments properly, you can’t get by with a “reasonable” approach or efficient strategy. Otherwise, the magic is lost.
An Example of Harnessing Moments Effectively
A small example of how to harness moments effectively isn’t taken from a software team or repo but from a tool I used called Grammarly (not an affiliate link, by the way). I’ve been using Grammarly for a few years now, and every week, I get a nicely designed and insightful email about how I have been using the tool. It covers all sorts of things like how long I’ve been writing, how many, words, and other insights.
For example, I’m on a 44-week writing streak on Grammarly. They let me know each week that I extend that streak, which is an excellent way to “not break the chain”. They show it in a badge, too, as opposed to just basic text.
In addition to the writing streak, they track my total word count and tell me when I hit 10,000 words and then 500,000 words (!). They also keep track of my most common errors and celebrate when I improve on a common error.
Every time I get these emails, I’m more motivated to keep writing and improving. How cool would it be to harness that feeling on our teams to keep devs motivated and improving, too?
I’m hoping to follow up on this post after trying out some of these ideas on my own team. Stay tuned for an update!
Until then, look for opportunities to celebrate small and big moments on your development teams. They are there; you just have to pay attention.
Happy coding!
If you enjoyed this article, you should join my newsletter! Every other Tuesday, I send you tools, resources, and a new article to help you build great teams that build great software.
Dan Goslen is a software engineer, climber, and coffee drinker. He has spent 10 years writing software systems that range from monoliths to micro-services and everywhere in between. He's passionate about building great software teams that build great software. He currently works as a software engineer in Raleigh, NC where he lives with his wife and son.