24

I am the team lead of a team with quite a diverse background in both age and knowledge. 2 COBOL developers around 60 years old, 1 business person, one project manager, and 3 Java developers. I am the most experienced Java developer and I also did the architecture design around the product we develop so I also act as architect. Now the problem is that the PM asked me to be team lead and I have very significant problems with the 2 developers that are around 60 years old. Just for comparison I am 38 years old with 18 years experience.

The two senior developers are questioning and competing with me on every possible occasion. Even though we develop Java applications and not COBOL it just happens that we are doing Core transformation so we need their knowledge which technically is not very relevant to what we do. It is very tiring and I really don't like my team lead position at the moment. I feel that at one moment it will just generate an open conflict which I prefer to avoid.

I am considering to go to my PM and directly state that I don't want to be team lead in this situation. What are my options? It should be noted that one of the old COBOL programmers is in my opinion not very well with her head. So I am not sure I can actually reason with her. At the same time they have worked with the other COBOL developer for 30 years and they defend each other on every occasion. So the situation when it comes to reasoning is a bit special.

More specifics:

Meetings very often are dragged in. One of the reasons I became team lead was the PM trying to put more structure and reduce the meetings and let the Java developers drive the project.

The COBOL developers need special attention all the time. They involve themselves into the Java development seeking explanations for everything. Very often they argue about things they don't understand.

Example situation: The COBOL developer finds out a new feature and wants to add it. Then I mark it as good to have and then a discussion happens about who am I to decide if it is good to have or MUST. At the end I find out that the developer has no idea about the Moscow prioritisation. Still the discussion drags on.

Another example: They need something to analyse all the time, while at the same time they are not able to deliver. We can not create smaller tasks for them because they want to be involved in everything.

At least on two occasions I have been the recipient of something similar to "Who am I to decide" or "Why should I decide". I find it actually pretty abusive. At the same time I have created the design of the complete application and I am the reporter of 180 Jira tasks. 180!!!!! for the last 3 months. This is in contrast to them reporting 0 tasks.

  • 2
    The two seniour developers are questioning and competing with me on every possible occasion. Can you be more specific with when and how this happens? Are they just dragging out meetings with a lot of alternative suggestions or are they actively going against instructions in doing the work? Trying to get the other developers to do things differently? Insisting your way won't work but not having an alternative? – BSMP Dec 16 '19 at 18:18
  • 4
    The COBOL developers are your team members too. What do they want? Training in the new technologies, reassurance of job security, support in moving to another job elsewhere? These things matter. You seem to be imagining yourself as leader of a Java team, and are complaining about these "interlopers". But focussing on the project and forgetting about the people rarely ends well... – Joe Stevens Dec 16 '19 at 22:13
  • 1
    Why are your team members deciding if something is a Must, Should, or Could? That’s a decision for the Product Owner, isn’t it? – nick012000 Dec 17 '19 at 7:15
  • 2
    @nick012000 this is not agile team. – Pesho Dec 17 '19 at 7:21
  • 3
    This whole situation seems to me like the PM trying to solve these specific problems you're talking about. "Who are you to decide?" gets a very simple answer now - you are a team leader and you have been given the authority to make such judgement and decisions. You're not on even ground anymore in the company and if they don't do the things their boss (now you) is telling them to, they're basically not doing their job, which in extreme cases you can easily escalate up to bring consequences. – johnyu Dec 17 '19 at 13:12
37

What path do you want your career to take? Are you one of those developers who want nothing more than to get their headphones on, put their head down and churn out lines of beautiful, well-structured code? Or do you want to work outside your IDE to deal with internal and external stakeholders (sales, support, customers, product managers) to drive projects to completion and follow a career path heading towards Head of Engineering/CTO.

That's what should determine your response to this situation.

If you just want to code and you are not comfortable in team lead role, then there is no benefit to you in continuing to fill the position. It's not the career path you want and you risk becoming stressed and your coding work suffering. You - and your employer - would probably be better off if you didn't take it on any longer than necessary.

If, however, you want to take the alternative route, then grab this opportunity with both hands and figure out how to make it work for you. Leadership roles have very different challenges to developer roles - so you are always likely to feel as though you've been thrown in at the deep end the first time out. You can shy away from it this time but, until you grasp the nettle, all subsequent attempts are likely to turn out the same way.

I made a similar transition and, like you, found myself feeling like a fish out of water until I got to grips with the role. Everybody has their own style - you need to find what works for you and that will take time. If it helps, to begin with I concentrated on just a handful of simple things at the very beginning.

  • What's the next step? I asked myself this constantly. What's the next step needed to get this work done? Do you need to do a proof of concept? Does somebody need to research something? Do you need something from the customer? Identify what that thing is and the person responsible for it. Agree a time for delivery and touch base regularly with them to see if the time is slipping. Never assign a task to "the team" because everybody will wait for somebody else to do it - and it will never get done.
  • Figure out the personalities. Different people respond to different stimuli. Some will need an arm around the shoulder, some a kick in the backside. Some excel with praise and attaboys and others want to know they have some input into decisions etc.. Figure this out and you'll know how best to deal with individual team members. This is half of the key to the conflict resolution challenges facing you - the other being...
  • Be decisive. Don't appear too dithering. Your team need to have confidence in you - make decisions, make them confidently and make them reasonably quickly. That's not to say rush into it - that would be foolish. If you need to, get the right people into a room. Let them talk. Listen. Ask intelligent questions. Then make a decision - and stand over it.
  • Protect the team. You are the umbrella that shields the team from all the external goings on. The project managers, product owners, customers, sales and support. Distil their input down to what the team need to know and communicate this, keep the team informed and you'll be letting the team get on with their job.
  • Don't be afraid to change things. No process is perfect so feel free to try something new. Observe the result and then adjust as needed. Just don't to it all at once.

