Emotional Intelligence and Relationship Building Questions

Using the STAR structure (Situation, Task, Action, Result):

Situation: I joined a team split across two offices with different norms, one where jumping in to give quick feedback mid-discussion was normal, one where interrupting was considered rude and people waited to be asked.

Task: as the person running shared planning meetings, make sure both groups actually got heard, not just whichever group's norm happened to match the meeting's format.

Action: I noticed the first office's feedback was dominating simply because they spoke up unprompted, while the second office waited for a pause that never came in a fast-moving meeting. I restructured the meeting to include an explicit round where I asked each region by name for input before opening the floor generally, and moved detailed feedback to a shared document with a 48-hour async comment window, so the wait-to-be-asked norm wasn't a disadvantage in a live setting.

Result: participation from the second office visibly increased, measured informally by comment volume in the shared document and by them proposing changes that previously would have gone unraised. At least one plan actually changed based on feedback that wouldn't have surfaced under the old live-only format: a scheduling conflict the async group flagged that the live-meeting group hadn't considered because it didn't affect them directly.

Trade-offs and pitfalls
The fix, a named round plus an async channel, cost meeting time and added a process step; it was worth it because the alternative was making decisions on input that felt complete but wasn't. The mistake to avoid is assuming a quiet group agrees, when the real cause is a mismatch between meeting format and communication norm, not a lack of opinion.

Confirming shared understanding at the close of a meeting matters more than it sounds like it should, most miscommunication is discovered days later, when it's expensive to fix, rather than in the room, when it's free.

Three closing techniques

1. Round-robin summary: go around and have each person state, in one sentence, what THEY are walking away committed to doing. This surfaces divergence immediately, because two people's one-sentence summaries of "the plan" often turn out to be different plans.
2. Parking-lot review: read the list of deferred topics back out loud and confirm who owns following up on each, so "we'll come back to that" doesn't quietly become "we forgot about that."
3. Follow-up note: a short written recap sent within a few hours, while memory is still fresh, stating decisions and owners plainly rather than narrating the discussion.

Follow-up note template (one sentence)
"To confirm what we agreed: [decision], owned by [name], due [date], flag me directly if that doesn't match your understanding."

Worked example
The same paraphrase-and-confirm pattern shows up mid-conversation too, not just at the close. A short paraphrase in the middle of a back-and-forth ("So you're saying the price is fine but the payment terms aren't") lets you confirm you've understood someone's actual position before responding to it. And at the end of a planning meeting, a round-robin once revealed two engineers had different understandings of who owned a migration script, caught live instead of discovered at the deadline. The same closing pattern matters just as much with an external partner: read their exact words back before the call ends, so a partner's stated position doesn't get "translated" into something looser by the time it reaches your own team.

Trade-offs and pitfalls
Round-robin summaries take real time and can feel redundant in a meeting that already felt clear, the value is precisely in meetings that feel clear but aren't, a genuinely confused meeting gets this scrutiny naturally. A follow-up note sent the next day, instead of within a few hours, loses the "still fresh" advantage, people have already moved on mentally.

The core idea

The goal in the moment is to convert a vague, emotionally flat comment into a concrete technical question without getting defensive, since "this is wrong" gives you a judgment but no information to act on.

Clarifying without escalating

• Ask a specific, non-defensive question: "Can you say more about what's wrong here, is it a correctness issue, a style preference, or does it conflict with something upstream?" This isolates whether it's a bug, a convention, or an opinion.
• Reflect intent, not just content: "I want to fix whatever's broken here, I just need one more detail to know what to change."
• Once they respond with something real, restate it back before touching code, so you don't do the work twice.

What happened

A reviewer, Tom, left "this is wrong" on a database query change with nothing else. I replied: "Thanks for flagging, can you point to what's wrong, is the join incorrect or is this about indexing?" He said the join would double count rows under a specific condition I hadn't considered. Restating it back, "so when one order has several shipment rows, the join matches each of them and that order's revenue gets counted once per shipment, is that the condition you mean?", confirmed I understood before changing anything, and the fix took ten minutes instead of a guessing match over comments. Two things about that restatement are deliberate. It names the mechanism, one row matching many rows on the other side, rather than gesturing at "the join", because a restatement vague enough to be unfalsifiable confirms nothing and the reviewer will read it as agreement. And it ends as a question, so a wrong mechanism costs one line to correct instead of a wasted change. When I genuinely cannot name the mechanism, I say so rather than guessing at one, since a smooth wrong paraphrase makes the reviewer stop explaining: "I want to fix the right thing, can you point me at the case where the counts diverge?" works better than a confident sentence that is subtly off.

