How to contribute to a technical discussion when you do not know every term

1. Start with the decision

Purpose: Establish what the group needs to decide and who will decide it.

If the discussion has become difficult to follow, establish what the group needs to decide. Are people exploring possibilities, choosing an approach or reporting a decision already made?

Try: “Before we compare the options, what decision do we need from this meeting?”

That question helps you judge what level of detail matters. You might need to understand the effect on users and ongoing support without being the person who evaluates every implementation detail.

Ask who will make the decision and what information they still need. Otherwise a meeting can end with several people assuming somebody else has approved the approach.

2. Ask for an example you can follow

Purpose: Connect technical terms to a user action you can follow.

A request for plain language works best when it is specific. “I’m following the reason for the change. Could you walk through what happens when a customer presses Save?” gives the speaker a starting point.

Other useful questions include:

• What does that term mean in this system?
• Can we follow one request from the user action to the result?
• What would a user notice if this part failed?
• Which assumption could change the recommendation?
• What do you need from me to move the decision forward?

You do not need to apologise for asking. You can also choose a follow-up conversation when the detail would take the group away from its immediate purpose. Before moving on, establish whether the unanswered question affects today’s decision.

Worked example: when “saved” needs a clearer meaning

Purpose: Explore the user experience behind a technical design choice.

This scenario is fictional and deliberately simplified. Actual systems need their own technical assessment.

A team is discussing a preference screen. A developer says a read replica can lag behind the primary database. A read replica is another database copy used for reading information; in some designs, updates take time to reach it.

You do not have to assess the database design yourself to ask a useful product question: “If someone saves their preferences and refreshes immediately, could the screen show the old choice?”

Suppose the answer is yes. You can then ask what the interface should communicate while that happens, how long the delay might be and what happens if the update fails. The developer can explain the technical options, while product and design help clarify the expected behaviour.

The group now has something concrete to examine. An acceptance example might be: after a successful save, the user can see which choice has been accepted; any delay in displaying it is handled without implying that an unconfirmed update succeeded.

The exact solution remains a team decision. Your contribution has made an assumption visible before it becomes a confusing experience.

Reflect back what you understood

Purpose: Check shared understanding and keep unanswered questions visible.

Before the group moves on, summarise the decision in your own words:

“My understanding is that the update can succeed before every read shows the new value. We still need to agree what the screen displays during that gap. Have I captured that accurately?”

Invite correction. This is a check on shared understanding, not a claim that you have validated the implementation.

Avoid signing off technical safety, security or feasibility beyond your expertise. Record the question and the person who needs to assess it.

Copy this technical discussion note

Purpose: Capture the decision, assumptions and next steps.

• Decision needed:
• User or service outcome:
• Term explained in this system:
• Example we walked through:
• Options and trade-offs described by the team:
• Assumption or unanswered question:
• Person responsible for checking it:
• Agreed next step and date:

Before your next technical meeting, write down the decision you expect, one user scenario and one question. Afterwards, check whether you can explain what was agreed and what remains open. That is a useful measure of understanding.