8

I work in a large team of 14 people. I am the team lead.

Over the past few years, as the team has gotten larger new people have joined. My manager was mainly responsible for hiring the team. I became team lead after the team was expanded. Nonetheless, my manager and I have different expectations of good developers.

Personally, I think a lot of the people in my team are not suitable for developing new features.
There are 3 developers who I would consider capable of doing new development. The other 11 are capable of fixing bugs and doing what is considered as small enhancements. Even sometimes with small enhancements they need to do "pair programming" and it ends up slowing down the other team members by a large margin. Needless to say, the team dynamics are way off balanced. 2 seniors, 1 mid level, 11 juniors.

Honestly speaking, my manager does not see this fact.
I have tried things like such:

  • In the daily standup, I will ask specific people if things are clear to get their confirmation in front of the manager. Even after they say everything is "clear". They insist to meet and "go over things", my manager allows it. He even promotes "pairprogramming".
  • I have also stepped back and watch people fail. This does no justice to the company.
  • Each time I start a new feature, I try to assign the new work to the top performing people. I want the strongest players in the right place at the right time. However, my manager always interferes and allows the most junior people to "lead" some of the most challenging parts.

From what I know, my manager does not hold people accountable if they underperform.

How can I tell my manager that certain people are not capable of handling new features? He either needs to fire them or just give them small bugs to fix and have low expectations.

Updates and Clarifications
Thanks for the comments and answers so far.

  • I don't mind pair programming. The real problem is we have too many guys in our team who just expect pair programming each time now. Whenever they have to repeat the same tasks for a new Module they don't even remember working on the same task for another module. I check the git history and it was clear they worked on an existing module they just have to remember how we "peer programmed" that part.
  • People are not preparing themselves. There are only 2 junior guys, who I see them reading technical blogs, watch technical videos, and so on. I think those guys will do well in the long run.
  • Time lapse of this has been 2 years. It's a repetitive process with some guys and I don't see them cutting it, in the long run. They don't know how to ask the right questions and I don't see them trying since there are no "real" consequences.
  • Since I became a lead, I stopped patronizing management's decision to hire juniors. At this point when I see the Seniors working extra long hours to pick up the slack, I would prefer for 3-4 of the juniors to burn and crash fixing bugs only. Instead use that money to hire 1 extra senior guy.

I have put in a transfer for another division because the situation is now detrimental to my continuous growth. The top developers are also in similar situations. We spend a lot of time at work "peer programming" and we don't have enough day hours to complete our tasks. We end up having to work extra hours and the manager is complacent with the situation as long as the juniors are learning.

There has to be some balance right?

16
  • 44
    How do you expect the juniors to grow into mid-level/senior if all they ever do is fix bugs? May 10, 2019 at 4:14
  • 8
    Why do you consider pairing and peer programming bad? May 10, 2019 at 8:17
  • 3
    Could you ask your management why does your team have 11 members? Chances are, they are there to learn.
    – lucasgcb
    May 10, 2019 at 10:24
  • 2
    No offense, but you do not have a vision for the long run, and you are not "growing" the team. You probably never heard of the term "hit by a bus" too.
    – Sandra K
    May 10, 2019 at 16:18
  • 9
    Can you address why you seem to believe that fixing bugs somehow relates to less complicated work? Some of the most complicated programming I've ever done has been fixing bugs. May 10, 2019 at 19:27

6 Answers 6

22

Talking with people often hinges on understanding their goal. It seems to me that while your main goal is to produce good software right now your manager wants a to invest some of the present expertise to train the juniors so that there will be more good developers in the future.

As you know very well, educating younger colleagues takes time and the tasks are often done faster and better by a senior alone. I think your manager knows that too, so telling him that is not going to change his view.

While training the juniors is likely one of his goals it is probably not the only one. There will be a limit on how much of the current productivity can be invested into training. If your team does not manage to hit its minimum targets you might talk him into tuning down the training, although probably not stop it altogether.

If, on the other hand, the problem is that you don't like having junior colleagues in the first place then you're probably out of luck. You'll need to find out why the team was expanded and why in this way. Senior developers are hard to find, so maybe the company had to take inexperienced ones to make them grow.

Relegating them to bug fixing is probably a lost cause. They'd quit and you would too in their place. The company knows it and it didn't spend time and money to find, select and hire them just for them to burn out. I'd expect a huge lot of resistance.

