Lead rudely demands fixing alleged error on weekend

Friday, the lead wrote an email to the projects developers asking to be in touch in case something happens. However, I never agreed to work this weekend. It is neither part of my legal obligations as an employee, nor par for the course in our job as an informal practice (at least, not in our department).

When setting boundaries, it's important to set them as early as possible.

There are essentially 3 approaches you could have taken on Friday:

1. Indicate that you are willing to keep in touch, and indicate your expected response time -- for example, that you may check your phone every hour or so, but do not promise to reply within minutes.
2. Indicate that you are willing to work on Sunday (full day or half day), in exchange for another day or half day off, or extra pay.
3. Indicate that you have prior engagements -- whether true or not -- and that you will not be able to accommodate this last minute request, this time, but that you are willing to try and accommodate future requests in the future.

All of these responses are professional. All of these responses allow the other party to know exactly where you stand, and give them a chance to respond if they judge your stance is not compatible with their goals.

Also note that all of them avoid any snark -- like pointing the lack of planning, or how poor an idea it is to do large changes when everyone's off. Keeping the snark off is also part of being professional.

About an hour ago, our lead posted in our work chat. He included some code snippet, tagged me, and complained about some error that, in his view, was caused by my changes. I haven't investigated it yet. The related task was indeed done by me some weeks ago. It was tested, accepted by the QA, and closed.

Why are you reading your work chat if you're not working?

As a European -- I've worked in France, the Netherlands, and Switzerland -- I simply do NOT read the work chat when off-work. I cannot actually, I am not connected to anything work-related on my personal devices.

I have been on-call in the past, and at the time I used a work-issued device (phone, later phone & laptop) to be reachable, and to be able to connect from home.

I have also worked from home (Covid...) and I simply turned off my work laptop when off-work. Systematically.

This sets up boundaries very clearly. No matter how dire the situation, I will simply not see any message addressed to me before Monday morning when I roll into work. If dedicated support overnight or during the week-end is necessary (I've done both), then it has to pre-arranged. I'm even willing to accommodate last-minute arrangements -- prior to leaving work on Friday -- IF I have no plan.

On the other hand, reading your work chat while not working weakens these boundaries, and creates an expectation that if pinged, you will (perhaps with some delay) react. And it's even worse if you've reacted to such messages in the past, obviously.

Obviously the risk of being sacked according to your response cannot necessarily be averted, and is something only you can judge.

Unless you have profoundly important plans for this particular weekend, then these things are often about some kind of principle of the matter, such as the need for rest, respect for plans, or the need to set boundaries on a manager whose only limit is what they can get away with.

It's hard to tell exactly what principle is at stake in your case here. You acknowledge such weekend availability is not a normal practice in your department (nor culturally), and you've been there 18 months (so enough time to indicate this demand for weekend work is very exceptional).

I think what's really happening here is that your lead is annoyed that a bug he considers your responsibility was not fixed, and both as an act of contrition and since it is now an emergency, expects you to fix it immediately.

If so, then I think your best course of action would be to join in the work and solve the problem, whilst either stating your annoyance (if the issues involved are mild and/or your fault is ambiguous), or (if it really raises a systematic issue) stating your desire to have a more thorough conversation about it later next week.

I think as well, the fact your lead mentioned the potential need for availability on Friday suggests there was some advance thought. If such availability is strictly necessary during future deployments, then you might want to open a conversation about the need for more notice and specific agreement, and compensation (at the very least, time off in lieu).

EDIT: I see the question was edited from referring to the bug being raised "a while ago" (i.e. some significant amount of days or weeks ago, where you could theoretically have fixed the bug in normal hours) to being raised "an hour ago"!

That is obviously a lot more egregious, but I think the advice still stands that (as a first-time occurrence in 18 months of employment) it is best to investigate the situation and help fix for now, and then talk about the matters of principle this raises later in the week.

I focused on things besides the core question about working the weekend:

Today, Sunday, is an important deployment of our product. They chose almost the latest version which wasn't tested that much (27 November). Perhaps, there were some crucial features whose delivery couldn't, in their view, be postponed.

About an hour ago, our lead posted in our work chat. He included some code snippet, tagged me, and complained about some error that, in his view, was caused by my changes. I haven't investigated it yet. The related task was indeed done by me some weeks ago. It was tested, accepted by the QA, and closed.

UPD: It turned out there was invalid data in the DB. It was not a conclusion of mine — it was determined by an independent party that I had no influence over whatsoever (the head of another department responsible for that particular functionality). Graceful handling of that invalid data was never part of any task that I'm aware of. The task was tested on valid DB data.

It appears that the bigger issue is the fact that they are trying to deploy versions that haven't been fully tested, and their solution they are suggesting involves making last minute code changes that would not have enough time to be fully tested.

Companies/projects pick the best time to deploy updates. They also decide who needs to be on call or ready to go. Doing the deployment on the weekend isn't the issue. The fact that they are asking for code changes that late in the deployment process is problematic. While it is possible that your code broke the system (your update shows it didn't), but asking for more changes with zero testing time could easily lead to more potential problems.

