Burnout in IT

The Problem

I was talking with an intern the other day and shared some advice with him that I feel many people in the tech community need to hear.

I have been working in the IT industry in one way or another since I was 18 years old, I turned 40 this year. I have worked every level of IT including but not limited to phone tech support, on site desktop support, server administration, programming, IT Project Manager, too running a an entire IT department.

I have seen many people burn out, and I hear the usual excuses. The job is emotionally draining, it is to mentally demanding constantly, it is to isolating. However, usually it is not the job that is the problem, it is the environment.

I find this really sad because we need good workers, and when people burn out and leave IT completely it hurts us all.

I have been very lucky and primarily worked with good companies during my stint in IT. Yet there are many bad companies. Some of the bad behaviors include the following

  • Unrealistic time tables
  • To much oversight
  • Not enough oversight
  • Mandatory Overtime
  • Expecting perfection

Lets address each one of these and why they are bad.

Unrealistic Time Tables: In this scenario the boss has no clue how a project should take so they pick some arbitrary number and then expect staff to meet the expectations. This is not healthy as many people will work themselves into the ground trying to meet these ridiculous deadlines. I have never faced this one personally but I have known many programmers who have.

To Much or To Little Oversight: Programmers do not need you looking over their shoulder every second of every day. Programming is not about typing code, it is about thinking and working out a problem. The way programmers do this vary. I have seen some people listen to music, some play video games, some watch TV, some work on a whiteboard. Usually it is a combination of all of these things. When companies want to come in and watch every little thing their employees do this can cause unease. You may ask then how do you know your employees that you pay very well are actually working and not just goofing off all of the time. The answer is deadlines. You need an experienced project manager who can give a good realistic time table on deadlines. Then if a programmer is constantly going over those deadlines it is time to have a talk. If you see someone who plays CS-GO 90% of the time but always meets their deadline then leave them be. Trust me if they write good code and meet their deadlines you would rather have them than people who are working 80% of the time and miss deadlines or turn in broken code. It is all about performance.

On the other side of this you need to be available when they do need your oversight. When they do good programmers will reach out to you and ask you to answer questions, clarify things, or look at the current state of the project. These are important times for you to have the time to give feedback.

Mandatory (usually unpaid) Overtime: This is a pet peeve of mine after watching many companies abuse managers this way. Salary work was designed so that if my schedule requires me to work 20 hours one week and 60 hours another week then I can do that and expect a consistent paycheck, while at the same time protecting my employer from having to pay me overtime when I do happen to pull 60 hours. Too many places treat this as minimum 60 and maybe up to 100+ hours for salary workers. This is just abuse and exploitation and will cause employee burn out.

Expecting Perfection: This one I have a story for. However, first let me say I have seen screw ups on every level. Production databases wiped out, entire sections of the internet blacked out for a day. I have made a few of these myself. I once wiped out the production database 2 days in a row due to a bad SQL query that I thought was a one time fluke. We got it back up and running and my boss understood.

Once I worked for a client as an independent contractor. I told him I would have a particular piece of code done on a Thursday. Well Thursday night I had not finished it due to a bug I ran into. I planned to finish it on Friday morning. This piece of work called me while I was out with my family demanding I come back into the office and finish it then. This was on a product that was nowhere close to even launching, no customers were affected. It was just a simple update of some VOIP code for a project that would be launched 6 months from that date. He accused me of being a liar because the month previous in my estimates for this part of the code I had listed today as the day I would have it done. For any of you who have worked on any complex programming projects in the real world where the specifications are constantly changing, you know that project deadlines are soft at best. The fact that I was only a few hours behind for an entire months worth of work should have in and of itself been applauded. Needless to say I left the project shortly afterwards.

Just to be clear deadlines are important. However, when whoever is lead on the project keeps changing their mind on what they want there is no way a deadline can be kept realistically.

What to do.

The solution is simple. Do not put up with an abusive or toxic work environment. Those are just a few examples I have and I am sure there are many more.

If you are in a situation where you feel your employer or client is being abusive do not be afraid to walk out.

You do not need to give them a reason, you do not need to confront them about what they are doing. You just need to move on and find one of the great IT companies that are out there to work for.