By the way, fixing bugs also requires care and knowledge. If you think new developers can handle it, why is it that they cannot contribute to a new feature?

EDIT: improved the last paragraph. Thanks to the commenters for pointing out unwanted interpretations of what I wrote.

7
  • 2
    Fixing bugs is a good place to start on a new project. You get to find your way around the code and get a feel for style. In fact it's probably the best place to start. But each noob has to have a mentor, someone who knows "there are no dumb questions, only dumb answers." The mentor is responsible for turning the noob into a team member. Yes, it takes time, but it has to be done. We all started out as noobs.
    – RedSonja
    May 10, 2019 at 7:08
  • 1
    There are codebases that are full of bugs that are easy to fix and would be perfect for a new squad of rookies. It's usually a sign of issues with the senior devs who are leaving lots of bugs though; either they are overworked or they are just sloppy.
    – Erik
    May 10, 2019 at 7:11
  • 2
    There are many examples of rookies or even schoolkids finding very serious flaws in code or even other things... That have been missed by those with "experience"...
    – Solar Mike
    May 10, 2019 at 7:41
  • 2
    I agree. Educating people does take time. It also takes investment from the company it self. When I first started up, I was mainly responsible for fixing bugs and making small enhancements. I grew by asking the right questions. I have tried to be understanding to the fact people don't learn the same way. But it has been two years and some guys still don't understand how the project set up works or how dependency inject works in our Angular and Spring applications. I have handled this by creating wikis.
    – earlyuser
    May 10, 2019 at 16:06
  • 2
    Also this is not something proprietary. If they really wanted to learn they would search google to understand. Our foundations are found in the base documentation of many popular libraries. Angular and Spring.
    – earlyuser
    May 10, 2019 at 16:09
13

You don't.

The main reason being that you don't seem to think that some people should stick to fixing bugs, you seem to think that only the most qualified people should be developing.

my manager and I have different expectations of good developers.

You can't only have 10s employees. You need 7s-8s to keep up with things. It's up to you how you use the talent at hand. If you are too picky, you end up with a 1 man/woman shop. However, if you think that the hires are bonkus you need to address those concerns to your manager.

There are 3 developers who I would consider capable of doing new development. The other 11 are capable of fixing bugs and doing what is considered as small enhancements [...] Each time I start a new feature, I try to assign the new work to the top performing people.

This is ludicrous. How do you expect 3 developers to keep up with development that is expected from a team of 14? It doesn't make any sense.

In the daily standup, I will ask specific people if things are clear to get their confirmation in front of the manager. Even after they say everything is "clear". They insist to meet and "go over things", my manager allows it. He even promotes "peer programming".

A daily standup should be about 15 minutes. That's roughly a minute per developer. I would be worried if people would not want to go over things in a meeting that is specified for a specific problem. The daily standup should be used to address what's being done, what's upcoming and what problems are in place. It's not the place to solve the problems, only address them.

Needless to say, the team dynamics are way off balanced. 2 seniors, 1 mid level, 11 juniors.

I understand that you may not want juniors to get into feature development right off the bat. Fixing bugs and getting an understanding of the systems is great but after a few months they should have enough understanding to add new features. If they're not, then they're not getting the coaching they need or the opportunities to prove themselves. Either that or they're simply unqualified.

You get nothing done in terms of features if you only have 2-3 developers working on features. That's a huge bottleneck.

Use the juniors that have some understanding of the system. Allow them to actually learn and prove themselves. They'll never become seniors this way. Besides, you can be sure that people will start leaving soon if all they ever do is fix bugs.

Besides, what are you so afraid of? If a junior screws up with the code then it should be discovered through the code-review process. Ask the seniors to help you turn those juniors into qualified software developers.

He even promotes "peer programming".

The fact that you don't worries me. I don't think it should be used all the time, but it's an amazing tool that even the most seasoned people in my company have used to get junior/mid level people up to speed in days that would have taken weeks.

I have also stepped back and watch people fail [...] From what I know, my manager does not hold people accountable if they underperform.

It's easy to under-perform as a developer when there's no development tasks assigned to them. Have you considered that people may be "underforming" because they're not getting the training they need?

