Workpace Hierarchy: Establishing respect with mature co-worker

Question

I work as a programmer and have been lead developer on a new project at my company for some time. I haven't been given the official title of lead developer, but for this project it is a role I have naturally filled and acknowledged in practice.

Recently, a new programmer started on the same project. He has some experience and skills. However, he brings with him a lot of bad practices which I need him to stop and also to follow the patterns already set in place.

I don't mean to talk myself up, but for the purposes of this question I do believe that I'm quite skilled at what I do and still best suited to role of leading development, aside from the project manager who doesn't code.

Anyway, I am relatively young in comparison to the new programmer. I have tried talking to him about some of the practices I desire him to stop. Early on he took it on-board, but now I am finding him more difficult to deal with. I've asked him to make changes which he initially agrees to but never follows through. I can sense some annoyance on his part.

Probably due to the age difference he doesn't appreciate being told how to do his job by someone half his age. I'm not afraid of conflict, but I would like him to listen to me without making him feel like I'm too big for my boots or that I am belittling him. I would like his contributions to be welcomed.

Knowing myself, I'm not exactly a push over so I want to be careful that I'm not being too forceful with my opinion either. I don't want to come across as a 'code nazi' so to speak. I've kept my engagement to suggestions, comments and the odd request, not so much a command or order.

If it comes to it, I will speak with the project manager about my concerns but I don't want to create any ill-will by superseding him in that way.

How might I best establish some more respect from my mature co-worker without causing a major drama or issue?

Answer 1

Probably due to the age difference he doesn't appreciate being told how to do his job by someone half his age. I'm not afraid of conflict, but I would like him to listen to me without making him feel like I'm too big for my boots or that I am belittling him. I would like his contributions to be welcomed.

My personal experience with an age (or experience) difference has been to emphasize my experience with the current company which will be more applicable than their outside experience. Unfortunately I've had to throw in a lot of reassuring compliments as well as be dismissive of certain things about myself. I find if I explain I have superior knowledge of how THIS company operates but assure them that I don't have as much experience as they do outside, or that that might not be the RIGHT way to do things, just how WE do things. I emphasize my more humble earlier career positions and try to make sure I come across as just wanting to be helpful.

You also need to demonstrate that you really are good at your job and could be helpful to him. If he hasn't seen that through actions he won't believe your words. It might just take time for him to realize your professional value.

Things to Consider in Your Approach

Do you have to proof his code? Who is both of yours boss? If you have no official responsibility for his work (maybe only a personal/ethical one that you want to see 'your' project done the right way) I'd take the rule of only telling him how to do a particular thing once. After you've given him specific feedback on a particular issue, if you aren't his boss and won't be blamed if his code isn't good, don't mention it again.

Secondly, are you trying to be helpful in other ways? If you are only offering him criticism on his code but not explaining how the company's 401k works when he asks, I can understand why he's not going to want to listen to you.

Thirdly, make sure you give him credit when he's picked something up quickly or when he has an idea that's good. Or if he suggests something that makes sense, but won't work for your project, make sure you give him credit for the good idea while acknowledging that unfortunately that's not the way it's set up there.

Lastly - don't go to the project manager (especially not unless that person is his or your supervisor) with complaints that he isn't cooperating. Instead, either propose that guidelines need to be established so that the code is good and everyone is conforming. Volunteer that you'd like to set that up because the project is important to you and you want to make sure everyone's on the same page. If they aren't giving you authority over other programmers though or responsibility for his work output in the long term there's very little you can do. If his stuff comes through and is wrong, your company has obviously not decided it's your responsibility to deal with it. That's an appropriate question for your boss or the PM, but try to frame it as an organizational/training issue, not a personality one.

Answer 2

Short answer: Simply put, respect must be earned and mutual.

I see in your question that you have had a number of cases where you've made recommendations to your co-worker to change things. However, have you acknowledged the good things that he does? If you want someone to listen, you have to meet them half way.

I would suggest finding some positive elements of your co-worker's work effort and well, not praise them, but state simply that you find that to be a good way to do something. Then you can suggest that something else might be better served doing it this way.

Rapport requires give and take. If you're only pushing on the take and ignoring the give then it's no wonder that your co-worker is getting his back up. Give a little, and see what happens :)

Answer 3

Ask for the title

With the title you are his superior and have every right to tell him what to do/make suggestions and expect them to be followed through. Without the title, you're just another guy at his level with no authority, bossing him around.

When he first started you were more experienced at the company and he was the new guy, so of course he was happy to accept your guidance: now he's found his feet, he doesn't feel the need to follow the guidance of someone who has no position of authority over him.

