RSA Track · Module 05

Consulting Craft

Discovery, whiteboarding, objection handling, and the trusted-advisor behaviors panels actually score.

Why this module decides the offer

The RSA is a billable Professional Services consultant, not a presales demo-er. As of mid-2026, the panel presentation — a customer simulation where interviewers roleplay stakeholders and push back deliberately — is consistently reported as the hardest and most decisive round. Spark internals get you into the loop; consulting craft gets you the offer. Everything on this page is scoreable behavior: do you discover before you solution, do you handle pushback without getting defensive, and would a customer trust you with their delivery.

The engagement lifecycle — where you lead, where you support

RSAs are embedded for short-to-medium engagements: reference architectures, migrations, productionizing data and AI use cases. You share the engagement with an Engagement Manager (EM), the account's presales SA, and sometimes a Delivery SA. Know the lanes.

Phase	Goal	RSA leads	RSA supports
Pre-sales handoff	Inherit context without inheriting assumptions	Validating the technical claims made in the sale	SA owns the relationship transfer
SOW & scope	Deliverables, assumptions, exclusions in writing	Technical estimates and feasibility	EM owns commercials and terms
Kickoff	Shared definition of done, named owners	Technical agenda, architecture walkthrough plan	EM runs logistics and governance cadence
Discovery	Understand the real problem and constraints	Everything — this is your craft	—
Design	Agreed architecture and decision log	Architecture, trade-off narration, security review	EM tracks scope impact of decisions
Build	Working, tested, governed pipelines and apps	Hands-on delivery, code review, standards	Customer engineers build alongside you
Enablement	Customer can run it without you	Runbooks, pairing, workshops	EM schedules and confirms attendance
Handoff / closeout	Clean exit, measured outcomes, expansion signal	Technical handoff package, hypercare plan	EM owns closeout report and references

Discovery as a craft: a question bank by persona

Bad consultants demo; good consultants interview. Run discovery persona by persona — each stakeholder fears something different, and your architecture must answer all four. Use these verbatim if needed.

Executive sponsor — outcomes, timeline, success metrics

What business outcome does this need to produce, and by when? What happens if it slips a quarter?
How will you personally judge success at 6 and 12 months — what number changes?
Who else has to believe in this for it to survive the next budget review?
What was tried before, and why didn't it stick?
If we could only ship one use case in phase 1, which one buys you credibility internally?

Platform owner — security, cost, operations

Who approves network and identity changes, and what is their lead time? (This question alone has saved more schedules than any architecture choice.)
What are your non-negotiables: regions, private networking, encryption, data residency, audit regimes?
How do you see and allocate cost today? What thresholds trigger alarms or finance escalation?
Who carries the pager after handoff, and what monitoring stack do they already live in?
What does your change-management process require before anything touches production?

Data team lead — skills, tooling, migration fears

What is the team's strongest skill today — SQL, Python, an ETL tool — and what is the gap to where we're heading?
Which jobs are most fragile or least understood — where does tribal knowledge live?
What in the current estate must not break during migration, even for a day?
How do you do code review, CI/CD, and environment promotion today?
What worries you most about adopting Spark and Databricks? (Ask it straight; the answer shapes your enablement plan.)

Analyst — consumption pain

Walk me through how you produced the last number you put in front of leadership — every step.
Where do you wait: data freshness, access requests, or query speed?
What do you rebuild in Excel because the official model can't answer it?
Which numbers do people argue about in meetings, and why do two teams get different answers?

You have run this exact multi-persona discovery inside ADM. Delivering Finance Record-to-Report analytics end to end meant aligning finance stakeholders and IT — each with different definitions of "correct" and different fears. The executive layer (Executive Committee and CFO-level consumers of the P&L, Budget vs Actual, and Expense Forecasting KPIs) cared about trust in the number; IT cared about Unity Catalog governance and operability; the data teams cared about lineage from JDE, SAP, HFM, and DB2 sources. In the interview, tell it as discovery: you didn't get alignment by presenting — you got it by interviewing each function, writing down their conflicting definitions, and making the conflicts explicit before designing the Gold layer.

