What is 'Quiet Quitting?'
'Quiet Quitting,' or as some may call it reverse hustle, has lost its trend appeal, yet the phenomenon of doing the bare minimum at work has had major economic repercussions all over the world.
Gallup's 2023 State of the Global Workplace report, which surveyed over 122,000 employed individuals aged 15 and above across 160 countries from 2022 to 2023, showed that a staggering 59% of workers worldwide were "quiet quitting." That has cost the global economy $8.8 trillion, the report says.
With the explosion of corporate wellness and worker wellbeing, quiet quitters want more, and at the top of their list is a healthy work-life balance.
Quiet quitters have taken to corporate coasting because their extra efforts, and the idea of going above and beyond, simply aren’t worth it. They’ve basically told their bosses (only in their heads 🧠 and not always in a very nice way) that they quit.
That means they won’t be taking on extra tasks, answering their phones, or replying to their emails after hours, unless they are paid extra or shown some form of gratitude. And I’m not talking about once a year on Employee Appreciation Day with a food voucher to a local favorite restaurant 🍟
What is 'Quiet Quitting' in Software Engineering?
In software engineering, quiet quitters may exhibit their disengagement in other ways. For instance, they may show minimal concern for ensuring that a feature meets its basic functional requirements, neglecting thorough testing for potential bugs or edge cases. Documentation might lack the necessary level of detail. Developers practicing quiet quitting may refrain from taking the initiative to propose new ideas, offer suggestions for improvement, or willingly shoulder additional responsibilities.
I believe at the core of this issue, there exists a larger problem: software engineers grappling with a sense of purpose in their work. Conversations I’ve had with engineers repeatedly echo the same sentiment. They express dissatisfaction when assigned projects involving technologies they despise and employing skill sets that no longer challenge them due to having mastered them already. Many have also mentioned that the products they build don’t bring the world any real good and fail to align with their personal values. Simply put, engineers are burnt out.
What Are the Signs of 'Quiet Quitting' in Software Development?
Here are some specific examples of the effects of quiet quitting I’ve observed in software engineering over the years:
Low Code Quality
The developer's code quality and attention to detail were very low. He introduced some bugs - some detrimental, others not - and wrote code on one project that was difficult to maintain or even understand.
Lack of Collaboration
The developer showed no interest in helping out another junior developer. He scoffed at the idea of mentorship and contributed less to code reviews. When feedback season rolled around, he failed to provide constructive feedback to those who wanted it from him. Asking him to give an internal talk was like pulling teeth 🦷 Mind you, he was getting paid handsomely; he just didn’t want the extra duties.
Loss of Interest in New Technologies
When we offered to pay him for upskilling, the developer showed no interest whatsoever. Learning and adopting new technologies or programming languages was not a priority. He was also not interested in seeking growth opportunities or expanding his technical skills. Stay updated with industry trends? That simply wasn’t happening.
Neglect of Documentation
The developer was a bit too relaxed when it came to documenting his code or updating project documentation. This resulted in a loss of knowledge transfer and made collaboration quite difficult among teammates.
Disengagement From Team Activities
The developer withdrew from our company outings a number of times. Sometimes, for standups and retrospectives, he didn’t even show up or was evidently busy doing something else. He also offered little or no input at all and failed to actively contribute to discussions.
Lack of Innovative Ideas
In the beginning, he brought to the table some cutting-edge concepts about using AI, but over time, they weren’t well-thought-out and failed to solve the technical challenges we were facing. He showed no initiative in suggesting improvements to the codebase or overall software architecture.
Reduced Involvement in Professional Development
The developer felt it wasn’t worth his time attending conferences or continuing to participate in an online forum, one of which he was the admin. He rejected the idea of putting on a workshop, for which he was going to be paid extra. What is it then if not money?! 💰
How Could Engineering Managers Prevent 'Quiet Quitting?'
Here are some actionable steps engineering managers could take to tackle quiet quitting and create an environment that fosters engagement, motivation, and high performance among software developers.
Track Mood and Behavioral Changes with Pulse Surveys
Pulse surveys (check out ours here) are a valuable tool to prevent quiet quitting among software developers. They offer real-time feedback and valuable insights into a developer’s satisfaction, engagement, and wellbeing.
These surveys, conducted at regular intervals, also help organizations understand the overall sentiment and needs of their dev teams. By asking specific questions about job satisfaction, workload, career growth, and work-life balance, companies can quickly identify any potential issues and proactively address them.
Create a Culture of Open Communication
Quiet quitting doesn’t come on quietly. It evolves over time, usually because a developer has already expressed disinterest in extra work before he or she chooses to rebel and mentally tap out.
Establishing clear channels of communication right from the get-go is vital because it allows engineering managers to hear out their developers more often. With an open-door policy, your developers could talk to you about anything and share their concerns, challenges, and ideas.
Regularly scheduled one-on-one meetings allow engineering managers and developers to discuss workload, job satisfaction, and potential roadblocks. Actively listen, provide constructive feedback, and collaborate on solutions to address any issues.
Work in Quick Iterations
Commit early, push often. By committing smaller chunks of code frequently, developers come in contact with other developers. That can result in better collaboration with their teammates and facilitate a faster feedback loop. That also means receiving praise, which is something that could energize the developer to do better.
Recognize and Reward Performance
Recognizing and appreciating your software developers' efforts is the most important initiative to prevent quiet quitting.
Because quiet quitters often cite a ‘lack of appreciation’ as to why they care very little to excel in their careers and at their companies, engineering managers should set up a performance recognition program that acknowledges excellent work and celebrates achievements.
This recognition can be in the form of public appreciation, rewards, public #kudos on Slack, professional development opportunities, or career advancement prospects. If money is what they want, then the money they shall receive 🤑
Provide Growth and Development Opportunities
If money is not the best way to motivate your developers, then engage them by offering continuous growth and learning opportunities. Encourage participation in workshops, conferences, and training programs to enhance their technical skills and broaden their knowledge base.
Help them find their passion again! 🛟 Providing challenging projects, mentorship programs, and opportunities for skill diversification can get your developers invested in their work again.
Promote Work-Life Balance
Addressing work-life balance is crucial in preventing quiet quitting. Recognize the importance of personal wellbeing. Implement flexible work hours, and remote work options, and consider workload distribution to avoid burnout. Encourage developers to take regular breaks, prioritize self-care, and foster a supportive environment where work-life balance is valued.
Make Collaboration and Inclusivity Essential
Foster a culture of collaboration, inclusivity, and psychological safety within your software development team. Encourage knowledge sharing, and cross-functional collaborations, and provide opportunities for developers to contribute their ideas and perspectives. Emphasize the value of teamwork and create an environment where everyone's contributions are respected and appreciated.
See What Your Developers Want Out of Their Careers
Don’t make assumptions about your developers’ career aspirations or if they’re willing to take on extra work. Instead, discuss this with them in an open and honest way to understand how they view growth.
You’ll quickly discover that there are as many unique perspectives on what they want out of their jobs as there are developers in your company - it surely will not be the same as your path or what you expect their path to be.
What you could do as an engineering manager is encourage them to explore new things. Still, it's crucial not to impose leadership roles, especially without providing official titles, influence, or appropriate compensation for the added responsibilities.
Respecting their autonomy and considering their individual goals and aspirations will foster a more positive and empowering work environment.
Conclusion
Quiet quitting is a real problem that costs companies millions in loss of productivity. But the solution that many propose isn’t always a financial one. Software engineers, like many others in the post-Covid era, need to find that spark again in something they love.
The only way I see out of this problem is to ensure quiet quitting developers can use the tools they love to build cool technology that changes the world. And of course, they need to get the appreciation they deserve while doing so.
Looking at you engineering managers, as now might also be a good idea to ask: Is this a problem with my developers, or is this a problem with me and my leadership abilities? 👀
