Don't miss my next post! Subscribe to my Technical Leadership newsletter and learn a bunch of useful stuff about effective technical leadership.
How do you ask questions?
|
What do you do if there's stuff you don't know? Can you ask questions? What questions should you ask? How should you ask those questions? In an earlier post, I addressed the fear of having colleagues with better technical skills than you. I suggested, "Spend time pairing with [those who know more than you]." And I added, "Handled without apology, this exercise will deepen your team members’ respect for you, rather than the other way around." I promised to explain what I meant in another post. Well, this is that post. I love questions. I could ask them for hours. I'm one of the nosiest people you'll ever meet, and yeah, OK, if you ever met me after hours and I pinned you to your seat with a million questions, I apologise. There's a reason this site's called Queen of Questions. And even the queen of questions can overdo it with a drink in her hand. But in this post I'm going to address the "without apology" thing. My career in software engineering was split in two halves, where for the first half I was afraid of asking too many questions, afraid of being a nuisance. I mostly just accepted it when I felt like I didn't know what was going on. I ended up feeling like I didn't belong and leaving the industry altogether. But after a brief stint as a high school maths teacher (whole other story), I came back full of curiosity and decided what the hell, how am I going to learn if I don't ask questions? But here's the thing: I was no longer apologetic about those questions. If you sidle up to someone, eyes to the ground, muttering "Look, I'm sorry, I know this is probably a stupid question and you've got better things to worry about, but... er... could you maybe explain to me..." NO. STOP THAT. It's a shame, but it's true that if you do that, people will judge you. If you apologise for wasting people's time then all you're doing is planting the thought that you might be wasting their time. Some of my most inspirational colleagues were those who were highly respected, very experienced, very clever... and would quite happily march into a room and loudly pronounce, "I have no idea what's going on. Someody please explain." When I started asking questions like that, I was continually astonished by how positively people responded. They respected me for being honest. And there was more. Not only did I ask questions confidently, like of course they were going to help me work it out... but I also gave enough context to remind them and me that of course I wasn't stupid. I just didn't happen to know this one thing. "So, I get this bit... and this bit... but I need help understanding how the widget will connect to the wotsit in the flapstick circumstances." Or even just, "You know what, I used to know about this but I've forgotten the details. Remind me?" The thing is, if I need to know the answer, then I need to know the answer. Simple as that. Nothing to be ashamed of. The team is composed of its members. And if one team member doesn't know something they need to know, the whole team suffers. I'll leave you with this excellent xkcd cartoon about Today's Lucky 10,000, which encapsulates why nobody should ever be embarrassed about not knowing something. If you want to hear more about this or many other topics, check out my upcoming events! Attend one of my talks, or join one of my workshops: PulpoCon ’25, Vigo (Spain), Friday Sept 19th 2025, WORKSHOP: Lift up conditional— The magical refactoring (LH) |
Clare Sudbery
Don't miss my next post! Subscribe to my Technical Leadership newsletter and learn a bunch of useful stuff about effective technical leadership.
Would you like to attend a talk about how to counter the fear of not being technical enough, or how we can stop making each other feel stupid, or how to make the most of diversity in the workplace? Or maybe you'd like to immerse yourself in one of my hands-on workshops... about refactoring skills, or about using TDD to wrangle AI coding, or facilitating mob / ensemble programming, or on how to handle the technical in technical leadership? Fancy spending time in Spain, or Berlin, or Paris, or...
Oh no! You’ve been given a new team to lead, and they’re working on this horrible legacy code base that everyone hates! I can't make sense of this code... Nobody enjoys working on this code. Team members are going through the motions with no interest in what they do, repeating the same terrible patterns and either counting the days to retirement or actively looking for more exciting work elsewhere. Here are three things you can do to make things better, for yourself and for your team: 1....
How will you fit through those holes? "I'm worried my current position only works at my current company. I moved up fast because soft skills come naturally for me. I prevent any office politics from affecting my devs, and they have the freedom of implementation at an execution level. But ask me to implement code for multi-threading? I am starting from 0." You are not alone When I'm running workshops with technical leadership, I see concerns like these raised repeatedly. People who started out...