From discovery to decisions: the decision log

Discovery output is not a notebook of quotes — it is a set of architecture decisions traceable to stakeholder constraints. Keep a living decision log from day one. It de-personalizes disagreement ("we're revisiting DEC-007, not relitigating your opinion"), it is your defense when scope creeps, and it is the artifact panels love hearing about.

DEC-007 | Status: ACCEPTED | Owner: RSA (proposed), platform owner (approved)
Decision:   Hourly batch ingestion for GL actuals, not CDC streaming
Context:    Sponsor outcome = month-end close visibility (discovery,
            exec sponsor). Source exports hourly. No intraday consumer
            named by any persona.
Options:    (a) hourly batch via Workflows  (b) CDC streaming
Trade-off:  (b) adds ops burden + cost for latency nobody asked for
Revisit if: treasury intraday cash use case gets funded (parking lot)

Every decision entry should cite which discovery answer drove it. If you can't trace a decision to a stakeholder constraint, you made it for your own comfort — flag it and confirm it. This habit is also your answer to the panel question "how do you handle disagreement on architecture?": you don't argue, you log options, trade-offs, an owner, and a revisit trigger.

Whiteboarding technique

The whiteboard (or shared screen) is a conversation tool, not a presentation. The technique panels score:

Start with boxes and arrows of the planes. Control plane, compute plane, storage in the customer's cloud account, Unity Catalog across workspaces. Orient everyone before any detail.
Narrate trade-offs out loud as you draw. "I'm putting batch here instead of streaming — here's what that costs us and what it buys us." You are showing your decision process, which is what they are actually evaluating.
Invite challenge explicitly. "Where does this break for your environment?" A board nobody pushes back on is a board nobody believes.
Timebox. Five minutes for the skeleton, then drill only where the audience pulls you. If you draw for twenty minutes uninterrupted, you have lost the room.
Leave a parking lot corner. Capture out-of-scope ideas visibly so people feel heard without derailing the session.

Estimation and scoping basics

You will scope PS work with the EM. T-shirt sizing is the lingua franca: S (one source, known patterns, ~1–2 weeks), M (a few sources, one novel integration, ~4–6 weeks), L (multi-source platform build with governance and enablement, a quarter), XL (migration programs — split them, never quote them whole). Phase everything: phase 1 should produce a visible win for the executive sponsor in weeks, not a foundation nobody can see.

What blows up estimates — name these as explicit SOW assumptions:

Source access lead time. Firewall rules, service accounts, security reviews. Weeks, routinely.
Data quality unknowns. "Clean" source data never is; budget a profiling spike before committing transform estimates.
Undefined acceptance criteria. If "done" isn't written down, the project ends when the customer feels like it.
Customer availability. Their SMEs have day jobs; your plan dies waiting for the one person who understands the legacy job.
"Just one more source." The classic. Handled by change control, below.

Objection handling playbook

The pattern is always the same: empathize, reframe, evidence, next step. Never argue the objection head-on, never bash the competitor, and always end with a concrete, low-commitment action.

Objection	Empathize	Reframe	Evidence	Next step
"It's too expensive"	"Scrutiny on platform spend is exactly right."	Compare total cost — infra plus people plus opportunity cost — and cost per workload, not the sticker.	FinOps levers: autoscaling, right-sizing, serverless, Photon price-performance, tagged cost attribution.	Two-week cost baseline of current estate, then a unit-economics comparison on one real workload.
"Snowflake already does this"	"It's a strong warehouse and your team knows it."	Scope, not speed: one governed platform for SQL, streaming, ML, and GenAI on open formats — no second platform when AI use cases land.	Unity Catalog spanning tables, files, models; Delta/Iceberg openness; their own roadmap likely includes ML they'd bolt on elsewhere.	Workload-level bake-off on one of their workloads with success criteria agreed in advance.
"Security won't approve it"	"Good — security blocking surprises is doing its job."	Security is a week-1 stakeholder, not a final gate. Approval failures are sequencing failures.	Private networking patterns, customer-managed keys, SCIM, audit logs, UC row/column controls, compliance attestations.	Architecture review session with their security team against a written reference architecture.
"Our team doesn't know Spark"	"That's a real risk and it's smart to raise it now."	Day-to-day work is SQL and PySpark DataFrames, not JVM internals — and enablement is a scoped deliverable, not a hope.	Pairing model during build, Databricks Academy paths, runbooks; SQL-first surfaces like Databricks SQL.	Skills assessment, then pair-build the first production pipeline with their engineers driving.
"We tried Hadoop and it failed"	"That scar tissue is data — let's use it."	List why Hadoop failed there — cluster admin burden, no managed platform, ops overhead — and map each cause to what a managed lakehouse removes.	Managed runtime, serverless options, no HDFS operations, governance built in rather than bolted on.	Joint post-mortem of the Hadoop program; turn its failure modes into this project's acceptance criteria.

