How to lead a technical discussion

Estimated reading time: 8 minutes

Key takeaways:

• Leading a discussion means facilitating and not having all the answers.
• The real skill is making tacit knowledge visible then finding alignment, even on what nobody knows.
• Strong emotions carry real information. Objections become testable predictions.

---

Most people picture building software as writing code, but it never was. You spend as much time discussing what you’re planning to build as you do building it. Nowadays, with AI taking over more of the writing of code, understanding what to build is becoming increasingly important. That usually requires having, or leading, technical discussions – something most of us are not deliberately taught how to do.

Technical discussions come in many shapes and forms. One of my most memorable occurred shortly after joining a scale-up in Amsterdam: I had to lead an incident call. I’d never been an incident manager before, but at this company every engineering manager was one.

Of course, like all good incidents, it happened in the middle of the night. PagerDuty went off and after shaking off the sleepiness, I slid in behind my laptop and dialed into the incident call. There were a handful of other engineers on the call, none of whom I’d met before. Everyone was silent.

“Hello?” I said quietly, trying not to wake my partner in the next room. One or two other engineers came off mute to say hi, and promptly muted themselves again. Nobody had their cameras on either, understandably.

It was at that point that I realized this wasn’t going to be easy. The issue was in a part of the system I knew nothing about, so I didn’t even know where to start. However, I knew I had to get the conversation going so we could work out what had happened, resolve the issue, understand the impact, update management, and get back to bed.

Most technical discussions don’t happen in the middle of the night, nor under such urgent or awkward conditions. Regardless, if you’ve never led a technical discussion before, you might find it just as alien and stressful.

So, you’ve been asked to lead a discussion and you’re quietly wondering whether you’ve got what it takes. The truth is, nothing beats first-hand experience – the more you do it, the better you’ll get at it – but there are a few things to help you get going.

What you’re actually being asked to do

Let’s start by understanding what the words themselves mean. If you look up ‘lead’ and ‘discussion’ in the dictionary, you’ll find something like:

• Lead: to serve as a channel for, or to bring to some conclusion or condition.
• Discussion: people talking together to share ideas, compare opinions, or solve a problem.

In other words, when you’re asked to lead a discussion, your role is to serve as a channel through which people can share ideas and compare opinions, with the aim of solving a problem or landing on a conclusion. Notice how none of this requires you to have all the answers or even be a subject matter expert? It just requires you to facilitate a conversation.

Externalize the internal

More subtly, what you’re really trying to do is ‘externalize the internal.’ People have a lot of knowledge about how things work, or should work, but it’s often locked away in their minds. 

Your first task is to make that visible. Once you’ve done that, you can focus on finding alignment. Alignment doesn’t mean agreement – in fact, you can look for alignment in what you don’t agree on, or what you collectively don’t yet know. That all counts because it creates shared ground that you can proceed from, together.

You’ll quickly learn that solving the problem often isn’t possible in a single discussion, but that doesn’t necessarily mean failure. Successful technical discussions might simply surface assumptions and allow better questions to be asked in follow-up conversations.

Start with questions

So how do you get people to talk about all that tacit knowledge that’s locked away in their minds?

Start by asking people for their observations and opinions on the matter at hand. Ask them about what they’ve seen, experienced, or done, rather than try to diagnose the situation on the spot. This allows everyone to participate, including those who don’t yet have an answer. 

How you ask questions also matters. Use open questions like ‘how would you approach this?’ when you’re getting the conversation going or trying to get that internal model out into the open. Closed, more specific questions like ‘does this need to be real-time?’ work when you need a fact that you can act on. Be deliberate about this because knowing when to ask open questions is just as important as knowing when not to.

One technique that has worked well for me is to identify the known unknowns and, if possible, the unknown unknowns, as there’s more value in spending time on those, together as a group, than on what you already know.

When someone feels strongly

There will be occasions where someone expresses a strong opinion that can feel emotionally charged – we are human, after all. It can be tempting to steer clear of situations like these, but handled with care, these situations can lead to the deepest and most revealing insights. 

Consider the engineer who’s been burned by an architectural decision made by someone who wouldn’t have to bear the consequences if it went wrong. Or the one who had to take a shortcut they knew was risky, only to find out the hard way the true cost of that decision later on. It’s precisely these sorts of experiences that teach us the best lessons, but they can leave scars.

Getting to the bottom of why someone feels so strongly about something requires genuine curiosity. You could try asking why they feel that way, or what they feel may go wrong. In doing so, you’re asking them to make a prediction, and that’s something that can be tested. After that, you can ask how they think that outcome could be avoided, which turns someone with an objection into an active contributor.

I remember leading a discussion on how we could deliver a piece of work in a third of the time the team had planned. The deadline was a regulatory one: it hadn’t come from us, and we had no ability to move it. I was accountable for the delivery, so I was the one who had to carry that date into the room.

As you can imagine, this wasn’t going to be an easy conversation. The engineers had given their estimate and they were being challenged on it – of course they weren’t happy. I knew I had to approach the topic with care, and make visible all of the decisions behind their estimate. This allowed us to test each one, to identify whether all the work they’d planned for was required as part of this feature build. In this case, the team had decided to refactor some related code, and they had good reason for doing so.

They felt strongly about it and expressed their opinions with conviction. I thought they were right about the work but wrong about the timing. I asked them to share why they felt this work had to be done now, and what would happen if they didn’t. With this out in the open, we could discuss options that would take less time now, but avoid the outcomes they feared most.

Ultimately, we were able to find other opportunities to do that refactoring, where there wasn’t as much time pressure to deliver.

When it feels like you went backwards

Not every discussion will go the way you planned. Some will feel like they took you backwards, like you spent an hour and came out further from an answer than when you went in. I’ve had plenty of those, and they’re frustrating, but even those got more of that internal model out into the open, and that’s the whole point.

Setting the conditions

There are several techniques you can use to create the conditions for a healthy discussion to take place. For example:

• Ensure the purpose of the discussion and expected outcome are both clear. Starting a discussion with this clarity will help keep it on track.
• Share the agenda early, so everyone has a chance to think about the topic before the meeting. Conversations where people feel prepared to contribute are more likely to be fruitful. 
• Keep an eye out for the quieter voices in the room, and make space for everyone to be heard. Equally, don’t put anyone on the spot. If they don’t want to speak, don’t force them to.
• Allow limiting beliefs, or assumptions, to surface – and name them, respectfully. As mentioned earlier, assumptions can lead to better questions, and some may turn out to not hold true in the context being discussed.
• Timeboxing and parking lots are useful if you need to move onto the next point but don’t want to lose those thoughts. 
• Whiteboards can be very helpful, particularly when the conversation involves something that can be represented visually, like architecture, design, or process. Virtual whiteboards can work just as well as physical ones. 
• If available, recording and transcribing the discussion allows you to use AI to further analyze any underlying themes or gaps that may have gone unnoticed.

You may have noticed that none of these points are technical. These techniques are more about general facilitation and they work for any topic, and while they’re useful to have up your sleeve when leading a technical discussion, they’re only part of it.

The rest depends on the system in front of you – how deep into the weeds to go, whether the problem on the table is the one worth solving, what everyone is assuming about how it behaves, and what the consequences of getting it wrong might be. That’s the part that makes it technical.

So the next time you have the opportunity to lead a technical discussion, take it. You don’t have to have all the answers; focus on externalizing the internal, find alignment on what you know and what you don’t, and keep the conversation moving. You learn this by doing it, and there’s no better way in.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.