The short answer
You manage the warehouse architecture and the analytical transformation layer. You absolutely do not control or take responsibility for upstream engineering negligence. When an Engineering Manager aggressively attacks you in public or in a direct message over a suddenly spiked Snowflake bill, they are making a highly calculated political move. They are attempting to actively isolate the blame on the data team before leadership asks questions. You must redirect the accountability immediately and forcefully. State clearly and with technical precision that the massive compute spike originated entirely from an unindexed, undocumented upstream schema dump. Inform them that your highly optimized transformation pipeline was forced to process a fundamentally broken, unoptimized load. Shift the conversation directly and permanently to compute cost optimization by demanding formal data contracts before engineering is allowed to push massive architectural changes to production. Do not accept a single ounce of blame for their deployment chaos. You are the victim of their bad code, not the perpetrator of financial waste.
Why this question is a trap
The Engineering Manager is intentionally using a highly visible financial metric to establish political dominance. A spiked Snowflake bill attracts immediate, furious executive attention from the CFO and the CTO. They know this. They want to frame the data team as careless with company capital to deliberately deflect attention away from their own team's abysmal release quality. This is a classic misdirection play.
If you accept the blame, you instantly invite a permanent, agonizing audit of your entire codebase. Leadership will begin to view analytics as an expensive, runaway overhead department rather than a highly strategic asset. Furthermore, the engineering team will continue pushing broken, unannounced schemas, knowing fully well that you will silently absorb the compute cost and work through the weekend to fix their mess. They will use your warehouse budget to subsidize their lack of quality assurance. You must fiercely reject this framing. The financial cost is merely a downstream symptom. The upstream engineering release is the actual, highly toxic disease. You must force the Engineering Manager to look in the mirror and acknowledge their direct, undeniable role in the resulting expense.
What most people say
Most Analytics Engineers respond exactly like junior developers who have been caught making a terrible mistake. They feel a sudden wave of imposter syndrome. They immediately adopt a highly defensive, apologetic posture and start rambling incoherently about SQL optimization and incremental materialization.
They say they will look into the DAG right away to figure out what broke. They apologize profusely for the unexpected cost to the department. They desperately promise to rewrite the dbt models to run faster next time. This reaction is a complete and total surrender. By promising to fix your code, you explicitly validate their false accusation that your code was the fundamental problem. The Engineering Manager successfully makes the data team the permanent scapegoat for the entire incident. You end up working frantically through the entire weekend to optimize a query that only spiked because engineering carelessly dropped a massive, unannounced table structure change into the production environment. You take the blame while they take the weekend off.
What to say instead
Stop defending your SQL. Attack the data pipeline source. Look directly at the Engineering Manager with absolute clinical detachment.
State factually and firmly that the six-hour pipeline run was directly triggered by an unindexed, complete schema dump pushed by their specific team at midnight. Inform them that your data models are meticulously built for incremental loads, not full-table rebuilds triggered by undocumented, chaotic upstream changes. Tell them that to ensure future compute cost optimization across the organization, the engineering department must establish and strictly adhere to rigid data contracts. Inform them that until upstream releases are properly indexed, thoroughly documented, and formally communicated to the data team, the massive warehouse bill will continue to accurately reflect their incredibly poor deployment choices. Put the financial burden directly back on their roadmap.
The phrase to anchor on
The absolute critical phrase you must memorize is compute cost optimization.
This specific terminology proves immediately that you care about the financial impact just as much as they do, if not more. It aggressively shifts you from a defensive, reactive coder to a highly strategic operational leader. You are absolutely not arguing about subjective code quality. You are detailing the hard, structural requirements for compute cost optimization across the entire engineering organization. It violently forces the manager to engage with the actual financial consequences of their own team's careless actions. They cannot argue against optimization.
How to deliver it
Deliver the hard facts with cold, diagnostic precision. Do not raise your voice in anger. Do not let your voice shake with frustration.
When they loudly accuse you of wasting company money, hold their eye contact without flinching. Let a brief, heavy second of silence pass to visually show that their aggressive tone has absolutely no emotional effect on you. State the root cause of the spike in a flat, unyielding register. Do not use weak filler words. Do not say "I think" or "it looks like." You have the server logs. You have the timestamps. You know exactly what happened. Present the requirement for data contracts as a mandatory operational change ordered by reality, not a polite request for a favor. Your tone must communicate that their team is officially a liability until they fix their release process.
Mistakes that cost you the room
The most fatal mistake is foolishly offering to manually monitor the pipeline every night going forward to catch the spikes. Do not volunteer for unpaid night shifts to babysit broken engineering releases. You are an engineer, not a night watchman.
Another critical error is desperately attempting to explain the highly technical nuances of Snowflake clustering or query plans to the manager. They absolutely do not care about your technical constraints. They only care about shifting the bill and the blame. If you dive into technical minutiae, you sound like you are making elaborate excuses to cover up bad work. Keep the conversation ruthlessly focused purely on the direct causal relationship between their upstream changes and the resulting massive financial compute penalty. Do not let them change the subject to SQL syntax.
Practice plan
This drill requires practicing highly authoritative technical pushback against a superior title. Record yourself delivering the response on camera.
Check your posture meticulously. Ensure you are not physically shrinking back or slouching when you state the cause of the spike. Rehearse stating the anchor phrase until it flows as naturally as a core business requirement. Drill the smooth transition from diagnosing the upstream failure to firmly demanding the data contract. You must sound exactly like a senior peer enforcing a non-negotiable architectural standard. Please note this comprehensive guide serves strictly as a rehearsal exercise for communication dynamics. Talk Rightly does not offer formal HR, legal, or employment counsel.