When to escalate instead of continuing over text

I'd move it off the thread, to a quick call, or to their manager or mine, if I've asked a specific clarifying question twice and gotten another one-line non-answer, if the language shifts from describing the code to describing me, or if the same reviewer repeats this pattern across multiple pull requests, since that's a pattern worth addressing directly rather than one comment worth re-litigating in text.

Where this can go wrong

Mirroring terseness with terseness reads as pushback and escalates tone without adding any information either side can use.

The core idea

A closed question is answerable in a word or two, usually yes, no, or a specific fact, and it narrows things down. An open question requires the other person to explain, describe, or reason, and it's what you reach for when you need to understand something you don't already have a hypothesis about.

Three closed questions while troubleshooting with a colleague

1. "Did this start after last night's deploy?"
2. "Is the error happening on every request or intermittently?"
3. "Have you already checked the connection pool settings?" (A connection pool is the set of reusable database connections an app keeps open rather than creating a new one per request.)

Three open questions for the same situation

1. "Walk me through what you were doing right before you noticed it."
2. "What's different about this environment compared to staging, where it doesn't happen?"
3. "What have you already ruled out?"

When to reach for one over the other

Closed questions are the right tool once you have a specific hypothesis to confirm or eliminate quickly; they're efficient for narrowing a known set of possibilities, did X happen, is it Y or Z. Open questions come first, or when a closed question gets an answer that doesn't add up, because they surface information you didn't know to ask for directly, like an environment difference or a step someone skipped without realizing it mattered.

What happened

Debugging an intermittent timeout with a colleague, I started open, "walk me through what changed recently," and got "nothing changed on our side." That was not a dead end, it was the first real piece of information I had: if nothing moved inside the service and the timeouts started anyway, the change came from something the service depends on rather than from the service itself. A second open question, "what does this code path call that your team doesn't own," narrowed that to the upstream API. Only then did I have a theory worth testing with a closed question: "did the upstream API's timeout setting change last week?" She checked and confirmed it had. That closed question would have been useless five minutes earlier, when I had no reason to single out that one dependency out of the several that path touches.

Where this can go wrong

Leading with closed questions when you don't yet have a real hypothesis just produces a slow, guess-by-guess interrogation instead of letting the other person surface the actual cause faster.

The core idea

The private 1:1 (a one-on-one conversation, just the two of you) version should read like a colleague raising something they've noticed and want to fix together, specific but low-stakes in tone. The manager-facing summary should read like a factual, dated record with less interpretation of motive, because the two documents serve different purposes. The subject of both is the runbook, the written step-by-step guide an engineer follows to handle a given kind of production problem, which is supposed to be updated whenever the code it describes changes. Both messages below are written to be sent word for word, so the explanation of the term stays here rather than inside a message to the engineer who maintains it.

(a) Private 1:1 message to the engineer

"Hey Sam, I noticed the last three runbook updates after your changes were a few days behind the code, including the payments retry logic last week. I want to flag it while it's small, is something making that hard to keep up with right now, like time pressure or not being totally clear on what needs updating? Happy to pair on the next one if that helps."

(b) Summary note to the manager

"Runbook updates for Sam's changes have lagged code changes by 2 to 5 days across the last three releases, most recently the payments retry logic. I raised it directly with Sam and offered to pair on the next update; flagging for visibility in case it's a broader capacity or process issue worth tracking."

The differences, explained

• Tone: the 1:1 is curious and collaborative, "is something making that hard"; the manager note is neutral and factual, with no speculation about cause beyond what was actually said.
• Level of detail: the 1:1 focuses on the most recent, most relevant example so it doesn't turn into an audit; the manager note includes the pattern across releases, because that's what supports a tracking decision later.
• Next steps: the 1:1 offers direct, personal support, pairing; the manager note surfaces it for org-level tracking without committing the manager to any particular action.

Where this can go wrong

Never let the manager summary come as a surprise to the engineer. Sam should already know I flagged it directly and, ideally, that I'd also mention it upward. Otherwise a well-intentioned paper trail feels like being reported on behind their back, and it undoes the psychological safety, the sense that raising a mistake won't be held against you, that the 1:1 was trying to build.