Disagreements in project decisions led me to lose all motivation

Question

We're a distributed team working on a new software project. My local team all joined around December, I joined in January. Nobody in my local team knows about the current codebase. Up until June, it was all design meetings (i was not involved), and now (July) we're working on actual implementation. The project is due at the end of this year.

Last Monday there was a meeting about implementation decisions and it turned into a design decision meeting for one of our biggest components. The question at hand was between solutions A and B. There were disagreements from all sides, tenured engineers proposed solution B but our project managers and a principal engineer want to go with solution A. So the decision was to go with solution A.

Now, upon hearing all arguments, I am not convinced solution A is the right approach, and I told my manager, but he told me that we're going with A regardless. My manager (who is also quite new to the team) is convinced solution A will free us from operational work, but I believe it will introduce regressions that will delay launch.

The problem I have is that the fact that less tenured engineers (in the company, not in their lives) were able to impose their decision over more experienced engineers made me lose all motivation. I believe we're shooting ourselves in the foot, I don't believe we're going to make it on time, and I can foresee us being asked to working overtime.

I trust my team's principal engineer, but I don't believe he ever worked in the codebase involved to understand the problems it has. I've started making changes in existing systems and I'm already running into problems that no one considered in the design meetings.

How do I recover from this? My mental health is deteriorating faster than ever.

I thought of bringing this up to my manager in my 1:1 that there are many unknowns that we haven't figured out in the design phase and they will impact the project, but i'm at this weird state of "I don't know what I don't know" so I don't really know what data to present.

Answer 1

Firstly, it is right and proper for experienced engineers to raise objections when they think a wrong decision has been made. That is part of the value that experience brings. By raising your objection, you did the right thing.

The decision has now been made. It is not one you (or the other engineers?) like. This, unfortunately, is a part of professional life. Not all decisions will go your way, all you can really ask for is that your voice is heard, as it seems it has been. Nevertheless, once a decision has been made, the right and proper thing to do is to follow that decision. It has been made clear that your employer expects you to do it, therefore, you need to do it. (Speaking as a manager, there are few things less helpful than an employee who refuses to accept that a decision has been made. It doesn't bring the work any closer to being done.)

If the decision is so objectionable that you simply cannot live with it, you could leave. This would be quite a serious step to take, and perhaps you may decide this is not worth quitting over. If that's the case, live with the decision. Only you can decide this.

If you go along with it, and things go badly, your objections are on record. A retrospective or postmortem may help people learn to listen to you next time (though of course raise this tactfully, rather than saying "I told you so"). I do not know your circumstances or your company, so I cannot say what your options will be if asked to do overtime to compensate for the bad decision, but "asked" implies you may have the option of saying "no".

If the location of the decision-making power in this company is something that concerns you, it would be reasonable to talk about this in a 1:1 or retrospective (again, tactfully). However, the blunt truth is that while good managers and leaders will listen to their staff, they are normally expected to have the final say when there is disagreement - someone needs to. The downside is that they carry the can when things go wrong (in theory at least; it doesn't always work out so idealistically).

In the extreme case, if you decide that you do not ever want to have decisions imposed on you by someone else, you could start your own company. All the decision-making will then be on you (for better or for worse!). Clearly this option would not suit everyone, but for as long as you choose to be an employee of someone else's company, the above considerations will continue to apply.

Answer 2

Here are some options for you:

1. Find something else to care about.

You are clearly very attached to your work and many people see that as a big part of their identity. When you see that work being wasted, it causes you pain. I get it. I have had that happen to me multiple times.

I just find some other things to care about and identify with when that happens. Perhaps pick up a major side project or go contribute to open source (see your employment agreement about this). If you have any, you might invest more time into your kids. Maybe you spend time painting or learning about economics or get a master's degree.

Basically, find a way to make your job a paycheck for you psychologically and less a part of your identity.

2. Find a new job.

A classic suggestion here on The Workplace, but given that you are probably an experienced software engineer, not an unreasonable one to easily accomplish. Switch on #opentowork on LinkedIn or visit Stack Overflow jobs and see what else is out there.

I have a year of experience and even I get interesting offers from just being open on LinkedIn. Maybe it is time for something new?

3. Join the average employee and spend the rest of the time preparing to exit.

The average employee is neither engaged at work nor terribly productive. They are also planning to quit. They still do not get fired. I have friends who care enough about their jobs to get their paycheck and otherwise are spending most of the time in their job training for their next job.

In most positions, there is flexibility to scale back contributions without anything being visible. Decline meeting requests unless truly required, halt improvement initiatives and mostly keep your head down and code. All that time spent fighting architecture and timeline decisions could be instead spent on you. Find a way to carve out three hours a day for Udemy and learn some new skills.

6 months is plenty of time to plan an exit around a new skill. So what if the plane is headed for disaster? You spent the time weaving a parachute. If things get bad, you can casually jump out the back.

You are not going to care about this project again, especially since I would bet you are right and the problems will just keep compounding. So make a plan to leave. The world is full of interesting puzzles. No need to be so attached to this one.

Answer 3

This is a fundamental problem with any type of job - "should I do what I deem right or what the client explicitly wants"?

I think it is professional to perceive yourself exactly as an employee of your manager and not as their parent. Your job is to do what they require, no matter how inefficient or wrong it may seem to you.

Of course, as a true professional, you have the full right to explain your objections and even better - document them for later reference, in case needed. Also, if you think, the manager's decision would incur further time and efforts than formally expected from you, you are in your right to ask for overtime payment/ payment increase/ promotion.

But in all cases, your actions should revolve around meeting your "client" requirements. It is not your job to decide what is the best decision for them. It is your job to propose the best decision for what they stated that they wanted.

If they are not sure what they want, then it is your job to explain options, revealing advantages and disadvantages of each option and then leave them to make their own mind.

(Of course there are exceptions such as medicine, construction, etc, where the employee carries the moral and legal obligation to prevent the client from self-harming choices. But those exceptions are out of context in this question).

For some reason, software engineers insist that they should decide what is good for the company and become very emotional if things do not go their way, to the extent of losing motivation and having mental health concerns, just like you describe. Employers like to spoil software engineers, because supply of such is limited and as a result, engineers get the wrong impression about their roles in the work process.