How do I help my teammates grow?

Question

I consider myself a senior software developer, I have lots of experience and so forth. Some months ago, I've started a new job. The project itself is interesting and has potential, but is not challenging (in the sense that there's nothing innovative on the software-side). The only challenge is delivering high quality features quickly, and this is really appealing for me.

My teammates are junior programmers. I don't know why, but they do think they are senior. This is not a problem per se: I'm perfectly fine with that. Also, they have identified me as a leader, and they ask me whenever they have a programming question.

However, they do not understand many important problems in software development. For example, they do not understand basic stuff like: factual details are more important than unverified hypotheses. This has been causing many delays. But again, this is not a problem for me.

The problem is that, because of their mistakes, the results are very low quality, and simple features take ages to be implemented. I need them to grow in order for the project to get challenging for me. I've tried to introduce them to the "advanced" problems of software development, and they have made some progress, but things are proceeding really slowly.

What can I do to motivate them? As I said, they believe to be senior and experienced, so if said that they need to learn, I'd just generate dissent. Perhaps, should I just leave? I have received many interesting and challenging opportunities, including management roles. But I feel that leaving would be like surrendering, and this is not good for a person who wants to become a good leader.

---

For completeness:

• the CTO is junior (and believes to be senior);
• management is very unhappy with the output from development team;
• management has recognized my experience;
• management supports my initiatives, and encourages me to start more;
• as far as I know, management has not spoken nor with my teammates about their need to grow;
• I'm going to ask management about what plans they have (if they have plans).

Answer 1

Something isn't adding up. You say they make mistakes, are slow, and recognize you as a senior and ask for help, so how could they not interpret this as needing to learn to get better? I guess if you say it explicitly, they may get offended, but it's obvious they're not as good as you.

Your question seems to speculate on their responses without any of their perspectives. It's like you have no working relationship with "your junior" developers.

They need to be a part of the solution. It's inefficient for all of them to come to you individually with problems that stem from the same skill deficit. Ask them what you can do to show everyone how to do this. Maybe you need to set aside a training session or generate some documentation/training materials. They can't keep calling themselves senior but not actually do anything that indicates they really are. It's not about having a false-sense of superiority that makes one a senior. You have to be able to get things done at a high level and less time.

If you find they're not willing to take responsibility for their own growth and use your time as a resource wisely, there's not much you can do about it. Management would need to step in and provide the proper motivation or find the right people.

Answer 2

Set an example.

Based on what you say, your team and management see that you are a good programmer. You deliver features quickly and with good quality. Focus on those metrics: is stuff done quickly? Is stuff done well? And then be an example of how to achieve those results. Push your peers to be better. Focus on the results, not the people. Then when they ask "how do I be better?" you're there to help.

But before you do all of that, I would caution you to take a step back and make sure you're right. As someone just running across this question randomly, there's a strong undercurrent of "I know what's going on and these others have no idea". That sort of thinking is exactly the sort of thing that you're accusing your coworkers of.

And your only sentence that talks about what's actually going on:

For example, they do not understand basic stuff like: factual details are more important than unverified hypotheses.

strikes me as something not terribly basic, nor clearly true in all cases.

But if you take a step back and find that your coworkers really could do better, then lead. Leading isn't pointing out criticisms or telling people what to do. It's setting an example for others to follow.

Answer 3

I need them to grow in order for the project to get challenging for me

I find it interesting that you are a lead on a project but you are primarily focused on what the team and the project can do for you. Ideally it should be the other way around. As the lead you need to ask yourself, what can you and your team do to result in better outcomes for your project or software.

They aren't there for your benefit and neither is your project. You may be losing sight of this.

But I feel that leaving would be like surrendering, and this is not good for a person who wants to become a good leader.

You can become a good leader in your role by focusing on what you can do to ensure that your project is a success under any circumstances. I advise that instead of helping your teammates grow, you should help yourself grow as a leader by leading them into good habits and practices that lead to success.

Answer 4

It sounds like code quality is a problem, and that your colleagues are perhaps a little parochial about their work.

Think about how you can build best-practice approaches into your team's work. Things like code reviews, pair programming are worth considering - encourage them to improve each other's code so it's not all coming from you and they get into the habit of teaching themselves and each other independent of your influence.

Probably the most helpful tool will be a comprehensive test suite and hopefully test-driven development. Encourage people as well to write tests with the aim of finding bugs and breaking the code, not just to pander to preconceptions. This will no doubt be difficult at first - but if everyone's code needs testing your colleagues become aware of their own shortcomings without it always being you who is having to point it out. Both finding bugs and writing code which passes a test suite are motivating achievements.

Once you work out your approach, articulate the problem to your managers, without criticising the professionalism of your colleagues but pointing out that there is a lot of room for improvement in the codebase and/or the turnaround time. Acknowledge that it will mean a slowdown for a month or so as people get used to more sustainable practices. Discuss the practical matters with your team - start with little things that you can achieve in a short timeframe, don't just drop everything to shoot for 100% code coverage of all existing features.

Finally, be open to the possibility that you will learn from your colleagues too. Be humble and make sure other people get equal chances to review your code. If you look down on your colleagues they will indeed resent you rather than respecting you.