# Client meetings in English: three situations every FDE should practise until they are reflex

> One clarifying question you don't ask in a meeting can cost two weeks of building the wrong thing. What you lack at that moment is rarely grammar. It is a sentence you have practised in advance.

Original: https://fdetimes.net/en/guides/fde-client-meetings-english-phrases/

Ten minutes into the meeting, the client's head of operations says: "We need the dashboard to be more flexible." The whole room turns to you. You understand every word, but you have no idea what they want.

For many engineers who did not grow up speaking English, the reflex at this point is to nod and say "Sure, we can do that." It sounds polite. But it can cost you two weeks of building the wrong thing, or a deadline your team never agreed to.

The difficulty rarely lies in grammar. It is that you have no sentences ready for the three moments most likely to catch you off guard: when you need to clarify a requirement, when you need to say no, and when someone asks "when will it be done?". Below are model sentences for all three, with a dialogue to practise.

## You don't need to sound eloquent, you need to ask the right question

PostHog treats one core FDE skill as the ability to read requests that are vague, or over-specified, and find the real question underneath. The company's FDE handbook also tells FDEs to solve the client's real problem, not the one that is easiest to turn into a ticket.

That is why you don't need to sound eloquent. You need to ask the right question. FDE Academy advises that when you start with a new client, you should ask "why" more than "what" before writing a single line of production code. PostHog suggests a very usable question: before you start, ask which decision depends on the answer.

In English it can be put simply: *"Before we dig in, what decision will this help you make?"* You don't need advanced vocabulary. You need to say it as fluently as you say your own name.

## How do you ask again without sounding as if you weren't listening?

Talaera, a business English platform, sets out a four-step process for asking for clarification: soften first, admit you haven't fully understood, restate what you heard, then ask a specific question. Step three is the key. When you restate the client's point, they see that you listened carefully, not that you missed something.

On softening, Babel Group suggests phrases such as "Can I just ask you…?" when cutting in, and using "would like" instead of "I want" when making a proposal. Without these cushions, your question can easily sound like an interrogation.

The technique most worth practising is offering two interpretations. Talaera's example: when a client says "flexible timeline", ask whether they want to push back the deadline or accept a change in scope. Offering two concrete options forces the client to choose, and that choice is the real requirement.

## A sample meeting, three sentences that save you

Picture the meeting from the start of this article continuing. The client is a delivery company, and you are building a dashboard to track late orders. Here is a passage you can practise, with each turn labelled with the technique it uses.

**Client:** "We need the dashboard to be more flexible."

**You (soften, admit you haven't fully understood):** "Can I just ask you something? I'm not sure I've got it fully."

**You (restate, offer two interpretations):** "When you say flexible, do you mean filtering by more fields, like region or driver, or changing the layout per team?"

**Client:** "Filtering. Our regional leads can't see their own late orders."

**You (confirm the interpretation):** "So, to confirm: filters by region for the regional leads, not a new layout?"

**Client:** "Exactly."

**You (ask about the decision):** "Got it. What will the regional leads decide once they see that?"

In a few turns, "flexible" has become a testable requirement: filter late orders by region for regional leads, and the client has confirmed it themselves. That is work you can estimate and deliver, in place of an adjective nobody can measure.

Then the client adds: "Should we also send them a daily email report?" This is the second situation, and the one where many FDEs slip.

## Saying no without closing the door

PostHog says it plainly in its handbook: push back on every "should we also..." suggestion. The same handbook treats a work item that has doubled in size as a new quote, not an informal extension. That principle gives you something to stand on. You are not turning the client down because you want to avoid work; you are turning them down because of the agreed scope.

FDE Academy suggests a "conditional yes" in place of an unconditional nod: agree, then spell out how the work changes the timeline. In the sample meeting, your line might be: *"We can, and it'd add work beyond what we scoped. Happy to scope it separately so the filters still ship on time."*

Note the structure: you don't say a bare "no". You acknowledge the value of the suggestion, state the cost, then offer a way forward. The client still hears a positive sentence, and the scope stays intact.

## "Let me check" is a strong sentence

The third situation arrives near the end of the meeting. FDE Academy points to a common mistake among new FDEs: promising a deadline or a feature in the meeting before asking the team whether it can be done. The way to avoid it is to defer the commitment while naming a time to reply, as in the final part of the sample meeting:

**Client:** "So can we have it by Friday?"

**You:** "I'd like to give you a date I can keep. Let me check with my team and confirm by tomorrow noon."

This only works if you actually report back on time. FDE Academy's reasoning is that clients remember who kept their word far longer than who sounded confident in the meeting room.

**Key point:** Clients remember who kept their word longer than who sounded confident.

## How to practise until it becomes reflex

Start with a short phrasebook, split by the three situations: clarifying, saying no, deferring a commitment. Each needs only three or four sentences you can genuinely say; don't copy out a hundred. Read them aloud until they come out without your head translating.

Then practise in real meetings, starting by speaking up early. Babel Group advises non-native English speakers to contribute right at the start of a meeting and not to worry that their English is imperfect. The longer you stay silent, the harder the first sentence becomes.

This skill should also show up in your CV. Instead of a generic "good communication skills", describe a time you turned a vague request into concrete work, or held the scope against a request for extra work. If the hiring process includes a client role-play round, the dialogue above is ready-made practice.

## The mistakes that let a meeting slip away

The costliest mistake is nodding before you understand, because you will build exactly what the client doesn't need. Close behind is the generic "Can you repeat that?", which leads the client to repeat the same vague sentence word for word. Instead, restate their point and offer two interpretations.

The third mistake is translating directly from your first language, producing sentences like "I want you to send the data", which sound far blunter than you intend. The last two are saying "no" without offering a way forward, and fixing a date on the spot. Both have replacement sentences above, as long as you have practised them.

A meeting in English does not require you to sound like a native speaker. It requires you to turn a vague "flexible" into work that can be done, hold the scope, and come back at the time you promised.

**Try this week:**

- Write a phrasebook of about 10 English sentences for the three situations of clarifying, saying no and deferring a commitment, then read it aloud every morning.
- In your next meeting, say something of value in the first few minutes and use the structure 'When you say X, do you mean A or B?' at least once.
- Record yourself playing both roles in this article's sample dialogue, listen back and fix the places where you hesitate.

## Sources

- [How forward deployed engineers work (PostHog Handbook)](https://posthog.com/handbook/forward-deployed-engineering/how-we-work)

- [10 Mistakes New Forward Deployed Engineers Make (FDE Academy)](https://fde.academy/blog/mistakes-new-forward-deployed-engineers-make)

- [Ask for clarification (Talaera)](https://www.talaera.com/speaking/ask-for-clarification/)

- [5 Tips to Help Non-Native English Speakers in Work Meetings (Babel Group)](https://www.babelgroup.co.uk/about-us/babel-blog/5-tips-to-help-non-native-english-speakers-in-work-meetings)