How to lead a team full of junior developers? [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 1 year ago.

Improve this question

Currently I'm leading a team of 4 developers, all of them started their careers 5-6 months ago. I can consider ourselves lucky, as we've been assigned to a greenfield project, it's completely up to us to achieve the business goals. The company itself is quite small and they have a long history of maintaining legacy applications and they are far from being up to date. These circumstances led to a certain level of isolation within the company. I was extremely motivated at the beginning but after several months I began to feel burnt out. My position is quite tricky: since it's only 5 of us, without any management or business team assigned specifically to the project, mostly I deal with it. Designing architecture (and writing huge part of it), holding code reviews, organizing the backlog, trying to drive everything and communicating our progress towards the management. As I mentioned, I started to feel burnt out, frustrated. I can't really get any help, not even technical discussions with someone, and I can't realistically expect the juniors to challenge my decisions.

Anyhow, my real question is: How do I deal with all this? I'm trying to keep the codebase as clean as possible, while maintaining progress, so the project won't be shut down, but sometimes I feel like I accept solutions that otherwise I wouldn't, for the sake of progress. These might sound silly questions, but I'm sure some of you might've experienced it before: how many times is it ok to decline a pull request? How many trainings do I need to hold or how many percent of my work should be writing documentations so I'm not a single point of failure? I obviously don't expect anyone to specifically answer this, but rather I'd like to hear an opinion.

Answer 1

All of your questions are related, and as you have said your team is quite young. If we were in a room together, I would ask questions on what you've done to shore up their knowledge gaps. There are several red flags I see:

• You are developing in isolation--meaning no one at the company is vested in what you are doing
• You are doing most of the progress, and that is frustrating.
• You don't really have a hierarchy of people to help take the load off

The answer is going to a tough pill to swallow:

You are going to have to accept some messiness in code.

Your team may be as green as your project, but you might be in a place where you are over-emphasizing pristine code. People can't learn in sterile environments. They will be too afraid to mess things up. If your team is too afraid to mess it up, knowing you'll come along behind them to redo it anyway, that demotivates them.

How many times is it OK to decline a pull request?

The glib answer is as many times as it takes. Real life is different though.

• Make sure you are failing the pull request because of something architecturally wrong or dangerous
• When you fail a pull request make it a training moment
• Help the team member know what the vulnerabilities are, or how it hurts the code
• Help them to understand how to avoid that problem in the first place
• Make them do the changes. They won't learn anything if you spoon feed them what to do

How many trainings do I need to hold or how many percent of my work should be writing documentations so I'm not a single point of failure?

That's hard to answer. I've found when training someone you have to pick one or two things tops to focus on. You have to balance both positive and negative feedback. If someone is doing something right, tell them. It will help reinforce the good behavior.

Include your team on design decisions. They probably aren't skilled enough to come up with the design from a blank sheet of paper, but they can definitely help tailor the design to work with your team's skills rather than against them.

Save the documentation for Why The Face?! (WTF) moments. In other words, when you have a surprising requirement, or deviation from the design standards, document it. Also, document what the conceptual design is. Just enough to communicate with your team.

The more you encourage your team to take ownership of their work, the more they will rise to the challenge. And if someone doesn't, then you can look at talking to management about changing that team member.

Answer 2

As much as I would like to offer you an advice I believe there is nothing much you can do. If you have communicated this problem to the management and management is unwilling (or unable) to help then you have minimal chance at success.

I believe problems like these often have no solution on team or technical level. Only management can truly solve problems like these. Possibly by adding people with more people-focused skills to help direct and coach the juniors. Or possibly by reducing pressure on value delivery and allowing for the juniors to fail, learn and re-do work that was already done, but poorly.

And getting management to accept those terms often involves politics, which you clearly are unwilling, unable or unmotivated to engage in.

Answer 3

Greenfield projects can be great, but for a team of junior developers it can be challenging and stressful. This sounds like a very difficult situation.

You have two questions that are good discussion points:

how many times is it ok to decline a pull request?

The team need to own and commit to the quality process. Try to build a consensus about quality - does everyone see the value in having high quality design and code? If not then quite frankly you'll be fighting every day and pushing the rock uphill, and it isn't worth it.

Far better is to get a shared understanding of (a) why quality is important, and (b) what level of quality is expected or required. When expectations are clear and people understand their target then you can more easily coach towards that target.

It's unreasonable to expect perfect code (as if that exists), but it is entirely reasonable to have some standards. Meet with the team and agree on those standards. It needs to be the team's standard, not your standard. Make sure that other members of the team are helping to enforce those standards. Help the team to come up with a solution for repeated PR problems, e.g. (a) a pair programming session for 'intensive care' to resolve issues, (b) a mob / group programming session for group learning, or (c) a discussion around the team's quality expectations, etc.

Try these things, and "inspect and adjust" periodically. This will be an evolving process that changes as the teams understanding, commitment, and experience with quality improve.

How many trainings do I need to hold or how many percent of my work should be writing documentations so I'm not a single point of failure?

You should be 100% available to getting others up to speed. Your primary responsibility is to get out of being the single point of failure (or bottleneck).

Note that writing documentation might be helpful, but might not be helpful. What does the team need and want? Do they want group instruction, or one-on-one coaching? Will approaches like pairing and mobbing help?

You want to delegate as much as possible and let people make mistakes, but provide feedback and course correction as soon as possible (i.e. frequent reviews). It's import to encourage people's resourcefulness and ability to learn these things.