The fatal panel mistake is treating an objection as a technical argument to win. Panels score whether you stay curious under pressure. If the "CFO" says it's too expensive and your first move is defending DBU pricing, you failed — the right first move is a question: "expensive compared to what baseline?" Half the time the objection dissolves when the comparison is made explicit; the other half, you now know what evidence actually matters.

Your fit-gap and tool-selection work at ADM is objection handling in production form. When you recommend batch vs near-real-time, CDC/SCD design choices, or Power BI vs Dremio/Denodo for the semantic layer, you are doing exactly the empathize-reframe-evidence-next-step loop: acknowledging what the incumbent tool does well, reframing to the actual requirement, and backing the recommendation with evidence rather than preference. Tell one of these as a story where you recommended against the shinier option — that is trusted-advisor evidence.

Scope creep and saying no gracefully

Scope creep is never one big request — it is fifteen small reasonable ones. The defense is a formula, applied kindly and every time:

Acknowledge the value. "That's a genuinely useful addition."
State the impact. "It adds roughly two weeks and pushes the Gold milestone past month-end close."
Offer options. Trade it for something in scope, phase it to the next engagement, or park it in the decision log with a revisit trigger.
Get the decision in writing. Change control through the EM — not because you don't trust people, but because memories diverge.

Notice you never actually say the word "no." You say "yes, and here is what it costs," then let the sponsor choose. The sponsor owning the trade-off is the difference between a contractor and an advisor.

Status communication and risk surfacing

RAG status only works if it is honest. The industry disease is the watermelon project — green outside, red inside — and the cure is a rule: no surprise escalations. Any risk that could turn the project amber must appear in a status report before it appears in an escalation. Going amber early is credibility; going red suddenly is malpractice.

WEEK 6 STATUS — AMBER
Done:       Silver conformance for 3 of 5 sources; UC catalog live
At risk:    SAP extract access — security review pending 9 days
Decision needed (by Fri): approve service-principal scope, OR
            accept a 2-week slip to the Gold P&L milestone
Next week:  Gold model build starts; enablement session #2

Every amber or red must ship with a decision request and a date, never just a complaint. "We are amber because X; we need decision Y by Friday or the impact is Z." Status reports that only describe problems train executives to ignore them; status reports that demand small timely decisions train executives to unblock you.

Enablement is a deliverable, not a vibe

An engagement where the customer can't run the platform after you leave is a failed engagement that happened to ship code. Enablement gets line items in the SOW:

Runbooks — failure modes, restart procedures, escalation paths, written for the 2 a.m. on-call reader, not for you.
Docs and the decision log — handed over as living artifacts, in their repo, not in your email.
Pairing during build — their engineers drive the keyboard on the second pipeline; you navigate.
Workshops — persona-specific: platform operations for IT, PySpark patterns for engineers, SQL/dashboards for analysts.
Hypercare — a defined window with defined response expectations, then a deliberate, dated exit.

This is the part of RSA work you already do without the title. At ADM you run CI/CD, monitoring, runbooks, and hypercare through Azure DevOps as standing discipline — operability as a deliverable, not an afterthought. And your mentoring of junior engineers — design reviews, code reviews, PySpark best practices — is enablement evidence in the purest form: you make other engineers able to run what you built. The Ecolab EBX 5.9 to 6.0.11 upgrade with zero downstream disruption is the same muscle: transition managed so well the consumers never felt it. Frame all three as "I treat enablement and handoff as first-class deliverables," with specifics.

