Comment by cod1r
16 hours ago
I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions.
That wasted a lot of time which is a lesson to be learned from.
I also struggled with self management.
My superpower as a staff engineer was having zero shame in asking questions. Anything from "what does that abbreviation stand for?" through to "what will the traffic look like when we go live?" - mostly people are worried about looking ignorant, so weirdly this makes you look both knowledgeable and confident! I wish I'd known that when I was younger...
Unfortunately it is a bit more subtle than that though:
(1) Questions reveal a lot about someone's state of mind, particularly if there are a lot of them. If someone is actually struggling and doesn't maintain a vague silence, the people around them will figure it out even faster. Arguably not a bad thing, hiding things is a weak strategy.
(2) There is a certain type of middle manager who fears clarity, because clarity leads to accountability and at some level they have identified that as a threat to their careers. It is prudent to be very careful what sort of questions to ask that manager - "what does that abbreviation stand for?" is fine, "what is the exact problem here and what do you want the solution to look like?" or "I don't understand, can you get into the details of why you think that?" can be unexpectedly controversial.
So there is a superpower in having zero shame in asking questions, but the real trick of it is being able to identify the set of inoffensive, basic questions that will move a project along. There is a large class of technically-reasonable-politically-imprudent questions that an inexperienced engineer might ask to their detriment. I've never been afraid of asking questions but if the mindset behind the question isn't fairly polished then there can be backlash and a most people learn to avoid questions rather than getting good at being mentally flexible.
Ok, I was a little tongue in cheek, so I agree it's a bit more complicated than just asking any question that pops into my pretty little head.
But I do think that not worrying about whether people will think I'm ignorant for asking is a very important first step that I could have applied successfully when younger. Confidence is hard earned though.
When explaining stuff I've been working on to others I often tell them "what the fuck?" is a suitable question (to try and lower this barrier) :)
1 reply →
> I wish I'd known that when I was younger...
While I wouldn't say more people shouldn't do this more of the time, there is also a lot of social capital you have as a staff level person that makes it "easy" to do this. (and is part of why it's important to)
Was just about to say this. As a staff engineer your position is (or should be!) so secure that you can get away with asking all sorts of “dumb” questions that more junior engineers don’t want to ask. I will also regularly say things in meetings like “I don’t understand, can you take us through that again” or “can you remind me how <xyz thing> works?”. Sometimes this makes the difference between a meeting being useful and everyone just being confused but afraid to say so.
In an ideal world, juniors would all do this too, but I don’t blame them if they don’t. So it’s very important to do it if you have the social capital.
3 replies →
For sure, a staff engineer asking lots of question is "disambiguating" a junior engineer asking a lot of questions is asking somebody else to figure out his/her project. Which is kinda true in a sense, you don't give a super-vague project to an engineer who's just starting up for a reason.
Yes, this is so powerful.
One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something.
Either way I'm modelling:
- that it's okay to ask questions to which the answer seems obvious
- that it is totally fine not to know everything
Mine is "I'm going to ask the stupid obvious question here", then ask the question.
In general people like to answer questions - it makes them/us feel mildly superior - hopefully in a good and positive way. You have to use some judgement on how to approach and engage.
Depending on who you are engaging with, a packet of Hobnobs (other socially acceptable bribes are available) might be needed or perhaps waiting until after lunch.
Now, your next mission is getting something done by making someone else think it was their idea in the first place. It might sound counter-intuitive: "How does that benefit me, they get the credit". Crack that conundrum and you will advance to the next level.
100% this: if you go every axis of what differentiates staff from senior one will see deep down it is about asking questions: either yourself or helping others ask the right questions (e.g. mentoring, impact/are we solving the right problem, etc.)
Schools don't teach this to students.
Eh, I'd say that's very org-cultural dependent.
Honestly, orgs that don't "get this" is why consultants exist.
Reminds me of Jason Freedman's "I don't know": https://archive.vn/Z7m9M
I struggle with this a lot. I'm currently about ten years in to the career and technically at my org I'm a "senior".
One issue I have quite often is I'll know I have a problem with understanding something and so I ask my team but then the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging. I think a lot of the time I notice people conflate experience level with amount of context I have with something.
I'm still struggling with these kinds of challenges and I would readily admit it could be my own weakness but I also wonder if it's a team culture issue; but I've noticed this across my current org and my last one so maybe it's more of a me-problem.
> [...] the response can be something like "you should know X" or "you should know this because of Y context" and it can be discouraging.
This is definitely a cultural problem. You should get clear and non-judgmental answers to questions like these, because it should be regarded as absolutely normal that you can’t keep everything in your mind, or that you may have missed some context.
In a culturally healthy org, everybody supports each other.
usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space.
whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
This is very common behavior. This is where a good manager can really help. They can recognize this is happening and then provide context.
One approach to deal with ambiguity is to write a short design doc, which writes down what you are trying to do, and all of the assumptions that you are making. If you don't understand the domain, some of your assumptions will probably be wrong. The stakeholder should be able to see that and provide guidance.