Team lead unhappy to lead team [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 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.

Answer 4

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.

Answer 5

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.