Are We Correctly Thanking Software Engineers?
We all need to feel appreciated, but sometimes we forget to thank people...
Receiving appreciation is a basic human need, with software engineers being no exception. Whether it be promotion, a pay increase, an award, or just a simple “Thank you!”, our self esteem needs validation. When properly thanked, we’re capable of pushing ourselves harder, achieving more, and enjoying work for longer. In contrast, lack of appreciation leads to frustration, resentment, and is one of the main reasons people leave their jobs.
Over the years, I’ve noticed situations where the “Thank you!” felt missing, or was attributed to the wrong person. I want to share some scenarios to explain why this happens, identify who received the praise, then consider who else should have been thanked.
Customer-Facing versus Behind the Scenes
In the software world, there’s work that’s visible to customers, and there’s work that’s “behind the scenes”. The customer-facing work includes frontend UI construction, as well as any backend feature development visible via the UI. In contrast, the behind-the-scenes work involves platform development, security, performance, latency, and system internals, things that are either hidden from the customer, or are less visible.
Both types of development are important, but the customer-facing work is easier to see, easier to understand, and easier to praise. Your colleagues in sales, marketing, developer advocacy, corporate leadership, and customer support, tend to have outgoing personalities and show excitement for each new feature. It’s easy to feel appreciated when so many are discussing your work.
As an example, I recall a UI developer demoing how they moved a button to a more prominent location on the screen. A simple code change, but the impact to the customer was significant, and the cries of “Ship It!” were free-flowing. On that same day, another developer describing their optimization of Docker images was met with polite applause, but an obvious lack of understanding or appreciation from many in the room. The developer clearly noticed.
If you see this in your organization, consider raising the profile of the behind-the-scenes work, describing it in terms important to customers. For example:
When significantly refactoring the software, publicize how the work increases velocity of new feature development.
When an improvement is made to the software’s reliability, advertise the expected decrease in system outages (e.g. we’ll achieve 99.99% uptime).
Likewise, an improvement in performance provides a less sluggish application.
Finally, an improvement in security directly impacts the software’s compliance report, as well as the customer’s peace of mind.
In other words, identify why people should be thankful for the work that was done. All developers deserve thanks for their work, not just those building highly-visible features.
Being Reactive versus Being Proactive
Escalations are common in the software industry, ranging from individual customer complaints through to complete system outages. No matter what, it’s important to identify the severity of the problem and resolve the issue accordingly. When a developer fixes a problem, they’ll surely be hoping for praise.
Be careful though - praise for reactive behaviour can give the wrong message. For example, John and Mary stay after work to resolve a system failure, working long hours into the night to address the problem. In the morning, customers are happy again and management is appreciative of John and Mary’s work. Should they receive thanks? Of course they should!
But, what about a different scenario where Frank works long hours to test his code, addressing review feedback from his peers. He believes in releasing quality code, putting in effort to ensure positive customer experience. For six whole months, he goes home at the end of the day with no outages, and no customer complaints. Should Frank receive thanks? He should, but often he doesn’t hear a thing!
To make sure praise is given where it’s due, you should always track metrics on the number of problems encountered. Although you should praise those who fight fires, much more appreciation is due to those avoiding fires in the first place (assuming they’re still able to deliver customer value!)
Individual Contributor vs Leader
As a software engineering leader, an important part of your role is to thank the members of your team. They look to you for validation of their effort, often going out of their way to please you, with praise being heavily sought after. It’s important for you to recognize good work, both from individuals as well as the team.
But what if you’re the leader? Who thanks you? You’ve put in countless hours of hard work, running meetings, scheduling the team’s activities, dealing with escalations, supporting low-performing team members, and even reviewing and writing code. Unfortunately, praise for your work can be hard to find.
Should the members of the team be thanking you? I’d like to think so, but the power dynamics makes it hard for individual contributors to feel comfortable praising their leader. After a while, they become accustomed to you performing those tasks, and don’t see it worthy of thanks. Ironically, you’re more likely to receive thanks if you do their work for them, such as finding the source of a complex bug.
Alternatively, should your own manager make an effort to recognize your work? I’d like to think so, but they’re just a single person who’s involved in numerous projects. They might forget to thank you, or in order to avoid bias they’ll thank the whole team, rather than thanking you personally. Unfortunately, that’s not the same feeling.
Small Tasks versus Large Actions
In my experience, it’s more common to receive a “Thank You” if you interact with somebody face-to-face to help with an immediate problem. For example, it’s easy to get praise if you spend time explaining a difficult concept, or if you pair with somebody to fix an annoying bug. It’s minimal effort to thank somebody, so it happens more often.
The challenge lies when your work is longer-term in nature, and people are at arms-length. You might be a leader, or might achieve great things for your company or community, but you rarely hear words of appreciation.
In one example, I once received company-wide praise for helping arrange chairs for an evening meet-up. The task required 15 minutes of my time, but was apparently worthy of a call-out to the whole company. This seemed odd to me, as somebody who spearheaded meet-ups for the past 10 years, spending 100s of hours to organize events. I had noticed the distinct lack of praise for my ongoing leadership, but why was that 15 minutes of chair moving worthy of mention?
In reality, I had received praise for my longer-term actions, but it was “behind my back”. From time to time, I’d overhear mention that I was a well-known leader in the community. I also came across email threads stating “Peter is the organizer of…”. Even though people were not giving thanks to my face, I’d instead been developing a reputation in the community. In the end (after 10 years), I did receive a significant community award, so the thanks eventually arrived.
Demo Presenter versus Innovator
If you’re somebody who likes to innovate, you may have seen the following scenario play out. Imagine you think of a great idea to solve a challenging customer problem, then you explain the solution to your colleague, William, to get his feedback. You draw pictures on a whiteboard, and spend time convincing William it’s worth implementing. William agrees to build a proof of concept, demonstrating the value of the idea.
A few months later, you start hearing about William’s great new idea! Apparently he gave a demo to senior staff members who loved William’s proposal. William is now the hero for solving a challenging problem, and is receiving lots of recognition for doing so. How does this make you feel? It was your idea!
At this point, you might be tempted to say “But it was my idea in the first place!”. In reality, William likely modified your idea and improved upon it, so now it’s unclear who actually deserves the credit. At the very least, you should share the praise.
The solution comes in the form of a document. Rather than white-boarding the idea, with somebody else building the prototype, you should personally write a two-pager document that explains the vision. This document should be quick to write, and can be refined over time, but there’ll be no doubt you had the original idea.
Short-Term Delivery versus Long-term Strategy
Along similar lines to the previous problem. You may be the innovator of a project that ends up being a long-term venture for your company. Imagine you spent six months implementing a prototype, gaining buy-in from leadership, campaigning for budget, and putting together the project plan. Your great idea is finally in motion!
The project ends up taking 18 months to build, with a team of ten developers. They work very hard to productize the idea, building a solid solution to delight customers. You trust the team to do a good job, so you switch your focus to the next big project on the roadmap. You don’t need to be watching over their work.
Of course, when the project is eventually delivered, there’ll be plenty of praise for the whole team. But wait! The first six months of work was entirely your effort, so shouldn’t you receive 25% of the praise? The reality of being an innovator is that it takes a whole team to turn your idea into a viable product, and to support the software in the longer term. That’s not something you could do by yourself. As an innovator, you must share the praise, and also be comfortable with delayed gratification - possibly years later.
At the Project End versus at Each Milestone
A large boost to a software team’s morale is when you find reasons to celebrate. This is easier when you release software on a regular cadence, providing that all-important praise from customers. However, many projects take multiple years to complete, leaving long periods of time with no visible reward.
As any good project manager will tell you, it’s important to break a large project into achievable milestones. This helps with resource allocation and budgeting, but also provides a reason to thank people, and to celebrate. Even if you’ve only got half the work done, that’s a milestone to celebrate.
One of my favourite memories of being a TPM in the IP networking industry was the “ping party” we held when our newly-built network devices first sent a “ping” message across the network. We would always celebrate with ice cream (in California it’s always time for ice-cream!). There would still be several months of development before the product was fully tested and ready for release, but reaching the intermediate milestone was a good excuse to stop, celebrate success, and to thank people!
Conclusion
If you’re working on a software project, and you don’t feel appreciated, I encourage you to think about why. What’s missing? Do you feel ignored or resentful? Is somebody else being praised for the hard work you’re doing, or perhaps their work is less complex but more visible? All are common reasons for feeling unappreciated in the work place.
I won’t claim to have a perfect solution, but I do find that identifying the root cause is the first step to feeling better about the situation. You might be able to change the way you work - to increase the visibility of your contribution, or to raise awareness of how important your work has been to the organization.
Thanks for reading!