Client and Customer-Facing Communication Questions

Direct answer

Do not bluff and do not deflect. Answer what you genuinely know at the level you know it, say plainly where your knowledge stops, and convert the gap into a dated, owned follow-up that goes to the engineer who can answer it. A senior engineer on the customer side is testing whether your claims are reliable; one honest "I don't know that, here is how I will find out" costs little, while one confident wrong answer costs the whole relationship.

What to say in the room

Suppose the customer's staff engineer asks: "When a node in your managed cluster fails mid-write, what is the exact consistency behaviour for in-flight transactions? Is it quorum-acknowledged before the client sees success?"

In plain terms: a node is one server in the cluster; an in-flight transaction is a write that has started but has not yet been confirmed to the client when the failure hits; quorum-acknowledged means a majority of the copies of the data have confirmed the write before success is reported; consistency behaviour is what readers and writers can rely on seeing after the failure.

You know the product guarantees durability, but not the precise protocol. Say:

"I want to give you the exact answer, not a plausible one. What I can state with confidence is that a write is only acknowledged to the client after it is durable on more than one node. What I can't state from memory is the behaviour of in-flight, not-yet-acknowledged transactions (writes the client has not yet been told succeeded) during the failover window (the short period while the cluster switches to a healthy node), and that is the part you are really asking about. I'm going to get that from the engineer who owns the replication layer, not from marketing material. Can I bring them to a technical call, or send you a written answer by Thursday noon, whichever you prefer?"

Why this works:

• Separate known from unknown out loud. The engineer hears exactly which part is solid, so the solid part keeps its credibility.
• Name the real question. Restating the part you cannot answer shows you understood the depth of the ask and are not dodging a simpler one.
• Offer a date and a format, and let them choose. A senior engineer often prefers a direct call with your engineer, which also helps you.
• Never guess "probably" on a correctness or safety property. Guesses about consistency, security or failure behaviour are the ones that come back as an incident.

Making the follow-up technically sound

1. Write the question down in their words and confirm it back in the meeting notes, so the answer addresses what they asked and not a nearby easier question.
2. Route it to the true source. Ask the owning engineer or read the design documentation or source of truth. Do not paraphrase a sales deck.
3. Test where you can. If the claim is testable (a failover test in a sandbox, a documented API call), run it and attach the evidence rather than only asserting it.
4. Answer in layers. Lead with a two-sentence direct answer, then the mechanism, then the edge cases and limits, then a link to documentation. Include what the product does NOT guarantee. Engineers trust answers that state limits.
5. Have the owner review before sending, and say in the reply who reviewed it.
6. Close the loop. Ask if the answer resolves the question, and capture any change to the design implication for the customer's architecture.

Worked example of the written follow-up

The written follow-up, as the actual email (figures illustrative):

Subject: Failover behaviour for in-flight writes (your question from Tuesday)

Hi Dana,

Short answer: writes that were not acknowledged before a node failed may or may not have been applied, so the client should retry them safely. Writes that were acknowledged are not lost. Detail below, reviewed by our replication engineer, Sam.

How it works: (1) the client sends a write to the leader node; (2) the leader copies it to the other nodes and tells the client "success" only after a majority (2 of 3) have stored it; (3) if the leader fails before step 2 completes, the client sees an error or a timeout, and the write may or may not have reached the other nodes. A new leader is elected, and writes pause until then.

Documented limit: during that election window we do not guarantee that an unacknowledged write is applied exactly once. In our sandbox test (killing the leader under load on Monday), writes resumed after 11 seconds, and 3 of 20,000 unacknowledged writes had in fact been applied.

Recommendation: use idempotency keys on client writes. That means the client attaches a unique ID to each write, so if it retries after a timeout the system recognises the ID and applies the write only once.

Does this answer your question? If not, I can bring Sam to a call.

This is the contrast with the first meeting: no new promises, only evidence.

Trade-offs and pitfalls

• Over-apologising signals weak competence. State the gap once, calmly, then move on to the parts you do know.
• Deferring everything makes you look like a messenger. Answer at the level you can, and defer only the depth.
• Bluffing is the failure that matters: a wrong detail on a consistency or security property is later found by their engineer, and everything else you said is re-examined.
• Letting the date slip. The credibility you protected in the room is spent if the follow-up is late. If the engineer is unavailable, send an interim note saying so before the deadline.
• Public correction: if you later discover you misstated something in the meeting, correct it proactively and quickly. That reads as integrity.

Direct answer

Give both executives the same recommendation and the same numbers, framed for what each is accountable for. The CFO (chief financial officer) owns spend and financial risk, so show the total cost over time and the cost of the cheaper path; the CTO (chief technology officer) owns delivery and technical risk, so show the operational and change risk of the cheaper path. Then get a decision documented in writing, with the alternative recorded as a chosen risk if they pick it.

