How awesome engineers ask for help

Techniques for collaboration

You reboot your development server, but it happens again: err_node_unsafe. This wasn’t here yesterday. What changed?

It’s 9:48 in the morning and your coffee is already cold. Most of the other people on your team aren’t in the office yet. This is your fifth week at the company, your feature was supposed to be done two days ago.

You raise the height of your chair as if that would give you some sort of different perspective on what’s going on. You reboot again, and the stack trace slides into your terminal again: err_node_unsafe. You wipe your development database: err_node_unsafe. Come on!

The tech lead of one of the other teams is at her desk across the room. Her headphones are on. She’s deep in the zone. Would she be able to fix this? What would she say? Does she know what’s going on? Can she help?

You stare, silently, and the sides of the screens swing towards you, imperceptibly, by an inch. A coffee ring appears on your notebook. You stay silent. Then, you reboot again. Maybe this time, the error won’t happen.

Asking for help is hard, and procrastination protects us from it. That’s why you must perfect your ability to ask for help. It’s key to achieving productivity as an engineer.

1. Clarify what’s expected of you.

Don’t work under unclear expectations. The result can only be ambiguity and guilt. Take, for example, the following:

• Get out of the house and go to work.
• Get out of the house and go to the gym.

Which of those two things are easier to do? Getting on my way to go to work in the morning isn’t the easiest thing in the world, but it’s far easier than going to the gym. I know that if I skip work, several people will notice. No one expects me to go to the gym. That lack of expectation means I’m less motivated to do it.

When your expectations are unclear, you’re going to procrastinate, make excuses, change your mind several times, and have a bad time getting the job done.

Getting help at work is the same. If you feel like no one is expecting you to ask for help, you’re going to have a heck of a time convincing yourself to do it.

Ask your manager what they expect you to do when you’re stuck.

This will change the way that you think about getting help at work. Ask your manager what you should do when you get stuck. After that conversation, you’ll start to think of getting unblocked as a part of your job instead of a failure to do your job.

Discussing how to get help normalizes your process of getting stuck. It prepares you to face the challenge head-on.

Are you worried what your manager might think when you bring up this topic? Be sure to start the conversation by restating common ground. Reiterate that your main goal is to be an autonomous and productive contributor to the team. Then discuss what a productive engineer does when they get stuck.

Define your personal procedure leading up to asking for help.

Describe the steps that you go through when you get stuck. Include anything that’s likely to unblock you without help. The final step in your process will be to ask to collaborate with someone else.

When it’s time to ask for help, don’t hesitate. Make the decision to ask for help as clear and objective as possible. The more you can remove subjective judgment from the decision, the better.

Here’s an example of a checklist that you could use:

- Did I restart my development environment?- Did I write down the problem?- Did I Google it?- Did I run that build-cleaning command that sometimes works?- Did I search our internal docs for it?- Did I read some of the related source code for 20 minutes?- If so, ask a teammate for help immediately.

Share this checklist with your manager and teammates. It’s a powerful way to set crystal-clear expectations for yourself. Remember to revise and update this list as you learn more about how to work on your team.

2. When you ask, take full responsibility.

Many engineers think of asking for help as a failure to do their jobs. To them, asking for help is giving up. When they ask for help, they’re only interested in getting unblocked so that they can resume their real jobs. That’s why they might ask a question like this one:

“My git branch is really messed up. Can you fix it?”

Then they might sit to the side while another engineer takes the keyboard and fixes the problem for them. Their eyes kind of glaze over as they watch someone else work. They’re so burned out on the problem that they have completely checked out.

Make it clear that you’re not giving up.

Avoid using phrases like “I need help” or “I can’t get this to work”. These both imply that you’re done working and you are now trying to pass the buck off to someone else. Instead, describe your ongoing work. For example: “I’m looking into this weird error on my development server.”

Next, hint at some of the work you’ve already done. “I’ve checked Slack for the error and searched the source code and haven’t found anything so far.”

Finally, describe how they can get involved in your next step. “I’m going to look at this file to understand what’s going on. If you have a minute to pair on it with me, it would be helpful.” You’re creating a productivity train that’s taking off whether or not they decide to hop on-board.

Bringing energy and focus to the conversation helps everyone have a better experience. Your teammates will be a lot more enthusiastic about helping you if they can see that you’re not checked-out.

Actively participate in the helping process.

Once you start working with someone, don’t step aside and let them work on their own. Work on building up your own copy of their own mental model. Ask “why” questions, like “why might a node be unsafe?” and “why are you looking in this file?”

Take short notes during the process. These might be useful to you later. They also display appreciation and respect towards your coworker. Active learning is far more effective than passive learning, so participate as much as possible by speaking and writing.

Pair programming takes a lot of energy. If you sense that you’re flagging, then don’t be afraid to say that you’re going to work on the problem on your own for a while. Be specific about how you will explore the problem so that they can leave you to it with confidence. This will keep you from zoning out.

3. After you get an answer, follow up.

It feels so great to make progress on a project after being stuck for several hours. The error goes away, and you’re ready to fly. I mean, being productive is what it’s all about, right?

Then, three days later, it happens. We’ve all done it. “Hey, Mark — what was that command I’m supposed to run to fix this problem again?” I wouldn’t blame Mark if he thought that his help was going in one ear and out of the other.

Getting help requires significant time investment from all parties involved. It’s just good business to make sure that investment doesn’t go to waste. Be intentional about how you act after you get help.

Solidify what you learned.

This is crucial: every time you work with someone on something, write down what you learned. Writing is the oven that hardens ideas in your mind like a brick.

Make capturing notes as frictionless as possible. I find that even choosing a filename is too much work, so I use Quiver to track my notes. My notes have no organizational scheme, and they are still useful to me on a daily basis.

If you posted your problem on a company Slack channel, follow up with what your solution was. This forms a knowledge base that is useful to you and others. It also creates a stronger sense of accomplishment for you so that you’re encouraged to find help again in the future.

Spaced repetition is one of the most effective ways to remember information. Anki is a powerful tool for managing spaced repetition. Sending yourself a boomeranged email or delayed Asana task is a simpler way refreshing yourself.

Show appreciation, not just gratitude.

If you make people feel great about helping you, then they’ll do it more. You probably already say “thank you” after someone helps you. That’s showing gratitude. Appreciation is different from gratitude. When you appreciate someone, they feel special and unique.

Here are some ways to do that:

• In your team Slack channel: “Shout out to Alice for helping me figure out that weird bug!”
• During standup: “Yesterday I was blocked for a while, but Alice helped me figure it out because she knows a lot about how our Controllers work.”
• Writing a quick email: “Thanks again for taking the time to help me earlier today. I’m making great progress now.”

Appreciating people after a delay makes the interaction feel less transactional. Instead, it feels like you’re building a strong professional relationship. Showing appreciation is harder than it looks, so remembering to do this will make you stand out in a good way.

Always make it count when you ask for help.

Software engineers explore uncharted territories of logic and data. The adventurous will always encounter the unexpected. There is much to uncover on your own. However, there is far more to learn in collaboration with your fellow explorers. Embrace it, and master it.

Your ability to solve difficult problems with others is one of your crucial skills as a professional software engineer. What can you bring to the table when you’re stuck on a problem? Learn that, and there’s nothing that can stop you.

If you’re passionate about helping teams collaborate effectively, you should work with me at Asana.