Dealing with senior engineer who prioritises requirements based on opinion and interestingness

Question

I am an engineer in a product team. We are building something rather new to our department. We do not have much experience with it, thus high uncertainty and risk. Decision making is either personal by the senior engineer or highly consensual (everyone must agree to proceed). Because of high conflict avoidance people agree but do not commit. Polar opposite of disagree and commit. Essentially we have a long, sometimes tiring discussion, agree on something and then just do what we intended to do anyway. And then sunken costs come in to play if someone points out that this is not the right this to do.

A senior engineer who decides on a hardware product requirements and also designs the product himself is putting intersting and complicated (therefore expensive) features as "must have" while features that are not interesting and challenging are considered not necessary. Some examples of such unnecessary feature is related to human safety ("it will be fine, we did is like this before and no one got hurt"), so this is not just disagreement between engineers about how to do things.

The engineer in question considers himself experienced and knowledgeable (20+ years of work experience) but confuses unrelated experience and opinion with facts (mind projection fallacy?). Also, if some feature in being implemented and later it is discovered that it was a bad decision, sunken cost fallacy comes in to play (ala we worked so hard to do this, we must continue working hard to finish it).

Cultural environment does not help. Project management maturity is low, most processes are ad-hoc and basically up to the lead engineer.

Sometimes even an argument "we did it this this way for years" or "we do things differently here", "this otherwise valid point does not apply here because [insert opinion]" comes in to play if someone new to company or team disagrees with something.

How could I approach this?

I am not sure how to name this and will be happy to get some advice on it.

Even though it is related to project management, but this question is about workplace human relationship and personal approach.

Edit, sample of the process application that causes me trouble

Senior makes a personal technical decision without thorough consideration about impact to architecture. Requirements are not analyzed or written, just spoken. Design process and implementation commences. Some time later a feature needs to be added. Personal decision is made. But because I am an expert of the feature I get asked for an opinion by a project manager. I do my homework and it turns out that requirements (especially safety) are not compatible with the design and would require significant effort. Then we have a lengthy discussion and can't come to an agreement, because my solution requires changes to the prior Seniors decision and he basically arguments with fallacies. I know that this will happen in advance when I do homework and I am basically going in to the meeting that will end in "I agree, but I do not commit".

Answer 1

This is a frustrating situation to be in. You obviously care enough about the project/product and/or company to be posting this here which is great. The weapon you need to win this battle is one of Influence.

It sounds as if the senior engineer is functioning as the product owner either by delegation or commandeering. You need to figure out which it is because that greatly impacts your options. Who started the project? Is there a spec that came from outside your group? What other teams are involved? If there are folks outside the team involved, you'll need them as allies to help sway decisions and prioritize. Think about previous interactions with people on this project. Start paying attention to who is talking and making decisions in meetings. Who are people in meetings looking at when questions arise? Who is everyone waiting for in email threads to reply? Figure out who the main players are and make a list, but don't engage them just yet. If this was entirely started within your team, or by the senior engineer in question, then you're going to have to directly work with the senior engineer and your manager to influence change yourself.

If it were me, the first thing I'd do is talk to the senior engineer one on one. You're an adult, they're an adult (presumably). Have an honest and professional discussion. Don't be aggressive or defensive, just talk to them and see if you can understand their motivations behind certain features/prioritization. You might gain new perspective and insight you didn't have before. Or you may inspire them to change their mind. They may also get upset and become agitated. If they have a history of doing this, let your past experiences dictate how much effort you put in here before jumping to...

Speak with your manager. Come prepared with concrete examples to back up your claims, but do not throw this senior engineer under the bus or trash talk them (e.g. do not say things "Soandso is ruining this project by prioritizing useless features."). If there's a spec that was started outside your team, you should read it thoroughly before going to your manager and make double sure that your concerns are valid. You want a civilized discussion that accomplishes several things:

