4

Background

I've been at my current workplace for going on 5 months and was hired as a senior dev to work on a new iteration of our product alongside a Lead Architect.

Problem

The Lead Architect. It feels like I'm not working on a team but I'm working within a dictatorship. He simply isn't open to input from anyone else.

For instance; I fixed a UI issue according to what our UX dev suggested and when I committed the fix he immediately say it wasn't being merged and "that's not how it's done." However later, for a different bug, I asked him what should be done - he said ask the UX guy. Ironic.

Having spoken to my colleagues - they have all agreed and said that that's just his personality and it's been raised as issues by two people before who actually quit. Yet nothing has been done by management to change this. I believe this is because he is in such a strong position within the company (He designed all the previous programs we created and is the go-to-guy about them) that management would rather lose me, and others, than risk losing him.

How can I handle this? How can I somehow get him to be open to input from me and the other developers?

This is about improving the overall process we use for building our product which I don't think can be changed until we fix this first.

Improve this question
5
  • By definition the architect is the person with the final word on how things are going to be done. In other words, your superior. Your working relationship should accommodate that.
    – Thorbjørn Ravn Andersen
    Mar 4, 2016 at 0:14
  • I agree that an architect would have the final word on a feature but when there's no first word or words permitted from anyone else then it's a problem and creates a negative working environment
    – Katana24
    Mar 4, 2016 at 10:17
  • Does this lead Architect wear Roman Sandles Cardigan and shorts in the middle of winter?
    – Autistic
    Mar 4, 2016 at 10:27
  • 1
    First you need to figure out why you want the lead to accept input from you and others. If there is a technical reason, then you have the "We need to find another way to make this work to make what we do of the highest possible quality". If it is because your ego does not work well in a setting where you are told what to do, then you have a good starting point for finding out how important that is to you. In any way, if you cannot resolve this with the lead yourself, then consider bringing it up to your common superior.
    – Thorbjørn Ravn Andersen
    Mar 4, 2016 at 11:21
  • @haven't had a 1-on-1 meeting yet. I'll let you know what happens when I have
    – Katana24
    Mar 8, 2016 at 10:25

3 Answers 3

Reset to default
12

Two people have failed and quit over it according to your question, think long and hard before you go down that track.

My strategy to get someone to accept my input is fairly simple (if I can't just force them). I don't make changes such as the one you made without consulting them first, I would do this by email cc'ing whoever is my boss. Outline how I think something should be done, and then wait for an OK to go ahead. It interrupts workflow a bit at first, but they get used to it, and it saves having a bunch of work thrown out because someone didn't like it. I don't think I'm always right, and I don't really care 'how' they want a problem solved, I'll do whatever I'm paid to do in that respect.

While it sounds time consuming, it actually isn't, it's become second nature to me and I do it as a matter of course, it's saved untold headaches and potential personality clashes. As well as leaving a clear paper trail covering my back if there's any issues.

Improve this answer
1
  • 2
    Yes and it establishes a "norm". If the same thing is repeated and OK'ed in the exact same fashion over and over you might be able to cut out the emails but at least get these things established or make them ask you to stop.
    – blankip
    Mar 3, 2016 at 23:52
6

It's my belief that dealing with difficult people lies in realizing why they're being difficult. Instead of talking with your colleagues, sit down with your lead and say "Look, we had this situation (exactly as you explained it to us). I know you've been with this company for a while and I just want to get a handle on your thought process so I can make things work more smoothly going forward."

The problem with some people, especially if they're high performers, is their thought process is everywhere. They sometimes think that after a hasty explanation, you're right there with them, and sure in some cases if you aren't it upsets them. Don't let it upset you though, because I think it's okay to ask questions, and get a better understanding of the people component here, even if you obviously know what you're doing in your role. I wouldn't let egos clash.

Improve this answer
1
  • I really, really like this advice! It is far better to enlist your architect as an ally. Also, the exercise of explaining "the big picture" to OP may get architect to take a second look at his ideas himself. Only once OP has won architect's respect (unfair but hey) will architect be open to changes.
    – akaioi
    Oct 22, 2017 at 2:58
4

My advice is keep a paper trail. Propose your fix to the architect (even the input from the UX dev), have him provide meaningful detailed feedback and iterate until your code is accepted. It's hard to tell if the architect just doesn't trust you yet or will never trust you. If the latter, then the architect has create a perfect position of power as original author and gatekeeper. You don't want to be stuck in this position, because he'll sabotage your progress for his job security.

Improve this answer
1
  • I agree with your point on trust - it certainly seems to be an issue
    – Katana24
    Mar 4, 2016 at 10:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .