Talk track: This is the most technical block in the course, but it's technical in the way a manager needs to be technical. You don't need to configure a Snowflake instance. You need to know what questions to ask, what trade-offs exist, and how to work with IT, Legal, and Engineering to make infrastructure decisions that your team can live with for the next two years.
⏱ Expected: 13:30 (min 0/100)
Talk track: Before we dive in, let's acknowledge the shift. This morning was heavy. You practiced giving uncomfortable feedback, you debated performance ratings with real stakes, and some of those conversations hit close to home. Take 90 seconds. Write down one thing from this morning that you want to carry forward. Then set it aside. We're shifting gears to something concrete and practical — infrastructure, tools, and the teams you depend on to get work done.
Talk track: These are not reversible decisions. When you pick a data warehouse, you're committing your team's workflows, your SQL dialect, and your cost structure for two to three years. Here's a scenario I've seen: a team of brilliant analysts, all with PhDs, completely blocked because their data pipeline broke over a weekend and nobody knew how to fix it. Three days of zero output. Your job is not to fix the pipeline — it's to make sure the right decisions were made so that doesn't happen.
Talk track: Here's a number that surprises most new analytics managers: you will spend thirty to forty percent of your time on cross-functional work. Not analyzing data. Not building dashboards. Managing relationships with other teams. You depend on Engineering to instrument events. You depend on IT to provision access. You depend on Legal to clear your data usage. And here's the thing — if any one of these relationships is broken, your team stalls. Not "slows down." Stalls. Let me show you what that looks like.
⏱ Expected: 13:36 (min 6/100) | XFN Failure Modes
Talk track: Let me make this concrete with real failure stories. Story one: Engineering ships a database migration over the weekend. They rename three columns. Your pipeline fails at 2 AM. Your morning dashboards are blank. The CEO pulls them up at 8 AM and asks what's going on — and you find out from the CEO, not from Engineering. Story two: you spend three months evaluating and implementing a new analytics tool. Then Legal tells you the data processing agreement doesn't meet GDPR. Three months of work, unwound. Story three: Finance doesn't renew your BI tool license because nobody flagged the budget cycle deadline. Dashboards go dark. Every one of these is preventable with a written SLA and a regular check-in.
Talk track: Notice the pattern — every relationship is bidirectional. You owe them things and they owe you things. Most new managers only think about what they need: "Engineering should tell me about schema changes." But Engineering needs things from you too — data contracts, documentation, SLAs for query load on their systems. If you only make demands without offering commitments, the relationship dies. The managers who do this well think in trades, not requests.
⏱ Expected: 13:42 (min 12/100) | SLA Template
Talk track: Here's a practical template. Four lines — that's it. What you'll provide and by when. What they'll provide and by when. Who to escalate to when someone misses — and you need a real name here, not "management." And how often you review the agreement. Start with your most critical relationship — usually Engineering — and get one SLA working well before expanding to others. The key: both sides need to see value. If the SLA only benefits you, the other team will ignore it within a month.
⏱ Expected: 13:42 (min 12/100) | SLA Example
Talk track: Here's a concrete example for the Engineering relationship. You commit to reviewing schema change impacts within three business days — that's fast, and Engineering values fast turnaround. They commit to notifying you two sprints before any schema change — that's the advance notice you need to update your pipelines before anything breaks. Both sides get something. And when someone misses the SLA? You don't send a passive-aggressive Slack message. You escalate to the names on the document. Draft one of these for each key partner. It takes thirty minutes and saves hundreds of hours of fire-fighting.
Talk track: Let me walk you through this with a concrete example. Your app generates a click event when a user signs up. That event flows through ingestion — something like Fivetran pulls it into your warehouse. Storage is where it lands — BigQuery, Snowflake. Transform is where dbt cleans it up and joins it with other tables. The semantic layer is where you define what "active user" means so the whole company uses the same number. And visualization is the Looker dashboard your VP checks every Monday. At every layer, you're asking: is it working, what happens when it breaks, and what does it cost? This flow is the mental model for the rest of this block.
Talk track: Each layer does one thing. Even if you've built models in Python and run complex SQL, infrastructure architecture is a different vocabulary. This table translates it. The key questions in the right column are what you ask as a manager — you don't need to know how ingestion works, you need to know how fresh the data is.
Talk track: Build versus buy is one of the most consequential decisions you'll make. The rule of thumb: default to buy for infrastructure, default to build for business logic. Infrastructure is commodity. Business logic is where your team adds unique value. And when you decide to buy — involve IT from day one, not after you've already started a trial. Procurement takes two to six times longer than you expect. If you need a tool by Q3, start the process in Q1. One more thing: AI tools are a new line item in your stack. API costs for LLMs, AI coding assistants, model serving — these are real infrastructure decisions now, and the same build-vs-buy framework applies.
⏱ Expected: 13:54 (min 24/100) | Hidden Costs
Talk track: This is the slide I wish someone had shown me earlier in my career. Open source is not free. Add it up: thirty to fifty thousand dollars a year in engineer salary to run a "free" tool. Versus four to fourteen thousand for a managed service. And here's the real kicker — it's not just the money. It's what your team doesn't build while they're maintaining Airflow. Every hour your data engineer spends debugging a scheduler crash is an hour they're not building the pipeline your PM is waiting for. That opportunity cost is the hidden killer.
Talk track: Before we move on, let's apply what we just covered. Turn to the person next to you. Think about your case context — name one tool or capability your team needs. Would you build it or buy it? Use the four questions. You have two minutes. Go.
Talk track: Before I show you specific tool choices, here's the story that every data stack lives through. You start scrappy — a warehouse, a BI tool, a spreadsheet for governance. That's fine. Then you get burned: a dashboard shows wrong numbers, the CEO asks questions, and you realize you need observability. So you add it. Then you get audited, or a regulator asks about PII, and you realize you need governance. So you add it. Nobody builds the right architecture on day one. You evolve toward it. Let me show you what each stage looks like.
⏱ Expected: 14:07 (min 37/100) | Stack by Size — Small
Talk track: Now let's see what these decisions look like in practice. Keep your build-vs-buy lens on. If you're in the small startup case context, this is your stack. Notice: almost everything here is "buy." Total cost: under two thousand a month. And here's the discipline part — skip everything not on this list. No data catalog for fifty tables. No ML platform when you don't have models in production. Add complexity when you feel real pain, not anticipated pain.
⏱ Expected: 14:07 (min 37/100) | Stack by Size — Medium
Talk track: At medium scale, the critical addition is observability. Without it, here's what happens: your dashboard shows stale data for six hours. Nobody on your team notices. The CEO pulls it up in a meeting and says "why does this say yesterday's numbers?" You find out from the CEO. With observability — Monte Carlo, Elementary — you get an alert at 6 AM saying "data freshness SLA violated." You fix it before anyone notices. That single tool changes your relationship with the rest of the company. Monthly cost jumps to ten to thirty thousand, but one prevented incident pays for it.
⏱ Expected: 14:07 (min 37/100) | Stack by Size — Large
Talk track: At enterprise scale, the challenges are fundamentally different. You're not trying to get trusted numbers — you're trying to maintain trust across dozens of teams, petabytes of data, and strict regulatory requirements. Data mesh means each business domain owns its data products — the central team sets standards but doesn't own every pipeline. You need model governance because regulators will ask. And you need cost management because at a hundred thousand a month, someone in finance is going to want accountability. For those of you in the large enterprise case context: your challenge in the activity isn't "what tools do I pick?" It's "what can I actually get approved in six months given procurement, legal, and budget cycles?"
⏱ Expected: 14:04 (min 34/100) | The Migration Trap
Talk track: Let me talk about what happens when you outgrow your stack. Story three is the scariest: a brilliant engineer builds a custom ingestion pipeline. Beautiful code. Handles edge cases nobody else thought of. Then that engineer leaves. Now nobody understands how it works, it breaks every few weeks, and nobody can fix it properly. You're stuck maintaining a system you can't modify and can't replace without a six-month migration project. The lesson: when you choose a tool today, ask yourself how hard it will be to leave it in three years. Use standard SQL. Use standard file formats. Make migration a design criterion, not an afterthought.
⏱ Expected: 14:13 (min 43/100) | What You Inherit (3 min)
Talk track: One more thing before the activity. You will almost never build a stack from scratch. You'll inherit one — and it will be messy. Before you propose any changes, spend your first month auditing what exists. What tools are we paying for? Who owns each pipeline? What breaks most? What's undocumented? The undocumented pipelines are the ones that break at 2 AM with no runbook. Spend thirty days understanding before you spend thirty minutes proposing. This connects directly to the First 90 Days framework you'll see in Block F.
Talk track: Since you're studying in Vienna, this isn't optional knowledge — it's your legal reality. GDPR gives you three concepts to internalize. Lawful basis: you need a legal reason to process personal data. Data minimization: collect only what you need for a specific purpose. Right to erasure: if a user asks to be deleted, your pipeline needs to handle it. And classify your data — know what's public, what's internal, what's confidential, and what's restricted. Every table in your warehouse should have a retention policy. "Keep forever" is not a policy — it's a liability.
⏱ Expected: 14:19 (min 49/100) | Activity: Data Infra Decision Brief (20 min)
Talk track: Time for hands-on work. This is focused and fast — three items, twenty minutes.
⏱ Expected: 14:19 (min 49/100) | Activity
Talk track: Three items, twenty minutes. First: current state — what exists and what's the biggest pain point. Five minutes. Second: how does AI change your case context? Pick the lens that feels most urgent — infrastructure, people, or governance. No wrong answer — the choice itself tells you something about your priorities. Eight minutes. Third: write a one-paragraph proposal to your VP. Lead with what you need. That's BLUF — you practiced it in Day 1. Seven minutes. Go.
⏱ Expected: 14:19 (min 49/100) | Activity Example
Talk track: Here's what a good one looks like. Notice the current state is one sentence — not an architecture diagram. The AI impact picks a specific lens and names a specific incident. And the VP proposal leads with what's needed, quantifies the cost, and names the consequence of no. That's BLUF. Aim for this level of specificity.
Talk track: Let's hear some proposals. Who wants to go first? Read your VP paragraph — sixty seconds. Class: is the BLUF clear? Would you fund it? After two or three, let's talk AI lenses. Who picked infrastructure? Governance? What made you choose? Notice how case context drove that decision. That's the real lesson — and it's exactly the skill Block F formalizes.
⏱ Expected: 14:54 (min 84/100) | Transition
Talk track: That wraps Block E. After the break, Block F is about communicating upward — executive communication, handling failure, and your first 90 days as a manager. We'll also cover the async QBR — your capstone deliverable. See you at 3:30.
⏱ Expected: 14:54 (min 84/100) | Transition
Talk track: We're taking a break. When you come back, Block F is about leadership communication — the Pyramid Principle, communicating failure, your first 90 days, and we'll brief you on the async QBR that's your capstone deliverable. During the break, think about the hardest thing you'd have to tell an executive in your case context. See you at 3:30.