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?

  • 3
    "I've kept my engagement to suggestions, comments and the odd request, not so much a command or order." - this seems like the problem. You need to say in concrete terms what you want and when. E.g. I noticed your function foo doesn't use our naming convention. I would like to see this fixed in time for the next release.
    – Brandin
    Nov 19, 2015 at 12:39
  • 3
    @PrivateQuestioner If you are actually the acting lead developer, you need to be able to say "yes" without any qualification. If you have to add "in practice" to your response then maybe it's not clear to everyone that you are actually have the authority.
    – Brandin
    Nov 19, 2015 at 12:43
  • 7
    One other thing to consider - have you tried asking him his reasoning for doing these "bad practices"? I've found most technical folks respond best if they have some input to how things are done, and that there are a lot of "best practices" being taught that could benefit from some tweaking with real world experience. Sometimes it's bad habits, so I'm not saying you're wrong. However working out pros and cons can get folks more invested in doing the right thing than just insisting they follow instructions.
    – ColleenV
    Nov 19, 2015 at 14:20
  • 1
    I think you should think about how ageist you are (and how that probably comes off to your peer as well). People don't flaunt your authority because they are older than you, they flaunt it because you have none that they can see. Difficult people come in all ages. I am older and work very well with several bosses I have had that are half my age, respect has nothing to with age but with how you treat people. It sounds to me as if you assume he is going to be worse because he is old. If I get that feeling, I'd bet he does too even if that is not the message you intended to send.
    – HLGEM
    Nov 19, 2015 at 16:13
  • 1
    Was is past tense. It is not working naturally. If management recognized you as the team lead they would have given the title.
    – paparazzo
    Nov 19, 2015 at 23:00

7 Answers 7


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.

  • Thank you, the PM can be considered our supervisor. I don't set out to necessarily check his work, but during the course of my own work I often need to go into it. Since we are using technologies new to the company everyone else has naturally looked to myself for the way forward and an air of ownership grew around it. I will try to lead by example and be diplomatic with my inclination to take the lead. Nov 19, 2015 at 5:01
  • 5
    @PrivateQuestioner - I feel like I am in some SNL skit. Why would you be deemed lead because the technologies are new? You are not the lead. You are not the lead. After all of the decent advice that people gave you this is your statement? Do you understand that just because you are inclined to be the lead has no bearing on you being the lead? I am inclined with being imperial ruler and it isn't working out for me either. Also I would remove your picture from your profile - as you might want to keep this question private.
    – blankip
    Nov 19, 2015 at 6:36
  • 1
    blankip: I was originally hired for this role due to my experience and skills with those technologies, which the previous staff had little experience with. I think there is a few assumptions flying around so I haven't described the situation quite right. Since the beginning, for all intensive purposes I have been the lead, only lacking the official title as it wasn't necessary. Nov 19, 2015 at 22:34

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 :)

  • I failed to mention that, yes, credit has been given where credit was due. Nov 19, 2015 at 1:46
  • 2
    @PrivateQuestioner Then continue to work on that avenue. Try to work together as a team, not a pair of individuals.
    – Jane S
    Nov 19, 2015 at 1:46
  • Issue is some of his practices are just plain wrong/bad. I'm happy to let personal pet-peeves slide, but if it effects the overall quality of the product I don't want to simply ignore them. Nov 19, 2015 at 2:00
  • 1
    I'm not arguing that point in any way (I'm a developer with 20+ years experience). But you need to still work together to improve his - and perhaps your - code quality. If you want to establish respect, you have to give it as well as earn it.
    – Jane S
    Nov 19, 2015 at 2:03

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.

  • 2
    I have found in life that it is never a good idea to accept responsibility when you aren't given the corresponding authority of the official role. You have no recourse if someone disputes your unofficial role. Make the lead position official or stop attempting to lead.
    – HLGEM
    Nov 19, 2015 at 16:11
  • Thank you, and you are right. Without a more official structure this arrangement won't work effectively for long. Nov 19, 2015 at 23:08

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.

  • Well, as it stands there is no official lead developer. There's not a lot of official titles in the company but rather more unofficial roles. When it boils down to it, I have been unofficially the lead developer on this project for quite some time. Nov 19, 2015 at 1:52
  • 5
    OK - unless someone has broadcast that you are the lead for the project then same thing goes. So either everyone knows you are the lead or not. This guy is not listening to the make-believe lead. If someone told you this that has a real job title I would make sure they announce this. If they don't, then they either don't trust you as lead or were just telling you crap in the first place (maybe to make you feel good).
    – blankip
    Nov 19, 2015 at 1:57
  • 2
    @PrivateQuestioner - Also I don't want to come off like I am saying you aren't the lead or don't have the ability. It is to the contrary. I don't know you. But understand your coworker is in the same place I am - he doesn't know. Someone will listen to you because they are foolish and listen to everyone, they are told to listen to you, or you have built enough cred with the person that they believe in what you say. Good news is that this guy isn't so foolish to listen to everyone.
    – blankip
    Nov 19, 2015 at 6:10
  • I realise now that this question is difficult one to answer because strangers on the Internet don't exactly know me or the company. I will seek to have a more official structure put in place. If that puts me as lead, great, if not then at least everyone knows their place. Nov 19, 2015 at 22:53

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!

  • Thank you. I think the time has come to discuss the official structure of our dev team as it has been officially unstructured up to now. Everything worked out naturally until now. Nov 19, 2015 at 22:49
  • @PrivateQuestioner, sounds like the right approach. If the response was helpful, please consider upvote ;) I also appreciate the question, it hit close to home and gave food for thought.
    – A.S
    Nov 20, 2015 at 13:42

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.


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.

You must log in to answer this question.

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