How to deal with a developer who thinks all technical questions should be answered by him only?

Question

I work as a UX Program manager in a large creative team where we take on a number of projects. The team by itself is pretty amazing and I get along with everyone and enjoy learning with everyone. However, recently I have had problems with one of the senior developers who takes offense to everything I say about technical aspects (I do have a fairly decent technical background so I understand technology as well as I understand user experience) and makes constant comments like these:

• I am the techie here and you should not talk about this
• I know what I am talking about and you should not be talking about things like this
• For technical questions, you come to me and don't directly ask questions to the team (he was recently promoted to a tech lead)
• Let techies answer technical questions. Program managers should not be talking about these things

On top of this, if I accidently ignore him or miss his email or calls, the next time he gets an opportunity, he makes sure he does the same thing openly in public when people are watching. When I asked him about his behaviour, he says, " Well, didn't you do this three days ago to me when you didn't respond to me when I called you? Now you know."

I tried talking to him and trying to sort things out but he seems to enjoy making a scene by shouting loudly in the office and responding in a loud voice to questions so that everyone can hear him (we sit in a fairly round room place so if your voice is slightly loud everyone can hear you).

I am at my wits' end about how to deal with him.

One option would be to ignore him, but since our projects are end to end and not only UX and since I oversee the whole project, I have to work with the development team too.

Other option is to pull him down to size but that won't work since I am pretty sure it will end in a loud argument with him which I am eager to avoid since I have a pretty good reputation with the rest of the team.

Input and advice would be helpful. Thanks.

Answer 1

There are a couple of points to address here:

Public confrontations are unprofessional. The two of you should discuss this sort of issue in private. He may want a senior manager present, and if you are able, accommodate such a request. If the public confrontations continue, then warn him in writing, and also CC a senior manager who oversees you both. Nip that in the bud.

I would also point out that the world does not revolve around him. If you miss a call, then follow up by other means. If he still considers your turnaround time to be too long, then instruct him that in the future, he should email you and a second responsible party. In the event you are not available, then the other party can follow up with him.

---

As for the "I am the techie here" comments. Everyone in work has a power base. This can be defined by different ways. But for him it sounds like he has an "Expert Power".

This means his role of leader is defined by his technical skills. So when dealing with him, you need to defer to him in technical matters even if you are the manager of the overall project. By questioning his decisions you undermine his power base, which in turn will elicit a negative response.

A technical power base is destroyed if the person displays a lack of technical knowledge in that field to his/her peers. It is possible in the past that either you displayed a lack of knowledge, or you pointed out something that would have undermined him.

So you need to acknowledge him as the expert. This doesn't mean you let him do what he wants, but he is responsible for explaining the actions/directions his team plans to take. If you feel it is not going in a good direction, ask him to explain why he is doing X instead of Y. Ignoring you is not an option, so once you force him to explain the reasons you can then use them to help underline his power base, which in turn makes him more favourable to helping you later.

For more reading on this I recommend "Understanding Organizations" by Charles Handy.

Answer 2

It is important that the different people working on a project understand what their roles are.

As the technical lead, he seems to believe that he is supposed to be involved in technical decisions. When you comment on the technical aspects, he may be taking this as (a) taking over his job and (b) making commitments about the product that you really can't.

Taking over his job

It sounds like the tech lead feels like you're trying to take over his job. You, as program manager, are making technical comments, which he may see as decisions/commitments. Let's look at it from his perspective. You have a technical background, but is it with this product? Are you familiar with the codebase? Are you familiar with the code changes that are already planned by the tech lead - not the features that will be added, but the implementation details?

As technical lead, what exactly is his role? What is he responsible for? Making the decisions? Designing the product? Providing time estimates? Guiding technical implementation? Whatever is his responsibility, this needs to be made clear - to the both of you.

Let's reverse the roles. If he were to start commenting about program management aspects would you be offended? If he started making comments about the schedule as it reflects other teams' work to other teams, to your boss, or to the vice president, how would that look? If he started talking to production and asking them about when they can start engaging in this project, would that be OK? What if he were to tell customers that the project would be ready for their acceptance testing on a particular date - one that you had never expressed? What if you had other things you were trying to schedule and knew that the date would never work? Or if you had a private discussion with your manager and s/he was pressuring you for a different date? What if he went to the VP and started talking about how QA's schedule was not in alignment with the rest of the project, but you knew that it was?

You need to let him be responsible for doing his job, and you need to be responsible for doing yours. You have plenty of work to do as a project manager without trying to take over the technical implementation.

So how do you use your technical knowledge?

