How to combat appeals to authority that have no facts

Question

I have an issue where my project leader is making ipse dixit statements (meaning [it's true because] he said it himself). It takes time to verify whether his statements are true or not (usually untrue), by which time a decision has been made, and will not be reversed.

As an example, "I'm rejecting your code change (from a code review to make some new code more readable) because your code is slower than the currently proposed code and uses more memory" when neither way has been benchmarked. After benchmarking, my code turns out to be faster, and uses less memory, but the other code has been accepted, and my code will no longer be considered.

He is currently using his authority to be "right", instead of waiting for facts that everyone can agree on. How can I diplomatically expose and take unverified statements out of consideration when talking to him?

Answer 1

Pick your battles.

If your aim is for this guy to prove and validate his claims "as facts", then you're only going to create an atmosphere of confrontation and distrust.

You could soften his claims with

Well, maybe

And leave it at that. In software development, "faster" isn't always "better", there's coding practices, security considerations, maintainability, etc.

And if you're both constructing code that does the same thing (i.e. you're comparing one against another on a like-for-like basis), then there's something wrong in the team - you don't typically developers duplicating work for no real reason.

Answer 2

TLDR: You need to accept your leader's authority, but you should point out incorrect assumptions, provide feedback, attempt to establish standards and teach him no argument is often better than a faulty one

Follow the herd leader

Exactly as Fattie said in a comment, as a team you will often encounter situations that will require a decision to be made and often enough there is no time to ditch out all the details to make a perfect fact based decision. Often enough it doesn't matter what is a few ms faster and code style can be arguable. At some point someone needs to decide which solution to go for so the team can move on to bigger challenges. Once such a decision has been made, as a team member, you need to accept that decision and move on.

Responsibility of the good herd leader

BUT: it is your team leader's task to lead by example and "take the team with him", when he's making such authoritative decisions. He can either explain why he thinks something is better or decide by authority or by standard. Usually you want as much standards for such situations based on facts as possible, so situations like this can be quickly resolved by citing the standard and are avoided most of the time anyway as the standard is known. If he argues unconvincingly or even repeatedly factually wrong that shows bad leadership skills and you should help him get better at it. That does require feedback.

Feedback

For instance, you can question his argument. If he says it is faster:

Is it really faster? Can you explain why? Last time we had something similar the other solution was faster. Look, I've got this similar test here...

Try to abstract away from individual things to general problems for which a standard way to solve them can be discussed, tested once and then widely applied.

If you don't have data ready when a decision is made, you can also bring it up in one of the next meetings.

I've read up/tested on lookup times of individual items in a linked list and a hash map and the hash map is always faster, maybe we should define a standard to always use hash maps for such problems from now on.

Pick your battles wisely. Don't try to fix some minor issue that only occurs once, after the fact, but try to get policies established that you can refer to. Note that performance isn't the ultimate measure, readability often trumps performance gains.

Don't attack the authority of your team lead, but try to support him:

Look, if you tell me this is the way we do things here for whatever reason, that's fine. But this is not faster for [reason], so if you want to squeeze out a little more speed, maybe we should give variant B a try.

Don't argue about "my variant" vs. "your variant", try to detach yourself from different options available. That way it is not as much between you and him, but about choosing the best option together.