How do you take on less stress in a role than your predecessor did?

Question

I'm a Senior Developer. My team's Tech Lead/Lead Developer was promoted to a newly-created role: Architect.

This guy was the epitome of stressed. He often didn't get full lunch breaks due to fires and emergencies. He often worked more than 40 hours per week and worked odd hours. He's had bursts of anger which I know are brought on by stress. He is constantly jerked around from one "#1 priority" to the next "#1 priority" only to be asked about the status of the first one.

My boss, the PM, floated the idea by me of taking the empty position. It's not terribly surprising, as I'm the only Senior Developer on my team.

The thing is, I have no tolerance for that level of stress in my life. I will not work overtime. I simply refuse because I know there are other jobs out there which pay as much or more, with less stress.

I told my boss that the stress and hours were my chief concern. He said it's a lot worse at other companies. I held firm. He said he did it for years and it wasn't a big deal. I held firm. He said he'd agree to work with me on any after-hours emergency that came up. I held firm. I did my best to make it clear that overtime is not a line I'm willing to cross. He finally relented.

Is there any chance I'd be able to fill that role and manage to work normal hours and manage stress levels? Has anyone done this successfully before? Can I realistically lay out those conditions and expect the agreement to be honored?

Answer 1

How do you take on less stress in a role than your predecessor did?

Do not take your predecessor's role.

Your boss in his attempt to convince you made it pretty clear that all the extra work and stress was normal and expected of the predecessor's role. He can say whatever he wants but the bottom line is if you accept this role you will likely face the same workloads.

The only way to somewhat protect yourself should you decide to take this role is to have stipulations in writing regarding overtime, emergencies,...etc. Just be aware that even having it in writing, does not guarantee that things will change much. If I were you, I would pass on this role.

Answer 2

I don't have a direct answer, but I do have some additional thoughts/strategies...

1 - People are different

I have worked with folks that would be stressed out no matter what the situation. I know others who are almost disturbingly cool under extremely stressful situations. Bottom line - stress level vs. reasons for stress are highly personal.

So - most important - where does YOUR stress come from? For some, it's the perception of others (wanting others to see you as good at your job, likeable, etc.). For others it's the demands between work life balance. For others it's actually being able to complete objectives.

That's the biggest element of "would this job stress you out"?

2 - Can you redefine the mission?

Hard to know until you get into it fully, but it's worth it to have a talk with the boss about what your powers are and whether you can eliminate some elements of the stressors. For example:

• if the fires and emergencies come from buggy code, and poor quality control, can you change how you do testing if you are the lead? Can you have time to build additional regressive tests, or improve the test environment to give you better feedback? Can you change the peer review process or get better design practices?

• if there are issues around conflicting and changing #1 priorities - can you set up a communication structure that makes it clear what priority will and won't be staffed when priorities change? Can you create a mode where when you accept/respond to a change in priority you have the ability to point out what won't get done as a result? I've seen new leaders get hung by this a lot - that they forget/don't realize how important it is to both accept a change in priority and react urgently but ALSO to make it clear what you won't do.

• can you and your boss work out a reasonable definition of what good work on your part looks like? Something that is actually achievable in a normal # of hours?

• can you staff a coverage model, so that if you have to support customer escalations off hours, it's not always you, but it can shared in some schedule able way across a team?

If your boss isn't open to talking about how you might change the way you, as the lead, get the work done - then I would doubt he's giving you enough autonomy to take the job and make something good out of it, and he just expects to overwork you and not really change anything.

If he's supportive, but says "well, that's not really controllable" - then it still may be a red flag, since there are some jobs that just can't be fixed.

3 - Overtime - controllable - yes or no?

Specifically on the topic of overtime, as a manager, I'll say that I'd be cagey too. If someone on my team came to me and wanted a 100% guarantee that they'd never have to work overtime, I would counsel them to find another team. IMO - there's an element of knowledge work where you make your own overtime.