If you can't design stuff for the dev team, and you can't comment on implementations, how can you use your technical knowledge? You can consider what the dev team is committing to and ask intelligent questions from the angle of project management. Don't tell them what database to use or what the implications will be, but ask them for a breakdown of how long it will take to use their database of choice, and future impacts (incorporating bug fixes and upgrades). If you know that their breakdown is missing something (like integration testing with the database) then ask them to add that to the estimate.

Use your knowledge as a BS detector, which will help you determine if work can be re-scheduled to be faster. When the dev team says that it'll take 4 weeks to write a new SQL query, dig deeper. Ask for a time breakdown. Make sure that the time breakdown is reasonable. Where things are out of whack, dig deeper there - with more time breakdowns.

Tools to help you fix this

There are tools, like RACI (responsible, accountable, consulted, informed) charts that are designed to serve just this purpose.

Whatever you do, be constructive!

He's rubbed you the wrong way, and I'm sure you've rubbed him the wrong way. The relationship is at a rough spot, but that doesn't mean it's unsalvageable. You can still work to recover the relationship. One of the most important things here is to recognize that you both really have the same goal: make the company make money so you can both get paid. This means that you need to approach conversations collaboratively. You need to demonstrate, possibly multiple times, in a way that he can recognize, that you really are there to help.

Answer 3

Do not back-off. Unless someone is my boss and doesn't want my opinion, no one gets to use "this is my area of expertise and not yours" as the sole reason to discredit your input. Status or title doesn't make right or wrong (Again, talking about dealing with a coworker and not a superior.). Admit when you're wrong, but only after you've been presented with a persuasive arguement (not in the yelling and screaming type of arguement). He can Feel free to ignore you, but he can't get away with that in a meeting.

This person is a bully and needs to be called-out on it. Continue to give your input during meetings as you see fit. Having a project manager with some technical expertise should open-up the lines of communication with a lead developer and/or the rest of the team. I can understand why he doesn't want you interupting his team or going around his back. If that's how the company stucture is set-up, you should respect that. But in no way does he get to categorically dismiss your input when you have an opinion or question on a technical matter. He doesn't have to like it; that's not part of his job.

Answer 4

If you oversee the entire project, I think it is normal you have some input in some of the technical aspects. That being said, I also understand that the lead technical engineer feels that he is in charge of the technical part, and feels you are micro managing (big pitfall for technically schooled managers). The way he expresses that is of course a bit crude and disruptive.

I think the two of you should sit down, and discuss how you want to approach your collaboration. Explicitly discuss how his behaviour is not helping the project. Conversely, also listen to him as he explains why you should not be involved in taking such technical decisions. After you both have said your mind, try and come up with a better way of collaborating by making some kind of compromise. Try and keep your discussion rational and factual, not emotional.

If this kind of conversation does not lead to a better working relationship, I would escalate this to a manager higher up. He or she then will have to make a decision on what needs to be done.

Answer 5

The technical is either very insecure about his position, or resents your influence in the group.

You could present your answers as:

My understanding of the problem is [...blah...], and that a solution could
look like [...blah...], based on [...blah..]. Of course, I'm a UX person, so
you may gain more technical insight from [tech lead], and I might not have
it all  right. 

This approach lets you help people appropriately, while openly deferring to the expertise of the tech lead. It also showcases your technical skill, and your ability to reason. And if the tech lead is a loser, he'll have to put in a lot of time to contradict your opinions to spite you, and everybody will see it. And if he is a real leader (not just because he was appointed), he can enhance his status in the group by "blessing" your correct reasoning, and perhaps augmenting it with his expertise, or by gently pointing out things you might not have known, which would cause you to reason incorrectly. Over time, you can build mutual trust with your tech lead and status within your team.

I do this all the time. Although I'm a developer I have enough brain cells to have opinions about how to best respond to business demands for software functionality. I always state the case for my opinion, and then say, "...but there may be business factors I'm not aware of which could reasonably lead to a very different decision. I defer to the product leader." Sometimes my opinions are right. Sometimes they are wrong, And sometimes they're right, but must be deferred because of short-term business requirements unknown to me which supercede long-term business requirements. But my team always knows that my opinions are well-reasoned from what I know.

Answer 6

I think the key point is "he was recently promoted to a tech lead".

That makes this a critical time for him to establish his authority and the boundaries of his position. He may feel, rightly or wrongly, that you are undermining his efforts to be the tech lead in reality, not just in the org chart. For the moment, you and the tech lead need to work out clear boundaries between your roles, and be extremely careful to respect those boundaries.

There may be more room for informal blurring of roles later, when everyone, yourself and the tech lead included, is solidly used to regarding him as the tech lead.