Politely telling an incompetent software project volunteer they are too inexperienced

Question

I am currently the project lead of an online volunteer run software project. I originally created this and work on it my in free time. There are also a few other people who took interest in this project and volunteered to help. I have never worked with other developers before. Currently, there is another developer volunteering to help program the project.

Before they were a developer, I knew them online since they took interest in the project. They did not have a lot of experience in software engineering, but they did know the programming language the project uses somewhat well. At this time, I was looking for another programmer to help speed up development, and told them that they could help code the project. I was hoping that despite their lack of experience, I would be able to get them up to speed with my guidance.

I was wrong.

This was two months ago, and by now I've realized that it will take a very long time for me to train them to become a fully competent developer. Currently, their skills simply aren't good enough for working on the project right now, and they need my assistance on completing almost every task. In retrospect, this might have been my fault since I miscalculated the amount of time I needed to train a new developer. I hope this does not sound unsympathetic, but from a purely business oriented perspective, the large amount of time I spend mentoring them is simply not worth the time I could otherwise be spending on the project itself.

I have considered that mentoring them is an investment, and eventually that they will have the skills to contribute to the project more efficiently. However, as it stands, I do this project for fun, after many responsibilities, so I really don't have the energy to teach someone every night when I get home. Mentoring takes the enjoyment out of the project for me. Besides, I plan on abandoning and/or finishing this project by the next 3 months, so it's worthless for me to make an investment in something I will abandon soon anyway.

Overall, it would be extremely beneficial for both me and the project to either remove them from the developer job, or reassign them to another role. However, this is awkward for three reasons:

1. They are a volunteer on this project. In fact, they showed enthusiasm for helping out, and I have a feeling they are very happy to be a developer. It's not the same as firing a paid worker, because they are sacrificing their relaxation and free time for this project. It would be very disrespectful to simply "fire" them.

2. They have already been a developer for about two months already. If I were to reject them for inexperience, I (normally) would have done this right away. As I mentioned earlier, I was not aware that their inexperience would interfere with the project this much.

3. I already knew this person online earlier, and they are a friend and also have been an enthusiastic supporter of this project. I don't want to burn any bridges.

Thanks in advance for any advice. I would rather work on my own currently without this other developer.

---

Note: I don't think this would apply to The Workplace, because they are a volunteer, and I am rather informal with the developer - in fact, I have mentioned that I am friends with them.

Similarly, I looked at this question about firing someone due to skills, but that is for a professional environment. As I mentioned in Awkwardness Reason #1, they are a volunteer and deserve some respect for sacrificing their valuable free time for this project.

Answer 1

You can side step that issue entirely.

You don't even have to be deceitful about it.

Simply say to them that the part of the project they can realistically help with is finished now (since it is, that's entirely the truth) and that you'll contact them again if something else comes up that they can help with. This has key advantages:

• You're not burning any bridges.
• It may prompt the junior developer to learn more in an effort to gain skills more relevant to the project.
• You're not firing them or insinuating they are incompetent at all.
• This is normal for collaborative free-time projects. At some point the stuff someone without certain skills can do ends.

Using this strategy, you're completely avoiding the problem of having to "fire" them at all.

Alternatively, you can re-assign them to tasks that need to be done but don't need a developer to do them, or tasks that are secondary (nice to have). Usually, this includes:

• Writing docs
• Code review
• Extensive Q/A testing

Be on the lookout for tasks that don't cost you anything if they're done poorly but do help out a lot when they enthusiastically complete them.

Answer 2

I'm not sure you have to fire them entirely from the project, you could also move them to a position where they don't block other people (including you).

First, it sounds like the main problem for you is the coaching - so scale back the coaching. You could say something like:

Hey Bob, currently there's a lot going on in my life and I simply can't find the time for our training sessions [or whatever you call them] any longer, sorry about that.

Then, move them "out of the way" by assigning them one or two simple tasks with non-urgent priority. If they can learn and complete the task on their own: great, give them something more challenging and repeat until you've found their level of competency. If not, come back to them when the task has moved up in priority (when it's needed soon). If you want to be diplomatic about it, you could then say:

Hey Bob, we need the documentation / translations / tests executed / foobar soon. Could you take care of that and I'll take over on the defrobulator in the meantime?

It really helps if you can convince yourself that documentation and testing are important tasks - because they are. Many devs don't want to write documentation and that seals the fate of many a small open source software project: their software solves some problem but most people can't figure out how to use it, so nobody uses it.

Finally: you mention "I have never worked with other developers before" and it's not quite clear to me how you organise the work in your project. Organising software development is a very valuable skillset, so you may want to use this opportunity to learn and grow yourself. Learn to break work down into tasks and subtasks, to figure out dependencies, to estimate the time needed, to prioritse what is important and what can wait, to gauge who can do what. Learn how to best communicate with your fellow devs and how to replan when things don't work out the way you expected. Use the collaboration tools (issue tracker, versioning system, etc.).

Maybe methodologies en vogue in the business world at the moment (Scrum, Kanban, etc.) would give you some useful guidelines.

Answer 3

First, I agree with the part about thanking volunteer for his time/effort to date, and saying that the part of the primary development you needed him on is finished.

May I recommend, for both your sake, you invest in one more mentoring session. The topic: show his bad self how to write unit tests. Then tell him that if he wants to do more technology help (as opposed to other kinds), he should start expanding the stable of tests. The advantages:

