How do you approach appealing to formal seniority in a technical discussion? | Hacker News Reader

How do you approach appealing to formal seniority in a technical discussion?

6 pointsbegoon9 comments

How do you approach appealing to formal seniority in a technical discussion? ("Listen, I am a senior/staff/honoured/etc. engineer here"), formal education ("Listen, I'm PhD, actually"), certifications ("I passed an official certification on this"), years of experience ("Trust me, I have been doing it for X years"), etc., without an actual point to bring to the argument?

Do you take any value of what I listed above as extra points to the actual objective details of the conversation? Do you ignore all that and focus on actual related facts brought by parties to the argument?

View on HN

Those are all logical fallacies.

I've been developing software for 40 years, yet there are still times when people who've only been developing software for 5 years or less have better ideas. One secret to surviving in this field for 40 years is leaving your ego at the door and being willing to learn from anyone, including those who are "under" you.

Having said that, from a practical standpoint, there needs to be a person empowered to make the final decision. That person is usually a lead developer, manager, and so forth. If you are that person, then your job is to facilitate the technical discussion and get as many ideas as you can. Remember that every single idea comes with a set of pros and cons - there's no perfect solution. You'll do your team a great favor if you do the analysis and decision-making out in the open.

Sure. In terms of making a decision, yes, in the healthy process, there should be a person with a formal power to decide (and take responsibility) eventually.

I was more curious about the discussion when the parties were speaking on the same level of command.

One way you can do that is to bring the business stakeholders into the discussion. This will help uncover implicit assumptions that may be being made about business needs. The business stakeholders can also help determine how the pros/cons of each solution impact the business and which they're more comfortable with. Business stakeholders won't be able to discuss technical merits, but they can discuss business impacts. This is also a great opportunity to build rapport with your business stakeholders because they learn you're not just a cog in the machine cranking out code. They learn the things to think about and see you more as a valued partner rather than a line item than can be cut to reduce expenses.

One way is to lead the discussion by asking questions and facilitating. You may learn something from others, they see you as thoughtful (and senior), and when necessary you can steer the conversation.

Is it a technical discussion or a work discussion? In a technical discussion you can certainly say something like "my experience has shown X and Y (without documentation), but if you can show evidence for !X or !Y, I'd take a look". Of course, if both sides are asserting facts without documentation, it's more of a pissing match than a technical discussion; but maybe you'd like to come to agreement on what kind of documentation would be acceptable.

In a work discussion, you can say "well, X or Y may be true, but my experience says !X and !Y, and this is my project, so let's assume !X and !Y, and y'all can blame me later when it becomes apparent I was wrong." and if the other party really doesn't want to go along with it, come up with a limited allotment of time for them to investigate after which either you'll be convinced to change your assumptions or to allocate more time, or they'll go ahead with your assumptions even if they don't like it.

I would lose a healthy dose of respect for you if you trotted one of these out in a conversation with me in an attempt to convince me of something. As another comment mentions, argument from authority is literally a logical fallacy (https://en.m.wikipedia.org/wiki/Argument_from_authority). Make an argument based on knowledge and facts, and be ready to accept opposing viewpoints, rather than browbeating the other party into submission. There are times when a decision is already made and disagree-and-commit is desirable, but there are more tactful approaches than just throwing your seniority around.

Don't just reach for lines like these if you don't have an evidence-based reason to back it up. The moment you do that, your coworkers will realize that you are just trying to shut them down and don't care about having an intellectually honest discussion. And besides, what good are experience and credentials if they don't give you the knowledge to substantiate your ideas?

If there's any other good reason for that (typical corporate externalities like "hey, I'm really sorry but management says we have to <do really stupid thing>, this is not up for debate"), that's one thing, but if it reflects entirely on you then that's a really bad look IMO.

Sometimes you should listen to it if it’s in a good faith.

Because experience does matter.

Often really experienced people have hi quality intuitions they can’t explain and break down to pieces clear to everyone in the room.

I don’t. I care about ideas well articulated not your title.

Reply on news.ycombinator.com