Saying “no” to a bad design without losing the client

Picture week three of a pilot. The client’s head of operations pulls you into a meeting room: “Let the agent write straight into the ERP. Drop the approval step. I’m demoing to the director next week.” You know it is the wrong call, and you also know the person across the table decides whether the project gets extended.

Many engineers’ first instinct is to nod and keep the peace. Their second is to win the technical argument at any cost. Both go wrong, just in different ways.

FDE Academy treats the ability to push back politely, or to negotiate so that each side gives a little, as a small skill that makes a large difference for an FDE.

The reason is practical. In their view, the habit of saying “yes” to every request leads straight to scope creep and delays the original commitment. Clients accept a refusal that comes with a reason. A missed deadline is much harder for them to let go.

Saying “no” is part of the job you were hired for

Atomic Object, a software consultancy, writes that its job is to lead clients down a more feasible, more productive path, not to go along with every idea they have.

The firm sees saying no as a way of protecting the client’s budget. It also commits to always speaking plainly when a technical constraint makes the original request impossible.

Speaking plainly is not the same as being curt, though. Kantata, which makes software for professional services firms, points out that nobody wants to hear “no” and then be left with the problem untouched. A bare “no” leaves too much room for the client to fill in the gaps, and people tend to fill them in badly: “this guy is lazy”, or “this team can’t do it”.

So a good “no” always has three parts: a clearly stated constraint, an explanation, and another path for the client to choose. The hardest part comes before all three. You have to know what the client actually needs.

The client says “drop the approval step”. What do they need?

According to an analysis by techinterview.org, FDE interview loops test exactly this ability: finding what the client actually needs, as distinct from what they ask for.

In the example above, “drop the approval step” is a solution the client came up with. The real need might be “the director has to see that the agent saves time”, or “the operations team is complaining about clicking approve too often”.

Those two needs lead to two different designs, and neither requires the agent to write straight into a live system with nobody checking. Once you have found the real need, you no longer have to choose between complying and refusing. You simply propose another way to reach the same goal.

The six-step script, line by line

Step 1: buy time. FDE Academy describes how experienced FDEs handle an unexpected request: they ask to confirm the details and respond later, rather than promising on the spot. In the meeting, that might sound like: “Let me check the ERP side. I’ll send you options by 4pm today.” With a specific time attached, the client will not read it as evasion.

Step 2: ask about outcomes, not features. Don’t ask “are you sure you want to drop approval?”, which sounds like an argument. Ask instead: “For next week’s demo, what does the director need to see for you to call it a success?” Suppose the answer is “an order going from email into the system in a few seconds, with nobody typing anything”.

Step 3: state the constraint plainly. “If the agent writes straight into the ERP, one bad extraction becomes one bad order in the live system, and the clean-up lands on your team.” This sentence is about the client’s risk, not about your reluctance to do the work. Atomic Object suggests a similar approach: don’t dismiss the client’s idea, but discuss together why it might not be what users want and look for a way around it.

Step 4: offer options. According to Kantata, offering options gives both sides common ground, and the client feels they still get to choose. A short table attached to that afternoon’s email might look like this (an illustrative example):

Option	What the client gets	The cost
A. Write straight to the ERP, no approval	The fastest demo	Bad data reaches the live system and is hard to pull back
B. Agent writes to a queue, approved with one click	The demo still shows the speed	One small extra action for the approver
C. Full automation for order types the agent handles reliably, the rest go through approval	Some real automation	Extra time needed to measure accuracy; the schedule slips

You keep option A in the table. Placed next to its cost, it is usually the one the client rules out, and they see that as their own decision.

Step 5: agree with conditions. If the client picks C, the response FDE Academy suggests is: “Yes, and here is how it affects the current timeline.” Say clearly which items have to move back. Don’t quietly work extra evenings to hold the old schedule.

Step 6: write it down. Kantata recommends putting deferred requests into a RAID log (Risks, Actions, Issues, Decisions) so they can be looked up later. A line such as “Automatic ERP writes without approval: deferred, revisit once accuracy for order type X has been measured” turns “no” into “not now”. The client knows their request has not been forgotten.

Ways of saying “no” that damage the relationship

The most common mistake is promising in the meeting because silence feels like looking incompetent. “Let me confirm and get back to you” always costs less than a promise you later have to withdraw.

The second mistake is a bare refusal: “That can’t be done.” The client loses their options and you lose credibility. The opposite mistake is just as damaging: talking around the constraint to avoid friction, so the client assumes it is still possible and the plan carries on.

The third mistake is treating each refusal as a matter for one project alone. PostHog’s FDE handbook describes how patterns that repeat across deployments are turned into reusable tools, shared skills and product improvements.

If a third client in a row asks to drop the approval step, the approval step itself may be too cumbersome, and the product team needs to know.

How to show this skill to employers

For developers looking to move into FDE work, this skill is hard to prove with a line about “good communication” on a CV. Prepare a real story instead: what the original request was, the real need you uncovered, the options you put forward and how it turned out.

On a CV, a line such as “proposed an alternative to request X, keeping the original delivery date” carries far more weight than generic adjectives about soft skills.

In interviews, don’t tell the story of how you won against the client. Tell the moment you understood what the client really needed, because that is exactly what FDE interviews are trying to test.

Exercise: rewrite this exchange

Here is a hypothetical exchange. Client: “We want the chatbot to answer customers without citing source documents. It looks cleaner.” FDE: “Sure, I’ll do it this week.”

Rewrite the FDE’s response using the six steps above: a line buying time with a specific deadline, a question about the outcome the client wants to see, a line spelling out the risk the client will carry, a table of three options with their costs, a conditional agreement and a RAID log entry.

If your rewrite contains no “no” at all and the client still understands why the original approach has been deferred, you have got it right.

Atomic Object says a consultant’s job is to lead clients to a more feasible path. An FDE who says yes to every request has given up exactly that part of the job.