# When the client's CTO rejects your AI design, don't explain it again

> Pushback usually hides a constraint you have not yet heard, and the right question tends to clear it faster than another round of explanation.

Original: https://fdetimes.net/en/guides/handling-cto-pushback-on-ai-architecture/

Picture it: you are on slide four, the architecture diagram for the AI assistant has just appeared, and the client's CTO cuts in. "Why add another vector database? Nobody on my team runs one." Most engineers' reflex is to explain again, in more detail, with more numbers.

That is the moment an advisory session starts to go wrong. The person across the table does not need you to be more persuasive. They are handing you a constraint your diagram has not accounted for.

For an FDE, this meeting matters more than it looks. First Round Review's piece on hiring FDEs treats living with the customer on site as central to the role. You are there precisely to hear constraints like this one, not to defend your slides.

## Treat pushback as data, not as an attack

Google's engineering guidance on handling pushback in code review contains advice worth taping to your monitor: if the other person is right, tell them so and drop the point. It sounds simple, but it requires you to stop and ask yourself the question before you push back.

Swap "code" for "the client's systems" and the advice applies even more strongly to a CTO. They know which team is on call at night, which system has gone down before, and which regulation keeps data inside their infrastructure. You have been there a few weeks.

The same guidance warns that letting people "clean it up later" is a familiar route to a degrading codebase. The same holds at a client: once you accept a point is right, fix it in the design straight away, rather than pushing it onto a "later" list nobody reopens.

## Don't let the CTO be the first person to read the design

Before you walk into the room, someone else should read the design. A guide on Refactoring English about getting feedback on design docs argues that fixing a mistake with one reviewer beats letting ten people trip over it.

At a client, the ideal first reader is one of their engineers, someone you have worked alongside for a few weeks. They can point out things you could not know yourself, such as the platform team having just turned down a new service. Every mistake they catch is a question the CTO does not have to ask.

## One advisory session, one objection at a time

Suppose you are proposing an assistant that helps an insurance company's claims staff look up case files. The architecture has a document store, an embedding step, a vector database, an LLM called through an external API, and an eval suite that scores the answers. The following three objections are fairly typical.

**Objection one:** "Claims documents contain personal data. They can't be sent to an external API." There is nothing to argue about here. The right answer: "You're right, I hadn't accounted for that constraint. I'll revise the diagram so the model runs inside your infrastructure and send you the new version before Friday."

**Objection two:** "Adding a vector database means one more system to be on call for." Don't rush to defend it, and don't rush to drop it either. Product Talk, writing about finding common ground with engineers who dislike a feature, describes cases where an engineer is stuck on an implementation problem but voices it as if they object to the feature itself.

So ask a targeted question: "Which data stores does your team run today? If we reused one of them, what would we give up?" According to Product Talk, simply asking often lets the person objecting see for themselves what their real concern is.

Here, the objection becomes a design criterion: the operating cost to their team.

**Objection three:** "Why not just fine-tune a model on our data and be done with it?" This one is genuinely contested. Product Talk advises that when two sides disagree on direction, they should not argue about the direction itself until both are frustrated, but move to the reasoning underneath.

What to say: "This is a big decision. I'll log it as an open issue, set out the reasoning for both approaches, and we'll settle it when your team reviews it together." The test for an open issue is simple: the person who wants to fine-tune reads your account of their view and still nods.

## Behind every objection sits a different worry

| What you hear | What usually sits behind it | How to respond |
|---|---|---|
| "Data can't leave our systems" | A legal or security constraint you didn't know about | Accept it at once, fix the design, set a date for the new version |
| "My team can't run that" | Operating cost, who is on call at night | Ask about existing infrastructure, make operations a criterion |
| "Why not do it with X?" | An approach they have weighed or strongly believe in | Log an open issue, present both approaches fairly |
| "Great, let's just do it" | Enthusiasm, not necessarily readiness | Check data, people and process before you promise anything |

The last row is the easiest to miss, because it doesn't look like an objection. But a CTO who nods enthusiastically may not have the clean data or the team to run what you have just drawn.

## When the third explanation still doesn't land

The clearest example of the limits of argument does not come from a CTO. Vinoo Ganesh recounts that at Kepler, the objector was a data quality engineer: she blocked the move of data from CSV to Parquet for about a year. Explaining the technical benefits again and again did nothing to clear her objection.

The real constraint lay in how she worked. She checked data by opening CSV files directly, and for Parquet she had no reader that let her do the same. What broke the deadlock was a viewer that preserved her ability to look at the data, and within a few days the migration was running.

A year of argument achieved less than a few days of fixing the right thing. The job titles differ, but the mechanism is worth taking into the meeting with a CTO: an objection that keeps coming back is usually protecting a habit or a risk your slides never touched.

A LeadDev piece on building consensus with people who object advises finding the deeper worry and addressing it at that level, rather than getting stuck in an endless argument. The question worth asking is "What would make you comfortable?", not how to phrase your case better.

**Key point:** Repeating technical arguments rarely clears an objection; understanding what the other person is protecting can.

## The mistakes that wreck an advisory session

The most common mistake is treating the presentation as a sales pitch, pressing on through the slides after the CTO has raised a constraint that brings down half the architecture.

The second is settling every dispute at the table, which leaves those who were absent feeling sidelined and objecting later. The third is promising changes without a date for the new version, so "you're right" sounds like mere politeness.

For your career, this skill is easier to demonstrate than you might think. If an FDE job posting mentions acting as a technical adviser to client leadership, that is a signal to have a story ready about a time a client pushed back on your design.

The story should have three parts: what you proposed, what they pointed out that you had missed, and how the final design was better.

## An exercise for your next CTO meeting

Before the meeting, copy the four-row table above onto a sheet of paper. For each row, write the objection you expect the CTO to raise about your own architecture, and how you plan to respond: accept and set a date, ask a follow-up, or log an open issue.

After the meeting, mark the ones you predicted correctly and the ones that surprised you. Next time, take those surprises to your first reader.

The person a CTO invites back is not the one who wins every argument, but the one who leaves the room with a different design because they listened.

**Try this week:**

- Take the most recent design you wrote, send it to exactly one colleague to read first, and ask them to play the toughest CTO they can.
- Pick a debate that has stalled in a document's comments, move it into its own open issue, and write each view as a paragraph its holder would still find fair.
- Rewrite one CV line about a time you changed a design after client pushback: what you proposed, what they objected to, and how it turned out.

## Sources

- [How Forward Deployed Engineering is done at Kepler (Vinoo Ganesh, AI Engineer World's Fair 2026)](https://ai.engineer/talks/1OMHGsUZiqA-forward-deployed-engineering-is-done-kepler)

- [How to build consensus when dealing with detractors](https://leaddev.com/communication/how-to-build-consensus-when-dealing-with-detractors)

- [How To Find Common Ground When Engineers Don't Like Features](https://www.producttalk.org/how-to-find-common-ground-when-engineers-dont-like-features/)

- [Handling pushback in code reviews](https://google.github.io/eng-practices/review/reviewer/pushback.html)

- [How to Get Meaningful Feedback on Your Design Document](https://refactoringenglish.com/blog/useful-feedback-on-design-docs/)

- [So You Want to Hire a Forward Deployed Engineer](https://review.firstround.com/so-you-want-to-hire-a-forward-deployed-engineer/)