1. I may be reading into it too much, but I wanted to put this as item zero. You mentioned "human safety" in your post. If you genuinely believe that there are truly lives at risk here, you need to make this known as loudly as possible. You don't want this on your hands. If you're manager won't listen, stop here and go to their manager ASAP.
2. Your manager becomes aware that there is disagreement on the team (if they aren't already). Make it clear that you are looking for them to take a more active role in this project to help mediate discussions on prioritization, ensure the team is working towards the decision (and not just doing whatever the hell they want), and keeping things on track for delivery. This is your managers job.
3. Your concerns about which features are prioritized are heard by your manager. Right or wrong, it should trigger them to probe deeper on all sides. Again, concrete examples. Also, bring solutions and suggestions ("I think we should work on X instead because it has Y impact for customers instead of Z impact."). You can mention your one on one discussion with the senior engineer. If you just complain you aren't doing yourself any favors. Ask your manager pointedly what they think of your concerns and how they will follow-up.
4. Your manager realizes you are passionate about this particular problem space. This can also help them with your career growth planning and making sure you're enjoying your work.

Ideally, your manager will spring into action and do magical manager things that helps bring clarity and direction to the team. But since that's rarely how things play out... if you've tried a one on one with both the senior engineer and your manager and feel you aren't moving in a positive direction, that's when you get out your list you made above. Schedule more one on one's with these people to get their perspective and to discuss your thoughts. If these stakeholders are reacting positively to what you're saying and in agreement with your vision that's a good sign. If they aren't, you might be in the wrong and it's time to go with the flow.

If you now have several stakeholders who are willing to fight with you, it's time for a big meeting to discuss. Call it a roadmap/planning/alignment meeting, schedule the stakeholders, your manager, the senior engineer, and the rest of your immediate team (don't exclude people who will be working on this project). Prepare for a grueling and painful experience. You may have to do this multiple times. Unless one of the stakeholders step up, you own this meeting, so you are expected to bring an agenda and drive the conversation. Ideally, you've got a stakeholder or two with some authority and they'll help immensely with this part (don't be afraid to ask one you trust to lead the meeting and see what they say). If it were me, I'd start by saying something like "I've spoken with all of you about some concerns I have on certain features/prioritization with this project. I'd like to discuss each one as a group to help drive clarity and direction for all key stakeholders so we can deliver the project on time and to spec." then proceed to go down the list and see where things go. The end result of this meeting should be an artifact that references the decisions made in this meeting and it should be communicated out broadly. Regardless of the outcome, everyone should now be on the same page and hopefully working together. If there are disagreements, you reference the artifact.

Ultimately, it doesn't sound like you are the one that is accountable if this project fails. The senior engineer has either been put in or has put themselves in this position. You'll have to decide if this is a hill worth dying on. Regardless, take this opportunity to establish a better relationship with your manager and the senior engineer to help improve working together in the future. This will not be the last time you experience this.

Answer 2

Decision making is either personal by the senior engineer or highly consensual (everyone must agree to proceed)...

How could I approach this?

This "either one person decides / or everyone must agree" process seems strange. But apparently management wants it that way. Unless you are management, it seems unlikely you can change the process. You apparently need to work within the process.

If this is the senior engineer who gets to make "personal" decisions, and has already made one, then you do nothing. The decision was made by someone who apparently has the authority to do so. You just go along.

If this is one of the "highly consensual" decisions, then you don't agree and force a long discussion. During the discussion you explain that you don't agree and what you would do differently. If the rest of the team agrees with you, then you can proceed. If not, then apparently someone must compromise.

Answer 3

Good answers already, my addition is on the safety aspect.

As an engineer you cannot ethically compromise on physical safety for end users and are obligated to stand your ground. Make sure you know exactly what you are talking about, but don't back down even if it means job searching.

For the rest of it, you don't have the authority or the professional respect to get things your way so you do what the bosses say.

My strategy is not to fight the little battles, I would focus purely on the things that must be done, the rest is not my problem. So someone in authorities decisions costs the company more? I don't care, it's not my money. I'd just point out options and save myself for the big battles which are a deal breaker for me. You gain more respect this way and you highlight what is important rather than make ineffectual white noise about everything.

Answer 4

From someone who has worked a lot with safety-related development (programming, electronics, machinery, mechanics, automotive).

If you have a project manager but no written specification, said manager is highly incompetent and might be the true source of the problems. There is no excuse for this.

If you are doing safety-related development without written requirements, you are most likely breaking European law. If your product later fails in the field and humans are injured, there will be backlash where authorities demand access to design documents (your technical file). If you can't even produce something as utterly basic as a written spec... very serious consequences. I would guess jail.