What I usually can promise as the boss, is that I'll do my best to make sure the team is giving me reasonable estimates, and that I can support a work/life balance when we take on emergencies that are needed to support the business. But if the need for overtime is coming from a way-too-short estimate, or I'm asking someone to work late because the business has a crisis with a deadline --- then as the boss, that's not something I can easily prevent. But at least some of that (too short estimates) - is under the individual's control, because I'm relying on the team to give me the estimates.

That's a nuanced conversation that not every boss is capable of having. And when an employee is stuck in the idea of "no overtime, I mean it, never, never, never" - then you two may be at an impasse.

But I've gotten a lot of good outcomes from getting super clear about what an "emergency" is, and how having emergencies WILL slow down the day to day planned work, and it's possible to work in a place that accepts that emergencies at a higher-than-expected level will interrupt planned work. It's also reasonable for the boss to expect the team lead to consider a normal level of emergencies when planning work.

4 - Stress & Leadership

My experience has been that team leadership is a different level of work, and one that can be difficult to put down. Even if you aren't being demanded to do overtime - the dynamics of leading people and getting a plan to come together and conflicting priorities managed is real work, different work, and a learning curve that can be either "stressful" or "energizing" - depending on how much you enjoy it.

For me - at least - it's harder to put the leadership stuff down at the end of the day. Code/design is much easier to shelve for tomorrow. It's no so much being trapped at a key board, but the fact that your mind will stick on issues of the day, regardless of when you go home.

I think that's a healthy kind of growing stress... that comes from being interested and learning new things. But it IS a kind of stress, and one that I would see as hard to avoid in this particular type of job change.

Answer 3

Consider what happens if you do not take the role

There are several answers here which outline why taking the role is not a good idea because management expects that the stress and expectations are just part of the job and that they may not honour the agreement in a few weeks/months.

However, one thing you should consider is what happens if you do not take the job.

A friend of mine worked in a company where there was a situation like this, i.e. a senior developer who did not really want the lead position because of the overtime and stress it required, especially as he had a new child at home. The technology was not well put together and as a result, was constantly in need of quick fixes at all hours of the day and on the weekend. The salary increase of 10,000 to be the lead was drawfed by all the extra hours required for the role.

What ended up happening is that the company decided to hire a non-technical as the team lead and effectively make the two senior developers responsible for all the firefighting. One senior dev quit and the non-technical filled his position with a junior. Within a month, that senior dev had no salary increase, no authority to hire or train the other developers on the team (he would have had this as lead), and all the responsibility for the problems with none of the authority or resources to make changes or any of the career or economic benefits of a better title or higher salary.

Now, if you can actually easily move jobs, that is a manageable risk. However, this guy was a self taught developer with a poor job title, a non-related degree, and not a lot of mobility due to the new kid. As far as my friend knows, he is still stuck there.

A cautionary tale that you may not be able to decline this job. You might just end up declining a raise and a title promotion.

Answer 4

So, the first answer is "do not take the role". @sf02 laid out the basics of that one out well enough that I don't feel the need to repeat his logic here. If that's not an acceptable answer, though, it's possible to take on a role like that and not be as stressed, largely through better organization and managing expectations. I note some things you say about your predecessor.

• "He is constantly jerked around from one "#1 priority" to the next "#1 priority" only to be asked about the status of the first one." If you choose to accept this role, you need to not let that happen. Make sure that there's only one person who gets to assign you "#1 priority" work. (This person is your boss, regardless of what anyone else says.) Keep clear track of what your tasks are and what priority they are. If you have one #1 priority, and someone else wants to jump in and insist that something else is your #1 priority, require that they go through your boss. If your boss jumps in and says "this is your #1 priority", make sure that they know that you'll be deprioritizing your previous #1 priority. If he then demands to know what happened to your previous #1 priority? Well, it was deprioritized.

• Work defined by fires and emergencies. This is generally a result of either disorganization within the team (a classic one being inadequate testing, leading to pushing bugs out the door that need immediate fixes) which you can fix yourself, or disorganization in those making demands. It sounds like those making demands on the team have grown accustomed to the idea that they can offload their own desperation and panic-stress on the Tech Lead rather than worrying about making emergencies like that not happen in the first place. Disabusing them of this is not trivial, but is doable.

