When was first hired to work for a startup, I was ecstatic.
Finally, I had a real shot to build something from nothing. I had the chance to get in on the ground floor and bust my ass to prove my value and make a mark on the world.
This was my chance.
Fast forward to 18 months later and my life was a wreck.
I had been working 10, 12, or even 16-hour days nonstop. Calls until 11 PM or 12 AM were standard–and I was back at the grindstone by 6 or 7 AM the next day. I had completely forgotten about the idea of a “weekend”.
All of that passion and enthusiasm that I felt had long been exhausted. The feeling of perpetual optimism and dogged, unrelenting work ethic had been replaced by resentment and hopelessness.
I was burned out.
It was only a matter of weeks later that I finally had a heart to heart with the CEO. We discussed options for how to change the situation. But at that point, I was too far gone. I decided to leave.
Just like that, my tenure at the startup–what I thought was my dream job–was over.
Of course, I’m not alone. Everyday, people decide that they can’t handle the stress, long hours, or poor working conditions. And they quit. This is an increasing concern for engineering teams that are constantly locked in a battle to find and hire top talent. All of that investment is wasted if that talent turns around and leaves a few months later.
Developer burnout is a common thing. The “disposable geek” mentality has been pervasive in companies of all sizes and it’s led to many talented people quitting important jobs or leaving the industry altogether.
But even for the ones who stick around, burnout can seriously erode performance, collaboration, and innovation.
It’s no secret that engaged talent performs better.
As a business executive or an engineering leader, there are steps you can take to help prevent developer burnout. It begins with culture and extends into all aspects of the work that you’re doing.
Build a culture of ownership
The most important cultural shift in software engineering in the past two decades is the shift from developers being seen as “nerds that just do code” to the realization that engineering talent is an indispensable part of any modern company.
If you want a team that cares about their work, it would be helpful to not treat engineers like a bucket of code and hours to be expelled upon request.
As part of this, it’s most imperative for your team to feel a sense of ownership over the products that they’re building. This means that they feel invested in solving problems and not simply following orders.
When our brains go into autopilot–when we’re told what to do and how to do it–we instinctively disengage. After all, there’s no point in wasting brain cycles on trying to solve a problem if the “solution” is just going to be dictated to us by a team lead or product owner.
If engineers feel their job has become reduced to that of a “code monkey”, they will react accordingly.
This is burnout in its most common form: Simple malaise.
For executives, this requires vigilance and careful attention to the culture you’re building. Teams need to feel enough autonomy to become personally invested in the outcome of their labor. They need a proper feedback mechanism–ownership throughout the product lifecycle.
But, most importantly, developers need to feel that the work they are doing actually matters and that their job is to try to solve problems, not just crank out lines of code.
Focus on the type of work people are doing
Not all engineering tasks are created equal.
Of course, code maintenance and debugging are part of the job. But, if you have team members who are tasked only with maddening, frustrating, and unrewarding work over a long period of time, you can bet that they will be the first to blow a fuse.
Many teams adopt systems wherein engineers rotate between performing more tedious tasks and the more rewarding exercises of solving new and exciting problems.
This allows each team member to take on some of the less glamorous work without being entirely consumed by it.
But, more importantly, the entire software development environment and the work cycle will often dictate how enjoyable the day-to-day life is for your engineers. Are your developers spending half of their time in maddening, back-and-forths with product owners because of ill-defined scope? Are they constantly having to hobble together workarounds to make up for outdated tools?
Because that kind of work universally sucks.
Joel Spolsky, author of the popular blog Joel on Software, devised a simple 12-point rubric for determining how good (or terrible) your software development environment is to work in. According to the rubric, everyone should shoot for a 12 out of 12–but anything below a 10 is dangerous territory.
The point here is that management should have an understanding of not just whether developers are working or how many hours they’re putting in, but also how that time is being spent.
Be cognizant of any team members who seem to be getting the short end of the stick and figure out how to strike a better balance across the entire team.
Perks can’t replace proper investment
Companies often use extravagant perks–free food, back massages, enormous tech budget–to try to lure and retain top talent.
Engineers are expected to take full advantage of these perks by hunkering down at their expensive stand/sit desk for 14 or 16 hours per day.
But, of course, therein lies the problem. Many companies that offer these kind of extravagant perks are offering these in lieu of investing in more engineering talent. The hard truth is that engineering teams can’t operate at high performance over the long haul if they’re also chronically understaffed.
These perks are often used to mask a lack of true investment.
One of the most important things that any business or engineering leader can do to avoid burnout is to make sure that the team has the proper resources they need. While the perks are a nice bonus, even the most gung-ho talent will crash and burn after 6 or 12 months of doing the work of 2 or 3 engineers.
The biggest takeaway here is that you can’t fake investment in your team.
If you want–and expect–optimal performance, then you need to be ready and willing to provide the necessary time, money, training, technology, and other resources necessary for your team to perform at their best over the long term.
Burnout is fundamentally a simple problem to solve.
The question is, is your organization willing to make the investment in the solution?
It’s one of the smartest investments you can make.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Top comments (0)