The numbers (illustrative, to be replaced with the customer's own)

Technical debt means the extra future cost created by taking a shortcut now. Re-platforming means rebuilding the solution on a different foundation once the first one is outgrown. Self-managed means the customer's own team runs and patches it. Compare two options over three years:

Option A costs $90,000 more up front. Option B costs $40,000 more each year, so the extra upfront spend pays back (is recovered by the lower running cost) in 90,000 / 40,000 = 2.25 years even before the re-platforming. Year by year, cumulative cost without the rebuild:

B is still $10,000 cheaper at the end of year 2 and $30,000 dearer at the end of year 3, so the lines cross a quarter of the way into year 3 (2.25 years). The assumption the result is most sensitive to (the one where a wrong guess moves the answer most) is the $200,000 re-platform: with it B totals $740,000, without it $540,000, still $30,000 above A. I would show both as a range of $30,000 to $230,000 in A's favour.

Messaging for the CFO

"Option A costs $90,000 more now. Over three years it is $510,000 against $740,000, because the cheaper route carries about $40,000 a year more to run and likely needs a $200,000 rebuild by year three. Even if you remove the rebuild, the cheaper route is not cheaper after about 2.25 years. If cash this year is the binding constraint (the limit that decides what is possible), there is a staged version of A at $170,000 now with the remaining $70,000 of the $240,000 build in year two (details to be priced; the three-year total stays about $510,000 before any financing or vendor charge for staging), which I'd rather you consider than the cheaper route."

CFO objections and responses:

• "Why spend more now?" Show the three-year total and payback (how long until the extra spend is recovered), and who bears the year-three cost.
• "How sure are those numbers?" Give the range and state the assumption most sensitive.
• "Can we defer?" Yes, with the staged option, and say what risk you carry meanwhile.

Messaging for the CTO

"Option B ships sooner and I can see why the team wants it. The risk is that your team owns patching, scaling and failover for a component that is not your product, and that it will need replacing once load grows. Option A moves that operating burden to us and keeps your engineers on the product. If you choose B, I'd want a documented exit plan and a trigger, such as sustained load above a set level, that starts the move (an exit trigger)."

CTO objections: "We want control and speed" (answer: what you give up in operational effort, and the exit plan); "Our team can run it" (ask who is on call and how many people it takes); "Lock-in with A" (being unable to leave later without heavy cost; show portability of data and interfaces).

Getting a documented decision

1. Pre-wire both (brief each separately beforehand), then meet together so neither is surprised.
2. Send a one-page decision record before the meeting: the decision, options with the table, recommendation, risks, assumptions, and a decision date.
3. In the meeting, ask for a decision or the missing information with a date.
4. After, send the record back for written confirmation (email reply or signed). If they choose B, record it as an accepted risk (a risk the customer knowingly chose to carry) with the exit trigger and owner. This protects them and you.

Trade-offs and pitfalls

• Presenting different numbers to each executive destroys trust; the facts must be identical.
• Do not frame B as stupid. It is a legitimate choice with a known price.
• The cost of delay (what each month of waiting costs the customer in lost benefit or revenue) and the cost of a change in requirements belong in the record too.
• If neither decides, record that as a decision to proceed as-is, with dates.

Direct answer

I would not give a single firm date for work that has not started. I would give a range, tie each end of it to named dependencies (things that must be true or must arrive for the range to hold), list my assumptions and the inputs the customer owes us, and then send a short written summary the client confirms. A date becomes firm only when the scope is agreed and the dependencies are met, and I say that out loud on day one so the first slip is never a surprise.

How I set the expectation

1. Start from the customer's reason for the date. A date is usually a proxy for something else (a board meeting, a contract expiry, a launch). Ask: "What happens if this lands two weeks later?" That tells me whether the date is truly fixed or just a wish.
2. Estimate with the team, not for them. Break the work into pieces, estimate each, and add a visible allowance for risk (unknowns I cannot size yet).
3. Express the answer as a range plus a trigger for tightening it. "Ten to fourteen weeks from kickoff, and I will narrow it to a firm date once discovery (the first phase, where we examine their requirements and real data before building) ends in week two."
4. Name what moves the range. Each driver gets an owner and a needed-by date.
5. Separate what we commit to from what we expect. A commitment is something we will do regardless (for example, "a working demo environment at week four"). An estimate is our best forecast and changes as we learn.

How I record what each side commits to

A one-page working agreement (it can sit inside the statement of work, the SOW, which is the contract document describing the deliverables, price and acceptance) with four blocks:

I send it by email after the kickoff call and ask the sponsor (the senior person on the customer side who owns the budget and can approve the work) to reply "confirmed" or mark up any line. A reply is a record both sides can point to later.

Worked example

A retailer wants its product catalogue migrated into a new platform "by the end of the quarter" and asks for a date. I reply:

"Based on what we know today, go-live is 10 to 14 weeks after kickoff. The short end holds if your team delivers the catalogue export by the end of week 1 (so that the data profiling can be done during week 2) and one person can approve mappings within two working days. Each week the export is late moves go-live by about a week. The long end allows for the data-quality issues we usually find once we see real files. I will give you a firm date by the end of week 2, after the data profiling (checking their real files for gaps, duplicates and errors) is done."

Where 10 to 14 comes from: the pieces total 10 weeks (2 discovery, 4 building the mappings and transformations, 2 trial loads and fixes, 1 customer testing, 1 cutover), and I add a visible risk allowance of 4 weeks (about 40 percent, because we have not yet seen their real files). 10 + 4 = 14, and the short end assumes the allowance is not needed. Once discovery shows the real data, the allowance shrinks or is spent, and that is what lets me firm the date.

Assumptions listed in the summary: the export is in CSV (comma-separated text files), product images are already hosted, no new sales channel is added during the project. Customer inputs: export, a named approver, a test-environment login.

Trade-offs and pitfalls

• Giving the optimistic end as "the date". Customers anchor on the first number (they fix on it as the promise and judge everything after against it). If I say "ten weeks" once, "fourteen" later feels like a slip.
• A range with no conditions sounds like hedging. A range with named drivers sounds like knowledge.
• A summary the client never confirms is a note to self, not an agreement. Chase the confirmation.
• When a firm date is genuinely forced (a regulatory deadline), I flip the negotiation: fix the date and let scope be the variable, rather than promising all scope by that date.

Direct answer

I do not absorb the new requirement silently, and I do not refuse it. I size it quickly, show the client three options with their cost in time and money, connect each to the priorities the client has already told me, recommend one, and record the decision in writing as a change request (a short, signed addition to the agreed scope; when it changes the price, the approved version is processed as a change order, a formal amendment to the contract). The date stays "original" only if something else gives way. The decision belongs to the client, and my job is to make the trade-off visible.

Steps

1. Acknowledge and clarify (same day). "That makes sense for your team. Let me make sure I understand it so I can size it properly." Ask what outcome it supports and whether it is a must-have or a nice-to-have.
2. Size it with the people who will build it, including testing and anything it touches that already exists. Give a range and state assumptions.
3. Check the client's own priorities. What did they tell us was most important at kickoff: the date, the budget, or particular features? The recommendation must follow their ranking.
4. Present options, each with time and money.
5. Recommend, then get the decision in writing before work begins.

Worked example

Mid-project on a customer portal, the client adds single sign-on (SSO, one login shared across their systems) and still expects launch on the original date. Sizing: 30 person-days to build and 6 to test, which is 36 person-days. At an illustrative blended rate of $1,000 per person-day (the average daily cost across the team's mix of junior and senior people), that is 36 x $1,000 = $36,000. With three engineers on it, the build is 30 / 3 = 10 working days (2 weeks), plus testing of 6 / 3 = 2 working days, so 12 working days in all, or 2.4 weeks. That is 12 working days, and I round it up to 2.5 weeks (12.5 working days) of slip when I quote it. That leaves only about half a working day to fix what testing finds, so if I expect testing to turn up problems I quote 3 weeks (15 working days) instead and change the table to match.

My recommendation depends on what the client said at kickoff. If they told us the date is tied to a trade show, I recommend C or B. I would say: "Since the launch is for the trade show, I suggest launching on the original date and doing SSO straight after, so nothing already planned is rushed."

Recording the choice

A short email or change request that states: the new requirement, the option chosen, the revised date and cost, what it replaces (if a swap), and who approved it. I ask for a reply of "approved" from the person who holds the budget, not only from the day-to-day contact.

Trade-offs and pitfalls

• Absorbing it to be helpful trains the client to expect free scope and puts the team's quality at risk.
• Presenting options without a recommendation pushes the thinking onto the client. Recommend and explain why.
• Costing only the build. Testing, documentation and rework of existing parts are part of the real cost.
• Taking approval from someone without authority. The person asking for the change is not always the person who can fund it.

Direct answer

For a small change in a heavily used workflow, I would tell people in the place they will notice it, shortly before it happens, in one or two sentences, and brief support first. No mass email and no long announcement: the aim is that nobody is surprised and nobody has to ask how to do what they did yesterday. Then I watch support tickets and whether people still complete the workflow, and I keep a way to roll back.

Running example (illustrative): the "Export" button moves from the toolbar into a "More" menu in a reporting screen people use daily.

The plan

What I watch after release

• Support tickets tagged to the change, compared with the normal weekly baseline.
• Task completion: share of sessions that start an export and finish one, before versus after.
• Time to complete the task, and use of the new location (clicks on "More").
• Direct feedback from CSMs and any in-app feedback.
  Illustrative trigger: if tagged tickets run at more than double the baseline for two consecutive days, or completion drops noticeably against the previous week, I improve the message or turn the change off for that group and investigate. I would set the real thresholds from the product's actual baseline.

Trade-offs and pitfalls

• Over-communicating a tiny change teaches customers to ignore your messages, and under-communicating costs support time. Matching the volume of the message to how disruptive the change is gets this right.
• Telling people only in release notes means the people who use the feature daily never see it. The message belongs where they work.
• If support hears about the change from a customer first, the plan failed: briefing them first is the cheapest step in the plan.