So, yes. It is possible to lay out rules like that, and, by dint of significantly improved organization and quite a lot of pushback, refuse to bend on them, and, if you do it well enough, it can even work... except....

Well, it sounds like those making the demands (be they customers or higher-ranking individuals in the company) have grown accustomed to the idea that they get to push the tech lead around whenever they're feeling stressed, and it sounds like the PM is inclined to let them, given that none of his attempts to convince you included any reference to providing actual political support at all. So doing this is going to require pushing back against the PM... which is stressful. It's going to involve pushing back against those making demands... which I guarantee they will cause to be stressful. People like it when they can offload stress and bad consequences on other people, and don't like being told to stop. It's going to involve implementing a better organizational framework, and that can be stressful. Also, there's a good chance that the folks making the demands will eventually be demand that you be fire or removed from the project or whatever.

So... it's technically possible, yes. At the same time... do not take your predecessor's role.

Answer 5

@Ben Barden mentions you should let your boss prioritze the tasks. this will put extra stress on him and not make your life better. The better approach in my opinion is to let the requesters sort it out themselves:

"I understand this is a #1 priority for you, but I also have a #1 priority request from Bob I am working on right now. Please contact him an figure out which one I should work on first. I will work keep working on Bob's request until then because he came first."

The second part is delegation. If you can figure out the problem in 10 minutes and then delegate the fixing and testing part that takes an hour to somebody else, you have improved your performance by a factor of 6. Even if they come back and need assistance, you will be still better off.

And the most important thing is that you understand and feel and live that this is only a job, where you get paid by the hour to do things. You should only do one thing at a time and not try to rush anything. Do as much as you can with the resources given, not more.

If emergencies come up at odd hours, you need a protocol which ones are really emergencies because lives depend on or because the customer will jump ship and which ones can be tackled the next morning without too much harm. If you work extra hours for emergencies make clear you will compensate by working less on normal stuff the next days. Also make sure extra hours are paid if you cannot make up for them with free time. Maybe even find people willing to do some fire fighting from time to time. If it is spread across the whole team, it doesn't feel like that much anymore.

And yes, improve everything you can about the current processes, infrastructure, suppliers. You should not aim for a quick response time, but for a low incident rate.

I would give it a try and see how far you get, will get you a boost in income, you will learn a lot about yourself and your limits and maybe how to reduce felt stress. You are not Jack Bauer, working 24 hours a day to stop terrorists and defusing bombs, it's IT man. ;-)

If it doesn't work out, ask to get transfered back or find a new job.

Don't panic!

Answer 6

The other answers already cover what you can expect should you take on the architect role – namely, exactly the conditions your predecessor faced: stress and overtime. There is no reason to assume that it will be different once you are in that role, whether it's because your boss thinks these conditions are okay or because he's unable to provide a better environment. But there is another aspect:

I simply refuse because I know there are other jobs out there which pay as much or more, with less stress.

Let's take that at face value and assume that money is your primary motivation, while stress is your primary concern.That is probably heavily simplified, but it is what you have told us.

I simply have to wonder: Why don't you take on these other jobs that pay better while being less stressful?

Answer 7

Your sample size of what it's like to be a software architect is too small.

Yes, fires crop up at odd times and people push you for information about one thing when you've been thinking about another. Guess what, that happens to everyone in IT.

Being a software architect is not about stress. Everything you just described to me sounds like fun. I love being in the mix. I love NOT being driven by the clock. But not everyone is like that. You can religiously stick to a schedule and be successful. What you can't do is pretend that you like working crazy hours and be happy anymore then I can pretend I like working normal hours. This isn't because of the job. That's because of who you are. Be confident enough to turn the job into what you need it to be. Believe me, the job is flexible enough.

You've already done the hard part. You told the boss how you'll work the job. Now you just have to stick with it and make everyone believe it. You'll find others who'll thrive working with you this way. You'll also find some, like me, who think nothing of showing up 4 hours early because they had an idea.