If this is the way they do their releases, I would be more concerned about code stability than helping on one weekend.

My background is software development and I've been a technical program manager. From what I understand of the scenario -- and I've got only one side of it -- the problem lies at the program management level.

I won't comment on what you should've done at the time: too late! Also, depends on information I don't have: what I could do in those circumstances with my employer and what you could do in your circumstances with your employer may be different, and I don't know well enough to advise.

However, I do have some suggestions for next steps. A post implementation review is in order: this was mismanaged. Among improvements I can see:

• Improve testing: something happened outside the bounds of what was tested, which suggests the testing was not sufficient. I like to see testing include 'bad cases' to show what happens when things fail. Expanding the tests to include bad input/malformed data could have caught this earlier.

• Arrange support: if it seems likely someone will need to be called on during deployment, arrange it ahead of time. Where I am, this means not just notifying, but paying for their on-call time (which goes up to overtime if they actually get called).

• Test deployment: some things can be deployed directly, safely. Other things are complex or important enough to warrant dry runs, deploying to a similar environment to confirm deployment scripts and what can go wrong. I had a deployment years ago that took three practice runs before we went to production... but it deployed flawlessly and according to (revised) plan once we did.

• Assess risks: some of what I suggested above would benefit from a risk assessment. What can go wrong, and how can we plan to deal with it?

These all are responsibilities of the program manager to arrange, as is a post implementation review (especially when things don't go smoothly, but even when they do). As someone who was affected by the events, or even just an observer on the team, in my opinion it is appropriate, and I would deem it professional, to ask for such a review.

(After a fashion, this is what I'm doing right now. I see a situation that didn't go as well as it should have, I look for ways to make it not go that way again!)

I think it's true that in general, European workplaces have stricter boundaries around the invasion of personal time from work life.

If this hasn't come up in the first 18 months of the job, it's entirely reasonable to politely ask how necessary this weekend work is, and what expectations are going forward. It's also reasonable to push back against those new demands, though I would advise joint problem-solving as a first resort. Eg, "with this mechanism, we can release without taking the shared database offline, so it can be done at the end of a normal work day". Is the release process slow and infrequent? Might you not just have observed it before?

It is also not uncommon to be on call to support releases, across the world in my experience. If you don't like being called in your personal time, go to extra effort to ensure your code is of high quality and deploys cleanly in other environments without error-prone steps.

Unless you have something on that you absolutely can't miss you should spend time trying to fix the problem raised.

I know you didn't agree to it and you legally don't have todo it, but mistakes happen even in the best run companies; and the cost to the company will be high if the problem isn't fixed. It's up to you of course but showing willingness to help when the company is in a hole is often a good idea.

Also when it comes time to do a post mortem on this incident you don't want the main story to be about how you delayed the release by refusing to look at a bug. If you are the one who fixes the bug, or at least makes a good attempt it enables you to shift the focus to other more important issues: how did the bug get there? Why wasn't it found earlier (in time to fix it well before the release)? Was enough testing done? What would have happened if you hadn't been available? Did you in fact create it? You also get to talk about whether you should be answering calls on your days off. But if you don't respond all those questions will be overshadowed by the fact you didn't try to save the release when you could have done.

I am assuming that this is the first time this has happened to you. If the company makes a habit of this that's a completely different question.

Put out the fire first - Be a team player. I am saying that from an employers perspective.

Effort doesn't equal work. Deliverables equals work.

If you don't want to be someone they can depend on for deployments, just say so. Just don't be surprised when you are left behind on promotions, etc.

It is much better to learn to design a deployment method that is less disruptive to life and easier to manage resources. That is a lesson to be learned by management. Offer up ideas after this deployment is past.

At my company, we got rid of "Crunch time" years ago. There is a clear expectation that we support our team members and clients during deployments. Which brings up the next question.

WHAT FRICKING IDIOT HASN'T LEARNED TO AVOID WEEKEND DEPLOYMENTS. (Yes, I know that wasn't part of your question but it is the root cause of the issue.)

There is hardly a valid reason left to require deployment on a weekend. Leave it in the 90s where it belongs. Please don't say how special a company is that they must have a weekend deployment.

UPDATE - to clarify for the DVs and are reading my answer as black and white.

A business can only survive and thrive by satisfying the clients. Having an attitude that doesn't reflect this understanding limits a person's career growth.

An engaged team member's thoughts and opinions will carry more weight.

Am I suggesting that a company shouldn't respect their team members - heck no. That isn't what I am saying at all. What I am saying, if possible to be available then help. Pushback if it gets out of hand.

As for when deployments can get done, since most companies are or have moved to global or 24/7/365 operations, the idea of weekends and afterhours being that special is diminished. Does that mean all deployments can be weekday? No, but if Monday through Thursday is possible, then why not?

I am proud that we have very low turn over at my company. A big part of it is that we try to live "Never Mistake Good Luck for Good Planning".

If OP's company planned ahead, they would had volunteers for the deployment and none of the grief. And I wouldn't have the DVs :)