‘TIPS’ on how to ask a question
With the hybrid model of working becoming more popular, here are some subtle ways to make your collaboration effective and efficient. Try before you ask, know your Intention, lay out the Problem and Speculate on potential solutions. Use this as a framework to structure your questions better.
The last two years have seen significant changes to what we thought was the norm, especially with remote work. It’s hard to say whether we moved into a WFH (Work from home) model or LAW(Living at work) model. Either way, we have had to learn some new things, unlearn a few things, and adapt to a few things.
One of the things that took a beating at work for me was face-time with my colleagues. A lot of discussions that lead to ideas and conversations that clarified roadblocks now moved into an online model — which meant I was talking endlessly into a black screen(sometimes) AND I had to be enthusiastic about it OR go back and forth with a question on slack AND not be discouraged about being blocked on it for long. This was quite stressful to adapt to in the beginning, but Corona was here for the long run, so we had to make peace with this.
In that effort, I replayed a conversation I had face to face with my colleague while getting an issue unblocked only to see that there was a pattern in the way the conversation took place.
Now imagine, back in the day in 2018 BC (Before Covid I mean :P), two colleagues meet at the break-room and the following transpires:
Me: “You know, I’ve been working on consolidating the owners of ABC for a while now. I made some progress but once again hit a roadblock.” (I)
Colleague: “Oh man, that’s an important initiative, what’s going on ?”
Me : “I’ve explored the XYZ create & update API, but for some reason, when I use the XYZ update API to update an entity, it doesn’t seem to work. I cross verified that the payload is correct.” (T)
Colleague: “Oh, interesting. Are you sure your authorization headers are correct?”
Me: “Yes, I’m sure, because I get a 200 OK, but the problem is I don’t see the entity updated.” (P)
Colleague: “Ok, I wonder if the update API is obsolete and we should use the upsert API instead of the update, may be check with the team with all these details? “ (S)
This conversation if looked deeply into, can be broken down into 4 distinct sections:
1. What am Intending to do ?
2. What have I already Tried?
3. What Problem am I encountering ?
4. What do I Speculate the problem to be
But more on this later…
I know it seems weird that we must re-think the way we ask questions, but bear with me as I go through this other example, where I was on the receiving end of a question.
Question:
“Hi, we are trying to setup and run ETL jobs, can you help us?”
Response: ¯\_(ツ)_/¯
- Who are “we”?
- What ETL job?
- Where are you trying to run it?
- What are your constraints?
One of the easiest ways to deduce if your question is too vague, is to try googling it. A search engine will struggle to give you a good answer for an ambiguous question.
The better way to frame this question would be:
“Hi, I’m a member in the big data team. In our effort to setup data pipelines, we are trying to evaluate whether to run our ETL job on an EMR or to use AWS Glue. Can someone help us?”
Do you see the difference/ pattern in the latter? Sometimes as engineers things may be obvious in our heads, but not necessarily outside of it.
Nothing is as invisible as the obvious.
As question askers, we often get so caught up in getting our own problems solved immediately that we sometimes forget about what it’s like for the responder. This strange year of working from home has taught me how to better structure my questions to get solutions as effectively and efficiently and with as less disruptions as possible for the responder.
So here are my TIPS on asking a question:
- What have you already ‘T’ried
- What is your ‘I’ntent
- What is the ‘P’roblem you are encountering
- What do you ‘S’peculate the problem to be
Structuring your question in the following manner not only helps the responder but also helps you understand if you’ve overlooked something.
Tried and Speculate:
Focusing on the problem first is great, but the fact that you are starting with what you’ve tried shows effort — effort you’ve taken to solve the problem by yourself before throwing your hands up in the air. It also shows that you are not reaching out because there happens to be a channel and it is convenient to ask a question and wait on it. The responder is surely incentivized to reply sooner because they are potentially responding to a genuine asker rather than a lazy slacker :P
Sometimes channels not only have on-call engineers and managers on them, but also have PMs, especially when the product is new. This section of what the customer has “tried” and what the customer “speculates” can be great pointers on Intuit’s Design For Delight policy. It shows the implicit thought process behind the customer’s mind. What they tried will translate to what they expected the product to do and what they speculate could translate to how they thought the product would work.
Problem:
Being articulate is a skill that needs constant honing. Being extremely clear about your question sometimes can be arduous for engineers. Our brains usually speak more like if-I-do-x-then-y-will-happen-else-z. But honing this skill over the last year, has helped me both as an asker and as a responder. For ex, sometimes when I fit my question into the TIPS method, I have found gaps in my effort or understanding of my intent.
In engineering, articulation can also mean sharing an API response and our understanding of it, screenshot of the errors and our understanding of the anomalies or debug logs or and any statistics can help in understand your situation better.
As an asker, our goal should be that the reader should be able quickly come to our level of debugging just by reading the notes — and if it is a SME addressing your question there may be a clues/pointer that they can quickly get to, to unblock you.
Intent:
This section is almost like a gist for the reader. You want them to give them a one liner on the problem you encountered without hashing out too much of the details just yet.
Common what-ifs
1. Will someone think I’m stupid for asking this question
- You know in my small 7 years of a career of asking all sorts of things, I’ve realized that no one cares to remember anyone’s birthday, let alone your supposed stupid question :D And also, you’d rather be stupid once and ask the question, rather than being stupid forever :P I’ve also noticed (out of my own introspection) that lot of those qualms are self-made. For ex. In software engineering, you might not know conventions until you encounter. That doesn’t mean you are stupid, it’s just that you haven’t encountered it before.
2. What if I’m already supposed to know this?
Oh well, then isn’t it better to be late than never ;)
3. If my question is ignored, what do I do ? Does it mean my question is too lame? What if no one responds to my question ?
- You must be in a responder’s shoe to really know what it is to handle back-to-back questions. There is no harm is sending a gentle reminder, it could’ve been a genuine miss.
- Also, RTFM!! There is a reason why there are pinned items on a channel- something you don’t know today is something someone else did not know yesterday. It is worth while to check the channel history for a similar question
- If this has happened too many times across the board, re-thinking the way you ask a question would be a good place to start.
4. Do I know enough about this to even ask a question?
- Believe me, if you ever have this doubt, write down your question in the TIPS method, you will know if you know enough :)
Asking questions means never letting your curiosity die. But asking questions effectively means living well :P That is the only way to learn. If we consider knowledge to be power, then curiosity is the muscle. So don’t be shy of exercising it!
