How to work with a knowledgeable but condescending senior?

Question

My manager wants me to challenge a software architect who is senior to the both of us and who has a a history of reacting poorly to this, going so far as to push colleagues out of the team. How can I approach this situation?

I am a software developer in a team of 8 members which includes a senior software architect, who provides us instructions about designs. This is in a medium sized company in north America.

I am introverted in general and like to avoid conflicts. According to my manager, I perform adequately for my role and received bonus for my performance. He does however think there are times where I tend to follow the architect's decision despite having good ideas of my own. He wants me to challenge the architect more often in a respectful manner.

The architect is a lot more knowledgeable than me on theories of computer science. He is also hard working and timely in his responses. The issue is he is always condescending in his responses. Some examples:

• if I come with a question with two possible solutions to know his opinion, instead of sharing what he thinks is better, he would say "Did you read chapter 'x' on the book 'y' or this particular paper?". He would then preach for 5 minutes what a good software developer should know before actually giving his opinion.
• he objects to pull requests that he hasn't approved, finding trivial faults in 50 different places quoting some theories/concepts and blocking the request
• in our stand-ups, he interrupts when other people are talking and doesn't miss an opportunity to portray how smart he is
• he favours theoretical best practices over simple, functional designs despite this leading to frequent complaints from users

The architect is above our manager in the organisation and has a lot of power and is close with the higher-ups, so my manager avoids getting involved. I want to tread carefully after what happened to a couple of senior developers who previously tried to address this. The architect ganged up on them with another principal engineer ultimately forcing them to move to another team. They've actually invited me to join them but I like my current team, the technology and the work we do. I would like to establish a better balance in my interactions with the architect though, because I have undoubtedly learned a lot from him and study the topics he points me to in my own time.

How can I navigate this situation effectively?

Options that I could think are:

