Soliciting Feedback and Help

Thanks to Vonage for sponsoring this article

Picture this - you're seven pages deep into a Google search, you've got anywhere from 16 to 21 tabs open, and you've revisited the same mildly helpful page on Stack Overflow too many times. In a word, you're stuck.

When you're working with code, this happens all the time. A unique type of frustration brews within you when the trajectory of your day gets curtailed by a misspelt variable name. While it's relatively easy to become unstuck when you're sitting with someone else, you need to rely on your problem-solving skills when you're on your own.

Now that most of us have been working remotely for two years, we've all become far more intentional with our catch-ups. You're unlikely to get chatting about that problem you're chewing over while making coffee in the kitchen. Remote work has, in some ways, brought us together and has made work, for many, way more accessible than it's been in years.

Depending on the make-up of your organisation, you might find that you're consistently going to the same one to three people for help every time. It's easy for a few people to become siloed with both knowledge of the application you're on and the framework you're working with. If you're one of a few juniors on your team, it won't take long before the people who become your go-tos on problems quickly become inundated with requests for help.

Just like in web development, we've got requests on one side of the equation and responses on the other, but unless people are equally and equitably distributed, we're in danger of burnout from occurring on both sides of the equation.

Even when people genuinely love supporting others, it can be challenging to come back to every single request that comes your way. Similarly, you shouldn't see this as a sign to suffer in silence. You are valid and should feel empowered to ask for help when needed.

So how do you ask for help?

Soliciting Feedback From People You Do and Don’t Know and Telling the Difference

Our mentors are often undefined in that they don't even know they're our mentors. It's common for us to see someone on social media assume that they're the sum of their projected successes and seek them out for help. It's essential to define your stakeholders in this scenario.

When asking for help from people you don't know, this handy talk from Kurt Kemple, Founder and Principal Advisor at Forthright, will help you get off to a great start at instigating and navigating positive transactional interactions.

If you are familiar with the person, maybe they're a colleague, classmate or someone from your network who you know particularly well, you can feel free to get to the question a little faster. Include some details about the scope of the task, along with the deadline.

In this case, you may know their time commitments and have a general idea of their availability. Understanding what else they're juggling can help you to determine how much time you likely can expect them to dedicate to your issue and get an early sense of their response times for messages on the matter.

Once you have an idea of the amount of time they might be able to dedicate towards helping you out, factor this into your deadline. Make sure you account for the time you intend to spend both working with them and implementing their advice or feedback. If this throws out your timeline and could potentially contribute towards a delay, speak up to anyone involved. It’s a good idea to manage these changes to your project proactively. It’s very rare that everything goes to plan and resetting expectations is an excellent skill to master.

As a brief overview on where to start when asking a question, it's essential to lead with why you're getting in touch and then share a short, sincere appreciation for their circumstances. By setting up the context for a conversation without outright asking a question but making a scoped request, you're allowing someone to make an informed decision regarding how and if to help you. The goal here is to help both of you to understand if you're a good fit for the type of discussion you're interested in having.

More importantly, it prevents you from getting into the scenario where you're hinging all your hope on someone's potential answer. We often love to think that our network might have our answers, but poorly scoped requests can, at best, open you up to a transactional relationship with someone and frustrate them and put them off working with you.

Here's an example of what a well-scoped request could potentially look like:

Hello! I'm currently studying Typescript and would love to get your advice on a problem I'm struggling with. Completely appreciate that you might be busy or not have the time to discuss this. Let me know if you'd be open to having a short conversation to help point me in the right direction regarding finding a solution. I can let you know how I've been working to solve the issue and how far I've gotten to troubleshoot it.

Knowing Who To Go To

Usually, when we find ourselves stuck on an issue or a particular problem, we're unable to parse the issue's cognitive load.

Cognitive load, by definition, is the total amount of mental effort being used in the working memory, and when the task at hand exceeds what we're able to give to it, we end up in that stuck state that we described at the very beginning.

Generally speaking, there are three types of cognitive load:

1. Intrinsic load is relative knowledge to the problem you're in the process of solving and is often described as the 'inherent difficulty of the problem you're solving’. It's what you bring to the exercise. In the case of programming, intrinsic knowledge might be how a class is defined or how you write a function.
2. Extraneous load refers to the efficiency of the task at hand and how you're able to tackle it. Extraneous load is how you present the job. Do you need to run between several documents to get what you need or jump in and out of several apps to check that your solution works? That's your extraneous load.
3. Germane load concerns the mental schemas you've constructed. Most commonly, this involves the effort of translating learning into long-term memory. Germane load will crop up in your domain experience around a specific topic and become apparent when you know your learning style. Most notably, this is usually the load the person you ask for help will likely exert as they get to grips with the task at hand.

