Because seeking assistance shows strength rather than weakness
Whether you’ve just landed your dream CTO role at a new cryptocurrency exchange using the latest blockchain technologies, or started day one of your first paid developer gig, it’s unlikely that you’ll know everything needed to do your job.
Faced with a bewildering number of frameworks, programming languages and business opportunities, even if you did know all the facts, you’d still lack the insight to know what’s the right thing to do. With increased choice comes greater confusion; for anyone that is used to getting things right, this can be quite frustrating. However, one of the simplest ways to overcome this problem is to ask for help.
With this in mind, I’ve outlined the simple five-stage process I’ve used on discovering that perhaps I’m not quite the know-it-all I thought I was.
Whose problem is it?
If you cannot get React Native to build, Docker to deploy or Redshift to respond, it’s not your fault. When Google unhelpfully confirms that everyone else in the universe has the same issue as you do — and nobody seems to have an answer — owning a small goat farm in the Brecon Beacons suddenly seems like a great career change.
Luckily, others have been in your position before, producing what can only be described as one of the finest engineering cheat sheet to help you through your ordeal:
Burying the problem, blaming someone else and shirking responsibility for it, is a great way to avoid asking for help. While many others may not be able to resolve a namespace conflict in Node.js, nobody else is going to miss their Monday night game of Risk (Walking Dead Edition) if they don’t commit in the next 20 minutes.
The first step in asking for help is to recognize that it is you, who owns the problem you need help with.
What’s the problem?
It’s unlikely that you’ll be in many situations where you find it tough to ask the technical equivalent of ‘Can you please pass the salt?’, unless someone has sent you looking for a left-handed screwdriver.
Knowing what the problem is will make explaining it to the person you want help from much easier. Although it may be cathartic to describe in great detail that you feel like banging your head against a wall because you cannot convince a team member to turn up to a scrum on time, you’ll probably lose the interest of whoever you are asking for help. Below is another handy cheat sheet you can use to classify ‘any’ problem:
If a problem is related to Scope then it’s typically because there is too much to do, if the problem is one of Quality it’s because what has been done is not up to a sufficient standard, and if Effort is to blame it’s often because not enough focus is being applied. If Resources are causative then you don’t have the right people with the right skills, the correct software and / or hardware. Finally, the problem may be that you don’t have enough time and an unachievable, looming deadline. Using these categories to contextualise the problem will improve your ability to explain the issue.
Telling someone the 25 different ways that you have tried to get your release to pass a penetration test is much less helpful than telling them: ‘We know what the security report says, but after 25 attempts to carry out the suggested remedial actions it’s clear that we don’t have anyone who knows how to solve this without pushing the release out by another month”. In this example, you’ve been clear that you have a quality, resources and time issue, possibly due to a scope increase but not due to a lack of effort.
Why is it difficult to ask for help?
In my previous article, I looked at the motivations that compel us to get up at 6.45am and go to work. These become very apparent when you find it difficult to ask for help. If you are driven by money, but are concerned asking for help could affect your bonus, putting up your hand can be a challenge. Additionally, if you are motivated by a great work environment where many of your colleagues are good friends, burying a report that says you need to cut staff costs by 50% is much easier to do. Is there an easy way to deal with a conflict between personal and business needs, and make the right choice? While the extended discussion is not within the scope of this article, there is one mechanism worth mentioning: consider the long versus short-term ramifications of not asking for help.
Problems unattended to, tend to get worse. Technical debt rises, arguments between team members escalate and customers move from upset to cancelling their monthly recurring payments. Whereas a strategy of ignoring and failing to deal with problems might be an appealing short-term strategy, history is littered with examples of the inevitable and disastrous consequences. Whether it’s the Intel Pentium FDIV bug, lack of inspections at the Fukushima nuclear power plant, or the Equifax security breach, all evidence points to the fact that people knew ‘stuff’ that could have prevented the fallout from all these incidents but chose not to. Maybe it’s because they didn’t ask for help?
When should you ask for help?
Timing is everything. You want the recipient of your request to be in the best possible frame of mind to listen, and act on, what you are saying. Need help debugging a particularly nasty null pointer exception? Probably worth waiting till Sandra has finished her first coffee as she is not a morning person. Want Sarah from Product to review your proposal to increase the size of the engineering team? Best to wait until after the current release has been demoed at Town Hall.
However, when working with a diverse team of individuals, it’s not just their receptiveness you need to consider, it’s also the stage of the project. Often projects that require a multitude of skills to work towards a common goal follows a specific rhythm as shown below:
People start at a ‘Cliff of Terror’ with immense fear and excitement about the new project, typically they fall off the cliff and descend the ‘Slope of Delusion’. As they move down the slope the ‘unknown unknowns’ begin to reveal themselves. The code won’t compile, the requirements are too vague, the team don’t have the skills, the budget for cloud services is too little and competitors are launching products ahead of them. The descent into the ‘Pit of Despair’, where the team hit rock bottom, is perilous and disheartening; however, for successful projects there is a point of inflexion or tipping point, and the team begins to ascend the ‘Slope of Enlightenment’. The code compiles, the team finally start communicating in the scrums, the competitors’ products received terrible reviews and pre-sales of your product increase dramatically. Above all you ship an Alpha, woo hoo! Although the ‘Slope of Enlightenment’ is great, at some point you run out of energy / budget / time and you settle on the ‘Plateau of Reality’. If you can minimize the depth of the ’Pit of Despair’ and maximize the ‘Plateau of Reality’ you are likely to have a successful project.
So, when is the right time to ask for help? Ideally, before the ‘Pit of Despair’, especially if asking will allow you to begin ascending the ‘Slope of Enlightenment’. The trick is knowing when that point is, not just for you, but also for the whole project and the person whose help you need. If you can align these, there will be a personal overwhelming motivation for you to make the ask and have your request accepted. You can still ask for help after the ‘Pit of Despair’, but it may be too little, too late, making the ‘Plateau of Reality’ an unachievable dream.
How to make the request
To quote a famous pharmaceutical sales manual:
‘Be brief, be bright and be gone.’
Get the request down to two or three sentences with plenty of specifics without unnecessary detail. For example:
‘I need to hire an experienced GCP DevOps contractor as soon as possible. The team does not have the skills and if we don’t do this we’ll miss the launch date. The cost will be £500 per day and, we’ll need them for three weeks so that’s £7,500 plus expenses.’
This type of ‘ask’ explains the who, what, why, when and how in three short sentences. It leaves the conversation open for further discussion if needed, where you can be very brilliant in explaining your encyclopedic knowledge of the problem’s history. While it is not important to explain the convoluted path that has taken you to this point, It’s crucial to have your back-up material with you when you make an ‘ask’. There is little point in trying to extensively justify, apologise or rationalise and ask for help, because you wouldn’t be doing so unless there was a serious problem.
Whatever stage of your career, you are going to need assistance at some point. Whether you are a CTO with 30+ years of experience or a developer straight out of university, asking for help is a sign of strength. Why? Because showing you have humility, a willingness to learn and a desire to get things done is never a sign a weakness.