Edit: By the way, age has nothing to do with it - ability does. Time/longevity does not equal ability and it certainly does not guarantee the traits required to be a good leader. One of the guys on my team when I first started had 20+ years on me and had been a very senior member of our military. He was gruff, self-confident, arrogant and more than a little intimidating Once I figured out what made him tick, dealing with him was easy.

9

I am considering to go to my PM and directly state that I don't want to be team lead in this situation. What are my options?

  • You could go to your PM, state that you don't want to be a team lead in this situation, and see what happens. Maybe your PM will intervene on your behalf. Maybe you'll be told to go figure it out. Maybe you'll be moved back into an individual contributor role without an advancement opportunity again. Hard to tell.
  • You could go to your PM and state that you don't want to be a team lead. Likely you'll get moved back into an individual contributor role without an advancement opportunity again.
  • You could ask the PM if you can fire or transfer the two problematic team members and replace them with better workers. The answer might be Yes, or it might be No.
  • You could work on your own to deal with the personalities on your team.
  • You could find a job that doesn't involve leadership and quit this one
  • You could ask your boss for help in learning how to be a more effective leader and being able to deal with the various personalities on your team, including older team members. You might get some advice. You might get some mentoring. You might be offered some training. You might be given a few books to read. It might all lead to future advancement opportunities.

I recommend the latter. At least for a first try.

3

I think the thing that needs to be asked is why do they feel the need to be like this. Many, many times I've found that people are working or reacting this way because they don't feel empowered. That is, they feel like they are spectators and not participants.

Now you're probably sitting there saying "no, I give them tasks to do. That can't be it. They just don't do anything productive." However, flip it around.

If you've got years and years of experience, then you should expect to be playing a more active role. If you say "this is a need" then you should expect people to agree with you. If you say "I'm going to do this" and then someone turns around and says "no, it's not important" then what's up with that? If they then complain you get nothing done but they're not allowed to do the things they think should be done then what the #$%$%?! Screw this place...

From your question it sounds like you and the other Java developers are already relegating them to the dust bin "we only need them for their knowledge of Core." That's not a healthy relationship and thus you're getting an unhealthy response. You need to figure out a way to get them more involved in the decision making even if you, yourself, don't completely agree with their conclusions. Part of being in a team is trusting your teammates.

  • that is a nice thought in general, but can you imaginge a workweek where 50% of the time you do meetings that lead to nowhere instead of coding. Because this was the reality up very recently. Now they may feel bad but at least we have progress. – Pesho Dec 17 '19 at 15:13
1

I guess the problem is that the two older employees do not feel respected enough. It must be very frustrating for them that the knowledge they have gained is not really needed any more.

I have the same problem, but from another perspective. Over the years, I myself find it increasingly difficult to deal with colleagues that are much younger and sometimes higher in rank. Young people that have just left university think they have to tell me what to do or to monitor my work. They do not realize that what they are trying to explain or to monitor has already been my daily working routine for the last 20 years. I try to be patient, but sometimes it is quite frustrating. Perhaps you can imagine how I feel in such situations.

Before you think of giving up, make sure that the experience of the two employees is fully acknowledged. Respect them and make sure they are respected by the rest of the team. Do not try to tell them what to do unless it is absolutely necessary. Try to have confidence in their work. Ask them for help.

  • I agree that the foundation of a good working relationship is mutual respect, and empathy can bridge differences. I disagree that decades of experience exempts a person from oversight. Your comments about younger people who outrank you, and "[they] think they have to tell me what to do or monitor my work" comes across as defensive, age-based discrimination, and resentfulness with a hint of insubordination. Managers manage - that's what they do. Plus, a twenty-year daily routine - presumably unchanged for most of that time - is opportune for new perspectives to lead to great improvements. – HappyGilmore Dec 17 '19 at 15:52
0

I would point out that stepping down from your role would not end the conflict, it would most likely result in whichever colleague they chose to replace you making the same arguments with more formal authority. Are you prepared to deal with that?

Leadership looks the same no matter your formal role. You make a case. You build consensus. You educate when others are not making decisions based on complete or correct information. You seek to fully understand your colleague's positions. You gather feedback and adapt. The times you make "because I said so" decisions should be relatively rare.

-7

If you have to deal with a difficult older person, have your meetings first thing in the morning. And you better make sure that person is well hydrated before you start those meetings.

That 60-year-old Cobal programmer may not be firing on all cylinders right now, but that may not mean he's like that all the time.

  • My point was that older does not guarantee superior performance. I was trying to convey to OP that just because two devs on his/her team are significantly older doesn't automatically mean they know better. As such, OP should not let him or herself be intimidated by this fact or let it stop them doing their job (i.e. managing the developers) – amcdermott Dec 17 '19 at 1:32
  • @amcdermott, My mistake. Sorry. I'll amend my post later tonight. – Stephan Branczyk Dec 17 '19 at 1:47
  • Don't sweat it - no apology required. You make an equally valid point. I just thought maybe I'd clarify in case my meaning wasn't clear. Sometimes my communication skills aren't the best. – amcdermott Dec 17 '19 at 1:51
  • 2
    I don't think this answer really addresses the problem that the OP is having: he is a team lead of a team that doesn't want to cooperate. Changing a meeting time is not going to change anything. – Rich Dec 17 '19 at 14:00
  • 1
    @Rich, Clearly, you've never dealt with elderly people around the clock. – Stephan Branczyk Dec 17 '19 at 21:16

Not the answer you're looking for? Browse other questions tagged or ask your own question.