Let's assume that the juniors are being assigned tasks that they underperform with. It's your job then to figure out where they need help with accomplishing their tasks. Help them becoming the top talent you so desperately want.

How can I tell my manager that certain people are not capable of handling new features? He either needs to fire them or just give them small bugs to fix and have low expectations.

You have not even addressed to us why you don't think they're qualified. Are they not capable because it's not done up to your senior level standard? If that's the case then you need to let go of your ego because it's hindering production. Sure, there should be standards, but those standards are implemented through mentoring and reviewing.

I'd understand your concerns if there would be a couple of developers that are simply unqualified that you'd desperately want out, but when the fact is that you only trust a couple of them to do development then I get the sense that you're the problem, not the other way around.

Let go of your ego and help those developers with accomplishing their tasks, that should consist of maintaining and developing. You'll start losing people soon otherwise or be stuck with people actually uncapable of developing.

8
  • 2
    +1 on the no fear hanging on code review; if juniors do a good job you get a feature and in the worst case you get to teach the junior something, and understand what's impeding in their ability to contribute to the project.
    – lucasgcb
    May 10, 2019 at 11:20
  • 4
    More importantly, if the development work can be done by only 3 developers, you have effectively proven you don't need 11 team members. Something tells me those 11 employees were hired for a reason. You certainly don't need 11 developers handling bugs, if you do, then you have to many bugs.
    – Donald
    May 10, 2019 at 11:56
  • 1
    I agree. You can't have all 10(s). What I am saying is that we have 2 that are 9-10. 1 that is 7-9. 11 that are around 3-5. I have updated my question to clarify some points. I don't think it is expected for 3 people to handle the workload of 14. Seniors are working 12-16 hour days... Juniors at best work 8-9 hours per day. I know the team is unbalanced by a large margin but my manager is not acknowledging how bad it is.
    – earlyuser
    May 10, 2019 at 15:58
  • 3
    BTW, working hours has absolutely nothing to do with the quality of work. I'd not want someone working 12-16 hours a day for me, I can only imagine the mistakes made in the final hours and the burnt out employees who'd leave soon.
    – Jonast92
    May 10, 2019 at 16:04
  • 1
    @Jack You're delusional if you think that everyone but the team leader is a failure.
    – Jonast92
    Nov 3, 2021 at 13:36
9

It's been mentioned in comments about how can you expect your Juniors to learn if you don't give them a chance, I echo that ten fold. You are gearing your company up for key-person dependencies, and that is ultimately a problem for the business in the long run. Junior devs are cheaper, and they can be molded, they can also learn a lot of negative traits from those above them (i.e. you).

Your manager actually seems like the clued up person in this hierarchy as he is trying to give the Juniors experience.

In the daily standup, I will ask specific people if things are clear to get their confirmation in front of the manager. Even after they say everything is "clear". They insist to meet and "go over things", my manager allows it. He even promotes "pairprogramming".

The junior devs are probably nervous and you're putting them on the spot. We've all been there. I can recall saying things were clear back in the day when it wasn't, it took a senior to sit me down and explain that asking question isn't a bad thing - not everyone understands everything.

The fact that you're complaining that they meet with you to "go over things" is a red flag for me, and certainly not the only one. You should encourage those who don't know to ask, as if they try and spend hours without finding a solution that costs money. You should be teaching them so that they can be confident of reaching out, getting an answer and being knowledgeable enough to not ask that question again.

You are a 'leader', that is your role, if they keep asking similar questions perhaps you need to rethink your technique or consider what training opportunities there are that you need to arrange.

Time lapse of this has been 2 years. It's a repetitive process with some guys and I don't see them cutting it, in the long run. They don't know how to ask the right questions and I don't see them trying since there are no "real" consequences.

If they are not getting to grips with it then you need to be looking at what learning opportunities there are for them, what training courses have you looked at?

How can I tell my manager that certain people are not capable of handling new features? He either needs to fire them or just give them small bugs to fix and have low expectations.

Juniors don't know what they don't know. A leader is meant to guide them so they can learn. Your manager should get rid of the blocker in their learning.

I would prefer for 3-4 of the juniors to burn and crash fixing bugs only. Instead use that money to hire 1 extra senior guy.

That is an absolutely ludicrous thing to say. You should be nurturing the Junior devs to get them to the place you need them to be.

