How to Ask for Help (on a distributed project)

Hint: it's all about draft PRs and creating a conversation

I use my garage as an office, so I work on remote and distributed projects. I follow up with my colleagues every few days about any pending issues and offer my help. One of the challenging aspects of software development is encouraging people to seek help. Here are some tips to make the work process more efficient and productive.

Asking for help is part of the job

We follow the 70/20/10 rule to manage our time. This means that 70% of our time is devoted to challenging work on the product, 20% to building relationships, and 10% to external learning. We want our team to understand that 90% of the work involves solving hard problems together, and that discussing those problems is part of the work. We also want to encourage our team to ask for help as easily as they offer it. For those who come from academic backgrounds, we may need to persuade them that tickets are not assignments, and that PRs are not evaluations. Fortunately, we have tools that can help us with that.

Draft PR early, push often

I will assume that you are using GitHub for source control and that you have a branching strategy that involves pull-requests. If this is not the case, you will have to adapt this to your own process. The best time to start a PR is when you begin working and have made some changes that are worth committing. You might object that you are not finished yet, but you can indicate that by creating a "Draft PR". If you have a paid edition of GitHub, you can use the actual feature for Draft PRs, but otherwise, you can simply add [DRAFT] or [WIP] to the beginning of your PRs to let others know that they are not ready to be merged. You should get used to making those PRs early and frequently. This way, you can easily ask for help when you need it.

Comment on the line giving you trouble

We use PRs to discuss the code asynchronously. We can comment on specific lines of code, start a thread, and even @mention our teammates. This way, we can present our problem to fresh eyes and ask for help without disrupting them in real-time. We can also send them a slack message with a link to the exact line of code that is causing trouble. Sometimes, this process can help us solve our own problem by getting a fresh perspective. So it is always a valuable time investment.

Signal your need for help

Choose a messaging system that you prefer and use it to request help from others. You should not feel ashamed or guilty for doing this. It should be a common and natural part of your daily interactions. As a leader, you should demonstrate to your team how to ask for help frequently. If you are afraid of asking for help, confide in someone trustworthy and overcome your fears. Asking for help should be the easiest thing you do every day.

Giving help is part of the Job

Recall the 70/20/10 rule for time management? Helping others falls under the 70% of your time that you should spend on your core tasks. Your colleagues are not bothering you, and helping them is part of your important work. If your colleague has prepared a Draft PR, commented on the relevant code line, and tagged you in a slack message with a link to the code, then respond to them with a positive attitude, and a curious and courageous approach. Together, you will overcome this obstacle and move closer to building that product.

Conclusion

I hope your team finds it beneficial to create PRs earlier in your process. This may require some time to adapt, depending on the habits they have developed during their career. It will take a few successful iterations of this process before everyone feels comfortable. Be consistent and reinforce the process by demonstrating this behavior to each other. When folks ask “Can you take a look at this”, reply with “Sure, send me a Draft PR”. Once your team adopts this practice, I think you will discover that asking for and giving help becomes less stigmatizing and more normal.