You may be under the understanding that you're the senior or have taken the lead role, but he may not know that, or may not understand how it's expected to work at the company. This means you either need the formal title, or need to have management make it clear that when it comes to this project, you are the lead.

If you don't have the title (permanent, or just an official, temporary, project-specific one), you are not his superior and there is no hierarchy, so you cannot establish hierarchical respect: it's that simple.

Answer 4

Well first I think you are assuming that this is an age issue. This might be but you are assuming. It could just be a you issue as in he either doesn't like you or doesn't value your opinion.

See that is what I don't get - why are you trying to tell him what to do? You are not the lead developer nor are you his boss nor are you the PM. You aren't even recognized as the technical lead of the project.

You and him are equal. So back off. It is fine to give some concise critiquing but you have worn him out. If you want to continue then you need to go to your boss or the real Lead Developer with your concerns and this person can work with his boss. Then you can come to an agreement on how you will work/code/whatever.

How do you establish hierarchy? Show that you are a good enough worker to get the actual title to move up and quit thinking you are better than your current position.

Answer 5

This response assumes you ARE the lead developer. Not that you are "in practice", or kind of a lead developer. But that you really are, as far as PM is concerned, the lead developer for this team.

Being indirect and tentative actually undermines the authority you seek to establish. You need to reassert your authority formally, then direct the newcomer's work from that higher ground.

To do so, ask your PM to formally, in a team meeting, stress to everyone that your role on project X is that of a lead developer, and that you are charged with managing persons A and B's work. The PM should also state that A and B should/will follow your lead, ask if that is clear to everyone and get affirmative nod or a "yes", and air any questions or comments.

Also, document your interaction with A and B. Try to have the majority of your feedback on paper rather than verbal. Verbal suggestions are unverifiable and therefore unenforceable. Email provides a specific and time stamped record of interaction which can be used as evidence if needed to make a case about insubordination or reasons for lower quality product from A and B.

Use good judgment to decide when it is worth cc'ing your PM on your emails to A and B and when it's sufficient to just email them (e.g., cc the PM when sending out agenda or follow-up summary from status checks with A and B, but not when answering minor questions by email that might make A and B feel patronized and insecure).

In your status checks with PM, speak from the facts and report any guidance that you have given the team, what part of that has been taken up and implemented, and what part has been ignored or implemented incorrectly requiring rework and extending the timeframe or affecting quality. Talk not with the goal of telling on why A's work sucks, but from objective principles: this makes sense to do this way because it will be faster/clearer/more effective down the road, however despite repeat suggestions this is not currently being reflected in A's code, period. The PM can make up his own mind about the severity of the issues you raise, and act accordingly.

One big caveat to the above advice is the assumption that your suggestions are, in fact, better and represent more effective / efficient ways of doing things than what A and B would have been doing using their own work styles and practices. This is a pretty big caveat. What might seem as the way to go to you, might be intentionally not practiced by the older/more experienced developer for reasons that they would struggle to explain, but based on which they have formed their coding habits over the years.

Sometimes the perception of being correct overshadows one's own lack of experience and willingness to consider alternative approaches.

So, my first and foremost advice would be to use the issues that come up between you and the older developer as opportunities for reflection on your own practice, the rationale and evidence for this practice in fact being superior, and whether the incremental change in quality or efficiency is worth the trouble of imposing it onto the guy who might be a bit settled in his ways. Good luck!

Answer 6

I haven't been given the official title of lead developer, but for this project it is a role I have naturally filled and acknowledged in practice.

So you are the most clever here, but who have told you this, or is it so that you have just decided yourself? It is same as to step down on the deck of the random ship and complain no sailor recognizes you as a captain. Why should they? You are not. The ship may look dirty for you, and maybe sailing the completely wrong way, but this does not make you the captain automatically.

To have others following you, you either need to earn the deserved respect or be the official supervisor. If none of the two, do not expect others taking you as a leader.

Answer 7

To add to other answers:

1) Don't criticise if you don't have the better answer ready and/or you aren't willing to do the work needed to apply it.

2) Don't criticise at all. Ask. "Hey, I see you wrote it this way. I think I would have written it that way. What did I miss, or does it matter?" Assume you're just as likely to be wrong, or at least present it that way, and listen carefully to the answer. Discuss, don't assert and don't argue. You may indeed have missed something. Or there may be legacy reasons it can't be done the way you prefer. Or it may be a matter of style and really not matter in this case. Or he may say one of these, but having heard the suggestion he might try it your way next time. Stop trying to win and focus on sharing ideas; that way everyone wins.