From what I can see you are definitely not a leader, you are a manager with a resource. I think you should take a step back and see whether you feel you are in the right position for the benefit of yourself, your team, and ultimately the company - as your short term gains can only damage it in the long run.

I have put in a transfer for another division because the situation is now detrimental to my continuous growth

I think that's a fantastic idea, as you're not leading and are detrimental to the continuous growth of your junior developers.

The top developers are also in similar situations.

If I was a senior and the burden of all the work constantly landed at my feet, rather than training up those lower down, then I'd certainly be looking to leave too.

2
  • Matt R. I think you actually reflected on a lot of things I have been evaluating myself on as well. I agree with all your points and the primary reason why i am leaving is because I don't think I am ready to be a team lead. My organization does suffer from a lot of problems. Ultimately, stressing and working long hours to delivery projects is no longer a healthy thing for me. In my next role I am looking to step back and have less responsibilities, specially since I am quite young and I still need to do a lot of growing myself. Not just the juniors.
    – earlyuser
    May 10, 2019 at 16:23
  • How much time do you think a junior guy needs ? Some of the juniors we have are not on their first job out of college.
    – earlyuser
    May 10, 2019 at 16:26
7

I can't tell you how to convince your boss of that, but I can tell you that it seems that your problem is with setting the team hierarchy. You defined the hierarchy in your question, but you don't seem to have defined it in your work stream.

If there are two seniors vs 11 juniors, then maybe those seniors should not be coding at all. They should be more concerned about the design of the new feature, and then, you hand these designs to the junior, who will be implementing these designs under the supervision of the seniors who will do code reviews, while tough parts can be given to the mid-level and the seniors when necessary.

2

The way you are going, you have two seniors, one mid level and 11 juniors today, and in five years you will also have two seniors, one mid level and 11 juniors.

Most efficient way to add something new: Let a senior come up with a plan, explain it to two juniors, and let them build it. With a bit of hand holding. Next time, same thing with less hand holding. And in a year they can do things on their own and only bother the senior for hard bits.

1

I see two root problems here which you've barely acknowledged, and a lot of complaining about the symptoms resulting from those problems. What's more, I've seen very similar situations and sentiments repeatedly throughout the SE industry.

First, 2 seniors is not even half of the number I would expect to be able to handle training 11 juniors. A single senior can on average handle 1 mid and 2 juniors. A really good team lead can handle 2 mids and 3 juniors at best, and your personal code output will dramatically decrease for it. However, this is how you build larger teams. It doesn't matter what your tech stack is, there simply aren't enough senior and mid level programmers with experience in your tech stack, and their won't be until you train them and do what's necessary to retain them.

As a team, your average experience per team member is way too low. Juniors can't and should not be expected to handle highly complicated problems yet, and they need mentorship. As someone else already said, you can't expect a team of only 10s, that doesn't exist because nobody starts out as a 10 and I have yet to find any interviewing criteria capable of accurately identifying 10s or even probable future 10s. Who you get trained by and how much effort they put into training you is important and completely outside that person's control. They largely do not yet know what they need to learn or how they can become more productive. Reading random tech articles might seem like a good corollary with future success, but most successful and productive engineers don't have it. It's a rare trait so you can't reliably find people with it and it's obviously not necessary to become a good developer anyway.

Second, just from the way you've described things, I can tell that your stories are too large. You need to have them broken down into smaller more manageable sizes. A story that takes a mid level programmer more than 3 days to complete can nearly always be broken down into smaller easier to understand requirements. I try to keep the average story at roughly 1 day's worth of work for a mid level engineer. Don't be afraid to have stories that are dependent on the completion of other stories before they can be started, the more you break things down the easier it is to keep everyone fed stories where the dependencies were already completed, feature branches come in very useful for this purpose. Additionally, how stories are written has a huge impact. The most successful approach I've seen utilizes Accordion style scenarios for acceptance criteria in addition to the basic "As A, I want, So that" description.

If you can get them to target a better ratio of senior to junior level members that will alleviate a large portion of the problem, but I've seen better story writing completely transform otherwise disorganized unmotivated teams into the kind of highly productive assets that management raves about. Your worst case scenario is that you need to limit who you're focusing on mentoring until they improve, then after a couple of sprint focus on a new pair of juniors to train. This isn't ideal, but it's how you bring up the average.

You must log in to answer this question.

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