Protect Your Team from Weekend Work
Is it unfair your team is constantly called for weekend work?
Are your team members complaining that they have no social life anymore?
Are they threatening to leave if something does not change?
The good news is, there are many scenarios where you can reduce or remove the need for your team in their downtime. First, you need to understand why you team is being called for weekend work. Let's go through a few reasons and how we might prevent them from happening.
Reasons For Weekend Work
A Class A, highest priority ticket has come in on Friday evening as everyone is preparing to leave - a customer's site has crashed. Your team must drop everything (including their social plans) to get online and come up with a solution.
After working all night Friday and half of Saturday, your team puts in a fix and calls it a day. But they are not happy - their weekend with their family and friends has been cancelled, and they wonder if the job is worth these weekend calls.
Prevent Site Outages
After the issue has been resolved, take a whiteboard or pen and paper and answer these questions.
- What did the user experience? For example, did they receive an alarm, get a 500 response error, etc.?
- Why did the site go down?
- Did something like this happen before?
- Who was involved / what expertise was required?
- How can we prevent this from happening ever again?
Once you have these answered, put a plan in place to mitigate this issue happening ever again. Sometimes, it can be as simple as adding a new test case. Other times it may be more complicated and involve setting up new test environments. Look at the cost/reward of fixing it going forward and make a decision.
Late Release Work
The release deadline fast approaches. There is only a few days left until the software is released. Everything is late, and your team are under pressure to deliver.
One of the tasks your team was working on is blocked because the environment was down the past two days. Now the environment is up, but management has requested the task be worked on over the weekend and completed by Monday morning.
Prevent Late Release Work
All teams understand the pressure of having features that are late and in danger of not making the deadline.
To prevent late delivery of features, here are a list of DON'Ts you can apply.
- Don't underestimate the work. Always take your final estimate and add an extra 20% onto it.
- Don't plan optimistically. Assume that things will go wrong, other teams will be late, code will break. In Ireland, there is a phrase "It'll be grand", meaning that everything will work itself out. It won't be grand. Nothing will work itself out. Plan accordingly.
- Don't promise delivery dates that are not feasible. Pressure from management may tempt you to do this. Do not give in. Have data to backup your claims.
- Don't promise delivery dates without doing your homework and gathering as much data as possible. List out as many tasks as possible and estimate each of them. What are your risks? How could your risks affect the delivery date? Are the risks low, medium or high?
- Don't hide problems from your manager during the release. Is a task going to be late? Tell your manager asap and show what you are doing to mitigate it.
An experienced team lead will have this list off by heart without even realising it. Have you got more Don'ts you have learned the hard way? Comment them below.
Late Sprint Work
This depends on your team. There are teams that are not strict on their sprint commitments, and there are other teams which require themselves to work weekends if the work is not ready to deliver.
Prevent Late Sprint Work
Late sprint work usually comes down to poor sprint planning in the first place.
- Did your sprint planning cover this task sufficiently?
- Why did the team underestimate this task in their planning?
- What can you take from this going forward to ensure future similar tasks are estimated more accurately?
Effective sprint planning is difficult, but is worth it to get the team in the habit of delivering their committed work.
Supporting Other Teams
If you are leading a high performing team, then more than likely you will have at least one or more persons who act as experts or specialists in a particular area. This is great for your team...most of the time.
A downside of being an expert is you get called up for consultation on things you were not even involved in. You could be called into an escalation because another team is behind in their commitments. I have often seen specialists called into very tricky situations like performance test failures, where an application is failing at scale and nobody knows why. Scenarios like this are dangerous for experts, because it could bleed your evening and weekends dry.
Prevent Supporting Other Teams
The title here seems unprofessional. Experts are there to act as experts, right?
This may be true, but the fact is that even experts don't like getting called on a Friday evening or Saturday morning and asked to go online. As the team lead, it is your job to protect your team as much as possible in their downtime, so that they can focus more effectively during working hours.
There is a host of reasons your team expert could be called into work unexpectedly. Work with your team to brainstorm how to reduce the need for being called to unplanned work. Here are some suggestions.
- Train a member from the other team in some debugging techniques for the particular area of expertise.
- Document troubleshooting procedures for various scenarios. Share this document with the organisation.
- If a call comes in, brainstorm some possible solutions for the caller to explore. There may not be a need for you to be online. Give enough information that they can proceed with troubleshooting.
As the team lead, your goal is to keep everyone happy as much as possible. Can you prevent the team from being called in the first place by preparing in advance during working hours? Discuss the above with the experts in your team and get a plan together to protect their weekends.
Dealing With Necessary Weekend Work
Sometimes weekend work is absolutely necessary - there is no way around it. That bug isn't fixing itself and the release date isn't moving, so your team is left with no choice.
Now your job as team lead is to reduce the team's pain as much as possible. Here are some suggestions for reducing this pain.
- Instead of John working Saturday and Sunday, can John work Saturday and Jess work Sunday?
- Challenge the work that is requested. Can some part of it can be investigated on Monday instead of now?
- Develop a rota for the next 4-8 weekends so that your team can plan in advance that they might need to be online. This will also prevent last minute requests to your team members and ruining their weekend plans.
- Is there a support team that could take some of the requested work? In my case, I discovered a 'secret' team that were setup specifically to support internal stakeholder escalations, yet my team had been supporting these cases for the past few months. Nowadays, any time an internal stakeholder asks my team directly for support, I forward their email to the dedicated support team. They're happy, I'm happy, and my team are none the wiser that I have protected their evening and weekend.
- Work smart, not hard. Most likely, your team do not need to be online 24/7. If so, propose time slots that your team will be online to check emails and answer requests. For example, when my team are asked to be online over the weekend 'just in case' something goes wrong, I insist that we give a list of times where we will be online and contactable. In general, the time slots are 10-11am and 3-4pm. Outside of these times, my team can relax and go about their day.
If all else fails and someone has to be online to support a problem, make sure they are not working alone. Any work is painful when it is done alone, and weekend work it is 10 times worse. It may be you that needs to make the sacrifice and go online to brainstorm ideas and support in the troubleshooting. They will be secretly grateful for your company, and won't feel the weight of the world on their shoulders.