Dealing with someone who thinks he's “divinely right”

Question

I have recently come across the situation where I have to deal with the person (software architect) who seem to think that the software solution he had come up with is basically "divinely correct" and can be applied for every situation. Without going into too much details on what the solution is, we have done quick analysis of applying the solution to the problem at hand and came away with more questions and problems that I care to list in the question, yet this person persists with applying the solution.

Some of the first attempts to utilize the solution this person come up with produced Rube Goldberg's machines which had been shown to run measurably slower then the previous solutions (no matter how outdated and badly written).

What is basically comes back from this person when questions begin to be asked is: "This is the way I have decided to do it and this is what we will do!"

How do you deal with a person like this?

Answer 1

The only quick solution I have found in these situations is to find a new situation. You are dealing with organizational insanity, and you won't be able to fix it anytime soon. The wrong person has been promoted and his management doesn't seem to know or care. You do not have enough influence to effect a change, and technical arguments will not work.

The alternative is to go along with the ineffective process and bide your time. Eventually the cost overruns will force someone to take notice. The architect will be encouraged to do something else. If you have stayed around, cooperating and winning friends, maybe you will be the next architect.

BTW, I left a very similar situation five years ago. The incompetent technical leaders were replaced last year.

Answer 2

If that person has the decision-making power, then that's that. If it's not meeting with the customer's requirements (i.e. the customer disagrees that the solution meets their requirements) then they don't necessarily have to pay for it (unless a contract says otherwise), and they can say something as simple as, "Ok, I hear why you want to go this way, but that doesn't solve the problem that I need the [software/product/solution] to solve."

Egos run high. This is part of any workplace. When it comes to engineer types, you can try to present objective, measurable performance and quality metrics (if that applies in your situation) - engineers (at least generally) will respond to reasoned arguments. If that fails, then you have to consider who actually has the decision making power, whether or not this is a fight worth fighting, and how it will impact your customers and business. I don't think it hurts to make your concerns known, so long as it is a reasoned, objective point of view, and not a personal attack on the engineer.

All that being said, what we don't see from your question is the engineer's point of view - perhaps you're wrong on this one, perhaps you're not - it's hard to make a determination without knowing both sides.

Answer 3

In simlar situations I've relied on getting a list of resources (books, blogs, Standards and Guidance from the major vendors in your particular development space eg IBM, Microsoft, Idesign, Thoughtworks to name but a few) to back up the points I'm trying to get across and have, sadly, had to produce them at meetings.

If you've gone through that process and are still being told you are, not right, incorrect or they know better. Then do as you are directed to do but keep a hold of your source material if thing go wrong to cover yourself and your own professional integrity. On a positive note, it will help to improve your skill set as you'll learn how to do the necessary research to back your statments and how to deal with difficulty (people, situations and flawed approches).

Finally, just ask how they came to the results of their decisions. Its the job of a software architect to show the intent and purpose of a design and how the working part all fit together to provide a solution.

Answer 4

The thing you can do is talk with him in group about it. If this is a shared effort then you need to see what other people think about his solution and if there is a better alternative.

If you feel the quality of his solution isn't good enough and would make your customer unhappy or jeopardize your project. Take it up with your teamleader or boss. Explain to them why you think his solution isn't correct. Show your alternative. However if you are the only one on your team that thinks he's wrong then you will have to go with the flow I'm afraid.