I was hanging out with a friend a few days ago when he told me a story of incompetent management — the sort you take for granted in any sufficiently large corporation, but one bad enough to pause drinking for.
(You know, for fear of spitting beer all over the countertop).
My friend started his story like so: “My boss sits me down on my first day of work and runs me through a few basic things. Just the basic things, mind, not enough for me to finish actual tasks that he assigns to me.”
I nodded, sipping my drink.
“A couple of weeks later, I'm handling this assignment that’s difficult because I’m new, and I don't really know what to do. So I go to my boss, and ask him how to do it, and he snaps at me: ‘go figure it out on your own!’
“So I’m frightened, right? I try and work it out. But I can’t get very far, and I do a bad job. When my boss finds out, he gets mad. He asks me why I didn’t ask him for help. I’m like ‘wtf?!’ At the end of that year my boss tells me that I have an ‘attitude problem’, and cites this incident as an example. It goes into my perf review. That was when I gave up.”
I commiserated with my friend and we drank to his bad luck. It was only much later, when I was on my way home and thinking back to the conversation, that I realised that I did have a suggestion to make.
It is probably true that my friend’s boss was a total asshat. But on reflection, I think his predicament could be explained by a simpler underlying principle: maybe, just maybe, he asked his questions badly over the course of a year, and got only bad outcomes as a result.
Not All Questions Considered Equal
You've probably heard of the saying “there is no such thing as a stupid question.” This is a laudable aphorism in the abstract, but in practice it simply isn’t true.
I work in the tech industry. When I first started as an intern, I noticed that certain people were much better at asking questions compared to others. They were more successful at getting answers. They were never seen as stupid, and were rarely — if ever — considered a nuisance. The simple fact was that senior engineers seemed more willing to help them in ways that weren't available to the rest of us.
And then there was … well, me. And all the interns who were like me. I noticed that I was comparatively bad at asking questions. I struggled with the tension between asking for things related to my tasks — necessary if I wanted to complete them on time! — and not being a nuisance to the higher-paid, higher-impact engineers I was working with.
This period of tension didn’t last long, however. I eventually became competent enough to do my tasks without asking questions, and usually ended my internships on a high note — treated no differently from and as competent as any other junior engineer in the company. My initial conclusion from those early experiences was that the awkward period of navigating this tension was part and parcel of any new role, and learning to work through such tension was simply a necessary step during any engineer’s life.
Today, I know enough to know that my initial conclusion was wrong. In fact, I've gone out of my way to teach my subordinates to ask good questions — for the simple reason that it allows them to onboard quicker, and with less friction with the rest of my team. All of this stemmed from a simple observation: at some point in my career, I realised that the good question-askers were better because question asking is a skill — and that you can get better at it.
Good question-asking allows you to sidestep the initial awkward period in any role. It also leads to a number of beneficial downstream effects — one of which is an ability to gain mentors in your chosen industry. This second bit is something I learnt from my boss at my previous company, one that he’s used to great effect in gaining mentors who were old hands in the ‘Chinese businessmen’ community in Singapore. More on this in a bit.
The Structure of a Good Question
There are three steps to a good question. Note that I’m talking about ‘on-the-job’ questions here, but much of what I say can probably be generalised to questions in other contexts, with varying degrees of success.
The three steps are as follows:
- Pick a good time. Most people don’t like to be interrupted when they’re in the middle of something — programmers more so than most. There are two ways to get around this. The first way is to observe and pick a good point at which to ask your questions — for instance, you could accost your boss when he’s on his way to lunch, and make sure you get all the answers you need before you get back. The other option is to simply ask for their time — while making it clear how long it would take. A simple “could I ask you some questions on implementing the shopping cart enhancements? It’ll probably take 15 minutes of your time, but I’ll need some help to get unblocked on this task” would suffice.
- Show that you’ve done your work. This is where most people screw things up. The worst kind of question-asker is someone who simply asks a question without showing proof of work. I’ll circle back to this in a bit, but for now, what this looks like is saying something along the lines of “I’ve tried approach X and Y but didn’t get anywhere, and I’m thinking this is because of root cause P and Q. I’m also considering approach Z, but I think I would do better to ask for your advice first.” This method demonstrates that you’ve actually done the work around your question. Most people don’t ask questions like these, though, and suffer for it. Instead, they ask: “I can’t solve A for task B. Help me pretty please?”
- Ask a well-formulated question. This is the last part, and it is the bit where you actually ask a question. Here, the normal rules of effective communication apply — just as you’d expect as with any other interaction with your superiors. This means providing surrounding context for your question, but doing so in a manner that presents just enough information for them to grok. In practice, this usually means using something like Minto’s Pyramid Principle to communicate your ideas; anything else and your explanation becomes too unwieldy.
In general, people tend to get step 1 and step 3 right. It’s clear that you shouldn’t tap a senior engineer on the shoulder when they’re busy programming, in the same way that you know not to barge in on a high-level staff meeting with your queries. Plus, if you’re not great at communicating context, you’ve probably got bigger problems with your communication skills than just ‘bad questions’.
No, the issue here is usually with step 2. So why is step 2 so important?
The reason step 2 is important is because most senior employees are very busy people, and the last thing they want is a young whipper-snapper trying to get spoon-fed answers out of them. Get a bunch of seasoned middle managers in the same room and it’s likely that the things they complain about to each other are some variant of “I have this subordinate who keeps asking stupid questions, and it’s dragging on the team and I don’t know what to do with them!”
That’s the worse case scenario senior people have in their heads when you approach them with a question; some part of their brain goes ‘oh, is this person one of those time-wasting bloodsuckers?’ And if their brains generate a ‘yes’, what happens is that you now have to fight against a narrative that you are bad at your job. This is the sort of narrative that tends to stick around; consequently, you only have a few minutes to show them you are not, and you have to make it count.
What step two forces you to do is to demonstrate that you aren’t a ‘young whipper-snapper who just wants to be spoon-fed’. By explaining what you’ve tried to do before asking your question, you are showing your boss that you’ve spent some amount of time thinking about the problem, and that you’ve taken some initiative before getting stuck. This assures the person you’re asking that you’re a) not dumb, and b) you’re not likely to keep leeching off questions in the near future. It makes them more inclined to help you, because they know you’re likely to go off and get shit done.
My ex-boss used this insight to build an impressive network of old-school Chinese businessmen advisors in Singapore. The way he put it to me was: “people like helping people who can be helped. So be someone that can be helped!”
The idea that people help those who possess initiative applies just as well to a mentor-mentee relationship just as it does to a more traditional manager-subordinate relationship. My boss, again:
You need to understand that people do like helping people — but only if their help counts for something. You need to show them that you’re actually listening to and acting on their advice if you want them as mentors to learn from!
And this is a somewhat intuitive, I think. If you mentor or coach someone, you want proof that you aren’t wasting your time. My boss said that he makes it a point to always bring up some advice from a previous meeting. What this looks like: “Mr Tan, thank you for what you said about sales the last time we met. I’ve been looking into applying it to our team, and it's really worked out …”
I don’t mean to say that an ability to ask good questions would solve all your communication problems. In fact, I’m a little uncomfortable writing this essay, because I think that many of the ideas here are obvious and a little trite. But then again, this seemed surprisingly useful to my friend at six years of work experience. Which makes me think that it might be useful if I wrote it out here. The things I talk about in this essay are things that I teach my subordinates (mostly because I dislike subordinates who take up too much of my time with ‘bad’ questions); it's helped me innumerable times in my career, and I hope it’ll help you with yours.
PS: Julia Evans has a wonderful guide for asking questions as a software engineer, and it's arguably better than my treatment; she summarises question-asking guides across multiple engineering publications on the web. See also: Erin Ptacek's Be Coachable, which is essentially my ex-boss's approach to mentorship, but expressed a different way.
Originally published , last updated .
