8 mins
You have 0 further articles remaining this month. Join LeadDev.com for free to read unlimited articles.

in partnership with

Work can be stressful, but using these four techniques can slow things down and help you make clearer decisions.

In an ideal world, there would be no need for any job to cause stress. Unfortunately in a world of distributed software teams, constant deadlines, meetings (often across time zones and continents), and demands of the business or your clients, stress is inevitable. That doesn’t mean it can’t be managed, dealt with, or reduced.

Every team at every company I have ever been on, whether that is in a senior lead role, or as a junior individual contributor, has had discussions about workload.

The reality is that hiring a new person onto the team will often cause that team’s workload to increase. No company wants to hire people and stay still. As a technical lead on the team, it’s your responsibility to manage not only yourself, but also the team’s welfare, workload, and levels of stress or anxiety. It is important to make sure the team is working effectively, that you are striking the right balance of projects, and everyone on the team feels respected and looked after. 

That is even more true in the current climate, where there have been huge amounts of redundancies and restructuring of companies both in and outside of tech. With that as the backdrop, it’s understandable that anxiety levels are raised beyond normal.

Here are four strategies that have helped me manage stress and wellbeing, both on a personal level, and for my team. I hope they can help you too.

Jellyfish

Strategy one: clear communication

In my experience, a consistent contribution to stress is a lack of clarity at work. This could be deadlines or a lack of clarity for the team on what the priorities are and how you as the senior engineer should plan work.

It may also be personal stress. Are you unclear about your progression at the company? Do you know what you should be working on to get that promotion in two years time? Do you even have a clear sense of your progression?

I tackle this by ensuring the team communication is clear and that as a small team you feel in sync with each other. The solution is not more meetings, but ensuring you are prepared for any regular syncs, and find a process that works well for you all.

When it comes to deadlines, clarity around the specifics of what is needed and when tends to help. Do you need the entire feature shipped, or is a minimum viable product (MVP) enough for us to A/B test? There is a huge difference in workload and effort between those options. 

If people are constantly reaching out to your team requesting bug fixes or new features, that is not only distracting but adds stress. It can be hard to say no to these requests, particularly if you are a less experienced member of the team, and you have a more senior person asking you. I like to make sure that all requests of this nature are sent through me, so I can assess, delegate, or reject those plans as required.

It is also a time to be candid with your manager about challenges facing you or your team members. If someone in a different team is constantly interrupting your workflows, you may need your manager’s help to speak to them and remind them of the proper process to follow. 

On a personal progression front, I like to explicitly ask my manager on a regular basis what I am working towards, ideally agreeing a timeframe for the next milestone, and understanding what I need to improve or demonstrate to reach it.

Strategy two: what is really urgent?

In my role as the Tech Lead of our team, I am naturally the person others reach out to to ask about our workload, priorities, or if we have considered this feature that they would really like built.

First, I try to avoid getting stressed by people reaching out. Ultimately they are only trying to help or suggest ideas, and I would rather they reach out to me than disrupt random members of the team. Even if I can sometimes begin to feel overwhelmed by requests, I remember that it is a positive that other people feel involved and confident enough to reach out to you, and that ultimately we all want the same end goal: to build a better product.

Second, it is important to set expectations. We work on a yearly but also quarterly basis, so when people reach out with ideas that do not fit into that broad roadmap, I am able to immediately tell them it is unlikely to be actioned, even if I may think it’s a great idea.

In my experience, work that is urgent is rarely actually urgent. I like to establish with people who are pushing for work (in particular bug fixes on a product) how important they are: is it that this impacts 50% of users (clearly urgent!), or that it impacts one user that happens to be vocal on social media?

In an ideal world, we would immediately fix all bugs, but in the real world with plans, features, and deadlines, this is not possible. It is amazing how often when I push back, something that was a top priority situation can actually wait a few weeks, or have a quick ten minute fix applied which buys us more time.

Strategy three: don’t forget to code

This is perhaps a more selfish strategy, but as you become more senior as an engineer, the likelihood is that you will end up doing more work that is not directly coding. That is the nature of progressing into Tech Lead-shaped roles – and I really enjoy the architecture, design and planning side of that – but I also really enjoy coding and find the act of building and shipping a feature immensely satisfying.

Sometimes when I am feeling a bit stressed, or demotivated, I realize that I have not had the satisfaction of shipping something recently, so I try to find some work that I can do and fit it into  my week. It might be that this week is planning heavy, but I will carve out a couple of hours to fix some bugs, or progress a feature to being ready for code review by a teammate.

I also block out time in my calendar where I will decline meetings, and ensure I have time to make progress on a piece of work – whether that is at the design doc, planning, or implementation stage. I don’t block out too much time; I need to be present and available if my team needs any help, but most requests can wait an hour or two. 

I have recently been experimenting at work with turning off chat entirely for a couple of hours so I don’t get distracted. So far no one has noticed, I have not missed any urgent pings, and it has enabled me to get my headphones on and ship things to our users.

Strategy four: a change of scenery

Since the COVID-19 pandemic I have primarily worked from home. This is a personal preference as I save time commuting, have invested in a nice home office environment, and do not get quite the same benefits of travelling to the office as others, because my team is not based in the same country as me. You may be the other way around and love the office – but whichever way you fall on this, I hope you will agree that a change of scenery can be a huge boost.

This can be as simple as a brief change of environment – for me, a dog walk to get some fresh air is often a nice boost – or it can be changing your working situation for a morning. I tend to go to the office once every week or two to work in a new space. A coffee shop also works for me – as long as the internet is good. It is astounding how often doing this will unblock things and help me figure out the problem, or take a breather before replying to a particular email.

I have found that now many people work remotely, it is easier to work from new locations for longer. I am writing this from a coffee shop in the Netherlands, far from home, where my wife and I are working remotely for a few weeks. We have both commented on the fact that being somewhere so different has been mentally refreshing. This may be an extreme example – but even a few days in an Airbnb within a short drive or train ride of your home might be a nice option if you can take it. 

Conclusion

In challenging, uncertain times, managing the wellbeing of you and your team is even more critical than normal. These strategies I have outlined have helped me and my team communicate more clearly, ensured that we understand our priorities, and that others know the correct processes to suggest feature work without unnecessary disruptions.

Leaning into the flexibility of remote working lets us keep our environments fresh and provide extra headspace when we’re having a particularly bad day. I would encourage everyone to think about ways you can implement something similar into your working life. Think about what is  causing stress, and ask if it can be reduced. Is it always the same project, or the same team that adds to your workload? Are you feeling stressed because you are lacking personal satisfaction from your current role? Whatever it is, it can be dealt with, and I hope this starts to help you reach that point.

Jellyfish

Recognizing and preventing burnout in your teams
Episode 02 Recognizing and preventing burnout in your teams
What recent data tells us about developer productivity and team health
Episode 04 What recent data tells us about developer productivity and team health