Find a way to let me keep being who I am and you'll be fine being who you are. I've successfully worked with people with stranger habits then sticking to normal business hours.

I've been the architect working crazy hours and I've worked with architects who were religiously time driven. It isn't the work. It's the personality. Best habit I've seen the time driven guys use is a simple phrase,

"I'll get back to you tomorrow".

Answer 8

I had a manager once (two levels above) who was totally stressed out. His boss wanted features A, B, C, D, E, F, G, H, I and J, and he promised to deliver them. Which was of course impossible, so he produced some half-arsed and incomplete results, had lots of stress, had a bad reputation, gave his team a bad reputation, and stress, and everyone was unhappy.

His successor used a very simple and effective strategy: When the same boss wanted features A, B, C, D, E, F, G, H, I and J, he just said NO. He said "No, you can't have this. We can do A and B, and if we are lucky we might manage C, but that's not something we can promise". The team then had a chance to deliver these results, no stress, and his boss considered him a genius for delivering what he promised.

Stress is very much something that you produce yourself. Stress kills your productivity, and long term it kills you. So both as a good employee, and as a selfish person, you do what you can to block stress off. For example, if someone changes priorities from A to B and then asks about results for A, you can let that stress you. Or you tell them when they change from A to B "you realise that we spent seven days on A, and that work will be largely wasted", and when you are later asked about progress on A, you don't worry about it but say "you told me to work on B instead, so obviously there is no progress on A.".

And here's a strategy for difficult times: You come to the office on time. You decide what's the most important thing to do today. Then you do it. And when your eight hours are over, you go home. You don't worry about anything else. If someone tries to stress you, you say "no". And next day you come in on time, rested, and repeat.

Answer 9

Congratulations for your offer to become a Tech Lead! It means that you have some trust of your colleagues, due to great work. Keep going! ;)

How do you take on less stress as a Tech Lead?

As part of the most senior team members, and especially if you become a Tech Lead, I think you should consider taking a bigger responsibility in the continuous improvement for your team. If you don't do it, who will?

The first improvements that I see coming are the following :

• Why isn't your team capable to plan and often need to change it's plan due to emergencies? If you have regular sprint planning, why do you need to change the content of the sprints so often? If you can't fix the flow of coming emergencies, can you at least keep some regular time to deal with them?
• Why does team members need to do overtime, especially on a regular basis? Do you need more people on the team? Do you need to set more realistic expectation on what you can produce on a given time interval?

This way, you will take the responsibility for setting an environment where all the team members can do great work without having to face a huge amount of stress and/or overtime.

Is there any chance I'd be able to fill that role and manage to work normal hours and manage stress levels? Has anyone done this successfully before?

The Tech Lead role have various meaning depending of the company, but if you have an "Architect" (which often mean technical expert, or at least having responsibility over technical choices), I suspect the Tech Lead role would be more focused on day-to-day delivery and its related process. So not only some Tech Leads have been able to do this on the past, but that's their mission.

Bottom line : Accept the job and make it clear that you consider that part of your mission to be driving the continuous improvement, and especially the two improvements that you really care about (emergencies properly managed and overtime reduced).

How to do that part of the job might require that you develop new skills though, but that's for other questions ;)

Answer 10

As opposed to other answers, I believe that this job is an interesting experience to have (for a new job down the line).

Depending on where you are, you may be more (say, the EU) or less (say, the US) protected in your job. If you are in a place where you cannot be merely fired for working a normal day then it may be worth a try.

When everything is an emergency, there are no more emergencies.

You do not need to jump between emergencies on your own. You can of course be directed to go from one to the other but the day ends at some point and you are done.

Go home. Switch off your phone. Do not read your emails.

This is hard at the beginning but then you get used to that. It forces your company either to fire you (when this is possible/easy), move you to another job or, maybe, understand that there is a problem with management (least probable version, but I have seen it happening once).

This is an interesting experience for you because handing stress is unfortunately a skill to have in tech.