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...
back
8 comments
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) :)
I would often ask questions I knew the answer to (or mostly knew the answer to) just to get insight into someone's point of view, or to give insight into my point of view (usually coming from ops/administration/devops pov), and sometimes as a way to subtly point out that they are doing something terribly inefficient from the 10000 ft view (usually to more junior devs who have tunnel vision on their cog).
> 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.
One of my favorite interview questions for senior positions is "Tell me about a decision you made that you would change in hindsight." Junior level people and people who are otherwise unfit for the role will try to give answers that minimize their responsibility or (worst case) have no examples. Senior level people will have an example where they can walk you through exactly how they messed up and what they would have done differently. Good senior level candidates examine their mistakes and are honest about them.
I do this for everyone, not just senior positions. "If you were to start that again today, knowing everything you do now, what would you do differently?" is a question you can ask regardless of seniority. Even if they've only done some school projects, being able to look back and say "yeah, that could have gone better from the start" is a hugely valuable signal.
The details of how I ask it might change based on seniority, but that I ask it? No.
It’s also true that the kind of people who are ready for staff level work are already doing staff level work. While social capital is a factor, it isn’t necessarily accumulated because of title or experience.
The idea of “disambiguation” is itself ambiguous. The way I recognize other people solving problems at a staff level is we are communicating in terms of properties, constraints and tradeoffs. Crucially, these constraints are not necessarily business constraints, but rather, constraints inherent to an architecture. For example, queuing works for ordering because it append-only, and monotonic. So as soon as you have multiple queues (such as partitioning) or try to reorder it, it also loses its ordering guarantee. Does the problem require ordering?
The first couple chapters of Roy Fielding’s dissertation goes through this. The first time I tried reading it, I did not have experience to understand. It was a slog and I got little out of it. The next time I tried reading it, it was helping me gel and articulate things I had started observing from experience. I recognized that I had previously been so focused on architectural elements and that the properties and constraints were far more important. It is this that determines what is being traded off, and antipatterns pop out. Knowing properties and constraints allows me to quickly identify problems, and start the process of disambiguation. Many of the other staff or principal engineers I have chatted with communicate along these lines.
I don’t try to ask smart questions or dumb questions. I ask questions so that I can understand properties and constraints.
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.
Reminds me of Jason Freedman's "I don't know": https://news.ycombinator.com/item?id=7334671 (2014) / https://archive.vn/Z7m9M
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.)
Eh, I'd say that's very org-cultural dependent.
Honestly, orgs that don't "get this" is why consultants exist.
Schools don't teach this to students.