Technical questions
Originally published on Medium, on 2018-01-10.
In February of 2016, I became the first employee at LumApps who was neither in the sales team nor a developer. My primary responsibility was to help partners deploy our product, but my time was also spent on pre-sales, support, and various client-related topics for which no one had clear answers.
One immediate consequence was that I was asked all sorts of technical questions. While it is often agreed that having a knowledge base for those questions is a good way to go, this article is about the nature of those technical questions. What are technical questions, exactly?
Technicality is self-exclusion
A technical question is usually nothing more than a very precise question about a very specific thing. It’s annoyingly accurate, and about something that isn’t obvious. As such, it takes time to research the answer.
There is a common misconception about developers. People who are not developers think developers have a magical skill that allows them to communicate with computers. The truth is that no one is born knowing how to do that. You try stuff — which most of the time doesn’t work at all — and you spend countless hours not understanding why the damn computer won’t do what you want it to do. And yes, some end up liking it.
Questions are labeled as technical by people who do not wish to deal with them.
Those questions fall into 3 categories:
- questions you don’t understand, or with terms you don’t understand
- questions you do understand, but don’t know the answer to
- questions requiring a certain kind of authority, or about a topic you don’t want to deal with
1. Questions you don’t understand, or with terms you don’t understand
Obscure acronyms are a trap. So are obscure terms and buzzwords. They feel like expertise, but they are actually a failure to communicate clearly.
You will hear things like:
Can your product reverse the polarity of the neutron flow if we have a VPN with MD5?
Don’t panic. If the term is important to your professional environment, you should get familiar with it quickly. Otherwise, it’s just someone trying to impress you.
If you don’t know what the person is talking about, there is little chance the question is important at this stage of the discussion. Try to understand the use case behind it: why are they asking this question? Why is it important? What are they trying to do?
When asking those basic questions, you’ll soon get to the root of the problem, which is usually much simpler to understand.
2. Questions you understand, but don’t know the answer to
This one is easy. If you don’t know, find the answer, and add it to your knowledge base — ideally, one that is available to the whole company, otherwise build your own. Odds are, the question will come up again, and your effort will not have been in vain. If nothing else, you’ll have learnt something. Cheer up :)
What is important is not to have the answer, but that you understand the question. If you don’t, you’re going to have a hard time passing it on to someone else.
3. Questions requiring a certain kind of authority, or about a topic you don’t want to deal with
This is the most difficult case, since it is more about politics than knowledge.
Authority isn’t necessarily the CTO, it’s someone whose input will have more weight than yours. A lot of people probably know more than you about a specific subject, but if you’re calling them every time for the same questions, you’re essentially showing that you don’t know how to learn.
I’m not saying you shouldn’t ask for external help, but the way to go will depend on your actual team structure — and sometimes your work environment and culture. My recommendation is to throw all those questions into an asynchronous process.
A good approach is to categorize all those questions into separate buckets, and deal with them one at a time. Yes, it does require spending time to understand them, even if you’re not the one who will eventually deal with them. But that little extra touch will benefit you in the long run.
The time of your teammates
You will rarely spend enough time understanding other people’s jobs.
It is safe to assume that when you’re invoking someone for help, you are pulling them from more interesting work. Yes, their input will be valuable to you, but it may not be so valuable to them.
Try to understand how people around you work, especially people providing the knowledge that you frequently require. They will magically find more time to help you.