Why engineers burnout (Part 1 - "temporary fixes")
Burnout is a common thing in the tech industry & something that you should strive to avoid if possible. When engineers burnout their productivity can fall precipitously, their performance & motivation to work can be non-existent & ultimately, they may leave your company for pastures anew.
It would therefore go without saying that, as a manager of engineers, preventing your engineers from burning out is something that you should strive to achieve. Many companies have strategies & culture that they claim prevent burnout, however, I believe that often these strategies don't work, are inefficient, or just plain don't work, if they are even applied at all and are not just lip service.
So, before you can go ahead & prevent your engineers from burnout, why don't we try and understand what leads to engineering burnout & then we can think about how to prevent it?
It's a common adage that "People don't leave bad jobs, they leave bad management". I'm here to tell you that this statement is mostly true.
We've all heard it before, when management tells you, "I know it's not the best way of doing something, but it's a temporary solution until XYZ happens". In my experience, 9 out of 10 times this is a false statement. There's an old Russian proverb "[there's] nothing more permanent than a temporary solution".
I can almost guarantee that you've experienced this in your career before. You've been asked to build a feature, understood the business requirements & then come up with a great solution that will not only be maintainable in the long run, but is efficient in some way (either performance, cost, or otherwise), but it'll take 2 weeks to implement instead of the 1 week management expected (how did they arrive at this expectation I hear you ask? ¯\_(ツ)_/¯). So instead of your good solution, they want you to cobble together some hodge-podge to get it out the door for some arbitrary deadline.
You raise your concerns that this is a bad idea, it's unmaintainable & you know that management is going to come along next month & add to the technical debt you're being asked to create (tell me I'm wrong?). And let's not forget the fact that paying down this technical debt is never scheduled into the roadmap. Then a further two months down the line, you've been asked for a new feature, but because of the way you cobbled together the previous one, delivering this new feature is going to take twice as long as it would have if you'd delivered the first feature the way you'd initially designed.
So you carry on for a year or two & eventually, you have this mess of a codebase that is unmaintainable & takes weeks to add even the most basic of features.
This drives an engineer to burnout & then you end up losing your engineers who know the most about the system, have to hire new engineers who take a substantial amount of time to learn how this system works because nothing is intuitive, the tests are convoluted & making a change in X part of the code breaks Y.
Furthermore, this sort of codebase breeds nasty bugs that are difficult to debug & fix. Then your clients end up not trusting your software because of the amount of weird bugs.
If only this could all have been avoided?
I'm here to tell you it could have, if only you'd trusted your engineers' estimates & decisions & "done things right!"™ from the start. There's been an awful lot of credence given to the thought of hacking things recently including life hacks, shortcuts & workarounds, designed to help you reach your goal without putting in as much effort.
I can tell you that the majority of these workarounds and the like do not pay off in the long run. They make the working environment of your engineers worse, which leads to them having less time & energy to care about doing good work & instead doing whatever it takes to get something out the door (this only makes the problem worse).
After all, why should I put in my best effort & design this new feature to last & be maintainable if feature XYZ is already causing even worse problems? On average, I'm not making the codebase worse by not fully applying myself, it's actually an improvement overall!
I hope you can see from my explanation above, that this situation is wholly avoidable, all you have to do is trust your engineers, and accept that initially, it might take as long as your engineers have told you to build it "right first time"™. But I promise you that if you trust your engineers this way, it will be paid back double in motivation & desire to deliver further good code & features by your engineers.
There's nothing more exciting to an engineer than building good, maintainable, long-lasting code that just works. As long as you allow your engineers to do this you won't have to worry about them burning out due to having to work in a shoddy codebase.