SA-301i · Module 3

Handling Technical Objections

3 min read

Technical objections during a proposal review are not opposition. They are the client's technical team doing their job — validating that your architecture will work in their environment, with their constraints, alongside their existing systems. The architect who treats objections as attacks gets defensive. The architect who treats objections as design review contributions builds partnership.

Do This

  • Welcome objections explicitly — "That is a good question and it reveals a constraint we should address in the design"
  • Acknowledge valid concerns and adjust the proposal — "You are right that the synchronous integration adds a single point of failure. Let me propose an async alternative with a local cache"
  • Distinguish between objections to the architecture and objections to the engagement — they require different responses

Avoid This

  • Defend the architecture against every objection — the client's team knows their system better than you do
  • Promise to "address it during implementation" — that is the eight most expensive words and the client's technical team knows it
  • Treat objections as obstacles to the sale — they are contributions to a better design