#The Objection-Handling Playbook
In a field loop, the panel will push back. In an enterprise loop, the stakeholder interviews are objections wearing polite clothing. Either way, how you handle disagreement is scored more heavily than whether you were right.
#The method
FEEL → FELT → FOUND → FACT, and the FACT is mandatory.
"I understand the concern (feel) — it comes up on most engagements (felt) — what we generally find is X (found) — and specifically, here's the mechanism and the number (fact)."
Three rules that matter more than the script:
- Concede what is true, first and specifically. An objection you refuse to grant any ground to becomes an argument. An objection you partly grant becomes a conversation.
- Answer the concern behind the objection, not the words. "It's too expensive" usually means "I can't predict or defend this cost." Those need different answers.
- Never win the point and lose the room. You can be right in a way that costs you the job.
#Commercial objections
1. "Databricks is too expensive."
"Compared to what, and measured how? Most cost problems I see aren't the rate — they're scheduled work running on interactive compute, clusters that never auto-terminate, and full refreshes that should be incremental. I'd start by attributing the spend from the system tables, because the conversation changes completely once every pound is tagged to a use case. And if after that the platform genuinely isn't worth what it costs for your workload, I'd rather tell you that in month one."
2. "The costs are unpredictable — we can't budget for it."
"That's the more legitimate version of the cost objection, and it's fixable. Cluster policies cap what can be provisioned, budget policies cap serverless spend, and tags let you attribute to cost centres. You're trading a fixed licence for a variable bill, which is genuinely harder to budget — but it's also the first time you can see which use case costs what."
3. "We already bought Snowflake / Fabric."
"Then the question isn't which is better, it's which workloads belong where and how we avoid paying to store everything twice. Plenty of enterprises run both well. What I'd want to avoid is duplicating the data and fragmenting governance — federation and sharing are usually better than another copy."
4. "Open source Spark on Kubernetes is a fraction of the cost."
"For the licence line, yes — and a strong team can absolutely build it. What the comparison usually leaves out is the fully-loaded engineering cost: who's on call, who does the upgrades, who builds the governance layer. I'd model both over three years including two or three platform engineers. If building still wins, build it — I've seen organisations where it does."
5. "We're locked in."
"Your data's in Delta or Iceberg in your own cloud storage, in open formats other engines read. That's genuinely less lock-in than a proprietary warehouse. The real stickiness is the governance layer and the skills — and that's true of any platform you'd pick, including one you build."
#Technical objections
6. "Spark is overkill for our data volumes."
"Quite possibly, and I'd rather say so than sell you a platform you resent. If it's a few hundred gigabytes with simple BI and no AI roadmap, something simpler is a better fit. Where it changes is when the workload isn't just SQL — streaming, ML, unstructured data. What does the next two years look like?"
7. "Notebooks aren't production engineering."
"Agreed, if notebooks are the deployment mechanism. They shouldn't be. Production means code in Git, tested, deployed as asset bundles by a service principal, with notebooks as a development and exploration surface. If your team is running production from a notebook someone clicks, that's a practice problem and I'd fix it."
8. "We tried Databricks and the costs exploded."
"I believe you, and I'd like to see the usage data, because that story usually has a specific cause — interactive clusters left running, everything on all-purpose compute, no auto-termination, no tags so nobody knew who owned what. The platform doesn't govern itself; you have to configure the guard-rails. What did the spend break down to?"
9. "Performance was worse than our warehouse."
"That's a real result and worth diagnosing rather than dismissing. Usually it's layout — no clustering on the actual filter columns, so every query reads far more than it needs — or queries hitting raw tables instead of a modelled layer. Can we look at a query profile? Files pruned versus files scanned tells us in about a minute."
10. "Our data isn't big enough for a lakehouse."
"Size isn't really the argument any more — the argument is variety and destination. If it's all structured and all going to BI, a warehouse is fine. If you have documents, events and models in the mix and an AI roadmap, one governed platform beats four."
11. "Streaming is too complex; we'll just batch."
"Often the right call, and I'd ask what decision the data drives before pushing streaming. But the incremental-batch trigger gives you streaming's bookkeeping — exactly-once, checkpointed, only processes new data — while running every fifteen minutes. You get most of the benefit without an always-on job."
12. "We don't want vendor-managed compute outside our network."
"Understood, and that's the serverless question specifically. Your data still lives in your storage account. The controls move rather than disappear — network connectivity configurations for private access, serverless egress control to restrict outbound destinations, private connectivity to storage. If that still doesn't meet your policy, classic compute in your own VPC remains available and it's a legitimate choice."
13. "Delta is proprietary."
"Delta Lake is open source under the Linux Foundation, and with UniForm the same Parquet files can be read as Iceberg. Iceberg v3 is GA on the platform now, and the two formats have converged on the same capabilities. The decision that's actually hard to reverse is the catalog, not the format."
14. "Unity Catalog migration will take forever."
"The metadata part is fast. The part that takes time is remediating older jobs for supported compute access modes — that's where the real effort sits, and it's better to find it in assessment than in month four. I'd scope that explicitly rather than promise a date I can't hold."
15. "We'll lose our dbt investment."
"You won't — dbt runs on Databricks compute and plenty of teams keep it. I wouldn't migrate off something that's working and that your team likes. The case for moving is specific: streaming, complex CDC, or the operational burden of running the orchestration yourself."
#Organisational objections
16. "Our team doesn't have these skills."
"That's usually the real constraint, more than the technology. I'd plan enablement as a workstream with a budget, not as a week of training after go-live — paired delivery on the first two use cases, a paved road so the common path doesn't require expertise, and certification targets. If we don't do that, we'll build something good that nobody can run."
17. "The last platform programme failed."
"Then I'd want to know why before proposing anything, because the same cause usually repeats. In my experience it's rarely the technology — it's scope that grew, foundations that took two years with nothing visible, or nobody empowered to decide. Which of those was it?"
18. "IT says no to cloud."
"What's the specific objection — data residency, a control they can't evidence, or a previous incident? Each has a different answer, and a blanket 'no to cloud' usually resolves into two or three concrete controls once you get into it. I'd want the security team in the room early, as designers rather than approvers."
19. "The business doesn't trust the data."
"Then that's the first problem to solve, and it isn't a platform problem — it's lineage, ownership, quality expectations and consistent metric definitions. Governed metrics in the catalog are a real fix for 'every dashboard says something different'. I'd pick one contested number and make it unambiguous end to end; trust rebuilds from a specific win, not from a programme."
20. "We need it in six weeks."
"Let me tell you what's genuinely deliverable in six weeks and what isn't, and then you choose. Foundation plus one end-to-end use case is realistic. The whole estate isn't, and I'd rather say that now than at week five."
#The hard ones
21. "Why should we use you rather than your competitor's architect?" Answer with evidence, not adjectives: a specific pattern you've seen repeatedly across engagements, a specific failure you've prevented, a specific number.
22. "You've never worked in our industry."
"That's true. What I'd bring is pattern recognition from adjacent industries with the same structural problem — regulated data, legacy warehouse, an AI mandate — and I'd be explicit that the domain knowledge comes from your people. The mistake would be me pretending to know your business; the first month is mostly listening."
23. "Your proposal is just the vendor's standard architecture."
"Some of it should be — the well-trodden path is well-trodden for a reason and I'm not going to invent novelty for its own sake. Where I've deviated is here, here and here, and those are the parts specific to your constraints. Let me walk through why."
24. [Interviewer states something technically wrong.] Do not let it pass, and do not humiliate them.
"That matches what I'd have said until fairly recently — I think it changed with [X]. My understanding now is [Y]. Worth checking, because it affects the recommendation."
25. [You realise mid-answer you are wrong.]
"Actually, let me correct myself — I had that backwards. It's X, not Y." Fast, clean, no spiralling. This gains points against truth-seeking. Candidates who defend a wrong answer for three minutes lose far more than the point.
#Drill protocol
Have someone fire fifteen of these at random, with no warning and no preamble. Sixty seconds per answer, hard stop. Record it.
Score each: Did you concede something true? Did you answer the concern or the words? Did you give a concrete fact or mechanism? Did you stay under a minute? Did you sound like an advisor or a salesperson?
The gap between rehearsed and unrehearsed on these is larger than on any other material here.