• You get unit tests!

• Volunteer gets introduced to the important nature of unit tests!

• If volunteer is slow or gets stuck, it doesn't interfere with mainline development

Then, as per other answers, you can beg off more training, as you have lost any slack in your schedule.

Answer 4

As they are a volunteer I don't think its necessary to "fire" them at all as wording it like that would come off as quite rude. Instead saying that the volunteer work that you need them for is finished for now might be more appropriate. Also, be sure to thank them kindly for the work they have done already, comment on its success and their personal growth just don't give them any new tasks.

This works especially for volunteers as they were never technically employed, only helping out where they were needed and if you can phrase it in a way that shows they succeeded in doing their task then not receiving any more tasks should be met with positive feelings rather than negative ones.

Thank you so much {name}, {X} part of the project is up and working well! You have done everything I needed but if its alright with you I might ask you to do some more work in the future?

Asking if its alright for something they would like is quite handy as it keeps the metaphorical bridge you mentioned up, it gets them agreeing with you, it provides them with options that which ever they choose you accomplish your goal of stopping them working on the current project and it is polite.

Unfortunately this will not work in all cases and I don't know the details of your project/what he was assigned. If you have to choose between being a bit more blunt or lying, being blunt would likely help in the long run (thats not to say you should focus on the bad!).

You have helped us out and improved a lot, but I think that it would be better if {others} and I completed the remaining tasks.

and

If something better suited for your skills comes along in the future I will be sure to send it your way.

Might be more appropriate in some cases.

Answer 5

My read of this situation is... lets say a bit cynical. Out there, there is constantly the advice for new developers to get their names on pull requests as a way of enhancing their GitHub cred for prospective employers. Looking out there on other sites, there is constant advice for new devs to join an open source project as a way to gain experience. That experience comes at the cost of the time spent mentoring of the more senior devs on those projects.

While yes, the junior dev is giving up their free time - I don't see it as such. This is a junior dev who is getting free mentoring and resume building at the expense of a volunteer project run by you. (In my opinion) the cost of mentoring on a volunteer project rarely worth the time unless the person is committed to the project and has a genuine interest in it beyond the GitHub cred.

There are two paths to consider.

Mentor the junior dev. You will continue to shepherd every commit and making sure that the material submitted is up to your standards for the project. Your primary role in this is that of a mentor to ensure that both your project and the junior dev's commits to the project are what you are expecting.

Don't mentor the junior dev. Your time in volunteering for working on your project is just as valuable, if not more so, than his time. There are likely many closing up shop in preparation to say "its done" and move on to another project. Often these are tedious and boring tasks, but they still need to be done. Things such as:

• documentation - have another person read through all of the text written and make sure it has the correct spelling, punctuation, grammar, formatting, and so on.
• style cleanup - grab your favorite linter and run the code through it according to the style that you want. Log all the style clean up items as issue per file to be cleaned up.
• test writing - work on improving code coverage. There are always tests to be written.

Realize and remember that if there is a task that will take you 4h to do yourself, or 3h of your time and 8h of the junior dev time, there isn't much business / time sense in having the junior dev doing it unless you are taking into account the value of having the junior dev gain experience.

Look into what each person (you and the junior dev) are getting out of the arrangement. You are both volunteers. If there isn't something for a volunteer to do - that's ok.

Answer 6

Tell them the truth, but stick to the facts.

Be straightforward and honest and lay out the facts as you've presented them here:

• With the benefit of hindsight now, you see that the amount of help they require is very time consuming. It has begun to hinder your own ability to do work on the project.
• You are winding the project down. You are approaching a point where you will no longer work on the project. Let them know the reasons for this. (E.g., maybe it is being superseded by a new project with better support/funding or there simply isn't much work left to do.)
• Thank them for all the effort they've sunk into this project, and tell them you hope that the experience has been helpful for developing their abilities.
• Possibly offer to help them find another project where they can continue to do development work, perhaps one more in line with their current level of skill.

Be aware that they might respond by asking if they could continue working without such close supervision. If it's feasible, you might consider intentionally taking a more hands off approach and then just reviewing their work when it's done (e.g., as a pull request). It's up to you whether this is viable. If you can find a small change for them to implement, you might consider this. If you try it and it doesn't go well, you can show them specifically what's wrong with their work, and you might need to return back to this discussion about not having time and the project winding down.

Things not to say:

• You're firing them.
• You don't enjoy the project anymore because of them.
• They're incompetent or anything else about their innate ability.

Sometimes, it's better not to say everything you think and feel. Not because you are dishonest, but because you know your feelings and thoughts are not completely objective. Our judgements are sometimes clouded by our unfulfilled desires, so sometimes we keep our mouths shut about thoughts and feelings that we know aren't really valid.

Yes, there's some inherent risk that you might hurt their feelings. Any approach here carries risks. Doing nothing risks you becoming frustrated and releasing it in an nonconstructive way, and lying or fudging the truth risks the other person finding out what really happened. Being honest has the virtue of trusting the other person to evaluate the situation themselves and come to see things as you do. The person can see you're not being unfair and that you're trying to approach the situation objectively. If they don't understand your point of view, it's okay to talk it out with them and explain; that isn't really possible if you aren't straightforward.

If you sense the other person starts doubting that your friendship will continue, make it clear that you want to continue it. How to do so is beyond the scope of this question, as it depends on specifics of how the other person responds.