Measuring success

Close the loop with numbers the sponsor recognizes from discovery:

Adoption — active users by persona, queries and dashboard consumption trending up after handoff, customer-authored pipelines appearing in the repo.
Time-to-value — days from kickoff to the first production use case an executive actually used.
Cost-to-serve — cost per workload or per report, trending down as FinOps practices take hold; tagged attribution so finance can see it.
Self-sufficiency — escalations during hypercare trending to zero; the customer deploys a change without you.

How panels test consulting craft

Three formats recur in RSA loops as of mid-2026: a role-play scenario (often given in advance — you present, the panel plays customer stakeholders and pushes back on cost and complexity), a behavioral interview ("tell me about a difficult stakeholder"), and presentation Q&A pushback where an interviewer interrupts and challenges mid-slide. The scoring is the same in all three: discovery before solutioning, composure under pressure, business framing, honesty about trade-offs.

Role-play: "I'm the CFO. Your platform proposal looks expensive and my team says Snowflake already does this. Why should I approve it?"

Outline: (1) Do not defend — discover. "Expensive against what baseline — current infra spend, the Snowflake quote, or total cost including the team's time?" (2) Acknowledge Snowflake's strength for the warehouse workloads they run today. (3) Reframe to the CFO's own outcomes from discovery: if the roadmap includes forecasting, ML, or GenAI, a warehouse-only choice means buying a second platform later — quantify that. (4) Offer a phased, low-risk commitment: one workload, agreed success criteria, measured unit economics, decision gate before any larger spend. (5) Close on their metric: "you told me month-end close visibility is the outcome — here is the date phase 1 delivers it." Composure and questions score higher than any feature list.

"Tell me about a difficult stakeholder and how you handled it."

Outline (STAR with a relationship arc, not a complaint): Situation — ADM Finance R2R delivery required aligning finance stakeholders and IT, with conflicting definitions of correct numbers and different risk appetites. Task — get one governed Gold layer all of them would sign off on. Action — persona-by-persona discovery instead of group debates; wrote conflicting definitions down and made the conflict explicit; used a decision log so disagreements attached to options and trade-offs, not people; gave the most skeptical function early visibility instead of a final reveal. Result — CFO-level and Executive Committee consumers using the KPI frameworks (P&L, Budget vs Actual, Expense Forecasting) as the trusted source. Land the lesson: "difficult stakeholders are usually un-discovered stakeholders."

Mid-presentation interrupt: "This is over-engineered. We don't need half of this."

Outline: thank them, genuinely — pushback is engagement. Ask which half: "which components feel like overhead for your team?" Then triage out loud: components that exist because of their stated constraint ("the private networking is here because your security team requires it — happy to confirm with them"), components that are honest defaults you can defer ("we can phase the streaming path out of phase 1"), and components you will concede ("fair — that's gold-plating, I'll cut it"). Conceding one item visibly is the strongest credibility move available in a panel; refusing to concede anything reads as ego, not rigor.

In the panel presentation, do not open with your architecture slide. Candidates who jump straight to solutioning — even brilliant solutioning — score worse than candidates who spend the first minutes confirming the scenario's goals, constraints, and success metrics with the "stakeholders" in the room. The scenario is written with ambiguities on purpose; the discovery questions you ask are the test. Practice the mechanics too: screen-share, slide flow, and a whiteboard fallback, rehearsed out loud at least twice.

Self-check before moving on

Can you run a 10-minute discovery from memory across all four personas without notes?
Can you deliver the empathize-reframe-evidence-next-step loop for all five objections above, conversationally?
Do you have one scope-creep story, one honest-amber story, and one enablement story rehearsed from your own delivery record?
Can you whiteboard the lakehouse planes in five minutes while narrating trade-offs, then stop talking?

Next, put all of it to work against full scenarios in Worked Case Studies.