Your ideal problem will exert one to two types of cognitive load. Usually, your intrinsic load will be somewhat fixed by the type of work you're dealing with. We can use this framework to our advantage by recognizing where we can minimize the cognitive load. Most commonly, that'll be the extraneous load.

Thanks to Vonage for sponsoring this article

We can alter this by ensuring the task we're working on involves the minimum amount of context switching possible and that any friction points are discussed ahead of time. For example, if you need a password or different user permissions to access the application you're working on, take care of this as soon as the person agrees to support you.

We can also look at cognitive load to exercise professional empathy. If you were them, which bucket would your request fall into? Does this match their area of demonstrated expertise? How much guidance would they need to review your work? Go through the process of understanding how they might support you, and you might even stumble across an angle of the problem you hadn't seen before.

Asking the Question

This part of the process is really important. We need to do three things here. Firstly, we need to clearly and completely state the problem. Give context on the conditions of the error or bug in question. Give the full error message. Make sure to outline what has gone wrong with references to your development environment (or if this has occurred in staging or production), the versions that you're running and which line you're having problems with.

Next up, have you done your homework? Before you even go to this person, you need to have attempted what you expect of someone else yourself. An associate software developer I know has this rule - he attempts to solve the issue for between 30 minutes to an hour. If he doesn't get to the bottom of the problem in that time, he starts constructing the request for help, citing what he's tried and where he's gotten that information. This is arguably the most important step.

Asking for help in a scoped way that demonstrates your understanding shows that you're improving as an engineer and committed to your own progression. It demonstrates that you'll be able to implement the knowledge you gain from this person helping you when you next come across an obstacle of this nature.

Lastly, make sure you detail your constraints. These can be time-bound, system-specific, and potentially more critical than functional requirements. State the urgency and importance of your ask to give the person you're working with a guide as to how to deal with the request at hand. This is the part that's the most important for remote and asynchronous working. There's a good chance someone's going to glance at your request for help from their phone screen.

Make sure you accurately convey to them the urgency and importance of your request, remembering that both of these factors are often subjective. Stating whether an issue is preventing you from making any further progress and detailing any consequences to it remaining unresolved can keep your discussion universal and productive.

This final section is usually a good indication of whether or not the recipient of your request is the right person for the job and, as such, able to meet the requirements you're after. Need a response in an hour? It might not happen. Half a day? Potentially more feasible. What’s urgent to you may not be urgent to the business or individual you’re speaking with. If you're in an incident response role, your threshold for urgency will differ from an associate engineer.

Recognizing the Road to Resolution

Now that you've made your ask, you've got a sense of the path to resolution. You need to confirm that you're on the right track. Here's where you can understand how many of your assumptions are correct and how much of the information you've documented is useful. This is the part of the process where your partner will start to dig deeper. They'll interrogate your approach to problem-solving and ask a few questions to determine if your understanding of the urgency and your grading of importance matches theirs.

The level of engagement you gain during this stage will give you a sense of how involved the person wants to be in your solution.

Do they ask a lot of questions? Are they offering you a co-working session to solve the issue live? They will offer this help if they're willing to give it. Use this as a chance to help them point you in the right direction.

As a final step, we need to manage the resolution process. Take the help you've been given and be proactive with the next steps. Will you take their suggestion and give it a try? Will you go to someone else? Let them know. Close off the conversation and be clear whether or not you're looking for another interaction with this person. People like to have a sense of how helpful they've been. Remember that both of you are looking to become better from this process.

If someone is going down the wrong road, they don't need the motivation to speed them up. What they need is education to turn them around.
- Jim Rohn

By teaching and helping others, we have the opportunity to really, thoroughly get to know a subject. Make sure to take back the reins of the conversation once you've been offered help and demonstrate your course correction.

If you think you might be asking too much of someone, empower them to tell you this at the elicitation stage. There's a chance you might, at some point, assume you have too much of someone's time or project your collaboration ideas onto them before you've even struck up a rapport with them. While this is entirely possible, it's not guaranteed to happen. Remember that if you don't ask, you don't get.

Thanks to Vonage for sponsoring this article