• Speak with the person (may make it better or worse for a narcissist)
• Speak with manager (might be labelled not a team-player)
• Speak with HR (probably requires more concrete misbehaviour)
• Move to another team (possible, but don't like the technologies so much)
• Move to another company
• Any other options is greatly appreciated

Answer 1

Bluntly, it sounds like this "senior architect" fellow is a real problem for your company. It sounds like he wants a stranglehold on your development work. He does two things that taken together are destructive. He won't answer reasonable questions, AND he nitpicks other peoples' work. Oh, yeah, and he doesn't respect you enough to let you say your piece in meetings. Yowza.

Let's give him the benefit of the doubt for a moment, and assume that he is committed to helping people like you develop your skills by asking you to figure stuff out for yourselves. That job is called "teaching", and a big part of teaching is helping people think through hard questions. Pulling rank "I know that and you don't" is just plain silly as a teaching method.

The guy is toxic.

But that's not what you asked. Your manager wants you to push back when this guy overcomplicates things. It's obvious your manager respects your engineering acumen and believes you could get good things done if you could balance out this architect's theoretical perfectionism.

So you're stuck in the middle. Ouch.

For some consolation while you're working on this go read https://TheDailyWTF.com Your architect plays a starring role.

And, level with you manager. Tell him, bluntly, that this guy is hard for you to challenge (your manager surely already knows he's toxic). Ask for advice on how best to do that. Consider asking him to get support from your company's executives for your task of ignoring or simplifying this architect's advice. Make it so the two of you are working together on this problem. If you and your manager can, together, succeed at this you will learn a lot and do really good things for your career. But you have to be in it together.

If your manager can't or won't support you in this, go join that other team. No whizbang technology is worth the damage to your career and personal life caused by an unrestrained toxic bigshot. Plus you'll be on a good team and learn a lot.

Good luck and strength.

Answer 2

I'm going to swing the other way and say that this Architect is being reasonable. Being an Architect is a very high position and involves understanding the best practices, the best systems and the in's and out's of the technologies in use.

if I come with a question with two possible solutions to know his opinion, instead of sharing what he thinks is better, he would say "Did you read chapter 'x' on the book 'y' or this particular paper?". He would then preach for 5 minutes what a good software developer should know before actually giving his opinion.

Honestly, it sounds like your Architect is really annoyed by constant questions regarding the same thing. While this is a flaw on his part (Part of his job is to learn and maintain knowledge), I can understand where this comes from if people keep asking him questions that he considers trivial.

he objects to pull requests that he hasn't approved, finding trivial faults in 50 different places quoting some theories/concepts and blocking the request

This sounds like the architect is ensuring the code that is being developed follows the principles of whatever method/solution is being applied. This can be important, because some methods only work really well if they are applied properly. E.g. there isn't much point in Object oriented coding if you just break large chunks of code into random functions because the code is getting too long.

In reality, I doubt an Architect should actually be looking at the code and approving changes like this. Usually a senior developer would fill this role because they are actively working on the code, while an architect is looking at the big picture.

in our stand-ups, he interrupts when other people are talking and doesn't miss an opportunity to portray how smart he is

This can be pretty normal for a stand up. A stand up is a quick report on what you are doing and what is blocking you. This way anyone who might be able to assist you in overcoming an issue can step up and help. Since you given us any example scenarios, I can only assume that he is offering pointers, but doing so very poorly.

he favours theoretical best practices over simple, functional designs despite this leading to frequent complaints from users

Same as some of the stuff above. Your architect is probably trying to make sure you conform to certain practices and methodologies to ensure the end goal of having good, readable, maintainable code is reached. Simple function designs are great and a good way of moving fast, but when you create large projects, you need to look at the big picture. A lot of theories work in theory, but fail in reality, simply because people skip steps which seem useless or redundant.

Summary: Your Architect is probably a very technical person and also a very busy person. They don't have the time to explain everything, but because the same issues get brought up again and again, they waste time complaining instead of addressing the issue at hand.

The easiest solution is to simply trust them. If they start to rant, cut them off. Tell them you need their decision and accept it. Of course, this isn't what your manager wants.

The other way is to simply talk to them. Ask them questions like "I have solution A and solution B. Solution A is faster and easier to use. you recommended solution B. Why is that?" Engage in the conversation, have a back and forth. Once you understand why the Architect chose a certain solution or method or coding practice, you have a better chance of proposing a solution and convincing the architect that your method is better for the business. "Solution A is better despite being less sophisticated because it will only be run once a week. The redundancy in Solution B would take too long to develop and is too extensive to cover the simple task of combining excel sheets together".

Answer 3

This question has already an accepted answer, but I would like to share my view.

I think, this is a political war between that senior architect and your manager. It’s not your war, don’t get involve.

If I was you I would have read every thing that the SA address in his answers and try my best to learn from him.If you believe he is better, then listen to him!

Answer 4

Your manager hopefully doesn't want you to challenge anyone, but they want to see problems being solved in a better way. The functional issue I see is only one:

he [senior architect, SA] favours theoretical best practices over simple, functional designs despite this leading to frequent complaints from users

In teams it all boils down to who has the decision-making power and responsibility. Ask your manager, what decisions you can make on your own. If they come back with "I want you to come up with solution together with SA" then ask who has to make the final decision. Proactively ask for an areas or parts of specification where you can make decisions on your own. Promise to consult anyone involved, but somebody has to be in charge.

Other points you raise have a lot to do with difficult personality of the SA.

Answer 5

You need a team effort to deal with such behavior. You have been asked to push back, showing that you have legitimately good ideas and skills. If you don't push back you will be smothered.

If you push back, the rant from him will likely start. When he is ranting, use language that proves you are not listening. For example if his name is Bob, then when he starts going on, repeatedly say Bob Bob Bob Bob ... you need to get him to stop talking before he can hear. Then directly ask him to explain what is physically wrong with your idea.

At the same time, the manager needs to interject minor objections being made into mountains.

Keep pulling back to the core purpose of the task. The task is XYZ. Would my solution accomplish it? Any time he directs to the theoretical and starts ranting, Bob Bob Bob him and pull back to the physical.

Don't be rude. Let all the insults and nonsense about engineers should know this and that, slide. Don't get roped in but instead stick to the one point.

For reviews, has this architect produced a solidified coding style document? Continually getting 50+ blocks implies there is no formal process and he is applying his methodology when it suits.

If there is a formal code doc, then follow it. If not, work with the manager to get one. You can also look into clang-format if its purely a stylistic thing. Warning though, code style formalization meetings tend to get brutal. The end result is good though.