diff --git a/_courses/engineers-mba/01-foundations-business-os/01-why-businesses-exist.md b/_courses/engineers-mba/01-foundations-business-os/01-why-businesses-exist.md
new file mode 100644
index 0000000..ddb5d24
--- /dev/null
+++ b/_courses/engineers-mba/01-foundations-business-os/01-why-businesses-exist.md
@@ -0,0 +1,105 @@
+---
+chapter_id: 1
+chapter_slug: why-businesses-exist
+chapter_title: "Why businesses exist (and why engineers should care)"
+chapter_summary: "Distinguishes value creation from value capture and uses Coase's transaction-cost theory to explain why firms exist. Locates engineering work in the value chain and establishes the translation problem from technical output to business outcomes."
+---
+
+{% raw %}
+## What you'll learn
+- The difference between *value creation* and *value capture*, and why a great product can still be a bad business.
+- Why firms exist at all instead of every engineer being a freelance contractor - Coase's transaction-cost argument.
+- Where engineering work sits in the [value chain](https://hbr.org/1985/07/from-competitive-advantage-to-corporate-strategy) and why that position determines what your work is worth.
+- Why "we built the best product" is not a strategy and what the actual strategic levers are.
+
+## Concepts
+
+A business is a machine for creating value and capturing some fraction of it. Those are two different things, and conflating them is the most common engineering-side mistake when reading a strategy doc.
+
+**Value creation** is the gap between what a customer would pay (their *willingness to pay*) and the *opportunity cost* of the inputs - the engineer's next-best job, the AWS bill for the next-best workload, the office rent for the next-best tenant. A firm that creates a lot of value is doing something useful. A firm that creates a little is, at best, redistributing.
+
+**Value capture** is the slice of that gap the firm actually keeps as price minus cost. Anyone who has watched a brilliant engineering team get crushed by a worse competitor with better distribution has seen the mismatch in person. Linux created an extraordinary amount of value; Red Hat captured a sliver of it; AWS captured more than Red Hat did, by operating it. None of those parties built more of Linux than the others.
+
+The two-by-two below is worth tattooing on every engineer's forearm before their first strategy review.
+
+| | Low value capture | High value capture |
+|---|---|---|
+| **Low value creation** | Dead, but quietly | Rent-seeking - usually unstable |
+| **High value creation** | The "great product, bad business" trap | The compounding businesses |
+
+Engineering work disproportionately produces the top row. Strategy work - pricing, distribution, moats - is largely about pulling firms to the right.
+
+### Why firms exist at all
+
+[Ronald Coase asked the right question in 1937](https://onlinelibrary.wiley.com/doi/10.1111/j.1468-0335.1937.tb00002.x): if markets are so good at allocating resources, why does any work happen inside a firm? Why isn't every engineer a contractor selling pull requests by the hour?
+
+His answer was *transaction costs*. Every market transaction has hidden costs: finding the counterparty, negotiating, drafting contracts, monitoring quality, enforcing payment. When those costs exceed the cost of doing the same work in-house under managerial direction, the work moves inside the firm. When the costs flip, the work moves back out.
+
+You see Coase quietly running every "build vs. buy" decision an engineering org makes. SaaS vendors exist because integrating a payroll system in-house has high coordination cost. AWS exists because managing your own racks has high transaction cost with hardware vendors, real estate, and electricians. The cloud is a giant statement about transaction costs falling.
+
+Engineers experience the limits of Coase from the inside. Why does your manager exist? Because the cost of coordinating five engineers via market contracts would be higher than the cost of one manager with hire-and-fire authority. Why does the org chart exist? Same reason, recursively.
+
+### The value chain
+
+Michael Porter's *value chain* decomposes a firm into the discrete activities that create value: inbound logistics, operations, outbound logistics, marketing/sales, service, plus support activities (HR, tech, procurement, infrastructure). For a software company, the chain compresses but doesn't vanish - the activities are roughly: build, operate, sell, support, and pay for it all.
+
+The engineer's job sits inside *operations* (running the service) and *technology development* (a support activity in Porter's original framing). That placement matters. Activities further from the customer - like the platform engineer maintaining the build system - are further from where willingness-to-pay is determined. They're not less valuable. They're just one degree removed from the conversation about value capture, which is why their work has to be translated into business language to be funded. We will spend the rest of this course on that translation.
+
+## Walkthrough
+
+A worked example. Suppose your team is choosing between two projects.
+
+```text
+Project A - Reduce p99 latency on the checkout API from 800ms to 200ms.
+Estimated cost: $300k (2 engineers · 6 months).
+
+Project B - Add a feature competitors charge $20/user/month for.
+Estimated cost: $300k (2 engineers · 6 months).
+```
+
+Both projects create value. Project A creates it for *every user every time they check out*. Project B creates it for *users who want that specific feature*. The crucial question is not which creates more value - it's which lets the firm capture more.
+
+Project A's value capture is *indirect*: faster checkout → fewer abandoned carts → more revenue. Estimating that conversion lift requires the marketing analytics team. If the lift is 0.5% on $200M ARR, that's $1M/year - a 3x return on the investment.
+
+Project B's capture is *direct*: it appears on the price sheet. If half of new enterprise prospects ask for that feature and 200 deals close per year, the feature might shift the close rate by a few percentage points - also worth a million or two.
+
+The framework lets you evaluate them on the same axis. Neither is obviously better. The point is: a chapter that ends "we should reduce latency because performance matters" is not a business case. A chapter that ends "we should reduce latency because the marketing team estimates a 0.5% lift in conversion at $4M ARR/year" is.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  inputs[Inputs: engineers, infra, capital] --> activities[Value-chain activities]
+  activities --> created[Value created: WTP - opportunity cost]
+  created --> price[Price set by competitive position]
+  price --> captured[Value captured: price - cost]
+  captured --> reinvest[Reinvested into inputs]
+  reinvest --> inputs
+```
+
+The loop closes. A firm that captures more than it spends compounds. A firm that doesn't, decays. Engineering work moves units around inside this loop - but the *shape* of the loop is set by strategy, pricing, and competition, which are the next four modules.
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Conflating value created with value captured | Engineers anchor on "did we ship something good?" | Always ask separately: did this raise willingness-to-pay, did it reduce cost, did it raise the price we can charge? |
+| Treating internal projects as having no business case | "It's just infrastructure" | Internal investments still have an ROI; the translation is via developer productivity, incident reduction, or unlocked product capability. |
+| Assuming a great product wins | The "great product, bad business" trap | Distribution, switching costs, and pricing power often beat product quality. See: every product category with a #2 player making more money than the #1. |
+| Reading the value chain as a process diagram | It's an *activity decomposition*, not a workflow | Activities run in parallel; the value chain just names them. |
+
+## Exercises
+
+1. Pick a product you use daily. Identify two activities in its value chain that *create* value for you. Identify one activity that exists primarily to *capture* value (a paywall, a tiering decision, a sales process). Notice that the third one is often invisible to engineers.
+2. Take a recent engineering project you led. Write one sentence describing the value *created* and one sentence describing how the firm *captures* it. If the second sentence is hard to write, that's information.
+3. Find a public S-1 (e.g. [Snowflake's](https://www.sec.gov/Archives/edgar/data/1640147/000119312520245725/d427360ds1.htm)) and identify the top three "risk factors" the company names. Almost all of them are about value capture, not value creation. Why?
+
+## Recap & next
+
+- A business creates value and captures some of it; the two are different and often unrelated.
+- Coase's answer to "why firms exist" - transaction costs - silently drives every build-vs-buy decision in the org.
+- The value chain places engineering work one to two steps removed from where willingness-to-pay is set, which is why translation matters.
+- "Great product" is necessary but not sufficient; distribution, pricing, and moats determine capture.
+
+Next, **Reading a P&L without panic** - the income statement decoded line by line.
+{% endraw %}
diff --git a/_courses/engineers-mba/01-foundations-business-os/02-reading-a-pnl.md b/_courses/engineers-mba/01-foundations-business-os/02-reading-a-pnl.md
new file mode 100644
index 0000000..a1ed6ae
--- /dev/null
+++ b/_courses/engineers-mba/01-foundations-business-os/02-reading-a-pnl.md
@@ -0,0 +1,152 @@
+---
+chapter_id: 2
+chapter_slug: reading-a-pnl
+chapter_title: "Reading a P&L without panic"
+chapter_summary: "Walks through the standard software P&L line by line - revenue, COGS, gross margin, R&D/S&M/G&A - and shows what 'good' looks like for SaaS. Explains why where engineering costs are classified materially shifts the ratios investors and execs benchmark."
+---
+
+{% raw %}
+## What you'll learn
+- The shape of a software company's income statement, line by line - revenue down to net income.
+- What each line tells you about the business, and what "good" numbers look like for SaaS.
+- Why R&D, S&M, and G&A are usually broken out separately, and how to read the ratios.
+- Where engineering costs land on the P&L and why that placement matters.
+
+## Concepts
+
+The Profit and Loss statement - P&L, or income statement - is the single document executives stare at most. Public companies publish theirs quarterly in their [10-Q filings](https://www.sec.gov/page/searchedgar-form-types-explanation); private ones produce a version every month for the board. Once you can read one fluently, you can follow most exec conversations about company health.
+
+It always has the same skeleton:
+
+```text
+                                    Q3'25       % of revenue
+Revenue                           $100.0M           100%
+  Cost of Revenue (COGS)          $(25.0)M         (25)%
+                                  ────────
+Gross Profit                       $75.0M            75%   ← gross margin
+                                  ────────
+Operating Expenses
+  R&D                            $(30.0)M          (30)%
+  Sales & Marketing              $(40.0)M          (40)%
+  General & Admin                $(10.0)M          (10)%
+                                  ────────
+Operating Income (Loss)           $(5.0)M           (5)%
+  Other income / expense           $1.0M             1%
+  Taxes                            $0.0M             0%
+                                  ────────
+Net Income (Loss)                 $(4.0)M           (4)%
+```
+
+You read top-to-bottom. Each section answers one question.
+
+### Revenue: what did customers pay us this period?
+
+For SaaS, this is almost always recognised *ratably* - a $120k annual contract becomes $10k of revenue each month, not a $120k spike at signing. The cash hit the bank account upfront; the *revenue* line on the P&L doesn't. This is why "ARR" (annualised run-rate revenue) and "revenue" can diverge sharply when a company is growing fast or signing long deals - more on that in [Cash, profit, accruals](/courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals/).
+
+Read the year-over-year growth rate (typically shown alongside the absolute number). For B2B SaaS, the rough bar is: 100%+ is hypergrowth, 40–60% is solid growth-stage, 20–30% is late-stage but healthy, sub-20% with profitability is mature, sub-20% without profitability is a problem.
+
+### COGS: what did it cost to *deliver* the revenue we recognised?
+
+For a SaaS company, COGS is mostly *cloud infrastructure, customer support, third-party service costs*, and *the salaries of people who run the production service* (SREs, support engineers, sometimes a fraction of platform engineering). It does *not* include the salaries of engineers building *new* features - that's R&D.
+
+Gross margin = (Revenue − COGS) / Revenue. This is the most important number on the entire statement. It tells you how much money is left over after you've delivered what the customer paid for, before you've paid for anything else.
+
+| Industry | Typical gross margin |
+|---|---|
+| SaaS | 70–85% |
+| Marketplaces | 60–80% (depending on take rate) |
+| Hardware | 30–50% |
+| Retail | 20–40% |
+| Cloud infrastructure providers | 50–65% |
+
+A SaaS company with 50% gross margin is doing something wrong, or isn't really SaaS. A SaaS company at 85% has a beautiful business - they have huge surplus to spend on R&D and S&M.
+
+### Operating expenses: R&D, S&M, G&A
+
+These are the costs of *growing* the business, not delivering what the customer already paid for. Public companies break them into three buckets:
+
+- **R&D (Research & Development)** - the salaries of engineers building new features, plus a slice of management, plus product/design. For most SaaS companies, R&D is 15–30% of revenue. Under-investing here is a slow death; over-investing without a clear product strategy burns cash.
+- **S&M (Sales & Marketing)** - sales team comp, ad spend, marketing programs, demand gen, partner programs. For SaaS, this is often the largest single line item - 30–50% of revenue is common at growth stage, and the line on which "is this company efficient?" is most often litigated. It encodes [CAC](/courses/engineers-mba/01-foundations-business-os/04-unit-economics/): every dollar of S&M is buying some amount of new ARR.
+- **G&A (General & Administrative)** - finance, HR, legal, the CEO's office, real estate. The "boring overhead." Typically 8–15% of revenue; if it's bigger than that, something is structurally off.
+
+### Operating income, net income
+
+**Operating income** = Gross profit − Opex. This is the profitability of the actual *operations* of the business, before you account for taxes, interest, or one-time events. For SaaS, this is the line investors care most about, often expressed as "operating margin" or "non-GAAP operating margin" (the latter strips out stock-based compensation, which is enormous in software).
+
+**Net income** = Operating income + Other income/expense − Taxes. This is what hits retained earnings. For software companies, the gap between operating and net income is usually small unless they have significant interest income (large cash piles) or one-time items.
+
+### Where engineering lands
+
+A senior engineer's loaded cost (~$400k all-in including comp, benefits, equity, infrastructure) is on the P&L *somewhere*. The placement depends on what they do:
+
+| Role | Where on the P&L | Why |
+|---|---|---|
+| SRE running production | COGS | Cost of delivering current revenue |
+| Customer support engineer | COGS | Same |
+| Product engineer (new features) | R&D | Investment in future revenue |
+| Platform engineer (internal tools) | R&D | Investment, even if internal |
+| Sales engineer (pre-sales) | S&M | Helps close deals |
+| IT engineer | G&A | Overhead, not customer-facing |
+
+The same person doing the same work can land in two different buckets depending on framing. This matters: shifting headcount from R&D to COGS can hurt gross margin while improving R&D efficiency, and vice-versa. Finance teams care about which bucket because the ratios drive valuation multiples.
+
+## Walkthrough
+
+Pull a real one. Here's Atlassian's FY24 P&L (rounded, [10-K filing](https://investors.atlassian.com/)) presented in the same structure:
+
+```text
+Revenue                          $4,360M         100%
+Gross profit                     $3,640M          83.5%
+  R&D                            $2,036M          46.7%
+  S&M                            $890M            20.4%
+  G&A                            $440M             10.1%
+Operating loss                   $266M             6.1%
+```
+
+Three things to notice:
+
+1. Gross margin of ~83% is excellent - pure-software SaaS at scale.
+2. R&D at 47% of revenue is enormous. Atlassian invests heavily in product breadth (Jira, Confluence, Bitbucket, Compass, Loom…). That's a strategic choice - they're betting product breadth is the moat.
+3. S&M at only 20% is unusually low for SaaS. Atlassian famously runs a low-touch, self-service motion - most customers buy without ever talking to a salesperson. The low S&M ratio is the visible footprint of that strategy.
+
+Compare with a sales-led peer: Salesforce's R&D is ~15% and S&M is ~36%. Same industry, completely different P&L shape, because the *strategy* is different.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  rev[Revenue from contracts] --> gp[Gross profit]
+  cogs[COGS: infra, support, SREs] --> gp
+  gp --> oi[Operating income]
+  rnd[R&D: product engineering] --> oi
+  sm[S&M: sales team, marketing] --> oi
+  ga[G&A: finance, HR, legal] --> oi
+  oi --> ni[Net income]
+  tax[Taxes, other] --> ni
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Conflating revenue with cash | Revenue is recognised ratably; cash arrives in lumps | Look at the cash flow statement alongside the P&L. We cover this next chapter. |
+| Treating gross margin as just a finance metric | It encodes "how scalable is this business?" | Low gross margin caps how much you can invest in R&D and S&M - it's a strategy constraint, not a finance trivia. |
+| Ignoring stock-based compensation | SaaS companies report "non-GAAP" numbers that hide SBC | SBC is real dilution; read both GAAP and non-GAAP. |
+| Misreading R&D as "engineering" | R&D includes product, design, eng management, and engineering benefits | When you see "20% of revenue going to R&D", remember it's not all engineers' base salaries. |
+| Assuming bigger R&D = better company | Spend without strategy burns cash | Compare R&D-as-%-of-revenue across years - is it scaling efficiently or growing as fast as headcount? |
+
+## Exercises
+
+1. Pull the latest 10-Q from any public SaaS company you use. Identify revenue, gross margin, R&D %, S&M %, and operating margin. Compare the structure to Atlassian's above. Write one sentence per number explaining what it implies about the company's strategy.
+2. For your own team, estimate which P&L bucket your salary lands in. If you're not sure, ask your finance partner - the answer often surprises engineers and reveals how your work is "framed" upstream.
+3. Find a software company whose gross margin is below 60%. Look at the 10-K footnotes to find out *why* (usually: significant professional services revenue, hosted hardware costs, or significant infrastructure pass-through). The reason almost always reveals the business model.
+
+## Recap & next
+
+- The P&L is the same five-section skeleton everywhere: revenue, COGS, opex (R&D/S&M/G&A), operating income, net income.
+- Gross margin is the most diagnostic single number - it caps how much you can invest in everything else.
+- The split of opex into R&D/S&M/G&A encodes the company's strategy: a heavy S&M ratio signals sales-led; a heavy R&D ratio signals product-led.
+- Where engineering costs land (COGS vs R&D) depends on what the engineer does, and the placement materially affects which ratios look healthy.
+
+Next, **Cash, profit, accruals: what each actually means** - why a profitable company can still run out of money.
+{% endraw %}
diff --git a/_courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.md b/_courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.md
new file mode 100644
index 0000000..3c59be8
--- /dev/null
+++ b/_courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.md
@@ -0,0 +1,167 @@
+---
+chapter_id: 3
+chapter_slug: cash-profit-accruals
+chapter_title: "Cash, profit, accruals: what each actually means"
+chapter_summary: "Explains accrual vs cash accounting, why a profitable SaaS company can run out of cash and vice versa, and how deferred revenue creates a structural advantage. Introduces runway, burn, and the cash flow statement as the engineer's first read."
+---
+
+{% raw %}
+## What you'll learn
+- Why a profitable company can still go bankrupt, and why an unprofitable one can have plenty of cash.
+- The difference between *accrual* accounting (what the P&L uses) and *cash* accounting (what your bank balance shows).
+- *Runway*, *burn rate*, and how to compute both from a board deck.
+- The three financial statements and why the cash flow statement is the one engineers should read first.
+
+## Concepts
+
+The first time you read a board deck you'll notice that the same company is described with two profitability numbers that disagree by tens of millions of dollars. One says "net loss of $(80M)" and the other says "free cash flow of +$30M". Both are correct. The reason they disagree is *accrual accounting*, which is the convention every public company uses for its P&L.
+
+### Accrual vs. cash, in one sentence each
+
+- **Cash accounting** - you record revenue when the money lands in the bank and expenses when the money leaves it.
+- **Accrual accounting** - you record revenue when it's *earned* (the customer has received the service) and expenses when they're *incurred* (the work has been done), regardless of when cash moves.
+
+For SaaS, this matters constantly. Suppose a customer signs a $1.2M annual contract on January 1st and pays the full $1.2M upfront. Under accrual:
+
+| | Jan | Feb | Mar | ... | Dec | Total |
+|---|---|---|---|---|---|---|
+| Revenue (P&L) | $100k | $100k | $100k | ... | $100k | $1.2M |
+| Cash (bank account) | $1.2M | $0 | $0 | ... | $0 | $1.2M |
+
+Revenue is recognised *ratably* - earned across the period of service. The cash is in the bank from day one. The difference creates an entry called *deferred revenue* on the balance sheet: a liability that says "we owe this customer eleven more months of service we've already been paid for."
+
+Now flip it. The same customer signs a $1.2M annual contract on December 31st with [Net 60 payment terms](https://www.investopedia.com/terms/n/netdays.asp). The customer pays in two months but starts using the product immediately:
+
+| | Jan | Feb | Mar | ... | Dec | Total |
+|---|---|---|---|---|---|---|
+| Revenue (P&L) | $100k | $100k | $100k | ... | $100k | $1.2M |
+| Cash | $0 | $1.2M | $0 | ... | $0 | $1.2M |
+
+January's revenue is real - the service was delivered. The cash comes later. The gap shows up on the balance sheet as *accounts receivable*: money owed to the company that it has earned but not yet collected.
+
+### Why a profitable company can run out of cash
+
+Consider a startup with the following pattern: it signs annual contracts billed annually upfront, has gross margin of 80%, and is growing. Its P&L looks ugly:
+
+```text
+Revenue        $20M       100%
+COGS           $(4M)       (20)%
+Gross profit   $16M         80%
+R&D            $(15M)      (75)%
+S&M            $(12M)      (60)%
+G&A            $(4M)       (20)%
+Operating loss $(15M)      (75)%
+```
+
+But here's what the bank balance looks like:
+
+```text
+Cash from ops:   $20M revenue + $30M deferred revenue from new annual deals
+               − $4M COGS − $31M opex
+               = $15M positive cash flow
+```
+
+It's losing $15M on the P&L and *generating* $15M in cash. The reason: customers pay annually upfront. The deferred-revenue float effectively finances the burn.
+
+This is the structural reason high-growth SaaS companies can run "unprofitable" for years and not raise emergency capital. Their cash dynamics are healthier than their accrual P&L suggests. The reverse - a company with a profitable P&L and negative cash flow - is much rarer in SaaS and is usually a sign of revenue-recognition shenanigans or massive accounts receivable. WeWork's pre-IPO disclosures showed flavours of this dynamic and were one of the things investors choked on.
+
+### Runway and burn
+
+**Burn rate** = net cash leaving the company per month. Almost always quoted in monthly terms even if calculated from quarterly numbers.
+
+**Runway** = (Cash on hand) / (Monthly burn). The number of months until you hit zero.
+
+These two are the single most important numbers in any private company. The CEO of any startup knows their runway to the week. Public companies talk about it less because they have access to capital markets, but it still matters during downturns.
+
+The formula breaks down when burn is volatile - for example, when a quarterly bill (e.g. annual subscription renewal *outflow*) skews the month. So real boards usually look at *trailing-12-month average burn* in addition to the latest month.
+
+### The cash conversion cycle
+
+In SaaS the cycle is unusually friendly to the company. The standard cash conversion cycle is:
+
+```text
+Days Sales Outstanding (DSO)  +  Days Inventory Outstanding  −  Days Payable Outstanding (DPO)
+```
+
+Software has no inventory, so DIO is zero. For an annual-billing-upfront SaaS, DSO is *negative* - customers pay before you've delivered the service. Combined with DPO of 30–60 days (the company pays its bills on standard terms), the result is a *negative* cash conversion cycle. The company is, in effect, being financed by its customers. This is one of the structural reasons SaaS is such a beloved business model.
+
+### The three statements at a glance
+
+Every company produces three financial statements. They link.
+
+| Statement | Question it answers | Time horizon |
+|---|---|---|
+| P&L (income statement) | Did we make money this period? | Period (quarter/year) |
+| Balance sheet | What do we own and owe right now? | Snapshot |
+| Cash flow statement | How did cash actually move this period? | Period |
+
+The cash flow statement *reconciles* the P&L's accrual numbers to the balance sheet's cash changes. It's organised in three sections:
+
+- **Operating activities** - cash generated by the core business. Start with net income, then add back non-cash items (depreciation, SBC) and adjust for changes in working capital.
+- **Investing activities** - capex, acquisitions, sales of assets.
+- **Financing activities** - issuing/buying back stock, raising debt, paying dividends.
+
+For SaaS, "cash from operating activities" is the line that matters. Engineers should read this before reading the P&L - it tells you whether the business is generating its own fuel.
+
+## Walkthrough
+
+A worked example. Hypothetical "Datadock" (not the real Datadog) closes Q1 with the following:
+
+```text
+Revenue (P&L, accrual)           $50M
+COGS                            $(10M)
+Opex                            $(55M)
+Net loss                       $(15M)
+
+But on the cash flow statement:
+  Net loss                        $(15M)
+  + Stock-based compensation       $20M    ← non-cash
+  + Change in deferred revenue     $25M    ← customers prepaid for future service
+  − Change in receivables         $(8M)    ← some customers haven't paid yet
+                                ────────
+Cash from operations              $22M
+```
+
+Datadock is "losing $15M" but generating $22M in cash. The lines that matter:
+
+1. **SBC** ($20M): the company paid employees in stock. That's a real cost to existing shareholders (dilution), but no cash left the company.
+2. **Deferred revenue** (+$25M): customers prepaid for service Datadock hasn't yet delivered.
+3. **Receivables** (−$8M): some customers were billed but haven't paid. That hits cash even though revenue was already recognised.
+
+The cash flow statement is where these reconciliations live. If you only read the P&L, you'd think this company was a disaster. If you only read the cash flow statement, you'd miss the dilution.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  pnl[P&L: accrual revenue and expenses] -->|adjustments| cfs[Cash flow statement]
+  bs1[Balance sheet: period start] --> cfs
+  cfs --> bs2[Balance sheet: period end]
+  cfs -->|cash from operations| runway[Runway and burn calcs]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Conflating P&L profit with cash | They're computed under different conventions | Look at both. The reconciliation is the cash flow statement. |
+| Ignoring deferred revenue | "It's just a liability" | For SaaS, deferred revenue is a free loan from customers. Track it growing or shrinking. |
+| Reading SBC as "free" | No cash leaves | It's dilution. Existing shareholders pay for it, just through ownership not cash. |
+| Quoting "runway" without a date | Cash on hand changes constantly | Always cite "runway as of X" and confirm the burn assumption. |
+| Treating burn as flat | Some months have one-time items | Look at trailing-12-month average and recent trend, not just last month. |
+
+## Exercises
+
+1. Take the most recent 10-Q from any public SaaS company. Find the cash flow statement. Identify the three biggest non-cash adjustments. For most, you'll find SBC is the largest. Note what fraction of revenue this represents - it's the company's silent ongoing equity grant to employees.
+2. Build a one-page model for a fictional SaaS company billing $100k annual contracts upfront. Show its P&L and cash position over 12 months as it adds 1 new customer per month. Note when cash and revenue diverge most.
+3. Take your own company's last all-hands. Look up whether the CFO quoted *revenue* growth, *ARR* growth, or *bookings* growth. All three can be different. Which one are they choosing to lead with, and why?
+
+## Recap & next
+
+- Accrual accounting records revenue when earned and expenses when incurred; cash accounting tracks the bank balance. The P&L uses accrual.
+- Deferred revenue is the SaaS-specific magic: customers prepay annually for service, the cash is yours immediately, the revenue ratably.
+- Runway and burn are the most-watched numbers in private companies. They're computed from cash, not P&L.
+- The cash flow statement reconciles P&L profit to actual cash movement; engineers should read it before the P&L.
+
+Next, **Unit economics: CAC, LTV, payback, retention** - the four numbers exec teams stare at.
+{% endraw %}
diff --git a/_courses/engineers-mba/01-foundations-business-os/04-unit-economics.md b/_courses/engineers-mba/01-foundations-business-os/04-unit-economics.md
new file mode 100644
index 0000000..6b8d528
--- /dev/null
+++ b/_courses/engineers-mba/01-foundations-business-os/04-unit-economics.md
@@ -0,0 +1,178 @@
+---
+chapter_id: 4
+chapter_slug: unit-economics
+chapter_title: "Unit economics: CAC, LTV, payback, retention"
+chapter_summary: "Defines CAC, LTV, payback, and retention; shows how to compute each; and identifies the most common manipulations. Maps each unit-economic lever back to concrete engineering investments (reliability, onboarding, infra, integrations)."
+---
+
+{% raw %}
+## What you'll learn
+- The four numbers that define whether a SaaS business is real: CAC, LTV, payback, and retention.
+- How each is computed, what "good" looks like, and the manipulations to watch for.
+- How engineering investments - performance, onboarding, integrations, reliability - move each metric.
+- Why the "LTV:CAC ratio" is the most-quoted and most-abused number in the industry.
+
+## Concepts
+
+Unit economics is the discipline of evaluating a business *one customer at a time*. The intuition: if the average customer is unprofitable, scaling the company just loses money faster. If the average customer is wildly profitable, you raise capital, pour gasoline on the fire, and grow.
+
+For SaaS, four numbers carry almost all the weight. Most board decks revisit them every quarter.
+
+### CAC - Customer Acquisition Cost
+
+```text
+CAC = (Total Sales & Marketing spend in period) / (New customers acquired in period)
+```
+
+Variations:
+
+- **Blended CAC** - all S&M spend divided by all new customers (including free signups, organic conversions, paid conversions).
+- **Paid CAC** - only the cost of *paid* channels divided by paid-channel conversions. Higher and more honest.
+- **Fully-loaded CAC** - adds sales team comp, fully-loaded sales-engineering time, and proportional G&A. This is what a rigorous CFO will compute.
+
+The variant matters. "Our CAC is $300" might mean blended CAC including the customer who signed up because their colleague tweeted about you. The paid CAC may be $3,000. Always ask which variant.
+
+For B2B SaaS, common ranges by ACV (Annual Contract Value):
+
+| ACV | Typical CAC | Common motion |
+|---|---|---|
+| $1k SMB | $500–$2k | PLG, self-serve, some inside sales |
+| $10k mid-market | $5k–$20k | Inside sales + lighter marketing |
+| $100k enterprise | $50k–$200k | Full-cycle AE, SEs, longer cycles |
+| $1M+ strategic | $250k+ | Field sales, executive sponsorship |
+
+### LTV - Lifetime Value
+
+```text
+LTV = (ARPU × Gross Margin %) / Churn Rate
+```
+
+This is the discounted-cash-flow-flavoured estimate of how much gross profit one customer will produce over their lifetime with the company. The formula assumes a steady-state world: customers pay the same ARPU (average revenue per user) forever, gross margin holds, and a fixed fraction churns each period.
+
+The components:
+
+- **ARPU** - annual or monthly average revenue per customer. Watch which.
+- **Gross margin** - the LTV is in *gross-profit* dollars, not revenue dollars. A customer paying $10k with 80% gross margin contributes $8k gross profit per period. Some companies report "revenue LTV" without margin - that's the *most common* manipulation.
+- **Churn** - fraction of customers lost per period (more in [GRR/NRR](/courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree/)). For B2B SaaS, annual logo churn of 5–7% is healthy, 7–10% is typical, 15%+ is concerning.
+
+Quirks:
+
+- The formula assumes infinite lifetime. For high-churn segments, this overstates LTV badly. Some teams cap "lifetime" at 3 or 5 years for honesty.
+- Net-revenue retention >100% (existing customers expanding faster than others churn) makes the formula explode toward infinity. Some teams use a more conservative steady-state assumption.
+
+### Payback period
+
+```text
+Payback period (months) = CAC / (Monthly gross profit per customer)
+```
+
+How many months until the cumulative gross profit from a customer pays back the cost of acquiring them. Easier to interpret than LTV:CAC because there's no fudge-able lifetime assumption.
+
+For B2B SaaS:
+
+| Payback (months) | Read |
+|---|---|
+| <12 | Excellent - efficient growth |
+| 12–18 | Healthy growth-stage |
+| 18–24 | Acceptable; watch trend |
+| >24 | Capital-intensive; sustainable only with cheap capital |
+
+A 24-month payback is the rough industry bar for venture-backed SaaS. During the 2020–2021 zero-interest-rate era, companies pushed it to 36 months in pursuit of growth. The 2022–2024 correction was largely about that number snapping back.
+
+### Retention / churn
+
+```text
+Logo churn = (Customers lost in period) / (Customers at start of period)
+Revenue churn = (Revenue lost in period from existing customers) / (Revenue at start)
+```
+
+For B2B SaaS, the more meaningful metric is *gross revenue retention* (GRR, only counting losses) and *net revenue retention* (NRR, including expansion). We cover those in [the SaaS metric tree](/courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree/). For unit economics, the key idea: low churn extends the LTV multiplier dramatically.
+
+A customer with 90% retention has an expected lifetime of 10 years (1 / 10% churn). At 80% retention, lifetime is 5 years. At 70%, 3.3 years. Tiny shifts in retention map to massive shifts in LTV.
+
+### Engineering levers on each metric
+
+This is the table to internalise. Every metric here can be moved by engineering work.
+
+| Metric | Engineering levers |
+|---|---|
+| CAC | Faster trial-to-paid funnel, self-serve onboarding, lower cost-per-lead via better SEO content systems, lower sales-engineering time per deal via better demo environments. |
+| LTV (ARPU) | Usage-based pricing infrastructure, better upsell prompts, packaging changes, expansion features. |
+| LTV (margin) | Infrastructure cost optimisation, multi-tenancy improvements, better automation reducing support load. |
+| LTV (churn) | Reliability, performance, integrations, sticky data exports/imports, depth of product. |
+| Payback | All of the above; faster onboarding shifts payback most directly. |
+
+When someone in a strategy review says "we need to improve unit economics," the answer almost always rolls back to a finite list of engineering investments. The skill is mapping which one.
+
+## Walkthrough
+
+A worked example. SaaS company "Twilex" reports the following:
+
+```text
+ACV (annual contract value):     $24,000
+Gross margin:                    75%
+S&M spend last quarter:          $5M
+New customers acquired:          200
+Annual logo churn:               12%
+```
+
+Compute:
+
+```text
+CAC                = $5,000,000 / 200            = $25,000
+Annual gross profit per customer = $24k × 75%    = $18,000
+Monthly gross profit per customer                 = $1,500
+
+Payback period     = $25,000 / $1,500            = 16.7 months
+LTV                = $18,000 / 0.12              = $150,000
+LTV:CAC ratio      = $150,000 / $25,000          = 6x
+```
+
+The 6x LTV:CAC and 16.7-month payback look good. But notice the levers:
+
+- If churn improves from 12% to 8% (e.g. via reliability investments), LTV jumps to $225k. LTV:CAC becomes 9x.
+- If CAC falls from $25k to $20k (e.g. via PLG-style self-serve onboarding), payback drops to 13.3 months.
+- If gross margin improves from 75% to 80% (e.g. via infra optimisation), LTV becomes $160k.
+
+Notice the asymmetry: a 4-point churn improvement moves LTV by $75k; a 5-point margin improvement moves it by only $10k. Retention is the dominant lever. Engineering work on reliability and integrations is usually higher-leverage than infra optimisation in unit-economic terms.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  sm[S&M spend] --> cac[CAC]
+  arpu[ARPU] --> ltv[LTV]
+  margin[Gross margin %] --> ltv
+  churn[Churn rate] --> ltv
+  cac --> payback[Payback period]
+  ltv --> ratio[LTV:CAC ratio]
+  cac --> ratio
+  ratio --> verdict[Business quality verdict]
+  payback --> verdict
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Revenue LTV instead of gross-profit LTV | Higher number; flattering | Always compute LTV in gross-profit terms. |
+| Blended CAC quoted as "CAC" | Includes free conversions, organic | Ask for paid CAC and fully-loaded CAC. |
+| Ignoring CAC payback in favour of LTV:CAC | LTV depends on a fudgy "infinite lifetime" assumption | Use payback as the primary efficiency metric; LTV:CAC as a sanity check. |
+| Computing LTV with NRR > 100% | Formula explodes to infinity | Cap NRR at 100% for the LTV calculation, or use a finite-horizon LTV. |
+| Mixing customer cohorts | New customers and old customers have different economics | Look at cohort-level CAC payback by acquisition channel and segment. |
+
+## Exercises
+
+1. Take a SaaS company you know well. Estimate (or look up) their ACV, gross margin, churn, and S&M spend. Compute their CAC, LTV, payback, and LTV:CAC. Check your estimate against any disclosed unit-economic numbers in their public reporting.
+2. For your own product, write down three engineering projects from the last six months and which unit-economics metric each was *intended* to move. For each, write down whether the eventual measurement confirmed the intent. Most engineers find this exercise reveals that the metric link wasn't ever measured.
+3. Find a public SaaS company's investor day deck. Search for "payback" - they almost certainly disclose it. Note whether they show "blended" or "by segment" or "for new cohorts only." Each variant tells a different story about efficiency.
+
+## Recap & next
+
+- CAC, LTV, payback, and retention are the four numbers that define a SaaS business one customer at a time.
+- Payback period is the most honest single metric - fewer fudge-able assumptions than LTV:CAC.
+- Retention is the dominant lever on LTV; small improvements compound enormously.
+- Every metric has direct engineering levers - reliability, onboarding speed, infra cost, integration depth.
+
+Next, **Business model archetypes in software** - how subscription, usage-based, marketplace, and platform models shape everything downstream.
+{% endraw %}
diff --git a/_courses/engineers-mba/01-foundations-business-os/05-business-model-archetypes.md b/_courses/engineers-mba/01-foundations-business-os/05-business-model-archetypes.md
new file mode 100644
index 0000000..080fcb1
--- /dev/null
+++ b/_courses/engineers-mba/01-foundations-business-os/05-business-model-archetypes.md
@@ -0,0 +1,175 @@
+---
+chapter_id: 5
+chapter_slug: business-model-archetypes
+chapter_title: "Business model archetypes in software"
+chapter_summary: "Surveys five software business model archetypes - subscription, usage-based, marketplace, transactional, platform - and shows how each shapes gross margin, sales motion, KPIs, and engineering priorities. Demonstrates that archetypes can be inferred from financial ratios alone."
+---
+
+{% raw %}
+## What you'll learn
+- The five major software business model archetypes - subscription, usage-based, marketplace, transactional, platform - and how each makes money.
+- Why the model shapes pricing, gross margin, sales motion, and engineering priorities downstream.
+- Hybrid and evolving models: when "SaaS" companies switch to usage-based, and what changes inside engineering when they do.
+- How to identify which archetype a given company belongs to from public financials alone.
+
+## Concepts
+
+The business model is the *shape* of how a company makes money. Not the price sheet - the underlying mechanic that determines what you charge for, when revenue is recognised, and what gross margin looks like. Five archetypes cover most of software.
+
+### 1. Subscription SaaS
+
+The customer pays a recurring fee - monthly or annual - for ongoing access to the service. The pioneer is Salesforce (1999). The model dominates B2B software today.
+
+**Mechanics:**
+- Revenue is recurring and predictable. Annual contracts are the norm in B2B; monthly is common in SMB and consumer.
+- Revenue is recognised ratably across the service period (see [accruals](/courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals/)).
+- Cash often comes upfront (annual billing) → deferred revenue → negative cash conversion cycle.
+- Gross margins are typically high (70–85%) because the marginal cost of an extra seat is small.
+
+**What engineering optimises for:** reliability (churn driver), feature breadth (price-sheet expansion), multi-tenancy efficiency (margin), onboarding speed (CAC payback).
+
+**Examples:** Atlassian, Salesforce, Workday, HubSpot, Figma, Notion.
+
+### 2. Usage-based (consumption)
+
+The customer pays per unit consumed - per API call, per gigabyte stored, per compute-hour. The pioneer is AWS (2006). The model has become dominant in infrastructure and developer tools.
+
+**Mechanics:**
+- Revenue scales with customer usage - uncapped on the upside but volatile on the downside.
+- Often quoted as "NRR" - when usage grows in existing accounts, expansion happens automatically, no negotiation.
+- Gross margins are typically lower (50–75%) because COGS scales with usage. The customer's heavy use of your service shows up directly in your AWS bill.
+- Forecasting is harder. Revenue can drop suddenly if a major customer cuts usage.
+
+**What engineering optimises for:** metering accuracy, infrastructure efficiency (every margin point matters), throughput, multi-tenant isolation under heavy load.
+
+**Examples:** Twilio, Stripe, Cloudflare, AWS, Datadog (hybrid).
+
+### 3. Marketplace
+
+The platform connects two sides (buyers and sellers) and takes a "rake" or "take rate" on each transaction. The model is ancient (Sotheby's, 1744) but software marketplaces are recent.
+
+**Mechanics:**
+- Revenue is *transactional* - the platform earns a percentage on each unit of activity.
+- Network effects often dominate the economics: more sellers attract more buyers, attracting more sellers.
+- Take rates vary from 1% (large B2B marketplaces) to 30%+ (app stores).
+- Gross margins are typically 60–80% but the unit of "gross profit" is the take, not the GMV.
+
+**What engineering optimises for:** matching quality, trust/safety, dispute resolution, throughput on either side of the marketplace, anti-fraud, search and discovery.
+
+**Examples:** Airbnb, Uber, Etsy, eBay, Shopify (hybrid), App Store.
+
+### 4. Transactional (per-event)
+
+The customer pays per discrete event - a payment processed, a message sent, an API call. Conceptually similar to usage-based but framed around *individual transactions* with externally-determined value.
+
+**Mechanics:**
+- Revenue is tied to the customer's own customer activity.
+- Often a take-rate-on-volume model rather than a fixed unit price.
+- Margins vary widely: payments are tightly bounded (~2–3% of transaction value, then ~50% margin on that fee); messaging is higher.
+- Strong negative correlation with customer downturns - when their business slows, yours slows automatically.
+
+**What engineering optimises for:** transaction latency, reliability, fraud detection, settlement timing, network of partner banks/carriers.
+
+**Examples:** Stripe (per-transaction fee), Twilio (per-message), Plaid, Square.
+
+### 5. Platform / infrastructure
+
+The customer builds *on top of* the platform; the platform sells primitives (compute, storage, APIs) at scale. Margins compound because the platform's investment in the underlying infrastructure amortises across all customers.
+
+**Mechanics:**
+- Often combines subscription floors with usage-based overages.
+- Two-sided value: the platform captures value from app developers *and* their end users (think iOS App Store).
+- Gross margins range widely depending on infrastructure intensity (AWS ~30% operating margin, Cloudflare higher) but are bounded by the underlying cost of compute/storage/bandwidth.
+- Strong moats from switching costs and ecosystem effects.
+
+**What engineering optimises for:** the developer experience for the platform's API surface, throughput, observability, multi-region availability.
+
+**Examples:** AWS, Cloudflare, GitHub, Stripe Connect, HashiCorp.
+
+### The model shapes everything
+
+A company's archetype determines an astonishing amount of what its engineering organisation looks like. Compare two companies of similar size:
+
+| | Subscription SaaS | Usage-based |
+|---|---|---|
+| Gross margin | 80% | 60% |
+| Revenue volatility | Low | High |
+| S&M intensity | Higher % of revenue | Lower % (usage expansion is automatic) |
+| Engineering priorities | Feature breadth, onboarding, reliability | Infra cost, metering, throughput |
+| Sales motion | Annual contracts, multi-year | Often signup-and-go, with enterprise overlay |
+| KPI obsession | NRR, gross margin, payback | Consumption velocity, NDR, cost per unit |
+
+A subscription SaaS company that wants to reposition as usage-based - common during 2022–2024 - has to rebuild its metering infrastructure, change its pricing page, restructure its sales comp, and retrain its CFO. None of this is reversible cheaply.
+
+### Hybrid models
+
+Most real companies are hybrids. Datadog charges a subscription floor *plus* usage. Snowflake is pure usage-based. Stripe is transactional with usage-based overlays. The mix matters because each component has different gross margin, different forecastability, and different sales motion.
+
+The most common hybrid in 2025 is "subscription + consumption commit": the customer agrees to a minimum annual spend (commit), and overages bill per-use. This combines the predictability of subscription with the upside of usage-based growth. Confluent, MongoDB-style cloud providers, and Cloudflare Workers all use variants of this.
+
+## Walkthrough
+
+A diagnostic exercise. Two anonymised public SaaS companies report similar revenue and similar growth:
+
+```text
+Company X:
+  Revenue                   $500M
+  Gross margin               78%
+  S&M / revenue              42%
+  NRR                        108%
+  Free cash flow margin      15%
+
+Company Y:
+  Revenue                   $480M
+  Gross margin               63%
+  S&M / revenue              25%
+  NRR                        125%
+  Free cash flow margin      8%
+```
+
+Which model is each? Let's reason:
+
+- **Company X** has 78% gross margin (subscription range), 42% S&M (heavy sales motion), 108% NRR (some expansion but mostly retention). This is subscription SaaS with an enterprise motion - Salesforce-flavoured.
+- **Company Y** has 63% gross margin (usage-based range), 25% S&M (lower because expansion is automatic), 125% NRR (massive expansion). This is usage-based - Snowflake-flavoured.
+
+The model can be inferred from the ratios alone. You don't even need the product description.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  model[Business model archetype] --> price[Pricing structure]
+  model --> margin[Gross margin profile]
+  model --> sales[Sales motion]
+  model --> kpis[Key metrics watched]
+  price --> rev[Revenue volatility]
+  margin --> eng1[Engineering priorities: cost vs. features]
+  sales --> eng2[Engineering priorities: self-serve vs. enterprise]
+  kpis --> eng3[Engineering priorities: metering, reliability]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Treating "SaaS" as one thing | "SaaS" covers subscription, usage-based, and hybrids | Identify the underlying archetype by looking at pricing page and gross margin. |
+| Comparing companies across archetypes | Different metrics apply | Benchmark within archetype (subscription vs subscription, usage vs usage). |
+| Assuming usage-based is "always better because NRR is high" | NRR > 100% can mask volatility | Look at the *distribution* of customer usage growth, not just the average. |
+| Underestimating the cost of model transitions | Pricing/comp/billing changes are deep | Treat a model transition like a re-platforming - measured in years. |
+| Conflating model with strategy | Same model can support many strategies | Two subscription SaaS can differ enormously in target market, channel, and product. |
+
+## Exercises
+
+1. Take three companies you know well. For each, identify the dominant model archetype, the secondary/hybrid component, and the gross margin you'd expect. Then look up the actual gross margin. Note any surprises.
+2. For your own company, look at the pricing page. Classify the model. Note whether the gross margin matches the archetype expectation. If it doesn't, find out why (often: one product line is a different model than the others).
+3. Imagine the company you work for switched from subscription to usage-based tomorrow. Write down three things that would change inside engineering. Then three things in sales. Then three in finance. This will give you intuition for why these transitions take years.
+
+## Recap & next
+
+- Five archetypes - subscription, usage-based, marketplace, transactional, platform - cover most software. Each has a distinct gross margin profile and engineering priority set.
+- The model shapes pricing, sales motion, KPIs, and engineering priorities. It's not just a billing decision.
+- Hybrids dominate in practice; subscription + consumption commit is the modern default.
+- You can usually identify a model from the financial ratios alone.
+
+Next, **Industry structure: Porter's Five Forces, applied to tech** - kicking off Module 2 with the most-used strategy framework.
+{% endraw %}
diff --git a/_courses/engineers-mba/02-strategy/01-porters-five-forces.md b/_courses/engineers-mba/02-strategy/01-porters-five-forces.md
new file mode 100644
index 0000000..7772990
--- /dev/null
+++ b/_courses/engineers-mba/02-strategy/01-porters-five-forces.md
@@ -0,0 +1,172 @@
+---
+chapter_id: 1
+chapter_slug: porters-five-forces
+chapter_title: "Industry structure: Porter's Five Forces, applied to tech"
+chapter_summary: "Applies Porter's Five Forces to three software companies (Stripe, Datadog, Cloudflare) and shows how industry structure varies dramatically within software. Emphasises that industry boundary definition is the make-or-break input to the analysis."
+---
+
+{% raw %}
+## What you'll learn
+- The five forces - buyer power, supplier power, new entrants, substitutes, rivalry - and what each one diagnoses.
+- How to apply the framework to a software company you know.
+- Why "the industry" you're competing in often isn't the one stated on the marketing page.
+- The limits of the framework - what it misses, and when to use complementary models.
+
+## Concepts
+
+Michael Porter introduced the Five Forces in 1979 as a way to diagnose the *structural profitability* of an industry. The idea: industry economics aren't accidents. They're set by five forces that determine how much of the value created flows to firms in the industry versus to customers, suppliers, or competitors.
+
+The diagnostic question is: *why do firms in industry X make (or fail to make) money?* The answer comes from analysing each force.
+
+```text
+                    [ Threat of new entrants ]
+                              ↓
+   [ Supplier power ] → [ Industry rivalry ] ← [ Buyer power ]
+                              ↑
+                    [ Threat of substitutes ]
+```
+
+### 1. Buyer power
+
+How much leverage do customers have over price and terms?
+
+- **High** when buyers are concentrated (a few enterprise customers dominate revenue), when switching costs are low, when products are commoditised, when buyers can credibly threaten to build it themselves.
+- **Low** when there are many fragmented buyers, when switching costs are high, when the product is mission-critical and small in cost terms ("budget dust"), when buyers can't realistically build alternatives.
+
+Engineering signal: if your team gets pulled into Q3 RFPs from a single customer worth 20% of ARR, you're feeling high buyer power.
+
+### 2. Supplier power
+
+How much leverage do *your* inputs have over you?
+
+- **High** when key inputs are concentrated (e.g. NVIDIA GPUs for AI), when supplier substitution is hard (a custom chip, a specific OS, a proprietary protocol), when suppliers can integrate forward (AWS competing with its customers via AWS-branded services).
+- **Low** when inputs are commoditised, when you have multiple supplier options, when you're a large enough customer that the supplier needs you more than you need them.
+
+Engineering signal: the constant "should we go multi-cloud?" debate is a supplier-power conversation. So is every public conversation about AI startups' dependence on NVIDIA.
+
+### 3. Threat of new entrants
+
+How easy is it for new players to come in and erode profits?
+
+- **High** when capital requirements are low, when expertise is widely available, when distribution is easy (the cloud, app stores, open source), when there are no regulatory barriers.
+- **Low** when capital is huge (chip fabs), when regulation is significant (banking, healthcare), when distribution is locked up by incumbents, when network effects favour incumbents.
+
+The general trend in software has been *lower* barriers to entry - open source, cloud, low-code. The pushback has been the rise of *capital-intensive* AI training, which has reintroduced a capital moat for foundation models.
+
+### 4. Threat of substitutes
+
+Can the customer's job get done a fundamentally different way?
+
+- **High** when alternative ways exist to satisfy the customer's job-to-be-done. Email replaced postal mail; Slack replaced internal email; LLMs are replacing certain SaaS analytics workflows.
+- **Low** when the product addresses a job uniquely.
+
+This force is the easiest to underestimate because substitutes often come from outside the industry's mental model. Kodak didn't lose to better film - they lost to phones.
+
+### 5. Industry rivalry
+
+How aggressively do current competitors fight?
+
+- **High** when there are many competitors of similar size, when product differentiation is low, when exit barriers are high (e.g. heavy investment in industry-specific assets), when industry growth is slow.
+- **Low** when there are few competitors, when differentiation is strong, when industry growth is fast (everyone can grow without taking share).
+
+A market with a single strong incumbent often has low rivalry - and the incumbent captures most of the value.
+
+### Putting it together
+
+For each force, you grade *high*, *medium*, or *low*. A consistently *low* force profile means the industry is structurally profitable - firms in it tend to make money. A consistently *high* profile means margins are thin and most participants struggle.
+
+For software, the canonical "good" Porter profile looks like:
+
+| Force | Typical SaaS profile |
+|---|---|
+| Buyer power | Medium-low (many buyers, but enterprise concentration in segments) |
+| Supplier power | Low-medium (cloud commodity, but possible GPU dependence) |
+| Threat of new entrants | Medium-high (low capital, but trust takes time) |
+| Threat of substitutes | Variable by category |
+| Rivalry | High in commoditised categories, low in defended ones |
+
+The good news for SaaS: the structural margins are decent. The bad news: low entry barriers + high rivalry in commoditised categories means margin pressure constantly.
+
+### Defining the industry
+
+The most common Porter mistake is to draw the industry boundary wrong. "We're in the CRM industry" is too broad if you're a vertical CRM for dentists; you face different forces from a horizontal player. The boundary is the set of substitutes the customer treats as interchangeable.
+
+Get the boundary wrong and the five-force analysis tells you nothing useful. Get it right and the framework becomes a strategic compass.
+
+## Walkthrough
+
+Let's apply it to three companies engineers know.
+
+### Stripe (payments)
+
+| Force | Grade | Why |
+|---|---|---|
+| Buyer power | Medium-low | Many small merchants (low individual leverage); some enterprise concentration |
+| Supplier power | Medium-high | Card networks (Visa/Mastercard) take a fixed cut; payment processors don't set interchange |
+| New entrants | Medium | Regulatory compliance is a moat; capital required is moderate |
+| Substitutes | Medium | Bank transfers, crypto, BNPL all peripherally compete |
+| Rivalry | Medium-high | Adyen, Block, PayPal, regional players all fight for the same merchants |
+
+Stripe earns money but the structural caps are clear: the card networks always take their cut, and competition keeps merchant fees compressed.
+
+### Datadog (observability)
+
+| Force | Grade | Why |
+|---|---|---|
+| Buyer power | Medium | Enterprise customers can threaten DIY (Prometheus, Grafana) |
+| Supplier power | Low | Cloud is commoditised; Datadog runs across all of them |
+| New entrants | High | Low capital, well-known patterns, open-source baseline (Prometheus) |
+| Substitutes | High | OSS observability stacks are credible substitutes |
+| Rivalry | High | New Relic, Dynatrace, Splunk, and many newer entrants compete fiercely |
+
+Datadog is profitable but constantly under pressure. Their answer has been *product breadth*: become the platform of record so the customer can't credibly multi-vendor. The current rivalry profile explains why they keep launching adjacent products.
+
+### Cloudflare (edge networking)
+
+| Force | Grade | Why |
+|---|---|---|
+| Buyer power | Low-medium | Many small customers; large enterprises can multi-vendor with Akamai/Fastly |
+| Supplier power | Low | Operates own network; not dependent on cloud providers |
+| New entrants | Low | Operating a global edge network is capital-intensive |
+| Substitutes | Medium | DIY proxies and CDN-as-a-service from clouds |
+| Rivalry | Medium | Akamai, Fastly are credible but smaller competitors |
+
+Cloudflare's Porter profile is structurally stronger than Datadog's. The capital requirements of running a real global edge network create a barrier most software businesses don't have.
+
+The three companies illustrate that *being in software* tells you almost nothing - the industry structure within software varies dramatically.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  forces[Five forces analysis] --> structure[Industry structural profitability]
+  structure --> strategy[Strategic options: where to compete, where to defend]
+  strategy --> moats[Build moats that *lower* each force]
+  moats --> outcomes[Sustained margins]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Drawing the industry boundary too broadly | "We're in B2B SaaS" | Pin down the set of substitutes for *this* customer's job. |
+| Ignoring substitutes outside the industry | Easy to miss adjacent threats | LLMs, in-house builds, and behavioural changes all count. |
+| Treating the framework as static | Industry structure changes | Re-run the analysis when conditions shift (new tech, regulation, capital availability). |
+| Confusing competitive *position* with industry *structure* | These are separate questions | Porter Five Forces analyses the industry; competitive position is the next layer. |
+| Skipping the framework for "intuition" | "We know our market" | Forcing the analysis exposes assumptions; intuition hides them. |
+
+## Exercises
+
+1. Pick your own company. Draw its Five Forces table. Grade each force as low/medium/high with one sentence of rationale. Now look at the company's last quarterly disclosure - does the strategy narrative match what your analysis predicts the constraints would be?
+2. Repeat for an adjacent product in your company's portfolio. Note where the forces differ between the two products. Often the company is competing in *two distinct industries* with shared engineering - but the strategy should differ.
+3. Find a company whose Porter profile got worse over the last 3 years (often: a force shifted from low to high). Examples: media (substitutes from streaming), retail (rivalry from Amazon). Write one paragraph on what the company did or should have done in response.
+
+## Recap & next
+
+- Five forces - buyer power, supplier power, new entrants, substitutes, rivalry - diagnose industry-level profitability.
+- The framework's value is the *forced* analysis of each force; intuition skips over forces silently.
+- Software has highly varied Porter profiles; "being in SaaS" doesn't tell you much about structural margins.
+- Industry boundary definition is the make-or-break input; spend time on it.
+
+Next, **Competitive advantage & moats** - once you've placed yourself in an industry, how do you build advantage that the five forces don't grind down?
+{% endraw %}
diff --git a/_courses/engineers-mba/02-strategy/02-moats-and-advantage.md b/_courses/engineers-mba/02-strategy/02-moats-and-advantage.md
new file mode 100644
index 0000000..e557ce2
--- /dev/null
+++ b/_courses/engineers-mba/02-strategy/02-moats-and-advantage.md
@@ -0,0 +1,168 @@
+---
+chapter_id: 2
+chapter_slug: moats-and-advantage
+chapter_title: "Competitive advantage & moats"
+chapter_summary: "Surveys five canonical moat types - network effects, switching costs, scale economies, data/learning, brand - and shows how each can be diagnosed in financial statements. Distinguishes structural moats from operational excellence."
+---
+
+{% raw %}
+## What you'll learn
+- The five canonical moat types: network effects, switching costs, scale economies, data/learning, brand.
+- Which moats compound over time and which erode.
+- How to identify what kind of moat (if any) your employer has.
+- Why "great engineering" is necessary but not sufficient as a moat.
+
+## Concepts
+
+A *moat* is a structural reason it's hard for competitors to take your customers. Without a moat, every dollar of profit is an invitation for someone to undercut you. Warren Buffett popularised the term; Hamilton Helmer's [*7 Powers*](https://www.amazon.com/7-Powers-Foundations-Business-Strategy/dp/0998116319) is the modern canonical treatment.
+
+Five moat types cover most of the cases that matter in software.
+
+### 1. Network effects
+
+Each new user makes the product more valuable for existing users. Adding a buyer makes a marketplace more useful to sellers. Adding a developer to a platform makes the platform more useful to users.
+
+**Subtypes:**
+- **Direct (same-side)** - users benefit from other users on the same side. Phone networks, messaging apps.
+- **Indirect (cross-side)** - users on one side benefit from users on the other. Marketplaces, app stores, payment networks.
+- **Data network effects** - more users generate more data, which improves the product for everyone (Waze, recommendation systems).
+
+**Why this moat compounds**: every new user makes leaving harder for existing users. Slack's value to your team grows with each new colleague added.
+
+**Why it can erode**: multi-homing (users participating on multiple networks at once), unbundling by category, regulator-mandated interoperability.
+
+**Engineering work that builds it**: features that increase user interconnection (mentions, threads, shared workspaces), API surface that brings in third-party apps and developers, integrations that turn one-sided users into network participants.
+
+### 2. Switching costs
+
+The cost - in time, money, training, or risk - of moving to a competitor. Customers stay because leaving is expensive even when the destination is better.
+
+**Subtypes:**
+- **Data lock-in** - proprietary formats, accumulated data, complex migrations.
+- **Integration lock-in** - dependencies woven through the customer's systems.
+- **Workflow lock-in** - operating procedures and trained users built around your product.
+- **Contractual lock-in** - multi-year contracts, prepayment, penalties.
+
+**Why this moat compounds**: every additional integration, every additional user trained, every additional year of accumulated data increases the switching cost.
+
+**Why it can erode**: open standards, data portability regulations, competitor-provided migration tooling. (Modern SaaS contracts often include cap on switching costs as an enterprise procurement requirement.)
+
+**Engineering work that builds it**: deep API integrations, importers that aren't matched by exporters, accumulated configuration, native ecosystem features. The pejorative term "vendor lock-in" is just switching costs viewed from the customer's perspective.
+
+### 3. Scale economies
+
+Unit cost falls as scale grows. Fixed costs get amortised across more customers; bargaining power with suppliers grows; learning curve drops costs.
+
+**Subtypes:**
+- **Cost-side scale** - infrastructure, R&D, S&M efficiencies (e.g. AWS's per-unit cost of compute drops with volume).
+- **Demand-side scale** - same as network effects; the demand side benefits.
+
+**Why this moat compounds**: a 10x advantage in cost means competitors either operate at a loss or can't reach your customers profitably.
+
+**Why it can erode**: technology shifts that reset the scale curve (cloud democratised access to global infrastructure; smaller players got AWS's scale on demand). Saturation - past some size, scale efficiencies plateau.
+
+**Engineering work that builds it**: multi-tenancy architecture (the per-customer marginal cost gets very low), infrastructure efficiency (lower COGS per request), automation that reduces support cost per customer, R&D leverage (one feature serves all customers).
+
+### 4. Data and learning advantages
+
+The product gets better with use, and use is hard for competitors to replicate.
+
+**Subtypes:**
+- **Learning curve** - your team gets better at solving the customer's problem faster than competitors can.
+- **Process power** - internal practices that produce superior products. Toyota's manufacturing system is the textbook example; in software, Amazon's Working Backwards process is often cited.
+- **Counter-positioning** - your business model is structurally incompatible with the competitor's, so they can't copy it without harming their existing business.
+
+**Why this moat compounds**: only the operator with the data advantage benefits from improvements; competitors stay where they were.
+
+**Why it can erode**: data leakage (employees move, vendors disclose), commoditisation of the underlying technology (LLMs are commoditising many data advantages), regulatory data-sharing requirements.
+
+**Engineering work that builds it**: telemetry, experimentation infrastructure, ML systems that compound on user data, internal tooling that makes the team faster.
+
+### 5. Brand
+
+Customers prefer the product because of trust, recognition, or status. Engineers underestimate this moat because it doesn't compile.
+
+**Why this moat compounds**: every successful interaction reinforces the brand; trust is an asset that's slow to build and slow to lose.
+
+**Why it can erode**: a single security incident, a single high-profile outage, a public misstep. Brand decay is non-linear - slow on the upside, fast on the downside.
+
+**Engineering work that builds it**: reliability (the most underrated brand asset in B2B), security posture, transparency in incidents, public status pages. SLAs aren't just legal documents - they're brand commitments.
+
+### Moats vs. operational excellence
+
+A common misreading: "We have an engineering culture of excellence - that's our moat." It usually isn't. Operational excellence keeps you competitive; it rarely creates structural advantage. Competitors can hire your engineers, copy your patterns, and adopt your tools. A moat is a structural reason it's *hard* to compete with you. Engineering excellence is a force multiplier - but if it disappeared tomorrow, the moat would remain.
+
+The corollary: the engineering work that *builds* moats is often less glamorous than the engineering work that produces excellence. Integration depth and reliability investments outlast benchmark-winning architectures.
+
+### How moats interact with Porter
+
+If [Porter Five Forces](/courses/engineers-mba/02-strategy/01-porters-five-forces/) tells you the structural profitability of an industry, moats tell you whether your *firm* will sit above or below the industry average. A firm with multiple moats in a structurally attractive industry compounds - Visa, ASML, Stripe. A firm with no moat in a structurally unattractive industry is a slow death.
+
+## Walkthrough
+
+A diagnostic exercise. For each company below, name the dominant moat:
+
+| Company | Moat | Reasoning |
+|---|---|---|
+| Visa | Network effect | Card-accepting merchants and cardholders reinforce each other; new entrants can't bootstrap either side |
+| Salesforce | Switching costs | Multi-year customisation, integrated workflows, trained users |
+| AWS | Scale economies | Massive infrastructure spread across all customers; reinvested R&D from years of compounding |
+| Atlassian | Switching costs (Jira workflows, accumulated tickets, integrations) | Companies build operating procedures around Jira; hard to migrate |
+| HashiCorp Vault | Switching costs (secrets baked into operational workflows) | Secrets engines and policies accumulate across teams |
+| Cloudflare | Scale economies (global network) | Few competitors can fund their own global edge network |
+| Figma | Network effects (collaboration) + switching costs (design files) | The collaboration loop pulls more designers in; design libraries trap them |
+
+Note that most successful software companies have multiple moats. Salesforce has switching costs (workflows), brand (the CRM standard), and increasingly platform/network effects (AppExchange). Compounding moats are the most durable.
+
+### Reading a moat from the financials
+
+A real moat shows up in the financial statements. Look for:
+
+| Signal | What it says |
+|---|---|
+| Stable or rising gross margins year-over-year | Pricing power; competitors can't undercut |
+| NRR consistently >110% | Existing customers expand; switching cost or value-from-use is high |
+| Low logo churn (<7% annual) | Switching costs are real, or the product is indispensable |
+| Operating margin expansion at scale | Scale economies are real |
+| Low S&M as % of revenue with strong growth | Brand, word-of-mouth, or network effect is funding growth |
+
+A "moat" claim without these financial fingerprints is usually marketing language.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  industry[Porter industry structure] --> firm[Firm's moats]
+  firm --> margin[Pricing power]
+  firm --> retention[Retention]
+  firm --> scale[Cost efficiency at scale]
+  margin --> compounding[Compounding capture]
+  retention --> compounding
+  scale --> compounding
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Calling features "moats" | Features can be copied | A moat must be hard to copy structurally, not just hard to copy this quarter. |
+| Treating brand as engineering's problem | Brand seems like marketing | Reliability, security, transparency build brand; engineers own them. |
+| Ignoring multi-homing | Network effects assumed to be absolute | Many "network" products in software let users participate in multiple networks; weakens the moat. |
+| Confusing operational excellence with moat | Excellence is necessary but rarely structural | Ask: if a competitor with $1B could replicate your engineering, would they catch up? |
+| Believing scale always wins | Tech shifts can reset scale | The cloud reset many traditional scale moats. |
+
+## Exercises
+
+1. List the moats your employer claims, then check each against the financial signals above. Note any that show up in marketing but not in the financials.
+2. Identify a moat that *eroded* over the last decade. Examples: print media's distribution scale, Microsoft's Office network-effect (now multi-home with Google Docs), Intel's process-tech learning curve. Write a paragraph on what reset the moat.
+3. For your own team's roadmap, classify each major project as "builds moat", "operational excellence", or "table stakes." Most teams will find that very little of the roadmap explicitly builds moat. This is the conversation worth having with leadership.
+
+## Recap & next
+
+- Five moat types - network effects, switching costs, scale economies, data/learning, brand - cover almost all software cases.
+- Real moats show up in the financials: stable margins, high NRR, low churn, S&M efficiency.
+- Engineering excellence is necessary but rarely a moat; structural advantage usually comes from systems and decisions, not from execution speed.
+- Compounding moats - multiple types reinforcing each other - are the most durable.
+
+Next, **Disruption theory and the innovator's dilemma** - why the strongest companies with the best moats still get blindsided.
+{% endraw %}
diff --git a/_courses/engineers-mba/02-strategy/03-disruption-theory.md b/_courses/engineers-mba/02-strategy/03-disruption-theory.md
new file mode 100644
index 0000000..b175689
--- /dev/null
+++ b/_courses/engineers-mba/02-strategy/03-disruption-theory.md
@@ -0,0 +1,125 @@
+---
+chapter_id: 3
+chapter_slug: disruption-theory
+chapter_title: "Disruption theory and the innovator's dilemma"
+chapter_summary: "Explains Christensen's sustaining-vs-disruptive distinction, why rational incumbents predictably lose to disruptors, and the Jobs-to-be-Done lens. Notes the descriptive (not predictive) limits of the framework."
+---
+
+{% raw %}
+## What you'll learn
+- Christensen's distinction between *sustaining* and *disruptive* innovation, and why most innovation is sustaining.
+- The Jobs-to-be-Done lens and why "the customer hires the product" is a useful reframe.
+- Two flavours of disruption - *low-end* and *new-market* - and how to recognise each.
+- Why rational, well-run incumbents predictably lose to disruptors, and the structural limits of the theory.
+
+## Concepts
+
+Clayton Christensen's [*The Innovator's Dilemma*](https://www.amazon.com/Innovators-Dilemma-Revolutionary-Change-Business/dp/0062060244) is the most-cited business book engineers actually read. It explains a specific puzzle: why do *well-managed* companies - companies doing everything textbooks say to do - get crushed by entrants offering worse products? The disk-drive industry was Christensen's original case; software is full of replays.
+
+### Sustaining vs. disruptive innovation
+
+**Sustaining innovation** makes the existing product *better along the dimensions the existing customers value*. It's the bulk of innovation in any industry. Incumbents are very good at sustaining innovation because their organisations, customers, and processes are optimised around it.
+
+**Disruptive innovation** changes the dimensions of competition. It's typically *worse* on the dimensions existing customers care about (performance, features, scale) but *better* on dimensions those customers don't yet value enough to pay for (price, simplicity, accessibility).
+
+The trap: when a disruptor enters, the incumbent rationally dismisses it. The product is worse on every metric the incumbent measures. Existing customers don't want it. The disruptor's margins look terrible. By the time the disruptor's product is good enough that the incumbent's customers start defecting, it's too late.
+
+Software examples:
+
+| Disruptor | Disrupted | Initially worse at | But eventually better at |
+|---|---|---|---|
+| Linux | Solaris/AIX | Performance, support quality | Cost, accessibility, ecosystem |
+| Salesforce | Siebel | Customisation, on-prem control | Cost, deployment speed, accessibility |
+| Slack | Email, IRC | Search, archive durability | Real-time UX, threading, ecosystem |
+| Figma | Sketch / Adobe | Single-user power features | Multi-user collaboration |
+| Notion | Confluence + databases | Performance, formality | Flexibility, ease of use |
+
+In each case, the disruptor's product was visibly worse for the incumbent's top customers. The disruptor served *non-consumers* or low-end customers the incumbent didn't fight for. Then the disruptor improved fast enough to climb upmarket - and the incumbent's customers started defecting.
+
+### Why incumbents predictably lose
+
+Christensen's deepest insight is that incumbents fail *rationally*. The asymmetry isn't about smart vs. dumb companies.
+
+1. **Resource allocation favours the highest-margin opportunities**. The disruptor's market is small and low-margin; the incumbent's resource-allocation process correctly rejects it.
+2. **Customer feedback is biased toward sustaining innovation**. Existing customers want what they have, only better. They don't ask for a product that ignores their priorities.
+3. **Cost structure rules out competing on price**. Once the incumbent has high-margin enterprise customers, restructuring for a lower-margin business is organisationally impossible.
+4. **Disruptors improve faster than the incumbent's customers' needs grow**. The disruptor's "worse" product eventually becomes "good enough" for the incumbent's customers.
+
+When the incumbent finally responds, it's typically by:
+- Trying to embed disruption into its existing business model (fails because the cost structure is wrong)
+- Acquiring the disruptor (works only if the acquired entity is left alone)
+- Building a separate business unit (rarely works because corporate processes leak in)
+
+### Jobs-to-be-Done
+
+A complementary lens, also from Christensen. Customers don't buy products for their attributes - they *hire* products to do a *job*. The job is consistent over time; the products that do it change.
+
+Classic example: the milkshake job. McDonald's discovered that morning milkshakes weren't competing with other milkshakes - they were competing with bagels, bananas, and coffee for the "I need something to occupy a long commute and tide me over until lunch" job. Once you see the job, you redesign the product around it.
+
+For software: a B2B team isn't really "buying project-management software." They're hiring a tool to do the job of "keep multiple stakeholders aligned without me having to chase them." Slack, email, Notion, a Google Doc, and Jira are all candidates. The category your competitor is in may not be the category the *customer* sees you in.
+
+### Low-end vs. new-market disruption
+
+Two distinct types:
+
+**Low-end disruption** - the disruptor enters at the bottom of the existing market, offering a cheaper, simpler product to customers the incumbent over-serves. Toyota's entry into the US auto market began here.
+
+**New-market disruption** - the disruptor brings the product to non-consumers, growing a market that didn't exist. Personal computers vs. mainframes; Squarespace vs. handwritten letters to a web designer.
+
+The two have different implications. Low-end disruption threatens the incumbent's existing revenue. New-market disruption grows the pie and pulls customers from non-consumption. Both can eventually climb upmarket and threaten the incumbent's core.
+
+### Limits of the theory
+
+Disruption theory is descriptive in retrospect and often wrong predictively. The Apple iPhone, often called "disruptive," was actually a high-end sustaining innovation in a new category - entered from the top, not the bottom. Many "disruptors" don't disrupt. Many incumbents survive disruption (Microsoft survived multiple cycles).
+
+Practical use: the theory is a *lens* for thinking about which threats to take seriously. It correctly flags the under-noticed entrant. It doesn't tell you which entrant will win.
+
+## Walkthrough
+
+A worked diagnostic: identify disruption signals in your industry.
+
+For a B2B SaaS observability company (say, Datadog), the questions to ask:
+
+1. **Is there a low-cost entrant serving customers we're ignoring?** *Yes* - Prometheus + Grafana stack serves cost-conscious teams Datadog over-serves.
+2. **Is the cheap entrant's product improving faster than our customers' needs?** *Maybe* - managed Prometheus (e.g. Grafana Cloud) is closing the operational-cost gap.
+3. **Is our cost structure compatible with competing on price?** *No* - Datadog's per-host pricing depends on enterprise-margin economics.
+4. **Are there new-category entrants serving non-consumers?** *Yes* - AI-native observability and unified developer-experience tools target teams that previously couldn't afford full observability.
+5. **What's our response?** Datadog has answered with product breadth (Module 2 Chapter 1's note on rivalry) and acquisitions, plus moves into adjacencies the disruptors don't yet serve.
+
+This kind of analysis won't predict the winner. It will help you spot the threats that look small now and matter later. The same exercise is worth running on every major product line in your company.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  inc[Incumbent: high-margin core] -->|sustaining innovation| more[Better products for top customers]
+  disruptor[Disruptor: low-end or new market] -->|fast improvement curve| upmarket[Climbs upmarket]
+  upmarket -->|threatens core| inc
+  inc -->|cost structure unable to compete| trapped[Trapped by own success]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Calling any new entrant "disruptive" | The word is overused | A new entrant that competes on the *same* dimensions is sustaining, not disrupting. |
+| Predicting which disruptor will win | Theory is descriptive, not predictive | Use it to identify *threats worth watching*, not to pick winners. |
+| Dismissing disruptors because of margin or scale | That's exactly the trap | Track the rate of improvement, not the absolute starting point. |
+| Building a separate business unit and integrating it | Corporate gravity pulls it back | If you spin up an internal disruptor, give it real autonomy or it dies. |
+| Confusing JTBD with personas | Different mental models | JTBD is about the *job*; personas are about the *person*. Customers can have multiple jobs. |
+
+## Exercises
+
+1. Identify a disruptor in your own product's category. Note where it's "worse" today and where it's improving fastest. Estimate the rate of improvement vs. the rate at which your customers' needs grow.
+2. Pick a famous "disrupted" incumbent (Blockbuster, Kodak, BlackBerry, Sun Microsystems). Re-read its strategic mistakes through Christensen's lens - what would have been the rational disruptor response? Note that almost none of them tried it.
+3. For your team's roadmap, classify each project as *sustaining* (better for existing customers) or *disruptive* (worse on current dimensions, better on new ones). Most engineering teams will find ~95% of their work is sustaining. That's normal - but worth knowing.
+
+## Recap & next
+
+- Sustaining innovation improves the product on existing dimensions; disruptive innovation changes the dimensions.
+- Incumbents lose to disruptors *rationally* - their cost structure, customer feedback, and resource allocation all push them away from the disruptor's market.
+- Jobs-to-be-Done is a complementary lens: customers hire products for jobs, not for features.
+- Disruption theory is more useful as a watch-list filter than as a predictor.
+
+Next, **Build / Buy / Partner - the strategic version** - when to acquire, when to integrate, when to build, with worked M&A examples.
+{% endraw %}
diff --git a/_courses/engineers-mba/02-strategy/04-build-buy-partner.md b/_courses/engineers-mba/02-strategy/04-build-buy-partner.md
new file mode 100644
index 0000000..a23671d
--- /dev/null
+++ b/_courses/engineers-mba/02-strategy/04-build-buy-partner.md
@@ -0,0 +1,179 @@
+---
+chapter_id: 4
+chapter_slug: build-buy-partner
+chapter_title: "Build / Buy / Partner - the strategic version"
+chapter_summary: "Frames the strategic build/buy/partner question through three M&A rationales (capability, market, time-to-market) and explores integration risk. Uses Stripe/Paystack and Atlassian/Trello as worked examples of preserve-autonomy integration."
+---
+
+{% raw %}
+## What you'll learn
+- The three strategic rationales for M&A: capability, market, and time-to-market.
+- How to assess integration risk and culture fit honestly before approving an acquisition.
+- When partnerships are the right answer instead of acquisition or build.
+- Why most engineering "build vs. buy" debates ignore the strategic version of the question.
+
+## Concepts
+
+Engineers think of "build vs. buy" as a vendor decision - should we adopt a SaaS tool or write our own? The strategic version is the same question one level up: when a company needs a new capability or market, does it *build* it organically, *buy* a company that has it, or *partner* with someone who does?
+
+The answer depends on three dimensions: how strategic is the capability, how scarce is the talent, and how compressed is the timeline. Get any of these wrong and you spend years and hundreds of millions.
+
+### Why companies acquire
+
+Three primary rationales:
+
+**1. Capability acquisition.** The acquirer wants a technology, talent pool, or product the target has built. The classic case is "acqui-hire" - buying a struggling startup for its engineers. The strategic version: buying a company because it built something the acquirer can't reasonably replicate in a useful timeframe.
+
+Examples: Microsoft acquiring GitHub (2018, $7.5B) for the developer community and developer tools market presence. Atlassian acquiring Trello (2017, $425M) for a consumer-grade product the enterprise-focused Atlassian had no DNA to build.
+
+**2. Market access.** The acquirer wants to enter a new market - geographic, customer segment, or industry - and the target is established there.
+
+Examples: Stripe acquiring Paystack (2020) for African market entry. Salesforce acquiring Slack (2021, $27.7B) to enter the collaboration market and reach end-user buyers Salesforce doesn't typically sell to.
+
+**3. Time-to-market.** The acquirer could build the thing but the time to do so exceeds the strategic window. Buying is faster than building.
+
+Examples: Facebook acquiring Instagram (2012, $1B) - Facebook had the engineering to build a photo app but couldn't bootstrap the network effect. Cisco's serial acquisitions of networking startups throughout the 2000s - each "build vs buy" answered in favour of buy because the technology window was closing.
+
+A fourth, less honourable rationale exists: **defensive acquisition** - buying a competitor to prevent it from threatening you. Sometimes legitimate, sometimes regulator-flagged. Facebook's WhatsApp acquisition (2014, $19B) had elements of all four rationales.
+
+### Integration risk
+
+This is where most acquisitions fail. The acquired company's value usually depends on people, culture, and momentum - all of which acquisitions tend to break.
+
+| Risk | What goes wrong | Mitigation |
+|---|---|---|
+| Key-person flight | Founders leave after earn-outs | Long earn-outs, equity retention, autonomy preservation |
+| Culture clash | Acquired team rejects acquirer's processes | Maintain separate operations longer than feels comfortable |
+| Roadmap disruption | Acquirer reprioritises the target's product | Lock down a 12-month roadmap as part of the deal |
+| Customer attrition | Acquired customers worry about being deprecated | Strong public commitments; rapid product investment signals |
+| Technical debt accumulation | Migrations and re-platforming take years | Budget realistically; expect 2-3x the initial estimate |
+
+McKinsey research and post-mortems on hundreds of deals converge on a depressing baseline: most acquisitions don't create value for the acquirer. The successful ones share a few traits - clear strategic rationale, preserved autonomy, retained leadership, and a board-level integration discipline.
+
+### Build vs. buy: the strategic question
+
+The strategic build vs. buy question is *not* "what's cheaper?" It's "what's the cost of being late?"
+
+Build cost = $X engineering investment + ($X × n quarters delay) × opportunity cost.
+
+Buy cost = Acquisition price + integration cost + integration risk × probability of failure.
+
+For a non-strategic capability, build is often correct. For a strategically critical capability with a closing window, buy is often correct. The fatal misreading is to estimate build cost as just the engineering work, ignoring time-to-market and opportunity cost.
+
+Engineers reflexively favour build. Their value system (technical purity, autonomy, control) and incentive structure (visible work, technical reputation) both point that way. Sometimes the build is right; sometimes the team needs a senior counterweight reminding them that *not building* is also an option.
+
+### Partnership as a third option
+
+A partnership splits the difference: the company gets the capability without owning it. Common forms:
+
+- **OEM / white-label** - embed the partner's product into yours, sometimes with cobranding.
+- **Reseller** - sell the partner's product through your sales motion.
+- **Strategic integration** - deep API integration, joint product development, shared customers.
+- **Marketplace listing** - partner's product available through your platform.
+
+When partnerships make sense:
+
+- The capability is non-strategic, but customers want it.
+- The capability would distract engineering from core work.
+- Multiple partners can serve the same need (avoiding lock-in).
+- The cost of acquisition is high relative to the strategic value.
+
+When partnerships go wrong:
+
+- Strategic conflicts emerge (the partner becomes a competitor).
+- Joint customers blame both parties for issues.
+- The partnership becomes "table stakes" and the partner extracts rent.
+- Integration debt accumulates and no one wants to own it.
+
+Stripe's relationships with banks and card networks are partnership-heavy. AWS's relationships with the consulting partners (Accenture, Deloitte) are partnership-heavy. Most successful platforms operate on a mix of build and partner.
+
+### A worked decision
+
+You're a CTO. Customer demand is rising for an AI feature inside your B2B product. Three options:
+
+```text
+Build internally (12 months, $5M):
+- Strategic control
+- Aligned with existing stack
+- 12-month delay before customers see anything
+
+Acquire AI startup (close in 3 months, $50M):
+- Immediate capability
+- Risk of integration failure
+- Talent retention risk
+
+Partner with foundation-model provider (deploy in 2 months, $300k/year):
+- Fastest to market
+- No long-term moat
+- Partner pricing risk
+```
+
+The right answer depends on:
+
+- Strategic importance: if this becomes the company's defining capability, build or buy.
+- Timeline pressure: if the market is moving in months, partner first, then build/buy in parallel.
+- Cash position: $50M acquisitions look very different at $200M ARR vs $20M ARR.
+- Existing AI talent: if you can't hire, partner; if you can, build.
+
+In practice, many companies execute all three sequentially: partner now to unblock customers, build a thin layer to test commitment, buy if it becomes strategically central.
+
+## Walkthrough
+
+Two real examples, contrasted.
+
+### Stripe acquiring Paystack (2020)
+
+**Rationale:** Market access. Stripe wanted Africa; Paystack was the leading payments processor in Nigeria with a strong product.
+
+**Integration approach:** Preserved Paystack's brand, leadership, and product autonomy. Paystack still operates under its own name, with its own leadership, on its own stack.
+
+**Outcome:** Considered a strong acquisition. Paystack's footprint grew; Stripe entered Africa without building it internally; the brand still has trust in market. The structural choice was: market entry capability > brand consolidation.
+
+### Atlassian acquiring Trello (2017, $425M)
+
+**Rationale:** Capability and customer base. Trello had a beloved consumer-grade kanban product with a self-serve, freemium motion. Atlassian wanted to expand from enterprise project management down into smaller teams and individual users.
+
+**Integration approach:** Preserved Trello as a separate product with its own product team. The "Atlassian Trello" rebrand happened but the product retained its identity. Trello continues to operate alongside Jira, with overlap but not consolidation.
+
+**Outcome:** Cited as a successful acquisition. The cultural and product autonomy preservation has been credited as the reason - Atlassian resisted the temptation to fold Trello into Jira. The lesson: when you acquire a culture-driven product, the value depends on letting the culture continue.
+
+Both cases share a common factor: the acquirer didn't try to absorb the target. The opposite pattern - try to "integrate fully" - usually destroys value. Marissa Mayer's Yahoo era acquisitions (Tumblr, Polyvore, dozens more) are the canonical anti-examples.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  need[Strategic capability gap] --> question{Is this strategic?}
+  question -->|Yes, urgent| buy[Buy / acquire]
+  question -->|Yes, not urgent| build[Build organically]
+  question -->|Not strategic| partner[Partner / OEM / SaaS]
+  buy --> risk[Integration risk: people, culture, roadmap]
+  build --> time[Time-to-market risk]
+  partner --> dep[Dependency risk]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Estimating build cost as just engineering work | Engineers count salaries, not opportunity cost | Include time-to-market lost revenue and opportunity cost. |
+| Acquiring and immediately integrating | "We bought it; let's optimise" | Preserve autonomy for 12–24 months minimum; resist the urge. |
+| Treating partnerships as table stakes | Partner becomes critical, then expensive | Build a "what if this partner doubles their price?" contingency. |
+| Acquihiring for technology | Talent flees in 18 months | Buy the company; preserve the team; build retention into the deal. |
+| Letting engineering dominate the framing | "We could build this" doesn't address strategic timing | Force the question: "if we don't ship by X, what's lost?" |
+
+## Exercises
+
+1. List the last three acquisitions your company made (or major OSS dependencies adopted). For each, identify which of the three rationales (capability, market, time-to-market) was operative. Then evaluate the integration outcome.
+2. Pick a recent failed acquisition in tech (e.g. Slack into Salesforce so far, or Yahoo into anything). Read coverage and identify which integration risk dominated.
+3. For your team's next "build vs. buy" decision, write out the strategic build-cost (including time-to-market) and partner cost. Most teams discover the partner option is dramatically cheaper than the build option once opportunity cost is included.
+
+## Recap & next
+
+- Three primary M&A rationales: capability, market access, and time-to-market. Plus defensive.
+- Integration risk dominates outcomes. Successful acquisitions usually preserve autonomy.
+- The strategic build cost includes time-to-market and opportunity cost - not just engineering salaries.
+- Partnerships are a powerful third option, especially for non-strategic capabilities and fast-moving markets.
+
+Next, **Strategy as a portfolio: the three horizons** - how leadership balances core, adjacent, and transformative bets without strangling either.
+{% endraw %}
diff --git a/_courses/engineers-mba/02-strategy/05-strategy-as-portfolio.md b/_courses/engineers-mba/02-strategy/05-strategy-as-portfolio.md
new file mode 100644
index 0000000..873298a
--- /dev/null
+++ b/_courses/engineers-mba/02-strategy/05-strategy-as-portfolio.md
@@ -0,0 +1,152 @@
+---
+chapter_id: 5
+chapter_slug: strategy-as-portfolio
+chapter_title: "Strategy as a portfolio: the three horizons"
+chapter_summary: "Introduces McKinsey's three horizons and the 70/20/10 allocation heuristic. Identifies the dominant failure modes - over-investing in H1, applying H1 metrics to H3, confusing H2 for H3 - and how to read portfolio allocation from public financials."
+---
+
+{% raw %}
+## What you'll learn
+- McKinsey's three-horizons framework - core, adjacent, transformative - and what each one means in practice.
+- How exec teams allocate capital and engineering across horizons (the 70/20/10 rule and its variants).
+- The portfolio failure modes - under-investing in H2/H3, killing transformative bets prematurely, starving the core.
+- How to read a company's strategy and identify which horizons are funded vs. neglected.
+
+## Concepts
+
+A company's strategy isn't *one* bet - it's a portfolio. Different bets have different time horizons, risk profiles, and return shapes. The job of the exec team is to balance them. The framework that dominates real strategy meetings is McKinsey's *three horizons*, popularised in the 1999 book [*The Alchemy of Growth*](https://www.amazon.com/Alchemy-Growth-Practical-Insights-Building/dp/0738203092).
+
+### The three horizons
+
+**Horizon 1 (H1) - Defend and extend the core.** The business that makes money today. Most engineering work, most capital, most management attention. Time horizon: 0–18 months. Return profile: predictable, near-term.
+
+**Horizon 2 (H2) - Build emerging businesses.** Adjacencies that build on the core but address new customers, segments, or products. Time horizon: 18 months–3 years. Return profile: medium uncertainty, medium scale.
+
+**Horizon 3 (H3) - Create new businesses.** Genuinely new bets - new markets, new technologies, transformative ideas that could become future cores. Time horizon: 3+ years. Return profile: high uncertainty, potentially transformative.
+
+The classic illustration is Amazon. AWS started as an H3 bet in the early 2000s, became an H2 business through the 2010s, and is now the H1 profit engine. Retail was H1 in 2005; Prime was H2; the now-flat retail business is mature H1. Alexa and Amazon Ads have been H2/H3 in different phases.
+
+### Why the three-horizon framing matters
+
+The framework's value is that it forces the conversation: *what's the right mix of bets across time?*
+
+The dominant failure modes:
+
+**Over-investing in H1.** The company gets so good at optimising the core that it can't allocate capital or talent to new bets. By the time the core matures, there's nothing to take its place. Microsoft in the 2000s is the canonical case - strong Windows/Office monopoly, almost nothing in H2/H3 for a decade. Their recovery under Satya Nadella required brutal reallocation.
+
+**Starving the core for "innovation."** The opposite failure. The company gets infatuated with H3 narratives and lets the core deteriorate. Yahoo throughout the 2010s.
+
+**Killing H3 too early.** H3 bets look terrible on conventional metrics - low revenue, no profitability, uncertain TAM. The H1 finance discipline applied to H3 bets kills them. Most large-company H3 efforts die in their second year because they can't beat H1 ROI hurdles.
+
+**Confusing H2 for H3.** Adjacent products that extend the core (H2) get rebranded as "new businesses" to justify investment. The strategy then claims H3 ambition without actually allocating to genuinely new bets.
+
+### The 70/20/10 rule (and its variants)
+
+A common allocation heuristic: 70% of resources to H1, 20% to H2, 10% to H3. Google formalised this internally under a similar rule. It's a *starting point*, not a law - actual allocations should reflect competitive position, life-cycle stage, and capital availability.
+
+A startup with one product might be 100% H1 by necessity. A late-stage public company with declining growth might shift to 50/30/20. The point is to *consciously* choose the allocation rather than letting H1 default to 95%.
+
+### Different metrics for different horizons
+
+A persistent organisational mistake: applying H1 metrics to H2/H3 bets.
+
+| Horizon | Right metrics | Wrong metrics (the ones used by default) |
+|---|---|---|
+| H1 | Revenue, margin, retention, market share | Same - work fine here |
+| H2 | Cohort growth, customer acquisition, product-market-fit signals | Revenue, profitability |
+| H3 | Learning, validated assumptions, optionality, key risk reduction | Revenue, ROI, payback period |
+
+H3 bets shouldn't be measured on revenue. They should be measured on *what they teach you* and *what optionality they preserve*. The maturity test is: did we learn what we needed? Did we de-risk the critical unknown?
+
+The most successful H3 efforts (AWS, Google Cloud Platform, GitHub Copilot before launch) had patron-style leadership at the exec level who shielded them from H1 metrics during their early years.
+
+### How engineering work distributes across horizons
+
+A useful exercise: classify your team's roadmap by horizon.
+
+| Type of work | Typical horizon |
+|---|---|
+| Reliability improvements to the main product | H1 |
+| New features for existing customers | H1 |
+| Adjacent product launches | H2 |
+| Migration to a new platform | H1 (despite feeling like H2) |
+| Technical debt paydown | H1 (it's defending the core) |
+| Internal platform/dev-velocity work | H1 (despite engineering's love of it) |
+| Pilots with non-customers, new segments | H2 or H3 |
+| Genuinely speculative new-tech R&D | H3 |
+| Acquihires of pre-revenue startups | H3 |
+
+Most engineering teams find their roadmap is ~95% H1. This isn't necessarily wrong - H1 should be the largest bucket - but it's worth knowing. If the company aspires to do anything transformative, somewhere there's an engineering team working on H3, and it's worth identifying who.
+
+### Reading a company's portfolio from the outside
+
+Public companies disclose enough to estimate horizon allocation. Look for:
+
+- **R&D breakdown by segment** in 10-K filings. If 90% goes to one segment, the company is H1-dominant.
+- **Acquired companies and their integration status.** Standalone acquisitions are often H2/H3 placeholders.
+- **Earnings call language.** Phrases like "our second growth engine" or "long-term bets" signal H2/H3 emphasis.
+- **Capex patterns.** Capital spending on new data centres, new manufacturing, new geographies signals H2/H3 commitments.
+
+A company whose narrative claims H2/H3 ambition but whose R&D and capex flows are 95% H1 is in a mismatch between strategy and resource allocation. This is one of the more common patterns and an early warning sign.
+
+## Walkthrough
+
+A worked example. Hypothetical "Cloudish" SaaS company allocates roughly:
+
+```text
+H1 - defend & extend core (subscription SaaS): 80% of R&D, 90% of S&M
+H2 - usage-based platform product: 15% of R&D, 8% of S&M
+H3 - AI-native developer experiences: 5% of R&D, 2% of S&M
+```
+
+The allocation looks reasonable on paper - 80/15/5 is in the 70/20/10 neighbourhood. But:
+
+- **H2 R&D allocation includes the migration of the core to a new architecture.** That's actually H1 work disguised as H2. Real H2 work might be only 5%.
+- **The H3 product has been "in incubation" for 18 months with no shipping deadline.** Without ship pressure, H3 bets stagnate.
+- **The CEO mentions H2 in every earnings call but H1 retains 95% of executive attention.** Patron-style sponsorship is missing.
+
+The corrective questions for the exec team:
+
+1. *What would have to be true for H2 to grow to $50M ARR in 24 months?* If no plan exists, H2 isn't really funded - it's marketing.
+2. *Who is the H3 patron at the exec level?* If no one owns it, it will starve.
+3. *What's our kill criteria for H3?* If there isn't one, the bet can never be wound down honourably.
+
+These are the kinds of questions a Staff+ engineer or tech lead can ask in strategy reviews. They're rarely framed in horizon language but they're the same question underneath.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  h1[H1: defend core] -->|cash, scale| funding[Pool of capital and talent]
+  funding --> h2[H2: build adjacent businesses]
+  funding --> h3[H3: create new businesses]
+  h2 -->|over time| h1
+  h3 -->|over time| h2
+  h2 -.maturity transitions.-> h1
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Letting H1 default to 95%+ | H1 always has measurable urgency; H2/H3 don't | Allocate H2/H3 *explicitly* in capacity planning. |
+| Applying H1 metrics to H3 | Defaults of the finance org | H3 measured on learning, not revenue. |
+| Confusing H2 for H3 | Marketing pressure to claim innovation | Pin down what would make this bet succeed; if it requires only the existing core capability, it's H2 not H3. |
+| Killing H3 in year two | "It hasn't shown ROI" | Define a kill-criterion at start: learning milestone, not revenue milestone. |
+| Calling internal platform work H2/H3 | Engineers like it that way | Internal dev-velocity work is H1 - it's defending the core. |
+
+## Exercises
+
+1. For your own employer, classify the top 5 product lines or major initiatives by horizon. Then estimate the resource allocation. Note where the allocation diverges from what leadership says publicly.
+2. Pick a public company (Amazon, Microsoft, Atlassian) and try to reconstruct their three-horizon allocation from their 10-K, earnings calls, and acquisitions. Note the gap between rhetoric and resource flow.
+3. For your team's roadmap, classify each item by horizon and report the distribution. Discuss with your manager what the ratio "should" be given the company's strategic position. The conversation alone is usually valuable.
+
+## Recap & next
+
+- Strategy is a portfolio of bets across time horizons - H1 (core, 0–18mo), H2 (adjacent, 18mo–3yr), H3 (new businesses, 3yr+).
+- The 70/20/10 allocation is a heuristic; actual allocation should reflect competitive position.
+- The dominant failure modes are over-investing in H1, applying H1 metrics to H3, and confusing H2 for H3.
+- Reading the gap between portfolio rhetoric and actual resource flow is one of the most useful exec-fluency skills an engineer can develop.
+
+Next, kicking off **Module 3 - Markets, Customers & Go-To-Market**, starting with **Segmentation, ICP, and Jobs-to-be-Done**.
+{% endraw %}
diff --git a/_courses/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.md b/_courses/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.md
new file mode 100644
index 0000000..1e1aa4c
--- /dev/null
+++ b/_courses/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.md
@@ -0,0 +1,167 @@
+---
+chapter_id: 1
+chapter_slug: icp-and-jtbd
+chapter_title: "Segmentation, ICP, and Jobs-to-be-Done"
+chapter_summary: "Distinguishes three segmentation axes (firmographic, technographic, behavioural), defines ICP vs persona, and introduces Jobs-to-be-Done. Shows how aspirational ICPs cause roadmap fragmentation and how a crisp ICP resolves arguments."
+---
+
+{% raw %}
+## What you'll learn
+- The three classical bases of market segmentation - firmographic, technographic, behavioural - and when each one matters.
+- What an Ideal Customer Profile (ICP) actually is, and how it differs from a persona.
+- The Jobs-to-be-Done lens and why it consistently outperforms feature/persona thinking.
+- How engineering decisions get warped when the ICP isn't crisp.
+
+## Concepts
+
+Market segmentation is the discipline of dividing a heterogeneous market into groups with similar needs. Every meaningful conversation about product, pricing, positioning, or GTM resolves down to segmentation. "Who are we for?" is the foundational question - and "everyone" is the answer that has bankrupted more startups than any other.
+
+### The three classical segmentation axes
+
+**Firmographic.** Properties of the *company*: industry, size, geography, regulatory regime, public/private status. For B2B SaaS this is usually the primary axis. "Mid-market SaaS companies in financial services in North America" is a firmographic segment.
+
+**Technographic.** Properties of the *technology stack*. Which cloud provider, which language, which CRM, which competing tool they're currently using. Datadog segments heavily on technographic data because their product complements or replaces specific stacks. "Companies running Kubernetes in production" is a technographic segment.
+
+**Behavioural.** Properties of how the customer *behaves* - engagement levels, growth trajectory, hiring patterns, recent funding events. "Series A startups that just hired their first VP of Engineering" is a behavioural segment.
+
+Sophisticated GTM teams blend all three. A great target list for an enterprise security product might be: *firmographic* (regulated industries, US-based, $500M+ revenue) × *technographic* (running their own k8s) × *behavioural* (recent security incident or compliance audit).
+
+### Ideal Customer Profile (ICP)
+
+The ICP is the firmographic + technographic + behavioural description of the customer the product is *best for* - the customer the GTM motion is optimised to reach and the product is optimised to delight.
+
+A good ICP is *narrow*. Not "B2B SaaS companies" but "B2B SaaS companies with 50–500 engineers, between Series B and pre-IPO, using AWS, who have a dedicated platform team." The narrowness is the point: it tells everyone in the company who to chase and (more importantly) who not to chase.
+
+The most common ICP mistake is to make it aspirational rather than diagnostic. "We want to sell to the Fortune 500" is an aspirational ICP. "We win 35% of the deals we run against [Competitor X] in regulated industries with 200+ engineers" is a diagnostic ICP - it tells you where you actually win.
+
+Test for a real ICP: can your CEO and your most junior salesperson independently describe the same one in a sentence? If not, the ICP isn't operational.
+
+### ICP vs. persona
+
+These get confused constantly. They're different.
+
+**ICP** describes the *company* you sell to.
+
+**Persona** describes the *individual person* who participates in the buying decision - economic buyer, technical buyer, champion, end user.
+
+A product can have one ICP and multiple personas. The technical buyer (a director of platform engineering) cares about API ergonomics and runtime cost; the economic buyer (a VP/CIO) cares about TCO and integration risk; the end user cares about ergonomics. Marketing typically targets the technical buyer + champion; sales handles the economic buyer; product designs for the end user. Different content, different conversations, all within the same ICP.
+
+### Jobs-to-be-Done
+
+The Jobs-to-be-Done (JTBD) lens, from Christensen and Bob Moesta, asks: *what job did the customer hire this product to do?* The job is consistent over time and across customers; the products that do it change.
+
+A useful JTBD statement has the form:
+
+```text
+When [situation], I want to [motivation], so I can [expected outcome].
+```
+
+For example, a marketing manager evaluating a CRM:
+
+```text
+When my pipeline reviews are pulled from spreadsheets every week, I want a system that auto-aggregates from email and meeting notes, so I can spend more time on strategy than data entry.
+```
+
+The job is "free up time from manual aggregation." The candidate solutions could be: a CRM, a workflow tool, an AI assistant, an admin hire. The customer evaluates all of them on how well they perform the job.
+
+Why JTBD beats personas:
+- **Personas have demographics**; jobs have desired outcomes.
+- **Personas overlap with competitors**; jobs cut across categories.
+- **Personas are static**; jobs change with situation.
+- **Personas hide substitution threats** (competitors with similar personas); jobs expose them (any product that does the job competes).
+
+### Segmentation traps
+
+The most common ways segmentation breaks:
+
+| Trap | Why it happens | Cost |
+|---|---|---|
+| Too-broad ICP | "We don't want to limit ourselves" | Every team optimises for a different customer; product, marketing, sales misalignment. |
+| Aspirational ICP | "We *want* to be enterprise" | Engineering builds features for nobody. The product never wins anyone. |
+| Confused ICP vs. persona | Misuse of terms | Marketing builds for the buyer; sales targets the wrong companies. |
+| One ICP, multiple ICPs in practice | Different segments slip in via sales | Resource allocation gets fragmented; no segment served well. |
+| Ignoring JTBD | "Customer journey" replaces "job" | The product gets built around persona attributes, not outcomes. |
+
+### Why engineers should care
+
+Engineers feel ICP confusion structurally. The signs:
+
+- Roadmap whiplash: one quarter you're building for SMB, next quarter for enterprise.
+- Feature creep: every customer request is a "yes" because every customer is the ICP.
+- Performance trade-offs that don't make sense: optimising for a workload that's not the target customer's workload.
+- Disagreements about API design that are really disagreements about who the API is for.
+
+A crisp ICP is the single most powerful tool for resolving roadmap arguments. "We're not building that because Y customers don't use it that way" only works if everyone agrees who Y is.
+
+## Walkthrough
+
+A worked example. You're an engineer at a B2B SaaS company. The CEO says the ICP is "growing SaaS companies." That's not operational. Drill down:
+
+```text
+Phase 1 - firmographic:
+  Industry: SaaS / digital-native services
+  Size: 50–1000 employees, 15–200 engineers
+  Revenue: $5M-$50M ARR
+  Geography: US, Canada, UK initially
+  Funding stage: Series B through pre-IPO
+
+Phase 2 - technographic:
+  Cloud: AWS or GCP (90% of pipeline)
+  Container orchestration: production Kubernetes
+  Existing stack: at least one of [Datadog, New Relic, Honeycomb]
+  Identity: Okta or Auth0
+  CI/CD: GitHub Actions or CircleCI
+
+Phase 3 - behavioural:
+  Has a dedicated platform team (3+ engineers)
+  Recent hire of VP of Eng, DevOps lead, or Platform lead
+  At least one engineering blog post in last 12 months
+  Active in OSS or developer community
+
+Jobs-to-be-done:
+  When deploying changes to production frequently, our platform
+  team wants a deployment system that surfaces risk before it
+  reaches customers, so we can move fast without on-call shame.
+```
+
+This ICP is operational. A salesperson can build a list. A marketer can write copy. An engineer can prioritise features. A founder can pass on a poorly-fitting deal without internal debate.
+
+Now flip it: imagine the same product trying to sell to "any company with a website." The roadmap fragments, marketing fragments, sales fragments, and the product becomes a worse version of three different things.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  market[Total addressable market] --> seg[Segmentation: firmo + techno + behavioural]
+  seg --> icp[ICP: the segment you win]
+  icp --> personas[Personas: people in the buying decision]
+  icp --> jtbd[Jobs-to-be-Done: outcomes the product enables]
+  personas --> msg[Marketing & sales messaging]
+  jtbd --> roadmap[Product roadmap priorities]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Aspirational ICP | "We want to be enterprise" | ICP comes from where you win, not where you wish you won. |
+| ICP as a slogan, not a list | "Modern teams that move fast" | Force a sharable filterable list with concrete criteria. |
+| One ICP on paper, three in practice | Sales chases anything | Track ARR by segment, expose the gap, enforce alignment. |
+| Personas without JTBD | Demographics don't predict purchase | Add a "what job did they hire us to do" question to every persona doc. |
+| Ignoring TAM constraints | A perfectly defined ICP can be too small | Validate that the ICP at full saturation supports the company's growth ambition. |
+
+## Exercises
+
+1. Write down your company's stated ICP as you understand it. Then look at the customer list and identify the top 20% of customers by ARR. Are they consistent with the stated ICP? Most companies find the answer is "no" - the ICP is aspirational, not diagnostic.
+2. For your team's last 5 feature commitments, identify which ICP-segment justified each. If two consecutive commitments were for different segments, that's the ICP fragmentation problem in miniature.
+3. Take the JTBD framework. Pick one product you use daily and write the "When..., I want to..., so I can..." statement. Then list three alternative products that could perform the same job. Notice that the competitive set is broader than the marketing category.
+
+## Recap & next
+
+- Segmentation has three classical axes - firmographic, technographic, behavioural - that combine into an operational ICP.
+- The ICP describes the *company* you win; the persona describes the *individual* in the buying decision.
+- Jobs-to-be-Done captures *what the customer is trying to achieve*, which often crosses product categories.
+- A crisp ICP is the single most powerful tool for resolving roadmap arguments inside engineering.
+
+Next, **Positioning & narrative** - once you know who you're for, how do you tell them?
+{% endraw %}
diff --git a/_courses/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.md b/_courses/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.md
new file mode 100644
index 0000000..d71e45d
--- /dev/null
+++ b/_courses/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.md
@@ -0,0 +1,176 @@
+---
+chapter_id: 2
+chapter_slug: positioning-and-narrative
+chapter_title: "Positioning & narrative"
+chapter_summary: "Uses Dunford's five-component positioning canvas - competitive alternatives, unique attributes, value, best-fit customer, market category. Shows how engineering decisions silently encode positioning and when reframing beats category creation."
+---
+
+{% raw %}
+## What you'll learn
+- April Dunford's positioning canvas - the five components of a positioning statement that actually works.
+- The difference between features, benefits, value, and category - and why most product pages confuse them.
+- Category creation vs. category entry, and which one to attempt.
+- How engineering decisions encode positioning, often without anyone noticing.
+
+## Concepts
+
+Positioning is the act of locating your product in the customer's mind relative to the alternatives they're considering. It's not what you say in the headline - it's what the customer concludes about *what you are*, *who you're for*, and *why they should choose you over the alternatives*.
+
+Most B2B SaaS products are positioned badly. The symptoms: a homepage that lists features instead of value; a sales motion that struggles to qualify; a product roadmap pulled in three directions because no one agrees on the category. The fix is rarely "better copywriting" - it's usually the underlying positioning.
+
+April Dunford's [*Obviously Awesome*](https://www.aprildunford.com/obviously-awesome) gives the cleanest contemporary framework.
+
+### The Dunford positioning canvas
+
+Five components, in dependence order:
+
+**1. Competitive alternatives.** What does the customer do *today* if they don't buy you? This is the actual competition - often not other products in your category, but spreadsheets, in-house builds, or "doing nothing."
+
+**2. Unique attributes.** What does your product *have* that the alternatives don't? These are features, capabilities, integrations.
+
+**3. Value (and proof).** What outcomes do those attributes *enable* for the customer? Value statements should be specific and measurable.
+
+**4. Best-fit customer characteristics.** Which customers care most about the value? Translates back to ICP.
+
+**5. Market category.** What frame helps the customer make sense of the product? This is where most products go wrong - they pick the wrong category or invent a fake one.
+
+The order matters. You can't pick a category before you understand the alternatives; you can't claim value before you know what features support it; you can't define the best-fit customer before you know which value resonates.
+
+### Features → benefits → value → category
+
+A common confusion. The four are linked but distinct.
+
+| Layer | What it is | Example |
+|---|---|---|
+| Feature | A capability of the product | "Distributed tracing across services" |
+| Benefit | What the feature does for the user | "Find the source of latency spikes" |
+| Value | What the user can do because of the benefit | "Reduce mean-time-to-resolve from hours to minutes" |
+| Category | The frame the customer uses to understand the product | "Observability platform" |
+
+Engineers default to the first layer. Marketing defaults to the second. Good positioning lives in the third. Investors and customers think in the fourth.
+
+A homepage that says "the leading observability platform" without saying *what value* and *for whom* communicates nothing. A homepage that says "reduce MTTR by 70% for platform teams operating distributed systems" communicates everything.
+
+### Category strategy
+
+Three category-level choices:
+
+**1. Win in an established category.** Take an existing category (CRM, observability, payments) and beat incumbents on a specific dimension. Most products take this path. The challenge: you have to be better on a dimension the customer values *and* communicate that quickly.
+
+**2. Reframe an existing category.** Take the category but redefine its boundaries. Slack didn't say "we're a chat tool" - they said "we're channels for work," which reframed the category to include parts of email, IRC, and project management. Datadog reframed "infrastructure monitoring" into "observability." Reframing is hard but often more durable than head-to-head fighting.
+
+**3. Create a new category.** Tell the market that an entirely new category exists and you're the leader. HubSpot did this with "inbound marketing." Figma started by claiming "collaborative design" as a new category distinct from "design tools." Category creation is the highest-risk move - most attempts fail because no one buys "an unknown thing from a new vendor."
+
+The rule of thumb: only create a category if (a) the existing categories truly don't describe what you do, (b) you have the marketing budget to evangelise it, and (c) your sales motion can handle the educational overhead. Otherwise win or reframe an existing one.
+
+### Engineering decisions encode positioning
+
+This is the part engineers often miss. Many engineering decisions silently express positioning - and sometimes contradict the stated marketing.
+
+| Engineering decision | What it positions you as |
+|---|---|
+| Free tier exists; minimum paid plan is $20/user/month | Self-serve, mid-market, individual-buyer GTM |
+| No free tier; minimum is "contact sales" | Enterprise, top-down, multi-stakeholder GTM |
+| 100ms p99 latency; multi-region deployment | "Mission-critical infrastructure" |
+| 5-minute setup; minimal configuration | "Developer tool, plug and play" |
+| Detailed RBAC, audit logs, SSO/SAML | "Enterprise security-conscious buyer" |
+| Public API, OAuth, webhooks | "Platform, ecosystem-friendly" |
+| Open-source core, paid commercial extras | "Developer-friendly, open-core business" |
+
+If engineering builds a public API with a permissive license while marketing positions the company as "enterprise-grade with strict access controls," the inconsistency confuses customers. The product is doing one thing; the page says another. Usually the *engineering reality* wins because customers experience the product, not the page.
+
+### Positioning is reversible (but expensive)
+
+Many companies reposition over their lifecycle. Slack started as a B2B chat tool, repositioned around "channels for work," and is now repositioning under Salesforce as a "work operating system." Each reposition was driven by a recognised gap between what customers actually valued and what the product was sold as.
+
+Repositioning costs:
+- Website rewrites and brand work
+- Sales team retraining
+- Sometimes pricing/packaging changes
+- Some customer churn from confused or unhappy buyers
+- 12–24 months for the new positioning to settle
+
+A small repositioning is fine and often healthy. A major one - moving categories, moving up-market, changing personas - is a multi-quarter project for the whole company.
+
+## Walkthrough
+
+A worked positioning exercise for a hypothetical B2B SaaS company.
+
+**Product**: "Velora" - a SaaS tool that helps engineering managers visualise team throughput, bottlenecks, and on-call load.
+
+**Bad positioning attempt**:
+> "Velora is the leading engineering analytics platform. We help teams ship faster."
+
+This is useless. Every analytics platform claims this. The CEO and the engineering manager will close the tab.
+
+**Dunford-style positioning**:
+
+```text
+Competitive alternatives:
+  - Manual reporting in Looker / Tableau using Git + Jira data
+  - Linear's built-in cycle analytics
+  - "We don't measure this"
+
+Unique attributes:
+  - Pre-built correlations between deployment frequency and incident rate
+  - Direct GitHub Actions + PagerDuty integration
+  - Slack reports that summarise weekly trends
+  - On-call rotation analysis with burnout signals
+
+Value:
+  - Reduce time-to-insight from "weekly slack-and-spreadsheet ritual" to
+    "morning Slack digest"
+  - Catch burnout signals on individual engineers 2-3 weeks before
+    they're spoken aloud
+  - Defend engineering investment in 1:1s with VP Eng using throughput data
+
+Best-fit customer:
+  - 50-300 person engineering orgs
+  - Already on GitHub + Linear or Jira + PagerDuty
+  - Eng managers who own throughput goals, not just delivery
+
+Market category: "Engineering management analytics"
+  (notable: not "DevOps analytics" or "engineering productivity")
+```
+
+The positioning now does work. A user encountering it can quickly decide: *are we a match?* The features list is a means to an end (value); the category locates Velora; the alternatives confirm we're not selling to "anyone with engineers."
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  alternatives[Competitive alternatives] --> attrs[Unique attributes]
+  attrs --> value[Value enabled]
+  value --> icp[Best-fit customer]
+  icp --> cat[Category frame]
+  cat --> msg[Marketing message]
+  attrs --> roadmap[Engineering roadmap]
+  msg --> sales[Sales motion]
+  roadmap -.must reinforce.-> sales
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Picking the wrong competitive alternatives | Use the in-category set instead of what customers actually do | Talk to recent buyers about what they considered. |
+| Leading with features | Engineers wrote the homepage | Lead with value; relegate features to a section deeper in. |
+| Category creation when reframing would do | Marketing wants to look bold | Only create a category if the existing one is truly inadequate. |
+| Engineering decisions inconsistent with positioning | No one owns the alignment | A weekly check: does the product reality support the positioning? |
+| Repositioning quietly | "We'll update the page" | Treat major repositioning as a 6+ month cross-functional project. |
+
+## Exercises
+
+1. Take your company's homepage. Identify which Dunford components are present, which are missing, and which are in the wrong order. Most pages fail at the "competitive alternatives" step - they don't say *what you'd otherwise do*.
+2. List three engineering decisions made in the last year that silently changed (or reinforced) positioning. Examples: shipping SSO, adding a free tier, deprecating an integration.
+3. For your product, write a one-paragraph positioning statement using Dunford's five components. Then test it: would your most junior salesperson recognise the positioning? Would your product engineer? Would a customer in the ICP?
+
+## Recap & next
+
+- Positioning is what the customer *concludes* about you, not what you say in the headline.
+- The Dunford canvas - competitive alternatives, unique attributes, value, best-fit customer, market category - gives a forced ordering that exposes most mistakes.
+- Engineering decisions encode positioning silently; misalignment between engineering reality and marketing positioning confuses customers and is usually won by the engineering reality.
+- Category creation is rare and risky; category reframing is often more durable.
+
+Next, **Pricing & packaging in B2B SaaS** - how the price sheet encodes strategy and what changes when you change it.
+{% endraw %}
diff --git a/_courses/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.md b/_courses/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.md
new file mode 100644
index 0000000..dcd233e
--- /dev/null
+++ b/_courses/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.md
@@ -0,0 +1,180 @@
+---
+chapter_id: 3
+chapter_slug: pricing-and-packaging
+chapter_title: "Pricing & packaging in B2B SaaS"
+chapter_summary: "Surveys SaaS pricing models (seat-based, usage-based, hybrid), packaging strategies and price discrimination via tiers. Highlights the engineering surface area required by each model: metering, entitlements, billing, enforcement."
+---
+
+{% raw %}
+## What you'll learn
+- The three dominant SaaS pricing models - seat-based, usage-based, hybrid - and what each encodes about the product.
+- The mechanics of packaging: tiers, feature gating, and add-ons.
+- Price discrimination and willingness-to-pay as the underlying economic logic.
+- Why engineering owns more of pricing than they realise - and what to do about it.
+
+## Concepts
+
+Pricing is the single highest-leverage business decision a software company makes. A 1% price increase that holds without churn drops directly to operating income. A 5% packaging change can shift NRR by a dozen points. And yet pricing rarely gets the attention it deserves - most companies do an annual review at best, and engineering is almost never consulted.
+
+That last bit is wrong. Engineering touches pricing in five ways: what's *meterable*, what's *gateable* (feature flags), what's *deployable* (SaaS architecture for entitlements), what's *integratable* (billing systems), and what's *enforceable* (without violating customer trust). Get any of these wrong and the pricing strategy can't ship.
+
+### The three dominant models
+
+**Seat-based (per-user).** Customer pays per user with access to the product. Salesforce, Atlassian, Notion, Figma. Predictable for customers, simple to forecast.
+
+```text
+Pros: Easy to understand; predictable revenue; aligns with hiring growth.
+Cons: Discourages broad adoption (people share logins); caps revenue at user count.
+Engineering surface: Need accurate seat counting; SSO/user-management integration.
+```
+
+**Usage-based (consumption).** Customer pays per unit consumed - API calls, GB stored, minutes processed. AWS, Twilio, Stripe, Cloudflare. Aligns revenue with value generated.
+
+```text
+Pros: Scales with customer success; lower friction to start; NRR > 100% common.
+Cons: Hard to forecast; sticker-shock risk; needs sophisticated metering.
+Engineering surface: Accurate metering, real-time rating, billing aggregation,
+                     cost-control features (caps, alerts), credit systems.
+```
+
+**Hybrid (subscription + consumption).** A subscription floor with usage-based overages. Datadog (per-host pricing + log volume), Snowflake-style data platforms, Cloudflare Workers. Combines the predictability of subscription with usage-based upside.
+
+```text
+Pros: Predictable base; expansion built-in; matches enterprise procurement preferences.
+Cons: Complex to communicate; complex to bill; price sheet hard to read.
+Engineering surface: Metering + entitlements + commit consumption tracking.
+```
+
+A fourth, rarer model: **outcome-based**. Customer pays based on a measured business outcome (loans approved, fraud detected, customers acquired). Powerful but operationally hard. Usually appears as a custom enterprise contract rather than a standard SKU.
+
+### Packaging: tiers, gates, add-ons
+
+Packaging is the *grouping* of features into purchasable units. Most B2B SaaS uses a three-tier structure:
+
+| Tier | Purpose | Typical features |
+|---|---|---|
+| Starter / Free | Acquire users, demonstrate value | Core functionality with limits (e.g. 5 seats, 10k events/mo) |
+| Pro / Team | The product most paying customers use | Full feature set, no limits, modest support |
+| Enterprise | Advanced security, custom requirements | SSO/SAML, audit logs, custom contracts, premium support |
+
+The art is in *which features go in which tier*. Two principles guide it:
+
+**Tier features by willingness-to-pay segment.** SSO is a near-universal enterprise requirement. Audit logs are enterprise. Advanced RBAC is enterprise. By gating these to the top tier, you let smaller customers buy without these features and force larger customers (who genuinely need them) up.
+
+**Tier features by usage intensity.** Limits on volume - events per month, GB stored, seats - naturally tier users. The customer using 100x more value pays proportionally more.
+
+**Add-ons** are features that orthogonally appeal to a subset of the customer base, not aligned with tier. Examples: data residency in EU, dedicated infrastructure, professional services packages. Add-ons preserve flexibility for the long tail of edge cases without complicating the main tier structure.
+
+### Price discrimination
+
+The economic engine behind tiering is *price discrimination*: charging different customers different prices for the same underlying capability based on their willingness to pay. Pure economic theory says this is profit-maximising. In practice the constraints are:
+
+- **Detectability.** You can't price-discriminate based on properties customers can hide. Hence: charging large companies more requires *signals* (seat counts, request volume, contract size).
+- **Customer perception of fairness.** Charging different list prices for the same feature publicly creates backlash. Hence: differentiated *packaging* rather than differentiated *prices* for the same thing.
+- **Arbitrage.** Customers near a tier boundary will minimise to stay below it. Hence: limit selection of features per tier shouldn't be too obviously gameable.
+
+The trick is to package *bundles of features* such that each bundle naturally attracts the right segment. Enterprise customers can't easily downgrade because they need SSO and audit logs. SMBs can't easily upgrade because they don't need (or want to pay for) those.
+
+### Pricing as strategy
+
+The price sheet *encodes* the company's strategy. Look at any two competitors and the differences in their pricing usually reveal strategic differences:
+
+- Atlassian's per-user-per-month, sub-$20 starting price → low-touch, mid-market, self-service.
+- Workday's "contact sales for all tiers" → enterprise-only, sales-led, custom contracts.
+- DataDog's per-host pricing → infrastructure-monitoring positioning.
+- Cloudflare's free-tier-for-most + enterprise → freemium funnel + upmarket motion.
+
+When pricing changes, strategy is changing. When companies switch from seat-based to consumption-based, the entire GTM motion changes (see Module 3 Chapter 4).
+
+### What engineering needs to know
+
+The pricing model determines what engineering builds:
+
+| Pricing model | Required engineering capabilities |
+|---|---|
+| Seat-based | Accurate seat tracking, user-management API, idempotent user provisioning |
+| Usage-based | Real-time metering, rating engine, idempotent event collection, cost-control UI, credit/refund logic |
+| Hybrid | All of the above + commit-and-overage tracking, prepaid-credit accounting |
+| Outcome-based | Custom integrations to measure outcomes, often with customer's data sources |
+| Free tier | Strict, race-free enforcement of limits (prevents abuse) |
+| Tiered features | Feature-flagging by plan, entitlement service, plan-aware code paths |
+
+These are deep engineering investments. A company that wants to add usage-based pricing without metering infrastructure is making a multi-quarter commitment. Most companies underestimate this work by a factor of 2-3x.
+
+### Price changes
+
+Raising prices is the single highest-ROI experiment a SaaS company can run, and the most rarely run. Industry studies (e.g. Patrick Campbell's research at [ProfitWell](https://www.profitwell.com/blog/pricing-strategy)) consistently find:
+
+- B2B SaaS companies under-price by 20–40% on average.
+- A 1% price increase produces ~10% improvement in EBIT in steady state.
+- Annual price reviews are a baseline; quarterly is better.
+- Grandfathering existing customers reduces churn; new pricing applies to new logos and renewals.
+
+Engineering's role in pricing changes: the entitlement and billing systems need to support "old pricing" and "new pricing" simultaneously. Migrations are non-trivial.
+
+## Walkthrough
+
+Two contrasting packaging tables.
+
+**Confluence (Atlassian) - seat-based with feature-gated tiers:**
+
+```text
+Free      $0          Up to 10 users, basic features
+Standard  $5.16/user  Standard support, 250GB storage
+Premium   $9.81/user  Advanced features, IP allowlisting, 24/7 support
+Enterprise Custom     Centralised admin, audit logs, unlimited storage
+```
+
+This packaging encodes Atlassian's PLG strategy: a generous free tier acquires users; the paid tiers are explicitly priced; feature differentiation is mild (more about scale and admin); enterprise gets bespoke treatment.
+
+**Snowflake - pure consumption (simplified):**
+
+```text
+Standard   $2/credit       Basic data warehouse
+Enterprise $3/credit       + multi-cluster, time-travel up to 90 days
+Business Critical $4/credit + advanced security, HIPAA, BAA
+Virtual Private $6/credit  + isolated infrastructure
+```
+
+Notice the structure: same product (Snowflake), four tiers, each is a *multiplier* on the credit price. The customer's bill is `credits used × tier multiplier × $/credit`. This packaging encodes Snowflake's enterprise-trust strategy - security and isolation features push customers up because they have to.
+
+The two pricing pages communicate different strategies even before you read any product information. That's the point.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  segments[Customer segments with different WTP] --> tiers[Tiered packaging]
+  tiers --> features[Features in each tier]
+  features --> eng[Engineering: gating + metering + billing]
+  metering[Usage metering] --> eng
+  eng --> billing[Billing system]
+  billing --> rev[Recognised revenue]
+  rev --> sm[S&M efficiency / NRR]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Pricing changes without engineering | "It's just a number" | Pricing changes require entitlement and billing engineering. |
+| Free tier with unenforced limits | "We'll enforce later" | Without enforcement at code level, free tier becomes the product. |
+| Too many tiers | "We want every customer to have a fit" | Customers can't choose; sales can't position. 3 tiers is canonical. |
+| Inconsistent gating | A feature gated in one place leaks via API | Single entitlement service; all features check it. |
+| Price never changes | "We're worried about churn" | Annual reviews are baseline. Grandfathering minimises churn. |
+
+## Exercises
+
+1. Look at your company's pricing page. Identify each tier's primary "what" (volume vs. features vs. support). Cross-check that the engineering systems enforce each tier consistently.
+2. Identify three features your company has but doesn't currently charge for. For each, classify it as "should be a tier upgrade trigger," "should be an add-on," or "should be free (core)."
+3. Find a competitor's pricing page. Reverse-engineer their strategy: are they PLG or sales-led? Are they targeting enterprise or SMB? Do their packaging choices align with their public strategy claims?
+
+## Recap & next
+
+- Three dominant SaaS pricing models - seat-based, usage-based, hybrid - each with distinct engineering requirements and GTM implications.
+- Packaging encodes price discrimination through tiers and add-ons aligned with willingness-to-pay.
+- The pricing page is a strategy document; changes reflect strategic shifts.
+- Engineering owns metering, entitlements, billing, and enforcement - the work behind every pricing decision.
+
+Next, **GTM motions: PLG, sales-led, hybrid** - how the pricing model and target segment determine the sales motion that scales.
+{% endraw %}
diff --git a/_courses/engineers-mba/03-markets-customers-gtm/04-gtm-motions.md b/_courses/engineers-mba/03-markets-customers-gtm/04-gtm-motions.md
new file mode 100644
index 0000000..201295a
--- /dev/null
+++ b/_courses/engineers-mba/03-markets-customers-gtm/04-gtm-motions.md
@@ -0,0 +1,195 @@
+---
+chapter_id: 4
+chapter_slug: gtm-motions
+chapter_title: "GTM motions: PLG, sales-led, hybrid"
+chapter_summary: "Compares PLG, sales-led, and hybrid GTM motions across CAC, S&M ratio, sales cycle, and engineering investment. Explains the PLG-to-enterprise transition and how to read a GTM motion from a company's homepage."
+---
+
+{% raw %}
+## What you'll learn
+- The three dominant B2B SaaS go-to-market motions - product-led growth, sales-led, and hybrid - and what each looks like in numbers.
+- When each motion works, what it costs, and what fails when it's applied to the wrong market.
+- How engineering's product surface shapes what motions are even possible.
+- The "PLG to enterprise" transition, the most common (and painful) GTM change in software.
+
+## Concepts
+
+A *GTM motion* is the system by which the company finds, qualifies, sells to, onboards, and expands customers. Every B2B SaaS company has one even if they don't think about it explicitly. The motion lives at the intersection of product, pricing, marketing, sales, and customer success.
+
+Three motions dominate the modern landscape:
+
+### 1. Product-led growth (PLG)
+
+The product itself drives acquisition, conversion, and expansion. Marketing brings users to a free or self-serve product; the product converts them; expansion happens organically as usage grows.
+
+**Hallmarks:**
+- Free tier or free trial; no "contact sales" gate.
+- Self-serve onboarding (signup → useful in 5 minutes).
+- Pricing visible on the website.
+- Many small customers; expansion via seat/usage growth.
+- Word-of-mouth and individual buyers, not committee buyers.
+
+**Examples:** Atlassian, Notion, Figma, Linear, Datadog (early days), HashiCorp Cloud Platform.
+
+**Why it works:** Users adopt the product before the company is even aware of them. The CAC is low because acquisition happens via product utility, not paid acquisition. The product *is* the marketing.
+
+**When it doesn't:** Products that need to be configured before they produce value (security, compliance), or that require a committee decision (multi-stakeholder enterprise deals), or that touch sensitive data (regulated industries).
+
+### 2. Sales-led
+
+A sales team drives acquisition. Inbound or outbound prospecting → qualification → discovery → demo → proposal → negotiation → close. The product gets bought after a sales-led education process.
+
+**Hallmarks:**
+- "Contact sales" or "request a demo" instead of "sign up."
+- Pricing hidden or "available on request."
+- High ACV - typically $50k+, often $250k+.
+- Buying committees with technical, economic, and procurement personas.
+- Long sales cycles (3–12 months).
+- High S&M ratio (often 40–60% of revenue).
+
+**Examples:** Salesforce, Workday, ServiceNow, Snowflake, Workato, Palantir.
+
+**Why it works:** Enterprise customers want to be sold to. They have complex requirements, multiple stakeholders, security reviews, procurement processes. A salesperson navigates this; a self-serve product can't.
+
+**When it doesn't:** SMB and mid-market customers who can decide alone. They resent being routed through sales for what feels like a $200/month decision. Sales-led motions also have minimum economics - you can't profitably sell a $1k product with a $50k cost-to-acquire.
+
+### 3. Hybrid (PLG + sales overlay)
+
+Start with PLG to acquire users; layer sales onto accounts when they grow. Most successful modern SaaS companies use a hybrid.
+
+**Hallmarks:**
+- Free tier and self-serve for low-end and individual users.
+- Outbound sales targets specific accounts with growing usage signals.
+- Pricing transparent up to a point; "contact sales" above a threshold.
+- PLG-flavoured marketing for top-of-funnel; sales-flavoured for enterprise.
+
+**Examples:** Datadog (started PLG, layered sales), Snowflake (sales-led with PLG hooks), HashiCorp (open-source → cloud product → enterprise).
+
+The hybrid is hard to operate but compounds. The PLG motion provides cheap top-of-funnel; the sales motion captures large deals; usage signals from PLG identify which accounts to prioritise for outbound.
+
+### Comparing the motions
+
+The numbers tell the story:
+
+| Metric | PLG | Sales-led | Hybrid |
+|---|---|---|---|
+| Typical ACV | $1k-$50k | $50k-$5M | $1k-$500k |
+| CAC | Low ($500-$5k blended) | High ($50k-$500k) | Middle |
+| Sales cycle | Days-weeks | Months | Mixed |
+| Free tier | Yes | No | Yes |
+| S&M as % revenue | 15-25% | 40-60% | 25-40% |
+| Buying motion | Individual user | Committee | Both |
+| Engineering priorities | Onboarding speed, self-serve | Custom integrations, security | All of the above |
+
+### What engineering builds for each motion
+
+**PLG demands:**
+- Sub-5-minute time-to-value
+- Self-serve onboarding with minimal config
+- In-product upgrade flows
+- Usage telemetry that drives product decisions
+- Reliability and performance (cannot fall over under abuse from a viral signup)
+
+**Sales-led demands:**
+- Enterprise-grade security: SSO/SAML, audit logs, advanced RBAC
+- Custom deployment options (private cloud, on-prem, single-tenant)
+- Integration depth with enterprise stacks (Workday, Okta, ServiceNow)
+- Compliance certifications: SOC 2 Type II, HIPAA, FedRAMP
+- Custom contracts, custom features, custom commitments
+- A "white-glove" customer success engineering function
+
+**Hybrid demands:** All of the above. Hybrid is hard because the engineering org has to invest in *both* sets of capabilities simultaneously. Many companies fail because they try to support both motions with one engineering org sized for one.
+
+### The PLG-to-enterprise transition
+
+The most common GTM transition in modern SaaS: a PLG company has saturated its self-serve segment and needs to move upmarket to enterprise. This is one of the hardest transitions in business.
+
+What changes:
+1. **Product** - must add SSO, audit logs, advanced security. The "developer-friendly defaults" change.
+2. **Sales** - hire account executives, sales engineers, account managers.
+3. **Pricing** - add an enterprise tier; learn to negotiate custom contracts.
+4. **Marketing** - content shifts from product-led to account-based.
+5. **Customer success** - white-glove engagement instead of help-doc-driven.
+6. **Finance** - invoicing, custom payment terms, multi-year deals.
+7. **Engineering** - entirely new feature surface area for enterprise.
+
+Companies that do this well include Atlassian (slow, patient, never lost the SMB), Figma (added enterprise without abandoning individuals), HashiCorp (open source → cloud → enterprise). Companies that did this badly are more numerous but more politely unnamed.
+
+The opposite transition - enterprise to PLG - is even harder because the engineering and sales habits are deeply ingrained. Workday adding a free tier would be culturally unthinkable.
+
+### Reading a GTM motion from the outside
+
+You can identify a company's GTM motion in 30 seconds on their homepage:
+
+| Signal | GTM motion |
+|---|---|
+| Big "Sign up free" button | PLG |
+| Big "Contact sales" button | Sales-led |
+| Both, with pricing visible | Hybrid |
+| Visible pricing tiers | PLG or hybrid |
+| "Talk to sales for pricing" | Sales-led |
+| Free trial with credit card | Self-serve, often hybrid |
+| Customer logos including F500 | At least partial sales-led |
+| Engineering blog with deep technical posts | PLG (engineer audience) |
+| Analyst reports prominently displayed | Sales-led (enterprise validation) |
+
+## Walkthrough
+
+A worked example. Consider two competitors in the API platform space.
+
+**Postman (PLG → hybrid):**
+- Started as a developer tool installed locally.
+- Free tier for individuals, paid plans for teams.
+- Sales motion added for enterprise contracts (governance, SSO, audit).
+- Visible pricing up to "Enterprise" which is contact-sales.
+- Time-to-value: 30 seconds (install and start using).
+
+**Kong (open source + sales-led):**
+- Open-source API gateway.
+- Commercial product is sales-led.
+- "Schedule a demo" rather than "sign up."
+- Long sales cycles; large enterprise contracts.
+- Time-to-value (commercial product): depends on the deployment engagement.
+
+Both compete in the API space. Their GTM motions are completely different, driven by product nature (developer tool vs. infrastructure component) and customer (individual developer vs. platform team). Both can succeed; neither motion would work for the other product without restructuring.
+
+The lesson: GTM motion is a strategic choice, but it's heavily constrained by product nature. The motion that works depends on whether the product is *developer-bought* or *committee-bought*; whether time-to-value is *seconds* or *quarters*; whether the deployment is *self-contained* or *integrated with enterprise systems*.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  product[Product nature & TTV] --> motion[GTM motion]
+  motion --> price[Pricing model]
+  motion --> sales[Sales team size & structure]
+  motion --> marketing[Marketing approach]
+  motion --> cs[Customer success]
+  motion --> eng[Engineering priorities]
+  motion --> ratios[S&M ratio, sales cycle, CAC]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Wrong motion for the product | "We want enterprise revenue" | The product's time-to-value and buying motion constrain the GTM. Adapt one or the other; don't fight both. |
+| Hybrid without resourcing both motions | "We'll do both" | Hybrid requires investment in both sets of capabilities; under-resourcing creates a worst-of-both result. |
+| PLG without telemetry | "Build the product, growth will come" | PLG requires usage analytics to identify expansion opportunities and at-risk accounts. |
+| Sales-led without security investment | "We'll add SSO later" | Enterprise buyers gate-keep on security; missing certifications kills deals. |
+| Treating GTM as marketing's problem | "GTM = pipeline" | GTM is product + pricing + sales + marketing + CS. Engineering owns critical parts. |
+
+## Exercises
+
+1. Visit five competitor websites in your industry. For each, identify which GTM motion they're running based on the signals on the homepage. Now compare to actual sales motion data if you have it.
+2. For your own product, list three engineering investments in the next quarter that are required *for the current GTM motion*. Then identify whether your roadmap reflects them or whether they're under-prioritised vs. feature work.
+3. If your company switched GTM motions tomorrow (PLG to enterprise, or vice versa), name three engineering capabilities that would have to be built. The exercise builds appreciation for how deeply GTM motion drives engineering investment.
+
+## Recap & next
+
+- Three dominant motions: PLG, sales-led, hybrid. Each has distinct hallmarks, costs, and engineering requirements.
+- The motion is constrained by product nature - time-to-value, buying motion, deployment complexity.
+- Hybrid is the modern default but requires investing in *both* sets of capabilities.
+- The PLG-to-enterprise transition is the most common and most painful GTM change in modern software.
+
+Next, **The funnel & pipeline math** - once the motion is chosen, what numbers does the company watch to know if it's working?
+{% endraw %}
diff --git a/_courses/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.md b/_courses/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.md
new file mode 100644
index 0000000..364db33
--- /dev/null
+++ b/_courses/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.md
@@ -0,0 +1,210 @@
+---
+chapter_id: 5
+chapter_slug: funnel-and-pipeline-math
+chapter_title: "The funnel & pipeline math"
+chapter_summary: "Walks through the standard funnel stages, conversion-rate benchmarks, the sales-velocity formula, and the 3x pipeline-coverage rule. Shows how engineering affects leading indicators with a 2-4 quarter lag to revenue."
+---
+
+{% raw %}
+## What you'll learn
+- The standard marketing/sales funnel stages - TOFU, MOFU, BOFU - and what each measures.
+- Conversion rates: what's normal, what's broken, what's gamed.
+- Sales velocity and pipeline coverage - the two numbers that tell you whether the quarter will hit.
+- How leading vs. lagging indicators connect engineering work to revenue.
+
+## Concepts
+
+Engineers often hear "the pipeline" mentioned reverently in exec reviews and wonder what specifically is being discussed. The pipeline is the *forecasted* set of deals at various stages of progression, valued and weighted by stage probability. It is the closest thing a B2B SaaS company has to a leading indicator of revenue.
+
+The funnel is the *historical* set of conversion rates from one stage to the next. The pipeline is its forward-looking application: "We have X opportunities at Y stages with Z weighted value - given historical conversion rates, what should close this quarter?"
+
+Both rest on the same staged model.
+
+### The standard funnel stages
+
+Marketing and sales teams divide the funnel into stages. There's no universal naming convention but the structure is consistent.
+
+```text
+TOFU (top of funnel)
+  Visitors / Anonymous traffic
+       ↓ ~2-5%
+  Leads (gave email, signed up)
+       ↓ ~10-30%
+  Marketing-Qualified Leads (MQLs)
+       ↓ ~20-30%
+MOFU (middle of funnel)
+  Sales-Accepted Leads (SALs)
+       ↓ ~40-60%
+  Sales-Qualified Leads (SQLs)
+       ↓ ~25-40%
+  Opportunities (sales has accepted the deal as real)
+       ↓ ~15-30%
+BOFU (bottom of funnel)
+  Proposal sent
+       ↓ ~50-70%
+  Closed-Won
+```
+
+The exact percentages vary by motion. PLG has high TOFU volumes and low average deal size; sales-led has lower volumes and higher average deal size. The *shape* is consistent - narrowing through the funnel as deals get qualified out.
+
+Across the entire funnel, the rough industry conversions:
+
+- **PLG** - 100 visitors → 1-2 paying customers ($)
+- **Mid-market sales-led** - 100 MQLs → 5-10 closed-won ($$)
+- **Enterprise sales-led** - 100 SQLs → 15-30 closed-won ($$$)
+
+The numbers drop fast, which is why the only sustainable strategy is to *narrow the funnel* (better qualification) rather than *widen the top* (more leads). Most companies do the latter when they should do the former.
+
+### Conversion rates
+
+Healthy ranges depend on the segment:
+
+| Stage transition | PLG | SMB sales-led | Enterprise |
+|---|---|---|---|
+| Visitor → Signup | 2-5% | n/a | n/a |
+| Signup → Active user | 15-30% | n/a | n/a |
+| Active user → Paid | 1-5% | n/a | n/a |
+| Lead → MQL | n/a | 5-15% | 10-25% |
+| MQL → SQL | n/a | 20-40% | 40-60% |
+| SQL → Opportunity | n/a | 30-60% | 50-80% |
+| Opportunity → Closed-won | 15-30% | 20-30% | 25-35% |
+| Win rate (against named competitor) | n/a | 20-40% | 30-50% |
+
+Conversion rates *trend* matters more than absolute numbers. A 25% opp-to-close rate trending down is more diagnostic than a 30% rate that's been stable.
+
+The most-gamed conversion rate: MQL → SQL, where marketing wants to claim leads as MQLs and sales wants to disqualify them as SQLs. The internal tension is healthy; the games are not.
+
+### Sales velocity
+
+The standard formula:
+
+```text
+Sales Velocity = (Number of Opportunities × Average Deal Size × Win Rate) / Sales Cycle Length
+```
+
+A company with 100 open opportunities, $50k average ACV, 25% win rate, and 90-day sales cycles has sales velocity = (100 × $50k × 0.25) / 90 = $14k/day, or ~$1.3M per quarter from those opportunities.
+
+The formula reveals four levers:
+
+| Lever | What it means | Engineering involvement |
+|---|---|---|
+| Number of opportunities | Pipeline volume | Indirect - better product enables more deals to enter |
+| Average deal size | ACV | Direct - features and packaging change ACV |
+| Win rate | Conversion at the bottom | Direct - product quality, demos, technical credibility |
+| Sales cycle length | Speed | Direct - onboarding, integration speed, technical decision support |
+
+Notice the asymmetry: shortening sales cycles by 25% has the *same* revenue impact as raising win rate by 25%. Engineers usually focus on win-rate via features; cycle-length is often the easier lever.
+
+### Pipeline coverage
+
+The forecasting metric. The question: do we have *enough* pipeline to hit our quota?
+
+```text
+Pipeline Coverage = (Total weighted pipeline) / (Quota)
+```
+
+The rule of thumb: 3x coverage is the minimum, 4x is healthy, 5x+ is comfortable. The 3x comes from typical conversion: if you need $10M in closed revenue and your closing rate is ~30%, you need at least $33M of pipeline.
+
+When coverage drops below 3x, the quarter is at risk. Sales scrambles to generate pipeline. Marketing gets pressured. Product gets pulled into "what can we ship this week to unblock this deal?" The chain reaches engineering quickly.
+
+### Leading vs. lagging indicators
+
+Revenue is the *lagging* indicator. By the time revenue drops, the underlying problem started 6-9 months ago.
+
+Engineering work mostly affects leading indicators:
+
+| Leading indicator | What it predicts | Engineering lever |
+|---|---|---|
+| Signup-to-activation rate | Future conversion to paid | Onboarding, time-to-value |
+| Product engagement depth | Future retention | Feature stickiness, integrations |
+| Customer health score | Future renewal | Reliability, support quality |
+| Time from PoC to closed | Future win rate | Demo environments, security posture |
+| Demos requested per month | Future pipeline | Product reputation, organic discovery |
+| Public engineering content engagement | Future top-of-funnel | Developer relations, technical content |
+
+A common engineering frustration: "We're working on the right things, but the revenue line isn't moving." That's normal - engineering's effect on lagging indicators takes 2-4 quarters to show up. The leading indicators move faster. Track those, not the revenue.
+
+### The funnel as a feedback loop
+
+Every funnel stage produces information about earlier stages. If 90% of opportunities that include a security review fail at the SQL stage, marketing should pre-qualify on security maturity. If 60% of demos in a vertical lose to a specific competitor, product should look at differentiation in that vertical.
+
+The information flow:
+
+```text
+Closed-Lost reasons → product roadmap signals
+Stalled deals → ICP refinement (or product gaps)
+Slow MQL → SQL → marketing-sales alignment
+High activation, low conversion → pricing or packaging
+Low signup → poor positioning or targeting
+```
+
+Engineering teams that ignore this feedback loop end up shipping into the void. The most senior product engineers spend non-trivial time in customer-loss debriefs because that's where the most useful product information surfaces.
+
+## Walkthrough
+
+A worked example. A hypothetical SaaS company reports the following quarterly:
+
+```text
+Visitors:                    50,000
+Signups:                     2,000        (4.0% conversion)
+Active free users:           600          (30%)
+Free → paid:                 18           (3%)
+Pipeline (mid-market):       80 deals × $25k ACV × 30% win = $600k expected
+Pipeline (enterprise):       20 deals × $200k ACV × 35% win = $1.4M expected
+Total expected close:        $2M from sales-led + $450k ARR from PLG = $2.45M
+
+Quota for the quarter:       $3.0M
+Pipeline coverage:           ~$8M / $3M quota = 2.67x  ← low
+```
+
+The diagnostic conversation that should follow:
+
+1. **Pipeline coverage is 2.67x, below the 3x threshold.** The quarter is at risk before it starts.
+2. **Free-to-paid is 3%.** Industry standard for PLG is 1-5%; this is fine but watch the trend.
+3. **Win rates are healthy** (30% mid-market, 35% enterprise) - the issue is upstream.
+4. **Enterprise deal count is 20.** For 35% win rate at $200k average, that's only 7 closed deals. If quota requires more, the sales team needs more enterprise pipeline *now* - not better win rates.
+5. **What's the leading indicator?** Demo requests in the last month - if they're up, pipeline will recover next quarter. If flat, marketing needs help.
+
+This is the kind of analysis that happens in every QBR. Engineers attending these meetings often have surprising insight into the leading indicators (especially for PLG: free-tier activation, in-product engagement, time-to-first-value).
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  visitors[Visitors / TOFU] --> leads[Leads / MQLs]
+  leads --> sqls[SQLs / Opportunities]
+  sqls --> demos[Demos / Proposals]
+  demos --> close[Closed-Won]
+  close --> revenue[Revenue]
+  eng[Engineering investment] -.improves.-> leads
+  eng -.improves.-> sqls
+  eng -.improves.-> close
+  revenue -.lag 2-4 quarters.-> visitors
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Widening top-of-funnel to fix conversion | "More leads will fix it" | The leak is downstream; better qualification beats more volume. |
+| Chasing revenue instead of leading indicators | Easy to measure, slow to move | Watch activation, engagement, demo-request volume. |
+| Marketing vs. sales lead-quality blame | Definitions of MQL/SQL differ | Force shared definitions; track MQL → SQL conversion as the alignment metric. |
+| Ignoring closed-lost reasons | "We won enough" | Closed-lost is the highest-information source for product roadmap. |
+| Sales velocity hidden | "The formula is complicated" | Compute it monthly; the four levers are all visible. |
+
+## Exercises
+
+1. Pull your company's funnel data for the last 4 quarters. Compute sales velocity. Note which of the four levers is most movable. Most of the time it's sales cycle length, but engineers default to thinking win rate.
+2. List the top 3 reasons your company lost deals last quarter. For each, identify whether engineering work would have changed the outcome. Then check if those items are on the roadmap.
+3. For your team's last shipped feature, identify which funnel-stage leading indicator it should have moved. If you can't name one, the feature didn't have a measurable business case - which is sometimes fine, but worth knowing.
+
+## Recap & next
+
+- The funnel is the staged conversion model from visitor to closed deal; the pipeline is its forward application.
+- Conversion rates vary by motion and segment; trend matters more than absolute numbers.
+- Sales velocity exposes four levers: opportunity count, deal size, win rate, cycle length.
+- Pipeline coverage of 3x quota is the minimum; below that, the quarter is at risk.
+- Engineering work mostly affects leading indicators; revenue lags by 2-4 quarters.
+
+Next, kicking off **Module 4 - Operating a Software Business**, starting with **The SaaS metric tree**.
+{% endraw %}
diff --git a/_courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.md b/_courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.md
new file mode 100644
index 0000000..9c87f99
--- /dev/null
+++ b/_courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.md
@@ -0,0 +1,235 @@
+---
+chapter_id: 1
+chapter_slug: saas-metric-tree
+chapter_title: "The SaaS metric tree"
+chapter_summary: "Walks the SaaS metric tree - ARR, NRR/GRR, magic number, burn multiple, rule of 40 - with stage-appropriate benchmarks. Maps each metric to engineering levers and identifies common gaming patterns."
+---
+
+{% raw %}
+## What you'll learn
+- The canonical SaaS metrics - ARR, MRR, NRR, GRR, magic number, burn multiple, rule of 40 - and what each measures.
+- How the metrics relate to each other (the "metric tree") and which ones drive the others.
+- What "good" looks like by stage and what gaming each metric looks like.
+- Where engineering work shows up in each metric.
+
+## Concepts
+
+A B2B SaaS company's quarterly board deck has roughly the same 10 metrics every quarter. The metrics form a *tree*: revenue at the root, broken down into components, each of which has its own diagnostic value. Once you can read the tree fluently, exec reviews become legible.
+
+### Annual Recurring Revenue (ARR) and MRR
+
+**ARR** is the annualised value of recurring subscription contracts. A company with 1,000 customers at $100k annual contracts has $100M ARR. ARR is the most-quoted private-company SaaS metric - it's the "size" of the company.
+
+**MRR** is the monthly version, used by smaller or earlier-stage companies. ARR = MRR × 12 for clean subscription companies.
+
+Subtleties:
+- ARR excludes one-time fees, professional services revenue, and other non-recurring revenue.
+- ARR includes signed contracts even before revenue is recognised; revenue is the GAAP measure.
+- ARR can include "committed" but not yet active contracts in some definitions - read the definition before believing the number.
+
+For usage-based companies, the analogous metric is "annualised run-rate revenue" - usage trends projected forward. Less stable, but the closest equivalent.
+
+### Net Revenue Retention (NRR) and Gross Revenue Retention (GRR)
+
+These are the most important retention metrics in modern SaaS. Both measure what happens to the cohort of customers you had at the start of a period over the period.
+
+```text
+GRR = (Revenue from start-of-period cohort, at end-of-period, BEFORE expansion) / 
+      (Revenue from start-of-period cohort, at start-of-period)
+```
+
+GRR captures *only the losses* - churn and contraction. It's capped at 100%. A GRR of 92% means you lost 8% of last year's revenue to churn and contraction (e.g. customers downgrading).
+
+```text
+NRR = (Revenue from start-of-period cohort, at end-of-period, INCLUDING expansion) / 
+      (Revenue from start-of-period cohort, at start-of-period)
+```
+
+NRR includes expansion. It can exceed 100%. NRR > 100% means existing customers grew faster than others churned. This is the metric VCs prize most for usage-based companies.
+
+What "good" looks like:
+
+| Segment | Good GRR | Good NRR |
+|---|---|---|
+| SMB SaaS | 80-90% | 100-110% |
+| Mid-market SaaS | 90-95% | 110-120% |
+| Enterprise SaaS | 95%+ | 115-125% |
+| Usage-based | n/a (different framing) | 120-140% |
+
+A NRR of 120% means existing customers compound by 20% annually with no new sales. Companies with NRR > 130% are highly prized - they have a structural growth engine inside their existing base.
+
+### Logo retention
+
+Distinct from revenue retention. *Logo retention* = % of customers (by count) retained. Useful because customer count and customer value can diverge - a company can have low logo retention but high NRR if it loses small customers and expands large ones.
+
+For B2B SaaS, annual logo churn of 5-7% is healthy; >15% is concerning.
+
+### Magic Number
+
+```text
+Magic Number = (Net new ARR this period × 4) / (S&M spend last period)
+```
+
+Effectively the ratio of S&M efficiency: for every dollar spent on sales and marketing, how many dollars of annualised new revenue did you get?
+
+Interpretation:
+
+| Magic Number | Read |
+|---|---|
+| < 0.5 | Inefficient - fix or slow growth |
+| 0.5-0.75 | Acceptable - typical growth-stage |
+| 0.75-1.0 | Good - efficient growth |
+| > 1.0 | Excellent - could pour more capital into S&M |
+
+The 4x multiplier comes from "annualise the quarter." Engineering investments in PLG (lower CAC), product (better conversion), and reliability (lower churn → higher net new) all affect magic number.
+
+### Burn Multiple
+
+```text
+Burn Multiple = Net Burn / Net New ARR
+```
+
+How many dollars of cash burn the company is taking on per dollar of new ARR added. Lower is better.
+
+| Burn Multiple | Read |
+|---|---|
+| < 1 | Outstanding - burning less than $1 to add $1 ARR |
+| 1-1.5 | Healthy growth-stage |
+| 1.5-2 | Acceptable in good environments |
+| > 2 | Capital-intensive - risky outside zero-interest-rate eras |
+
+Burn multiple became a more popular metric after 2022 when capital got expensive. Pre-2022 companies could burn 3-5x and still be funded. Post-2022, burn multiple <1.5 is the bar most boards expect at growth stage.
+
+### Rule of 40
+
+```text
+Rule of 40 = YoY Revenue Growth Rate (%) + Operating Margin (%)
+```
+
+A composite. The premise: at growth stage, the sum of growth rate and operating margin should exceed 40. A company growing 50% YoY with -10% operating margin scores 40 - acceptable. A company growing 20% YoY with 20% operating margin also scores 40 - also acceptable.
+
+The rule encodes a trade-off: high growth justifies losses; high profitability justifies slower growth. It collapses if both are bad.
+
+Public software companies are evaluated against rule of 40 in nearly every analyst note. The bar shifts with the market - in bull markets, 30 is the floor; in bear markets, 50 is.
+
+### Other commonly-tracked metrics
+
+- **CAC payback period** - covered in [Module 1 Chapter 4](/courses/engineers-mba/01-foundations-business-os/04-unit-economics/). Typically 12-24 months for healthy SaaS.
+- **Gross margin** - covered in [Module 1 Chapter 2](/courses/engineers-mba/01-foundations-business-os/02-reading-a-pnl/). 70-85% for pure SaaS.
+- **Sales productivity** - average ARR per quota-carrying rep per year. $1-2M for enterprise; $500k-$1M for mid-market.
+- **Free-to-paid conversion** (PLG only) - 1-5% of free signups become paying customers.
+- **Time to value** - minutes/hours/days from signup to first useful action. PLG companies obsess over this.
+
+### How the metrics relate
+
+The metrics form a tree:
+
+```text
+Revenue (root)
+├── New ARR
+│   ├── Number of deals (pipeline metrics, win rate)
+│   └── Average deal size (pricing, packaging)
+├── Expansion ARR (from existing)
+│   ├── Seat/usage growth (product engagement)
+│   └── Tier upgrades (pricing/packaging)
+├── Contraction ARR
+│   └── Downsells, downgrades (product utility)
+└── Churn ARR
+    └── Logo churn × ARR per lost logo
+
+Costs
+├── COGS (gross margin) - infrastructure, support
+├── R&D - product engineering
+├── S&M - sales, marketing
+└── G&A - overhead
+```
+
+Engineering moves several metrics:
+
+- **Reliability** → reduces churn → improves NRR, GRR.
+- **Performance** → improves NRR via reduced contraction, improves CAC payback via reduced sales cycle.
+- **Onboarding** → improves time-to-value → improves free-to-paid conversion.
+- **Infrastructure cost** → improves gross margin → improves rule of 40.
+- **Feature breadth** → enables tier upgrades → improves expansion ARR.
+
+### Gaming the metrics
+
+Every SaaS metric can be gamed. Common patterns to recognise:
+
+| Metric | Gaming pattern |
+|---|---|
+| ARR | Including non-recurring revenue; including unsigned LOIs; including discount-heavy contracts at full price |
+| NRR | Choosing cohort boundaries favourably; including upgrades from one-time fees |
+| Magic Number | Excluding marketing spend; using "blended" CAC |
+| Burn Multiple | Excluding stock-based compensation from burn |
+| Rule of 40 | Using non-GAAP operating margin (strips out SBC) |
+| CAC payback | Using marketing-only CAC instead of fully-loaded |
+
+The signal of gaming: when management changes definitions between quarters or uses different definitions from their public peers. The cure: always ask for the definition.
+
+## Walkthrough
+
+A worked example. Company X reports:
+
+```text
+ARR: $200M (up from $150M last year = 33% growth)
+Gross margin: 78%
+NRR: 115%
+GRR: 92%
+Magic number: 0.8
+Burn multiple: 1.4
+Operating margin: -5%
+Rule of 40: 33 + (-5) = 28
+```
+
+What this tells you:
+
+1. **NRR of 115% with GRR of 92%** - existing customers contract by 8% but grow by 23%, net 15%. The business has a real expansion engine.
+2. **Magic number 0.8** - decent S&M efficiency.
+3. **Burn multiple 1.4** - healthy for growth stage. The company is burning $14k for every $10k of new ARR - sustainable.
+4. **Rule of 40 = 28** - below the bar of 40. The company is growing fast but burning more than the growth justifies. Either growth needs to accelerate or burn needs to come down.
+5. **The diagnostic conversation**: how do we get rule of 40 to 40? Either raise growth from 33% to 45% (hard) or improve margin from -5% to +7% (also hard but more controllable). Or both.
+
+This kind of read happens in every board meeting. Once you can do it, you can follow the conversation.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  rev[ARR] --> growth[Growth rate]
+  rev --> nrr[NRR/GRR]
+  nrr --> retention[Customer retention]
+  cogs[COGS] --> gm[Gross margin]
+  sm[S&M] --> magic[Magic Number]
+  sm --> cac[CAC payback]
+  burn[Net burn] --> bm[Burn Multiple]
+  growth --> r40[Rule of 40]
+  gm --> r40
+  r40 --> valuation[Valuation / capital access]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Conflating ARR with revenue | They differ by deferred revenue and timing | Watch both; the gap signals growth velocity. |
+| Reporting NRR without GRR | Hides churn behind expansion | Always look at both; large NRR-GRR gaps reveal aggressive expansion masking weak retention. |
+| Magic Number with non-fully-loaded S&M | Looks better | Fully-loaded includes sales benefits, sales-engineering time, G&A allocation. |
+| Rule of 40 with non-GAAP margin | Strips SBC from costs | Both GAAP and non-GAAP versions matter; read both. |
+| Comparing across stages | A $10M ARR company has different bars than a $1B ARR company | Use stage-appropriate benchmarks. |
+
+## Exercises
+
+1. For your own company, list the 5 metrics most quoted in the last board meeting. For each, write down the definition you understand and verify it with finance. Many discrepancies surface in this exercise.
+2. Compute the rule of 40 for a public SaaS company from their latest 10-K. Check it against the analyst consensus number - small differences reveal definitional choices.
+3. List 3 engineering investments your team made in the last year. For each, identify which SaaS metric it should have moved. Then check if there's a measurement of whether it did. Most teams discover the measurement was never set up.
+
+## Recap & next
+
+- The SaaS metric tree organises ARR, NRR, GRR, magic number, burn multiple, and rule of 40 into a coherent hierarchy.
+- Each metric has standard ranges by stage; trend matters more than absolute number.
+- Engineering work moves specific metrics: reliability → churn → NRR/GRR; performance → time-to-value → conversion; infra cost → gross margin → rule of 40.
+- All metrics are gameable; ask for definitions and compare to peers.
+
+Next, **Operating cadence: OKRs, planning, business reviews** - the annual/quarterly/monthly rhythm of a software company.
+{% endraw %}
diff --git a/_courses/engineers-mba/04-operating-a-software-business/02-operating-cadence.md b/_courses/engineers-mba/04-operating-a-software-business/02-operating-cadence.md
new file mode 100644
index 0000000..b239c70
--- /dev/null
+++ b/_courses/engineers-mba/04-operating-a-software-business/02-operating-cadence.md
@@ -0,0 +1,186 @@
+---
+chapter_id: 2
+chapter_slug: operating-cadence
+chapter_title: "Operating cadence: OKRs, planning, business reviews"
+chapter_summary: "Describes the annual/quarterly/monthly operating cadence (AOP, QBRs, MBRs, board, all-hands) and what each forum is for. Distinguishes OKRs from KPIs and shows how engineers should adapt their framing per audience."
+---
+
+{% raw %}
+## What you'll learn
+- The annual / quarterly / monthly rhythm of a software company and the purpose of each forum.
+- OKRs vs. KPIs, what they're for, and how they go wrong.
+- What actually happens in a Quarterly Business Review (QBR), a board meeting, and an all-hands.
+- How engineering plugs into the cadence and what to bring to each meeting.
+
+## Concepts
+
+Every company that grows past 50 people develops an *operating cadence* - a recurring rhythm of planning, reviewing, and adjusting. The cadence is invisible from the outside but structural inside. Engineers who don't recognise the cadence often miss the windows where strategy is set, budgets are decided, and big bets are funded.
+
+The cadence operates at three time scales: annual, quarterly, monthly. Different decisions happen at different scales.
+
+### Annual: planning + board approval
+
+The **Annual Operating Plan (AOP)** is the year's commitment to the board. It includes:
+- Revenue targets by segment, by quarter
+- Spend by department (headcount, S&M, infrastructure)
+- Strategic priorities for the year
+- Major capital allocation decisions (acquisitions, new offices, new products)
+
+The AOP is built bottom-up *and* top-down: each function proposes a plan, leadership reconciles them, and the board approves the consolidated version. The process typically runs September-November for January-start fiscal years. The work is intense - every team submits multiple drafts, head-counts get fought over, budgets get cut, strategic bets get prioritised or killed.
+
+Engineering's role in AOP: headcount requests, infrastructure capex projections, major platform/migration plans, R&D allocation by product line. Engineering leaders should be active drivers, not passive recipients - the AOP often defines what engineering can and cannot work on for the year.
+
+### Quarterly: business reviews and re-planning
+
+The **Quarterly Business Review (QBR)** is the most regular strategic conversation. Each function presents:
+- Performance vs. plan for the quarter
+- Outlook for the next 1-2 quarters
+- Key risks and asks
+- Strategic learnings from the quarter
+
+QBRs run 1-3 days, typically with the leadership team and senior managers. Pre-reads are distributed in advance - sometimes 6-pagers, sometimes deck-form. The discussion is supposed to be *strategic*, not operational. (When it slides into operational, that's a sign the company is in trouble.)
+
+Engineering at QBR: present roadmap progress and outcomes, flag strategic risks (e.g. a major architectural concern), make asks (capital, time, prioritisation). The most senior engineers attending QBR usually represent a specific business unit or product area.
+
+### Monthly: business reviews (MBRs)
+
+The **Monthly Business Review (MBR)** is shorter and more operational. Each function reports on:
+- Last month's actuals
+- Funnel and pipeline metrics
+- Operating issues and corrective actions
+- Items requiring leadership decisions
+
+MBRs typically run half a day. They're less strategic, more diagnostic. The MBR is where missed quotas, slipping deadlines, and operational drift surface.
+
+Engineering at MBR: usually a slide on uptime, incident summary, and roadmap progress. Sometimes a deeper dive if engineering is the operational bottleneck.
+
+### Board meetings (quarterly, usually)
+
+For private companies, the board meets quarterly. The board pre-read (a "board deck") goes out 5-7 days before the meeting. It covers:
+
+- CEO's strategic update
+- Financial performance (the metric tree from [Chapter 4.1](/courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree/))
+- Functional updates (product, sales, marketing, customer success)
+- Major risks and asks
+- Specific board decisions required
+
+Boards rarely make tactical decisions. Their job is to: (a) validate strategic direction, (b) approve major capital allocations, (c) hire/fire the CEO, (d) provide strategic guidance.
+
+Engineering rarely presents to the board directly. The CTO sometimes does, on architectural strategy or platform investments. The board is interested in engineering *outcomes* (does the platform scale? are major risks managed?), not engineering *details*.
+
+### The all-hands
+
+A different kind of cadence event. The all-hands is communication, not decision-making. It typically happens monthly, with the full company in attendance. The CEO communicates:
+- Strategic direction and updates
+- Key wins and losses
+- Major announcements
+- Sometimes Q&A
+
+For engineering, all-hands is mostly listen-mode. The signal value is high - the CEO's framing of priorities tells everyone what matters. A change in framing (e.g. shifting from "growth above all" to "profitable growth") is often the first signal of strategic re-direction.
+
+### OKRs vs. KPIs
+
+These are different tools for different purposes.
+
+**KPIs (Key Performance Indicators)** are *steady-state operational metrics*. NRR, uptime, p99 latency, pipeline coverage. They run continuously and answer "how is the operation performing?" KPIs have targets but the targets stay relatively stable. Missing a KPI target prompts an investigation; chronically missing one prompts a structural fix.
+
+**OKRs (Objectives and Key Results)** are *change-oriented goals* with a time horizon. They typically run quarterly or annually. An objective is qualitative ("Become the standard observability platform for fintech"); key results are quantitative ("Win 10 fintech logos over $100k ACV"; "Publish 3 industry-recognised case studies"). OKRs answer "what are we trying to change?"
+
+The most common OKR mistake: writing OKRs that are really KPIs (steady-state targets). The result is meaningless because there's no change being driven.
+
+A good OKR for an engineering team might be:
+
+```text
+Objective: Reduce customer-reported reliability incidents by half
+KR1: P0/P1 incident rate < 1/month (currently 2.3/month)
+KR2: MTTR for P1 incidents < 30 minutes (currently 78 minutes)
+KR3: Customer satisfaction score for "reliability" > 4.2/5 (currently 3.6)
+```
+
+Note: each KR has a clear target with a baseline, and the objective is genuinely a change-effort with a defined success.
+
+A bad OKR for the same team:
+
+```text
+Objective: Improve reliability
+KR1: 99.95% uptime
+KR2: Reduce incidents
+KR3: Faster response to outages
+```
+
+This is a steady-state KPI dressed up as an OKR. The targets are either pre-existing or undefined; there's no theory of change.
+
+### What to bring to each forum
+
+A practical guide for engineers attending:
+
+| Forum | Bring | Don't bring |
+|---|---|---|
+| Annual planning | Strategic engineering bets, headcount requests, infra plan | Sprint-level details |
+| QBR | Roadmap outcomes, strategic risks, asks | Code-level discussion |
+| MBR | Operational metrics, incident summary | Architectural debates |
+| Board meeting | Architecture-level strategic story (rare, when invited) | Technical jargon |
+| All-hands | Listen-mode | (Usually nothing to bring) |
+| 1:1 with manager | Anything not on this list | (Anything fits here) |
+
+The mismatch - bringing operational details to QBR or strategic debates to MBR - is one of the most common engineering communication mistakes.
+
+## Walkthrough
+
+A worked example. You're a senior engineer asked to present at an upcoming QBR. The CTO says "5 minutes on what your team did this quarter."
+
+**Wrong approach** (operational):
+> "Our team shipped 47 PRs, reduced flaky tests by 30%, ran 12 incidents, and migrated 60% of services to the new gateway."
+
+This is great work, completely misaligned with the audience. Sales leadership doesn't know what a gateway is. The CEO is mentally checked out by minute 2.
+
+**Right approach** (strategic):
+> "Three things this quarter. First, we cut incident rate in half - which the customer success team confirms reduced support tickets by 30% and contributed to our NRR uptick. Second, we shipped the SSO/SAML support enterprise pipeline has been asking for; the deal team confirmed it unblocked $4M of stalled pipeline. Third, the platform migration is at 60% - on track for end of next quarter - which will let us launch the API platform on the new infrastructure. Risks: we have one senior engineer leaving and the gap in distributed-systems expertise is the biggest single risk to next quarter's commitments."
+
+Same work, completely different impact. The frame is:
+- Outcomes, not output
+- Business metrics moved, not engineering metrics
+- Asks and risks in business terms, not technical terms
+- Calibrated to the audience's mental model
+
+This is the translation skill that [Module 6 Chapter 1](/courses/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business/) covers in depth. It's the difference between engineering work being valued at the exec table and being invisible.
+
+## How it fits together
+
+```mermaid
+flowchart TB
+  annual[Annual planning: AOP, board approval] --> q1[Q1 QBR: outcomes, learnings, re-plan]
+  q1 --> q1mbrs[Q1 MBRs: monthly operational]
+  q1 --> q2[Q2 QBR]
+  q2 --> q2mbrs[Q2 MBRs]
+  annual --> board[Quarterly board meetings]
+  q1 --> board
+  q2 --> board
+  ah[All-hands: monthly communication] -.broadcasts.-> everyone[The whole company]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Engineering absent from annual planning | "We just build what's asked" | The AOP defines what you'll work on; show up early and shape it. |
+| Bringing operational details to QBR | Default to what you know | Translate to business outcomes; leave engineering details to MBR. |
+| KPIs disguised as OKRs | Confusion of intent | OKRs are change goals; KPIs are operational metrics. Separate. |
+| Missing the cadence calendar | "I wasn't told" | The cadence is public; ask for it and put it in your calendar. |
+| Treating board meetings as theatre | "Board doesn't get involved in details" | Board questions surface strategic concerns; track and address them. |
+
+## Exercises
+
+1. Find your company's operating cadence calendar. If you can't find it, ask your manager to walk you through the annual rhythm. Many engineers have never seen it laid out.
+2. Read the last board deck (or annual plan, if accessible). Identify the engineering asks and commitments. Note any gaps between what your team is doing and what the company committed externally.
+3. For your own team's OKRs, classify each KR as "actual change goal" or "steady-state KPI in disguise." Most teams find 30-50% are disguised KPIs. Rewrite at least one to be a genuine change goal.
+
+## Recap & next
+
+- The operating cadence runs at three time scales: annual (planning), quarterly (QBRs, board), monthly (MBRs, all-hands).
+- OKRs are change goals; KPIs are operational metrics. They're different tools for different purposes.
+- What to bring to each forum differs sharply by audience and scope.
+- Engineering presence in strategic forums (especially annual planning and QBR) shapes what gets funded and prioritised.
+
+Next, **Org design as you scale** - how the org chart silently sets strategy, and why Conway's law runs in both directions.
+{% endraw %}
diff --git a/_courses/engineers-mba/04-operating-a-software-business/03-org-design.md b/_courses/engineers-mba/04-operating-a-software-business/03-org-design.md
new file mode 100644
index 0000000..636c976
--- /dev/null
+++ b/_courses/engineers-mba/04-operating-a-software-business/03-org-design.md
@@ -0,0 +1,218 @@
+---
+chapter_id: 3
+chapter_slug: org-design
+chapter_title: "Org design as you scale"
+chapter_summary: "Compares functional/divisional/matrix structures, introduces two-pizza teams and spans/layers, and uses Conway's law to explain why org design is a strategic lever. Discusses reorg costs and when reorgs help vs harm."
+---
+
+{% raw %}
+## What you'll learn
+- The three canonical org structures - functional, divisional (product-line), matrix - and what each is good at.
+- Two-pizza teams, spans and layers, and the geometry of how many people one manager can run.
+- Conway's law and its inverse, and why org design is a strategic choice not an HR detail.
+- The signs that an org needs to reorganise and the costs of doing it.
+
+## Concepts
+
+The org chart is one of the most under-respected strategic documents in any company. It silently determines what gets built, what gets neglected, what conversations are easy, and what conversations are nearly impossible. Engineers who don't read the org chart strategically miss most of the operational truth of their company.
+
+### The three canonical structures
+
+**Functional.** People grouped by *function*: engineering, product, design, sales, marketing, finance. Each function has its own leadership. Cross-functional work happens via coordination meetings and shared OKRs.
+
+Strengths: deep functional expertise, efficient career ladders, clear specialisation. Most useful when the company has *one product* and *one customer segment*.
+
+Weaknesses: cross-functional coordination is expensive. Functions optimise for their own metrics, not for the business outcome.
+
+**Divisional / product-line.** People grouped by *product or business unit*: each division has its own engineering, product, design, marketing, sales. Divisions operate semi-independently with shared services (finance, HR, sometimes platform).
+
+Strengths: faster product velocity, clearer ownership, easier accountability. Most useful when the company has *multiple products* or *multiple customer segments* that operate differently.
+
+Weaknesses: duplicated effort, divergent technical decisions, organisational politics over shared resources.
+
+**Matrix.** People report to *both* a functional manager and a product/division manager. The functional manager owns career growth and craft; the product manager owns delivery and outcomes.
+
+Strengths: combines functional depth with product accountability. Most useful when products need shared infrastructure but have distinct customer focus.
+
+Weaknesses: dual reporting is confusing, decision-making slower, perceived political. Many companies adopt matrix in name but operate functionally or divisionally underneath.
+
+Most large software companies *evolve* through these structures:
+
+1. **Early stage (0-50 people):** flat, ad-hoc. Roles are fluid.
+2. **Functional (50-300):** product, engineering, sales, marketing have clear boundaries.
+3. **Hybrid functional-divisional (300-1000):** product engineering organised by product line, but platform/infra/security remain functional.
+4. **Matrix or full divisional (1000+):** business units have full P&L responsibility; only true platform stays shared.
+
+### Two-pizza teams
+
+Amazon's leadership principle that no team should be larger than two pizzas can feed (5-9 people). The constraint forces:
+- Small, focused teams with clear scope
+- Each team owns a service, deployment, and on-call
+- Inter-team contracts via API, not shared code
+- Decision velocity is high; coordination overhead is low
+
+Two-pizza teams scale well because the *team* is the unit of organisation. Adding people means adding teams, not enlarging them. The pattern works best when service boundaries align with business boundaries (Conway's law, below).
+
+The downside: small teams need to be self-sufficient on many dimensions, which requires investment in platforms, tooling, and shared infrastructure. Two-pizza teams without good platforms produce duplicated infrastructure across the company.
+
+### Spans and layers
+
+**Span of control** = number of direct reports per manager. **Layers** = number of management levels from CEO to IC.
+
+The empirical findings:
+- Span of 5-9 is the sweet spot for engineering management
+- More than 9 directs and the manager loses depth on each report
+- Fewer than 5 directs and the manager has too little to do (often a sign of an unnecessary layer)
+- 7-10 layers is typical at 10k employees; 4-5 layers at 1k; 3-4 at 200
+
+Each layer adds:
+- Communication delay (information takes longer to propagate up and down)
+- Translation loss (the message changes at each layer)
+- Bureaucratic overhead (each layer wants to be involved in decisions)
+- Career stagnation (slow promotion velocity)
+
+The trade-off: more layers = more management capacity, but slower decisions. The right number is whatever supports your decision velocity.
+
+### Conway's law
+
+> "Organisations design systems that mirror their communication structure."
+> - Melvin Conway, 1968
+
+The system architecture and the org chart converge. A company with three teams will produce a system with three major components and interfaces matching their team boundaries. A company that reorganises into product divisions will, within 12-18 months, see its architecture restructure along those lines.
+
+The inverse is even more useful: *if you want a specific architecture, design the org chart accordingly*. Want microservices with clean APIs between them? Form teams owning each service. Want a monolith with tight integration? Form one large team. The architecture follows the org.
+
+This insight is one of the most underused tools in engineering leadership. Reorganisations are often done for HR/management reasons; the strategic version is to reorganise to *enable* an architecture or product strategy.
+
+Example: many companies migrating from monolith to microservices fail because they reorganise the codebase without reorganising the teams. The result is microservices that are jointly owned (or unclearly owned), which is worse than a single monolith.
+
+### Reorgs: when and why
+
+Reorgs happen for several reasons:
+
+| Reason | Quality |
+|---|---|
+| Architecture/strategy shift | Often good |
+| New leadership wants to leave a mark | Often bad |
+| Performance management at scale | Sometimes necessary |
+| Mergers and acquisitions | Necessary but disruptive |
+| Decision velocity has slowed | Often good |
+| Customer segment expansion | Often good |
+
+Reorg costs are usually underestimated:
+- 6-12 months of slowed delivery
+- Some attrition of senior people who land badly
+- Erosion of trust in leadership if reorgs are frequent
+- Knowledge loss as relationships re-form
+- Reinvestment in tools, processes, runbooks per the new structure
+
+The empirical guidance: reorgs should be rare (every 18-24 months at most), explicitly tied to a strategic shift, and communicated with the *reasoning* not just the new chart.
+
+### Reading the org chart
+
+A useful exercise: read the org chart, looking for these structural features:
+
+| Pattern | What it suggests |
+|---|---|
+| Engineering reports through Product | Product-led culture |
+| Engineering reports separately to CEO | Engineering-led culture, often platform-heavy |
+| Sales reports directly to CEO | Sales-led culture |
+| Customer Success in Sales | Revenue-focused CS (renewal-driven) |
+| Customer Success in Product/Eng | Product-focused CS (success-driven) |
+| Platform team owns CI/CD | Platform investment is real |
+| No platform team | Either too small or in for trouble |
+| 12+ direct reports to CEO | Often a transitional state; layer addition coming |
+| Disproportionate G&A | Often a sign of operational dysfunction |
+
+The org chart is the strategy in human form. A skeptic reading the org chart can often predict the next year's priorities without reading any planning documents.
+
+## Walkthrough
+
+A worked transition. A 200-person SaaS company at $30M ARR is reorganising. Current structure:
+
+```text
+CEO
+├── Eng (40 people, functional)
+│   ├── Frontend
+│   ├── Backend
+│   ├── Mobile
+│   ├── Platform
+│   └── QA
+├── Product
+├── Design
+├── Sales
+├── Marketing
+└── CS
+```
+
+Problems:
+- Cross-functional coordination is slow
+- Backend team is a bottleneck for everything
+- Product roadmap items take 3+ teams to ship
+- Customer feedback gets diluted across many engineering teams
+
+The proposal: reorganise into three product-line teams, each with its own frontend, backend, design, and product, plus a shared platform team.
+
+```text
+CEO
+├── Product Eng (3 product lines: Core, Integrations, Analytics)
+│   ├── Core (8 people: frontend, backend, design, PM)
+│   ├── Integrations (8 people: similar mix)
+│   └── Analytics (8 people: similar mix)
+├── Platform Eng (10 people: shared infra, tooling, mobile core)
+├── Design (centralized leadership; ICs embedded in product lines)
+├── Sales
+└── ...
+```
+
+Trade-offs of the new structure:
+
+| Gain | Cost |
+|---|---|
+| Each product team owns the full stack | Some duplicated engineering (3 frontend teams) |
+| Faster product velocity | Less depth in functional craft |
+| Clearer ownership and accountability | Mobile expertise consolidates in platform - slower for product teams |
+| Customer feedback maps to single owner | Some technical debt risk per product line |
+
+This is a *Conway's law-aware* reorg: the team structure is being designed to produce the product architecture. The platform-team carve-out is a strategic decision - shared infrastructure will be owned by a dedicated team, preventing duplication.
+
+The reorg will cost 6-9 months of delivery slowdown. The argument for doing it: the current functional structure is the bottleneck for the next $30M of ARR. If the diagnosis is wrong, the company gets the slowdown without the benefit.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  strategy[Product / customer strategy] --> org[Org chart]
+  org --> teams[Team boundaries]
+  teams -->|Conway's law| arch[System architecture]
+  arch --> velocity[Decision & ship velocity]
+  velocity --> strategy
+  org --> spans[Spans, layers, reporting structure]
+  spans --> comms[Communication patterns]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Reorg without strategy shift | Defaulted to "things feel slow" | Tie every reorg to a specific outcome you can measure 12 months later. |
+| Architectural change without org change | "We'll just restructure the code" | The team structure has to support the architecture; Conway's law is real. |
+| Excess layers | Each promotion adds one | Audit periodically; flatten when spans drop below 5. |
+| Matrix in name only | "We'll just say it's matrix" | A matrix that operates as a functional org has matrix overhead with functional weaknesses. |
+| Reorging every 6 months | New leadership keeps re-shuffling | Reorgs should be every 18-24 months max; more often signals leadership churn. |
+
+## Exercises
+
+1. Draw your company's org chart from memory. Compare with the official version. Note where your team's actual collaboration patterns don't match the chart - these are usually informal coordination channels worth understanding.
+2. Identify three engineering decisions in the last year that were silently shaped by org structure (e.g. "we built this service because Team X owned this layer"). Note how a different org would have produced different decisions.
+3. For an architectural change your team wants to make, ask: does the org chart support this architecture? If not, can the org be adjusted, or does the architecture need to change?
+
+## Recap & next
+
+- Three canonical structures - functional, divisional, matrix - fit different stages and strategies.
+- Two-pizza teams scale via service ownership; spans of 5-9 are the sweet spot.
+- Conway's law: the org chart and the architecture converge. The inverse is a strategic tool.
+- Reorgs cost 6-12 months of velocity; tie them to strategic shifts, not to leadership preference.
+
+Next, **Headcount, capacity & the cost of an engineer** - why hiring is a multi-million-dollar strategic decision.
+{% endraw %}
diff --git a/_courses/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.md b/_courses/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.md
new file mode 100644
index 0000000..effb8cd
--- /dev/null
+++ b/_courses/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.md
@@ -0,0 +1,192 @@
+---
+chapter_id: 4
+chapter_slug: headcount-and-cost-of-engineer
+chapter_title: "Headcount, capacity & the cost of an engineer"
+chapter_summary: "Builds the fully-loaded engineering cost model and distinguishes capacity from velocity. Treats headcount as multi-million-dollar capital allocation and walks through hiring lead times and ramp curves."
+---
+
+{% raw %}
+## What you'll learn
+- The fully-loaded cost of an engineer - what goes into the number beyond base salary.
+- The difference between *capacity* and *velocity* and why mistaking one for the other causes chronic over-commitment.
+- Hiring lead times, ramp curves, and why "we'll hire faster" isn't a real plan.
+- Headcount as a capital decision: why one engineering hire is structurally a multi-million-dollar commitment.
+
+## Concepts
+
+Engineers experience headcount decisions as HR events. From a business perspective, they're capital decisions. A senior engineer at a US tech company is a 3-5 year commitment of ~$400-500k/year fully-loaded - easily $1.5-2.5M in capital deployed per hire. By that math, the question "should we hire 3 more engineers?" is the same capital allocation question as "should we spend $5M on a new product line?" - and should get the same level of analytical rigour.
+
+Most companies don't treat it this way. Headcount sneaks past board approval as "operating expense growth" while a $5M cap-ex project requires a memo and a vote. The asymmetry is one of the structural inefficiencies of how software companies are run.
+
+### Fully-loaded cost
+
+The visible cost of an engineer is base salary. The fully-loaded cost is several multiples of that. A US-based senior engineer at a typical SaaS company might look like:
+
+```text
+Base salary                                $200,000
+Bonus (target)                              $30,000
+Equity (annual vest, fair-value at grant)   $80,000
+Employer payroll taxes (~7.65% + state)      $18,000
+Health benefits (~$10-25k depending on family)  $18,000
+401k match (3-6%)                             $9,000
+Other benefits (life, disability, FSA, etc)   $5,000
+                                            ────────
+Direct comp + benefits                    $360,000
+
+Allocated overhead:
+  Office, equipment, software licenses      $15,000
+  HR, recruiting, IT, finance allocation    $20,000
+  Engineering management/leadership            $30,000
+                                            ────────
+Fully-loaded annual cost                  $425,000
+```
+
+The number varies by role, location, and company. Levels.fyi-style total comp is closer to "comp" than "fully-loaded." A staff engineer at a top tech company costs the company ~$700k-1M/year fully-loaded. A junior engineer in a lower-cost region might be ~$150k.
+
+When engineers compute "is this project worth it?" they almost always use comp, not fully-loaded cost. The factor is typically 1.5-2x. A project that "costs 2 engineers × 6 months = $200k of salary" is closer to $400k of capital.
+
+### Capacity vs. velocity
+
+A confusion that drives chronic over-commitment.
+
+**Capacity** = the maximum amount of work the team *can* do under ideal conditions.
+
+**Velocity** = the *sustained* rate of work the team actually produces over time.
+
+These differ by 30-60% for most engineering teams. The reasons:
+- Time spent on operational work (oncall, support, bugs)
+- Time spent on coordination (meetings, reviews)
+- Time spent on hiring, mentoring, document writing
+- Recovery time from intensive sprints
+- Holidays, sick days, time off
+
+A team of 6 engineers has *capacity* of ~6 × 50 hours/week × 50 weeks = 15,000 person-hours/year. Its *velocity* is typically 6,000-8,000 useful person-hours/year of net-new feature work. The remainder is the support and operational work that keeps the company running.
+
+Planning based on capacity is the cause of most engineering over-commitment. The fix is straightforward: plan based on observed velocity, not theoretical capacity, and reserve 30-40% for non-feature work.
+
+### Hiring lead times
+
+"We'll hire" is rarely a fast answer to a capacity gap. Empirically:
+
+| Role | Time from open req to seated | Time to productive |
+|---|---|---|
+| Junior engineer | 6-8 weeks | 2-3 months |
+| Mid-level engineer | 8-12 weeks | 3-4 months |
+| Senior engineer | 12-20 weeks | 4-6 months |
+| Staff/principal | 16-24 weeks | 6-9 months |
+| Engineering manager | 12-20 weeks | 3-6 months |
+
+The "time to productive" is when the new hire is producing *net positive* value - accounting for the time existing engineers spend onboarding them, the slowdown from their early code, and the time they spend learning. Most new senior engineers don't break even until month 4-6.
+
+The implication: "we'll hire 5 more engineers and be back on schedule" is rarely a real plan. By the time the engineers are productive, the gap has compounded. Hiring is a 6-12 month investment in *next year's* capacity, not a fix for this quarter's gap.
+
+### Headcount as a capital decision
+
+A useful reframing: a hiring decision is a multi-year capital commitment. The structural framing:
+
+- Hiring 1 senior engineer = $400-500k/year × ~3-5 years = $1.5-2.5M
+- Hiring a team of 5 = $7-12M of capital allocated to one product/area
+- The reversal cost is significant: layoffs damage culture, the company's hiring brand, and morale for years
+
+For comparison: a $5M capex project on physical infrastructure would require a board memo, sponsor, ROI analysis, and explicit approval. The hiring decision, of equivalent capital cost, often goes through as "engineering team expansion for the year" with little equivalent scrutiny.
+
+The corrective discipline: treat headcount requests with the same rigour as cap-ex. Each request should answer:
+
+- What outcome does this team enable that we can't otherwise achieve?
+- What's the expected ROI? (Hard to compute, worth attempting.)
+- What's the alternative use of this capital?
+- What's the kill criteria if it doesn't work?
+
+Some companies (Stripe, Notion, others) explicitly model headcount as capital allocation. Many don't, and the structural inefficiency shows up in over-hiring during bull markets and painful layoffs during bear markets.
+
+### What a feature actually costs
+
+A useful exercise: cost a feature accurately.
+
+```text
+Feature: SSO/SAML integration
+
+Engineering: 2 senior engineers × 3 months
+  = $400k × 2 × 0.25 = $200k loaded cost
+Product: 1 PM × 1 month
+  = $250k × 0.083 = $21k
+Design: 1 designer × 2 weeks
+  = $200k × 0.04 = $8k
+QA: 1 engineer × 3 weeks
+  = $250k × 0.06 = $15k
+Documentation: tech writer × 2 weeks
+  = $200k × 0.04 = $8k
+Customer support training: support team × 5 hours each (10 people)
+  = $100k × 0.0025 × 10 = $2.5k
+Sales training: sales team briefing
+  = $5k of time
+Marketing materials, launch content
+  = $10k
+
+Total: ~$270k for the feature
+
+Annual maintenance: ~$30k/year (debt, bugs, evolution)
+```
+
+The feature cost $270k, with ongoing maintenance of $30k/year. If the feature enables $1M of enterprise ARR over the next year, the math works. If it enables less, or if it could have been delivered by a $50k SaaS integration, the build decision was wrong.
+
+The exercise alone improves engineering's strategic conversations. Most engineering teams have never costed a feature accurately, which is one reason "build vs buy" debates lean reflexively to build.
+
+## Walkthrough
+
+A worked headcount conversation. The CEO asks the VP Eng: "Can you ship the new analytics product by Q3?"
+
+**The honest answer:**
+> "Currently the platform team is 6 engineers. Velocity is ~6,000 hours/year of net feature work. The analytics product is estimated at ~12,000 hours of net feature work. That's two years of velocity at current size, or one year if we double the team.
+>
+> To double the team, we need to hire 6 senior engineers. At 16-week req-to-seated and 4-month time-to-productive, that's 8 months before they're producing useful work. So a 'double the team' plan reaches productive size around Q2 next year, and ships Q3 next year - not this Q3.
+>
+> Alternative options:
+> 1. Ship the analytics product Q4 next year with current team size (more realistic).
+> 2. Ship a minimum version Q3 this year with current team, full version a year later.
+> 3. Acquire a small analytics startup ($5-10M, see [Module 2 Chapter 4](/courses/engineers-mba/02-strategy/04-build-buy-partner/)) - possibly faster to market.
+> 4. Pull from other product teams temporarily, accepting their roadmaps slip.
+>
+> My recommendation: option 2 (MVP Q3 + full Q3 next year). Option 3 is worth investigating in parallel."
+
+This response reframes "can we hire to fix this?" as a real cost conversation. Most VPs are bad at this framing. The ones who get good at it become CTOs and CEOs.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  ask[Strategic ask: ship feature X] --> work[Estimate of net-feature work]
+  team[Team size] --> velocity[Observed velocity]
+  velocity --> achievable[Achievable in T months]
+  hire[Hire more] -.lead time + ramp.-> future[Available in T+8 months]
+  buy[Acquire / partner] -.faster.-> alt[Alternative path]
+  achievable --> decide{Decision}
+  future --> decide
+  alt --> decide
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Using comp instead of fully-loaded cost | Visible number, easy default | Fully-loaded is 1.5-2x comp; use it in business cases. |
+| Planning by capacity not velocity | Engineering optimism | Use observed velocity; reserve 30-40% for non-feature work. |
+| "We'll hire faster" as a plan | Wishful | Hires take 6-12 months to be net positive; not a quarterly fix. |
+| Skipping headcount business cases | "It's just OpEx growth" | Treat each hire as multi-million-dollar capital allocation; require ROI rationale. |
+| Confusing layoffs with cost recovery | "We saved $X" | Layoffs damage hiring brand, culture, and trust for 12-24 months; the net cost is larger. |
+
+## Exercises
+
+1. Compute the fully-loaded cost of one of your engineers (your own salary, or a typical senior). Compare with the comp.fyi median for that level. The factor is usually 1.5-2x; verify for your company.
+2. For your team, compute observed velocity over the last 4 quarters. Then compare with "capacity" (theoretical). The gap is your non-feature work load - often 30-50%.
+3. For one feature shipped in the last year, cost it accurately using the model above. Then estimate the business outcome it produced. The ratio is your true ROI.
+
+## Recap & next
+
+- Fully-loaded engineering cost is 1.5-2x base comp; planning at base understates capital commitment.
+- Capacity is the theoretical max; velocity is the sustained rate. They differ by 30-50% on most teams.
+- Hiring lead times are 3-9 months by level, with 4-6 months ramp to productive contribution.
+- A headcount decision is a multi-million-dollar capital commitment; treat it with the rigour of a cap-ex project.
+
+Next, **Vendor economics & build-vs-buy at scale** - the real math behind "let's build it ourselves," with TCO, switching costs, and integration debt.
+{% endraw %}
diff --git a/_courses/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.md b/_courses/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.md
new file mode 100644
index 0000000..63b6fcb
--- /dev/null
+++ b/_courses/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.md
@@ -0,0 +1,216 @@
+---
+chapter_id: 5
+chapter_slug: build-vs-buy-economics
+chapter_title: "Vendor economics & build-vs-buy at scale"
+chapter_summary: "Uses 3-year TCO comparisons to show why build typically loses for commoditised or regulated capabilities. Covers switching costs, integration debt, and vendor concentration risk with worked Stripe vs build-payments example."
+---
+
+{% raw %}
+## What you'll learn
+- Total Cost of Ownership (TCO) - what to include and what's commonly missed.
+- Switching costs, integration debt, and the lock-in math that makes vendor choices semi-permanent.
+- Vendor concentration risk and how to manage it.
+- The narrow cases where "build it ourselves" actually wins.
+
+## Concepts
+
+The engineering "build vs. buy" question gets revisited about once a year per major tool. The naive version compares "annual SaaS subscription" to "engineering cost to build." The strategic version is much harder - and almost always weighted further toward "buy" than the naive comparison suggests.
+
+### Total Cost of Ownership (TCO)
+
+TCO is the *complete* cost of a tool over its useful life, including hidden costs. The textbook breakdown:
+
+| Cost type | Captures | Often missed |
+|---|---|---|
+| License / subscription | Direct vendor invoice | - |
+| Implementation | Setup, customisation, integration work | Cross-functional time, change management |
+| Operation | Ongoing administration, monitoring | Manager time, sprawl across teams |
+| Training | Onboarding to the tool | Repeat training as the tool evolves |
+| Support contracts | Premium support / dedicated CSM | Internal "support of the support" |
+| Compliance / audit | Security and audit overhead | Renewal-cycle reviews, SOC2 questionnaires |
+| Switching costs | When you eventually leave | Almost always omitted from initial analysis |
+
+For SaaS tools, the rule of thumb: the 3-year TCO is 1.5-2x the visible subscription cost. For complex tools (CRMs, ERPs, identity providers), 3-year TCO can be 3-5x. For "build it ourselves," the multiplier is much higher because operational and switching costs are dramatic.
+
+### Build vs. buy: the real math
+
+The build case is almost always understated. Here's the typical TCO comparison for a hypothetical "internal auth system":
+
+```text
+Option A: Use Auth0 / Okta-style identity provider
+  Year 1: $50k subscription + $40k integration work = $90k
+  Year 2: $60k subscription + $10k upkeep = $70k
+  Year 3: $70k subscription + $10k upkeep = $80k
+  3-year TCO: $240k
+
+Option B: Build internal auth
+  Year 1: 2 engineers × 9 months @ $450k loaded = $675k
+  Year 2: 1 engineer × full-year for ongoing dev/support = $450k
+  Year 3: 1 engineer × full-year (security patches, OIDC updates,
+          MFA, audit log, etc) = $450k
+  3-year TCO: $1.575M
+
+  Plus: opportunity cost of those engineers not building product.
+  Plus: ongoing maintenance burden ~$200k/year past Year 3.
+  Plus: switching cost if we ever want to migrate later.
+```
+
+Build is 6-7x the TCO of buy in this example. The naive comparison ("$50k subscription vs. building it") gets the magnitude wrong by an order of magnitude.
+
+Engineers reflexively underestimate build because:
+- Ongoing maintenance gets compressed into "we'll keep it up to date" without sizing.
+- Edge cases (compliance, audit, MFA, federation) aren't anticipated.
+- The "we'll build a quick MVP" path leaves out the long tail of features the vendor already has.
+- Opportunity cost (these engineers not building product) isn't priced in.
+
+### When build does win
+
+Build occasionally is the right answer. The cases:
+
+1. **The capability is core to the product's strategic value.** If "great authentication" is what differentiates the product, building it is justified.
+2. **The unit economics demand it.** At very high volumes, the marginal cost of a vendor's pricing becomes prohibitive vs. amortising a build. AWS S3 is an existence proof - eventually scale makes the buy decision flip back.
+3. **The vendor can't meet a specific requirement.** Compliance, latency, geographic, integration depth that no vendor offers.
+4. **The vendor is unreliable or will go away.** Vendor risk is real; if the only vendor in a category is a 10-person startup, build the critical path internally.
+5. **Switching from a vendor we have to leave.** This is a forced build, not a choice.
+
+The pattern: build for things that are core differentiators or where vendor economics genuinely don't work at scale. Buy for everything else.
+
+### Integration debt
+
+When a SaaS vendor is integrated into your product, the integration accumulates as debt over time:
+
+- API contracts may change
+- The vendor may deprecate features you use
+- Auth and rate-limit assumptions get baked in
+- Custom logic written around vendor quirks accumulates
+- The "thin wrapper" you wrote becomes the "thick wrapper" no one wants to touch
+
+Integration debt usually surfaces during:
+- Vendor pricing changes (you're trapped)
+- Vendor outages (you have no fallback)
+- Vendor acquisition (terms change)
+- Vendor end-of-life (you must migrate)
+
+Mitigation: thin abstractions over each external vendor, with the abstraction matching your domain rather than the vendor's API. This is more work upfront but pays dividends when the vendor switches change.
+
+### Switching costs
+
+The cost of moving from vendor X to vendor Y. The components:
+
+- **Data migration.** Moving accumulated state. Can be huge for stateful systems (CRM, observability, code hosting).
+- **Integration re-work.** Every integration written to X must be re-written to Y.
+- **Training re-cost.** Users learn the new tool.
+- **Operational delta.** Two vendors run in parallel during the cutover.
+- **Risk premium.** The new vendor may turn out to be worse; switching back is also costly.
+
+Switching costs are why vendor decisions are semi-permanent. The de facto "we'll switch when we need to" assumption is rarely accurate - most "we'll switch" plans never execute because the switching cost outweighs any annual savings.
+
+### Vendor concentration risk
+
+Relying on a single vendor for critical functionality creates concentration risk:
+
+- The vendor can change pricing (recent example: Twilio's 10x SMS pricing increase in some markets).
+- The vendor can be acquired (Stripe Radar becoming part of a different company).
+- The vendor can go down (every cloud outage tells this story).
+- The vendor can change strategic direction (Meta deprecating APIs).
+
+Mitigation strategies:
+- **Multi-vendor by design** for critical path. Multi-cloud is the macro version; multi-CDN is the micro version.
+- **Active second-source** - even if you don't use it daily, maintain a tested path.
+- **Contractual protections** - price-cap clauses, deprecation notice clauses, data-portability clauses.
+
+The 2022-2024 era taught many companies that "single vendor is fine" was an unhedged risk. Multi-vendor was suddenly important when vendors raised prices and customers were locked in.
+
+### Build / buy / partner - revisited from the engineering side
+
+[Module 2 Chapter 4](/courses/engineers-mba/02-strategy/04-build-buy-partner/) covered build/buy/partner at the strategic level (acquisitions, market entry). The engineering-level version is the same question for individual capabilities. The framework:
+
+| Capability type | Default choice |
+|---|---|
+| Core to product differentiation | Build |
+| Commodity infrastructure | Buy or use cloud |
+| Industry-standard (SSO, payments, email) | Buy |
+| Specific regulatory or compliance need | Build only if no compliant vendor exists |
+| Internal developer tooling | Buy first, build only if no vendor fits |
+| Emerging tech (AI, etc.) | Partner first, build later |
+
+The pattern: build the moat-relevant work; buy or partner everything else. Engineering teams that build everything end up with an internal ecosystem of half-built infrastructure that's worse than the vendor versions and consumes 30-40% of engineering capacity.
+
+## Walkthrough
+
+A worked decision. A SaaS company is choosing between using Stripe and building an internal payment processor.
+
+```text
+Option A: Use Stripe
+  Stripe fees: 2.9% + $0.30 per transaction
+  At $50M ARR: ~$1.5M/year in Stripe fees
+  Engineering: 1 engineer × 3 months to integrate = $112k
+  Ongoing: 0.25 engineer for maintenance = $112k/year
+
+  3-year TCO: ~$5M + $336k engineering = $5.3M
+
+Option B: Build internal payment processor
+  Engineering: 8 engineers × 18 months = $5.4M
+  Compliance: PCI DSS Level 1 certification = $200k initial, $100k/year
+  Banking relationships: Setup $500k, maintenance complex
+  Ongoing: 4 engineers full-time = $1.8M/year
+  Card-network agreements (Visa, Mastercard): not feasible at this scale
+  Fraud detection, dispute resolution, settlement: $1M+ to build
+
+  Year-1 build cost: $7-8M
+  Annual operating cost: $2-3M
+  3-year TCO: ~$15-20M
+  
+  Result: 3-5x more expensive than Stripe, with significant operational risk.
+```
+
+The build case is wildly unfavourable. Reasons:
+- Payments are not the company's differentiator.
+- Compliance overhead (PCI DSS) is structural and expensive.
+- Card-network agreements are gated at scale most companies don't reach.
+- Fraud, disputes, settlement are entire engineering disciplines.
+
+The case for buy is overwhelming. The pattern is general: deeply commoditised, deeply regulated, and operationally complex categories should almost always be bought. Stripe, identity providers (Auth0/Okta), email (SendGrid/Postmark), error tracking (Sentry), feature flags (LaunchDarkly), and payments are the classics.
+
+The build winners: companies where the capability *is* the product (Stripe building its own infrastructure for payments).
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  capability[Capability needed] --> classify{Core differentiator?}
+  classify -->|Yes| build[Build]
+  classify -->|No| commodity{Commodity / regulated?}
+  commodity -->|Yes| buy[Buy SaaS]
+  commodity -->|No| evaluate{Vendor fit?}
+  evaluate -->|Yes| buy
+  evaluate -->|No| build
+  buy --> tco[3-year TCO + switching cost]
+  build --> opp[Ongoing cost + opportunity cost]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Comparing subscription to engineering build cost | Naive math | Use 3-year TCO with maintenance, switching, opportunity cost. |
+| Underestimating ongoing maintenance | "We'll keep it up to date" | A built system requires 0.5-1 FTE/year in steady state per substantial component. |
+| Ignoring switching costs in vendor choice | "We can switch later" | Switching costs make decisions semi-permanent. Choose carefully. |
+| Single-vendor for critical path | Speed/ease | Critical-path systems should have a second-source plan, even if not actively used. |
+| Build to learn (vs. build because we should) | "Engineering wants to" | Learning is a legitimate goal but not for production systems. |
+
+## Exercises
+
+1. Pick three SaaS tools your company uses. For each, estimate the 3-year TCO including hidden costs. Compare to the visible subscription. The factor is usually 1.5-3x.
+2. Identify one capability your team built that, in retrospect, should have been bought. What was the rationale at the time? What's the cumulative cost of the build decision so far?
+3. For your tier of SaaS vendors, identify which are *concentration risks* - vendors where a price change, outage, or acquisition would seriously damage you. Map the second-source options for the top 3.
+
+## Recap & next
+
+- TCO is 1.5-2x the visible subscription for SaaS; 3-5x or more for build.
+- Build is rarely the right answer for commoditised or regulated capabilities; buy for those, build for differentiators.
+- Switching costs make vendor decisions semi-permanent; choose with the next 5 years in mind.
+- Vendor concentration is a structural risk worth actively managing for critical-path systems.
+
+Next, kicking off **Module 5 - Capital, Risk & Decisions Under Uncertainty**, starting with **Capital allocation: how exec teams actually choose**.
+{% endraw %}
diff --git a/_courses/engineers-mba/05-capital-risk-decisions/01-capital-allocation.md b/_courses/engineers-mba/05-capital-risk-decisions/01-capital-allocation.md
new file mode 100644
index 0000000..e96979c
--- /dev/null
+++ b/_courses/engineers-mba/05-capital-risk-decisions/01-capital-allocation.md
@@ -0,0 +1,190 @@
+---
+chapter_id: 1
+chapter_slug: capital-allocation
+chapter_title: "Capital allocation: how exec teams actually choose"
+chapter_summary: "Explains the implicit ROI bar at different company stages, opportunity cost, and sunk-cost trap. Critiques prioritisation frameworks (RICE, ICE) as conversation tools rather than decision rules; emphasises asymmetric bet sizing."
+---
+
+{% raw %}
+## What you'll learn
+- Why a company's available capital is *always* less than the worthwhile projects competing for it.
+- The implicit ROI bar - how exec teams compare apples-to-oranges projects, and what your project needs to clear.
+- Opportunity cost, sunk-cost traps, and the difference between cancelling and pausing.
+- Why most prioritisation frameworks (RICE, ICE, MoSCoW) underdeliver, and what successful teams do instead.
+
+## Concepts
+
+Capital allocation is the question every leadership team revisits, formally or informally, every quarter: *given finite capital, where should we put it?* The capital can be cash (literal $), engineering capacity (engineer-quarters), or executive attention (the scarcest resource at most large companies).
+
+The corollary every engineer needs to internalise: there is *always* less capital than worthwhile projects. The question is never "is this project worth doing?" - it's "is this project worth doing *more than* the alternatives?" Many engineering proposals get approved or rejected on the second question without anyone explicitly stating it.
+
+### The implicit ROI bar
+
+Every exec team has an *implicit* ROI bar - the minimum return a project must clear to get funded. The bar isn't usually written down. It's discovered by watching what gets approved and what doesn't.
+
+Common shape of the bar at different company stages:
+
+| Stage | Typical implicit ROI bar |
+|---|---|
+| Startup (pre-PMF) | Survival / learning. Almost anything that materially de-risks the business. |
+| Growth-stage SaaS | 3-5x return over 2-3 years; or sub-18-month payback; or strategic learning. |
+| Mature SaaS | 4-6x return over 3-5 years; harder requirements for strategic bets. |
+| Public / mature | NPV-positive with risk-adjusted hurdle rates; bar varies by horizon. |
+
+Engineering projects rarely articulate ROI explicitly. The implicit framing is: *would this customer have churned without this?*, *would this deal close faster?*, *would we hire fewer engineers in five years if we built this platform?*
+
+The skill engineers need: estimate the ROI of their work *before* asking for funding. Most engineering proposals don't do this. Most proposals that do, get funded.
+
+### Opportunity cost
+
+The real cost of any project is the *next-best project* you didn't do because you did this one.
+
+If your team can ship two of: (A) a new feature, (B) a reliability improvement, (C) a platform migration - choosing A means giving up the next-best of B or C. The cost of A isn't its build cost; it's its build cost *plus the opportunity cost*.
+
+This is why senior engineers and managers sometimes seem irrationally negative about good projects: they're not comparing the project to "doing nothing" - they're comparing it to what *else* the team could do.
+
+A useful discipline: when proposing a project, always include "what we won't do if we do this" in the proposal. Most teams find this exercise surfaces an alternative that's better than the original proposal.
+
+### Sunk-cost trap
+
+When a project has consumed significant resources, there's organisational gravity to keep going. *We've already spent $5M; we can't just stop.* This is the sunk-cost fallacy in action.
+
+The rational analysis is forward-looking: from now, given what we know, is finishing this project the best use of the remaining capital? Sometimes yes; sometimes no. The $5M already spent is irrelevant either way - it's gone regardless of the decision.
+
+Real-world examples:
+- The OS rewrite that's three years late and might never ship. Sunk cost says keep going. Forward analysis often says cut losses.
+- The data warehouse migration where the team has done 60% of the work but the original justification has evaporated. Sunk cost says finish. Forward analysis sometimes says park and revisit.
+- The acquisition that's not delivering the expected value. Sunk cost (and corporate ego) says keep investing. Forward analysis sometimes says "preserve standalone value and stop forcing integration."
+
+The discipline is brutal but correct: every project should be re-evaluated against its forward-looking ROI, not its history.
+
+### Sequencing investments
+
+A more subtle insight. Capital allocation isn't just "which projects?" - it's "in what *order*?"
+
+Sequencing matters because:
+- Early-stage projects de-risk later ones. Building the data infrastructure before the analytics product is sequencing 101.
+- Some projects compound returns. Network effects, brand, customer accumulation.
+- Some projects produce learning. The first 100 customers are worth more than the next 1000 because they teach you what the product needs to be.
+- Some windows close. Markets move; competitor entry; regulatory changes. A project worth $10M this year may be worth $1M next year.
+
+Common sequencing pattern at a SaaS company:
+
+```text
+Year 1: Build core product → reach product-market fit (small revenue)
+Year 2: Add table-stakes enterprise features (SSO, audit) → reach enterprise readiness
+Year 3: Build expansion features → drive NRR
+Year 4: Build adjacent products → expand TAM
+Year 5: Build platform → enable ecosystem
+```
+
+A team that tries to jump directly from Year 1 to Year 4 without the intermediate work usually finds the leaps fail. The platform without enterprise features doesn't get bought; the adjacent product without core PMF doesn't get adopted.
+
+### Why prioritisation frameworks underdeliver
+
+RICE, ICE, MoSCoW, weighted scoring matrices - these frameworks promise to make prioritisation rigorous. They mostly fail in practice because:
+
+1. **The scores are made up.** "Reach: 80, Impact: 7, Confidence: 60%" is rarely defensible. Teams optimise the scores rather than the underlying decisions.
+2. **They don't model dependencies.** Sequencing matters; a static score doesn't capture it.
+3. **They don't model strategic intent.** A project that scores low on user impact might be high on strategic value (e.g. enables a future product line).
+4. **They don't distinguish projects from initiatives.** A 6-month initiative is not directly comparable to a 6-week feature.
+5. **They imply objectivity that doesn't exist.** Prioritisation is fundamentally a judgement call.
+
+What works better:
+
+- **Top-down strategic guidance** from leadership, articulated in 1-2 paragraphs.
+- **Themes and bets** rather than individual feature scores. Each theme gets a capacity allocation.
+- **Explicit kill criteria** for in-flight bets.
+- **Periodic re-evaluation** rather than annual locked-in plans.
+
+The best teams use prioritisation frameworks as *conversation tools* (force the relevant questions) rather than *decision tools* (the score decides).
+
+### What good capital allocation looks like
+
+A few hallmarks:
+
+| Sign | What it means |
+|---|---|
+| Strategic narrative in every funding decision | Connects to a larger story |
+| Explicit kill criteria | Willingness to stop |
+| Re-evaluation cadence | Adjusting as you learn |
+| Asymmetric bet sizing | Big bets on conviction, small bets on uncertainty |
+| Tracked opportunity cost | What didn't get funded |
+| Clear connection to metrics | Tie to ARR, NRR, gross margin, etc. |
+
+A team or company that does all of these will allocate capital better than one that does none.
+
+## Walkthrough
+
+A worked decision. An engineering org has $15M of capital for the year (after fixed costs). Three projects compete:
+
+```text
+Project A: Build enterprise-grade audit log feature
+  Cost: $1.5M
+  ROI: Unblocks $8M of stalled enterprise pipeline; ~5x return
+  Strategic: Strong (enterprise positioning)
+  
+Project B: Migrate to a new infrastructure platform
+  Cost: $8M
+  ROI: Reduce annual infra spend by $2M; ~3x over 5 years
+  Strategic: Medium (enables future scale)
+  
+Project C: Build AI-powered customer-facing feature
+  Cost: $4M
+  ROI: Highly uncertain; possible 10x if it lands; possible 0
+  Strategic: Strong (positions as AI leader)
+  
+Total ask: $13.5M for the three projects → fits in the $15M budget
+```
+
+The naive answer: fund all three. But:
+
+- Project A is fundable on ROI alone - $1.5M for $8M of pipeline is a great deal.
+- Project B has a real ROI but a long payback. The 3x over 5 years is below the implicit bar of "3-5x in 2-3 years." It also competes against alternative uses of the $8M.
+- Project C is the highest-expected-value bet but also the highest variance. Funding it as a $4M investment with kill criteria at month 6 might be smart; funding it as a no-questions-asked commitment is risky.
+
+The execution decision might be: fund A fully, fund C with kill criteria, postpone B until either (a) infra spend gets worse or (b) the migration cost shrinks. The remaining capital becomes optionality for next quarter.
+
+This kind of analysis is what exec teams actually do, even if they don't always do it explicitly. Senior engineers who can think this way become high-impact.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  pool[Available capital pool] --> proposals[Project proposals]
+  proposals --> roi[ROI estimate per project]
+  proposals --> strat[Strategic fit]
+  proposals --> opp[Opportunity cost]
+  roi --> decide{Selection}
+  strat --> decide
+  opp --> decide
+  decide --> funded[Funded projects]
+  funded --> kill[Kill criteria + re-evaluation]
+  kill --> learn[Learning] --> proposals
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Estimating ROI without a baseline | "We'll improve X" without saying current X | Always include current state, target state, mechanism. |
+| Sunk-cost preservation | "We've already spent so much" | Re-evaluate forward, not backward. |
+| Treating every project as equally riskable | High-variance bets get diluted | Bet small on uncertain projects, big on conviction. |
+| Annual locked-in plans | "It's in the plan" defends bad projects | Quarterly re-evaluation with kill criteria. |
+| Score-driven prioritisation | Optimising scores not decisions | Use as conversation tool, not decision rule. |
+
+## Exercises
+
+1. For three projects your team has shipped, estimate the actual realised ROI (revenue moved, cost saved, churn avoided). Compare with the implicit case made at the time of funding. The gap is often educational.
+2. Identify one project your team is currently working on. Apply the forward-looking test: from where we are today, with what we now know, is finishing this the best use of remaining capital? Sometimes the answer is no.
+3. For your team's roadmap, write down each project's opportunity cost - "if we do this, we don't do __." Most teams find this exercise surfaces uncomfortable trade-offs.
+
+## Recap & next
+
+- Capital is always less than the worthwhile projects competing for it.
+- The implicit ROI bar varies by stage; learning to estimate ROI for engineering work is a high-leverage skill.
+- Opportunity cost and sunk-cost trap are the two structural errors that distort allocation.
+- Prioritisation frameworks (RICE, ICE) are conversation tools, not decision rules.
+
+Next, **Fundraising 101** - how the money gets into the company in the first place, and why your 409A matters to you personally.
+{% endraw %}
diff --git a/_courses/engineers-mba/05-capital-risk-decisions/02-fundraising-101.md b/_courses/engineers-mba/05-capital-risk-decisions/02-fundraising-101.md
new file mode 100644
index 0000000..493bd5f
--- /dev/null
+++ b/_courses/engineers-mba/05-capital-risk-decisions/02-fundraising-101.md
@@ -0,0 +1,227 @@
+---
+chapter_id: 2
+chapter_slug: fundraising-101
+chapter_title: "Fundraising 101"
+chapter_summary: "Walks through the standard funding round structure, pre/post-money math, dilution mechanics, and preferred vs common stock. Shows how 409A determines option strike price and includes worked exit-scenario analysis."
+---
+
+{% raw %}
+## What you'll learn
+- The standard funding round structure from seed through IPO, and what each round is *for*.
+- Pre-money vs. post-money valuations, dilution math, and the cap table.
+- Preferred vs. common stock and why the distinction matters at exit.
+- 409A valuations, option strike prices, and what they mean for your equity.
+
+## Concepts
+
+Software companies are unusual: they require lots of capital upfront to build product and acquire customers, but produce relatively little cash for years. The bridge between *capital needed* and *cash generated* is fundraising. Most engineers at startups encounter fundraising as a series of confusing emails and dilutive moments without understanding the structure.
+
+The structure matters. Your equity, your understanding of company runway, and your ability to read board-level signals all depend on knowing how the money flows.
+
+### The standard round structure
+
+Companies raise in a sequence of rounds. Each round has a typical purpose, size, and valuation pattern.
+
+| Round | Typical size | Purpose | Typical valuation |
+|---|---|---|---|
+| Pre-seed / friends-and-family | $100k-$1M | Build prototype | $3-10M |
+| Seed | $1-5M | Reach product-market fit | $10-30M |
+| Series A | $5-15M | Scale early traction; build sales motion | $30-100M |
+| Series B | $20-50M | Scale GTM; expand product | $100-500M |
+| Series C | $50-100M | Scale further; consider international | $500M-$2B |
+| Series D+ / growth | $100M+ | Capital for acquisitions, public-market prep | $2B+ |
+| IPO | varies | Liquidity for founders/investors; growth capital | varies |
+
+The numbers shifted dramatically in different eras. 2020-2021 saw inflated rounds at any stage; 2022-2024 saw the same companies struggle to raise at flat or down valuations. The structure is consistent; the multiples are not.
+
+The pattern within software:
+
+```text
+Seed: prove the product
+Series A: prove the GTM
+Series B: prove the scaling
+Series C: prove the durability
+Growth/IPO: prove the cash flow
+```
+
+Companies that try to raise rounds without proving the corresponding milestone struggle. The rule of thumb: each round should validate the next.
+
+### Pre-money vs. post-money
+
+The arithmetic that confuses everyone the first time.
+
+**Pre-money valuation**: the company's worth *before* the new capital enters. If a Series A is "$50M pre" and the round is $10M, the company is valued at $50M just before the round and $60M just after.
+
+**Post-money valuation**: pre-money + new capital. The valuation *after* the round closes.
+
+The investor's ownership is: (round size) / (post-money valuation).
+
+```text
+Round: $10M
+Pre-money: $50M
+Post-money: $50M + $10M = $60M
+Investor ownership: $10M / $60M = 16.67%
+```
+
+Founders prefer to negotiate on pre-money (the company is worth $50M before you put money in). Investors prefer post-money (the company is worth $60M after). Same arithmetic, different anchoring.
+
+### Dilution
+
+Every funding round dilutes existing shareholders. A 20% round means existing shareholders' ownership shrinks to 80% of what it was.
+
+```text
+Before Series A:
+  Founders: 70%
+  Seed investors: 20%
+  Option pool: 10%
+
+After Series A (20% round):
+  Founders: 70% × 0.80 = 56%
+  Seed investors: 20% × 0.80 = 16%
+  Option pool: 10% × 0.80 = 8%
+  Series A investors: 20%
+  Total: 100%
+```
+
+Notice the option pool got diluted too. In practice, Series A investors usually require the option pool to be *expanded back* to a target percentage (often 10-15%) before they invest - which means the dilution comes out of the founders' and existing investors' shares, not the new investors'.
+
+Over the full lifecycle, founders typically end with 15-30% of the company by IPO. The rest is investors, employees, and management hires.
+
+### Preferred vs. common stock
+
+**Common stock** is what employees get (via options) and what founders typically hold. Standard ordinary shares.
+
+**Preferred stock** is what investors get. Preferred carries protections that common doesn't:
+
+- **Liquidation preference.** At exit, preferred holders get their money back *first* before common holders get anything. 1x preference (the standard) means $X invested → $X out before common. 2x or 3x preferences existed historically but are rare now.
+- **Anti-dilution protection.** If a future round happens at a lower price, preferred shares get re-priced to limit dilution.
+- **Pro-rata rights.** The right to maintain ownership percentage in future rounds.
+- **Information rights.** Board seats, financial reporting, etc.
+- **Veto rights.** Approval over major decisions (acquisition, new fundraising, executive hires).
+
+The implication: at exit, the *split* of proceeds depends heavily on the preference stack. A company that "sold for $100M" might pay $80M to preferred holders (recovering their investment) and only $20M to common. Founders and employees with common-only get the residual.
+
+Worst-case: a "down exit" where the company sells for less than the total preference stack. Founders and employees can get $0 even from a $50M sale if preferred holders absorb the whole amount.
+
+### 409A and option strike price
+
+The 409A is an independent valuation of common stock for tax purposes. It must be done by a third-party valuation firm every 12 months or when material events occur (fundraising, large product launch).
+
+The 409A sets the *strike price* for new option grants. When you join a company and get options at "$2/share strike," the 409A determined that $2.
+
+Why this matters to you:
+- A *low* 409A is good for new option grants (lower strike = more upside).
+- A *high* 409A means a smaller spread between strike and current value.
+- The 409A is usually 30-50% of the preferred share price. So if a Series B priced at $10/share, the 409A might be $4-5/share.
+
+When a company raises a new round at a higher preferred price, the 409A usually rises too (but with a lag). Employees joining *before* the 409A re-priced get the old strike - sometimes a significant arbitrage.
+
+If you ever join an early-stage company and get options, your real upside depends on the spread between strike and eventual exit price. A $0.50 strike on options that exit at $20 is a 40x return. A $15 strike on options that exit at $20 is barely worth exercising.
+
+### Reading the cap table
+
+The cap table (capitalization table) is the list of all shareholders, their share counts, their share class, and their percentages. Every company has one; many employees never see theirs.
+
+The relevant lines for an employee:
+
+- **Total shares outstanding** - denominator for ownership calculations.
+- **Your option grant size** - numerator. Plus your vesting schedule.
+- **Outstanding preferred stack** - affects exit math.
+- **Available option pool** - informs whether future grants are likely.
+
+You usually have legal rights to information about your own grant. Many companies provide a self-service portal (Carta, Pulley) showing your equity status.
+
+### Why this matters to engineers
+
+Several practical reasons:
+
+1. **Compensation negotiation.** Equity is part of the offer. Understanding the offer requires understanding what stage the company is at, what the dilution path looks like, and what the strike/valuation implies.
+2. **Company-stage signals.** "We raised a $20M Series A at $80M pre" tells you a lot: the company is at growth-acceleration stage; the burn rate is probably ~$5M/year; the next round will need significant revenue scaling.
+3. **Strategic context.** A company that just raised a big round will spend; a company that hasn't raised in 18 months is either profitable or running out of runway. The fundraising state is a strong signal about company behaviour.
+4. **Personal financial planning.** Your equity is potentially a major asset; treating it as "lottery tickets" without understanding the math is leaving money on the table.
+
+## Walkthrough
+
+A worked example. You're being offered a Series B startup with these terms:
+
+```text
+Offer:
+  Base: $200k
+  Equity: 0.10% of the company (1,000 options out of 1,000,000 outstanding)
+  Strike price: $2.50 per option
+  Vesting: 4 years, 1-year cliff, monthly thereafter
+
+Company context:
+  Series B raised 6 months ago: $30M at $200M pre, $230M post
+  Preferred Series B price: $11.50/share
+  409A: $2.50/share (consistent with strike)
+  
+  Total preferred stack across rounds: ~$50M cumulative invested
+```
+
+What this offer looks like in different scenarios:
+
+```text
+Scenario: Company sells for $1B
+  Preferred stack ($50M) gets paid first
+  Remaining $950M distributed by ownership
+  Your 0.10% × $950M = $950k
+  Less strike cost: 1000 × $2.50 = $2.5k
+  Less taxes (~30-40%)
+  Net: ~$570-670k
+
+Scenario: Company sells for $300M
+  Preferred stack ($50M) gets paid first
+  Remaining $250M distributed
+  Your 0.10% × $250M = $250k
+  Less strike + taxes
+  Net: ~$150-175k
+
+Scenario: Company sells for $50M (down exit)
+  Preferred stack absorbs the entire $50M
+  Common gets $0
+  Your options: worth $0
+  Net loss: time-opportunity cost
+```
+
+A senior engineer should be able to do this math before signing the offer. The "good" outcome scenarios anchor expectations; the "bad" scenarios reveal the downside risk that equity represents. A reasonable offer evaluation includes some probability-weighting across these scenarios.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  founders[Founders + seed] -->|raise| roundA[Series A]
+  roundA -->|raise| roundB[Series B]
+  roundB -->|raise| roundC[Series C / growth]
+  roundC --> ipo[IPO or M&A exit]
+  each_round[Each round dilutes existing holders] -.-> founders
+  pref[Preferred stack] --> exit_math[Exit proceeds split]
+  ipo --> exit_math
+  exit_math --> common[Common holders: residual]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Treating equity as fixed | Forgetting future dilution | Model dilution through all expected future rounds. |
+| Ignoring liquidation preference | Optimistic equity math | Check the preference stack; it can absorb the entire exit. |
+| Counting option grants as 'free' | Strike cost is real | Include strike × shares in the cost calculation. |
+| Misreading 'fully diluted' | Different ownership numbers depending on definition | Ask: "what's my percentage on a fully-diluted basis assuming the announced future grants?" |
+| Skipping 409A timing | Joining right after a re-price means high strike | Joining before the 409A update can yield a better strike. |
+
+## Exercises
+
+1. For your own company (if private), find out the current valuation, the total preferred stack, and the size of the option pool. If you have options, compute the breakeven exit price (the price at which your options become worth exercising).
+2. Read a Form S-1 from a recent tech IPO ([Snowflake](https://www.sec.gov/Archives/edgar/data/1640147/000119312520245725/d427360ds1.htm), [HashiCorp](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001783029), etc). Find the cap table section. Note the dilution pattern from seed to IPO, and the founder vs. employee vs. investor splits.
+3. Pretend you've been offered a job at three companies - pre-PMF startup, Series B, and pre-IPO. For each, write down what you'd want to know before signing. The list is longer than most engineers realise.
+
+## Recap & next
+
+- Funding rounds follow a standard pattern (seed → A → B → C → growth → IPO), each validating a specific milestone.
+- Pre-money + investment = post-money; ownership = investment / post-money.
+- Preferred stock has liquidation preference; common holders get the residual at exit.
+- 409A sets option strike prices; the spread between strike and exit price is your real upside.
+
+Next, **The investment case** - how to write a memo asking for resources that gets read, taken seriously, and approved.
+{% endraw %}
diff --git a/_courses/engineers-mba/05-capital-risk-decisions/03-investment-case.md b/_courses/engineers-mba/05-capital-risk-decisions/03-investment-case.md
new file mode 100644
index 0000000..f4acdf5
--- /dev/null
+++ b/_courses/engineers-mba/05-capital-risk-decisions/03-investment-case.md
@@ -0,0 +1,276 @@
+---
+chapter_id: 3
+chapter_slug: investment-case
+chapter_title: "The investment case"
+chapter_summary: "Provides a five-section investment-case memo template (problem + why now, proposal, base/upside/downside, cost, decision + kill criteria). Argues kill criteria increase funding probability rather than decrease it."
+---
+
+{% raw %}
+## What you'll learn
+- The structure of a memo that gets read, taken seriously, and approved.
+- Base/upside/downside cases - how to write each and what they actually accomplish.
+- Expected value reasoning and how to bring it into engineering proposals.
+- Kill criteria - why specifying them upfront makes funding more likely, not less.
+
+## Concepts
+
+An *investment case* is a memo asking the company to commit resources - money, engineering time, executive attention - to a specific bet. It can be a half-page Slack message for a small project or a 10-page memo for a major strategic move. The structure is the same.
+
+Engineers usually write investment cases badly. The common failure modes:
+
+- Lead with the solution, not the problem.
+- Argue technical merit without business framing.
+- Present one scenario instead of a range.
+- Hide the assumptions.
+- No kill criteria.
+- No clear ask.
+
+The good news: writing investment cases is a learnable skill, and the framework is consistent enough that you can get fluent at it in a few iterations.
+
+### The structure
+
+A working investment case has five sections:
+
+```text
+1. The problem and why it matters now
+2. The proposal
+3. Expected outcome - base, upside, downside
+4. Cost (capital + time + opportunity)
+5. Decision required + kill criteria
+```
+
+Most exec readers will read section 1, glance at sections 2-4, and look for the decision in section 5. So lead with the problem clearly stated, and have a clear decision request at the bottom.
+
+### 1. The problem and why now
+
+The most important section. Two questions to answer:
+
+- **What problem are we solving?** Specifically - in customer terms or revenue terms, not engineering terms.
+- **Why now?** What changed that makes this urgent? A new customer requirement, a competitive entry, a regulatory deadline, a market window.
+
+If you can't answer "why now," the project probably isn't urgent and shouldn't be funded *yet*. Many great proposals lose to "let's revisit next quarter" because they don't establish urgency.
+
+```text
+Bad: We should build an audit log feature.
+Good: Three enterprise prospects ($4.2M total ACV) have audit log
+       as a hard requirement in their RFP. Two more will start RFP
+       in Q3. Without audit log, we lose all five deals.
+```
+
+### 2. The proposal
+
+What you're proposing to do. Crisp, one paragraph. Include the rough scope so readers know what's in and out.
+
+```text
+Build an enterprise-grade audit log that captures user actions,
+admin changes, and data access, retains 1 year, exports via API,
+and meets the SOC 2 requirement. Phase 1: core capture + UI.
+Phase 2: SIEM integrations. Total 4 engineer-months.
+```
+
+### 3. Expected outcome - base, upside, downside
+
+Three scenarios. Most engineering proposals show only the "this will go well" case. That's not analysis; that's marketing. Show all three.
+
+- **Base case** - what we realistically expect.
+- **Upside** - what's possible if it goes better than expected.
+- **Downside** - what happens if it goes worse than expected.
+
+For each, attach a rough probability. The expected value of the project is:
+
+```text
+EV = P(base) × value(base) + P(upside) × value(upside) + P(downside) × value(downside)
+```
+
+Concretely:
+
+```text
+Base case (60% prob): Win 3 of 5 RFPs → $2.4M ARR. EV contribution: $1.44M
+Upside (20% prob): Win all 5 → $4.2M ARR + reference logos. EV contribution: $840k
+Downside (20% prob): Win 1, deals delayed → $700k ARR. EV contribution: $140k
+                                                       ────────
+Total expected value: ~$2.4M ARR
+```
+
+Compare to the cost ($400-500k of engineering, see [Module 4 Chapter 4](/courses/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer/)). EV/cost ratio of 5-6x is excellent. The proposal funds itself.
+
+The discipline of writing down the scenarios is more valuable than the math. It surfaces what you're really betting on. If you can't construct a credible upside or downside, you don't understand the problem well enough.
+
+### 4. Cost - capital, time, opportunity
+
+Three components:
+
+- **Capital cost** - fully-loaded engineering cost, plus any vendor, infrastructure, or third-party costs. See [Module 4 Chapter 4](/courses/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer/) for fully-loaded.
+- **Time cost** - calendar time. "4 engineer-months" can mean 4 months × 1 engineer or 2 months × 2 engineers - different time-to-value.
+- **Opportunity cost** - what else those engineers won't do. Be specific.
+
+```text
+Cost:
+  Capital: 2 engineers × 4 months × $400k/yr = $267k
+  Time: Ships in 4 months calendar time (parallel team allocation)
+  Opportunity cost: Defers the analytics dashboard work for the
+                    same period; impact ~$300k of post-Q3 ARR.
+  Net: $567k of capital + opportunity, against $2.4M expected ARR.
+```
+
+### 5. Decision and kill criteria
+
+Two parts:
+
+**The decision** - what specifically are you asking for? "Approve" is rarely enough. "Approve allocation of 2 engineers for 4 months starting June 1st, plus $30k for SIEM partner setup" is operational.
+
+**Kill criteria** - what would make us stop the project mid-flight? This is *counterintuitively* the section that increases the probability of funding. Why?
+
+- It demonstrates honest engagement with downside risk.
+- It pre-commits to walking away if signals are bad - making the bet recoverable.
+- It limits the loss without limiting the upside.
+
+```text
+Decision required:
+  - Approve 2 engineers × 4 months starting June 1st
+  - Approve $30k SIEM partner setup
+  - Approve scope freeze on adjacent features for the period
+
+Kill criteria:
+  - If by month 2, technical complexity has expanded such that
+    Phase 1 timeline slips past month 5, pause and reassess.
+  - If by month 3, two of the five RFPs have moved on without us,
+    consider whether the urgency case still applies.
+```
+
+Good kill criteria are specific, time-bound, and tied to observable signals. "We'll re-evaluate periodically" is not kill criteria.
+
+### When to write each level
+
+The intensity of the memo should match the size of the ask.
+
+| Ask size | Format |
+|---|---|
+| < 1 engineer-month | Slack message, paragraph |
+| 1-3 engineer-months | 1-page memo |
+| 3-6 engineer-months | 2-3 page memo, includes the five sections |
+| 6+ engineer-months | Full memo, often a 6-pager (see [Module 6 Chapter 2](/courses/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos/)) |
+| Strategic bets (multi-team, $5M+) | Full memo + verbal pitch + Q&A cycle |
+
+Over-investing in the memo for small asks looks weird; under-investing for big asks gets you rejected.
+
+### Writing tone
+
+A few mechanics:
+
+- **Lead with the problem; bury the solution.** Many engineers do the reverse.
+- **Use customer/business language.** "Reduce SOC 2 questionnaire response time by 80%" beats "automate audit log capture."
+- **Show your assumptions.** "Based on 5 RFPs in the last quarter requiring audit log..."
+- **Quantify wherever possible.** "Significant" or "important" carries less weight than a specific number with a specific source.
+- **Anticipate objections.** A skeptical reader is silently saying "but what about...". Address it before they ask.
+
+## Walkthrough
+
+A complete investment case. You're proposing a 6-month project to migrate the company's deployment infrastructure.
+
+```text
+TITLE: Migrate deployment infrastructure to platform-as-a-service
+
+PROBLEM AND WHY NOW
+Our current deployment pipeline is the #2 reason new hires take 
+>3 months to ship their first feature (per Q2 onboarding survey). 
+Average deploy time is 47 minutes. Two of three Series B-class 
+companies we benchmarked deploy in <5 minutes.
+
+Why now: We're hiring 20 engineers in the next two quarters. The 
+onboarding cost (engineer-weeks lost) of the current pipeline 
+scales linearly with hiring. At current headcount growth, the 
+cost will exceed $1.5M/year by Q4.
+
+PROPOSAL
+Migrate from our custom Jenkins-based pipeline to GitHub Actions 
++ a managed deployment platform. Phase 1: pilot with two product 
+teams (2 months). Phase 2: rollout to the rest of engineering 
+(3 months). Phase 3: deprecate Jenkins (1 month).
+
+EXPECTED OUTCOME
+
+Base case (60% prob): 
+  Deploy time reduced to <8 minutes
+  Onboarding time reduced by 2 weeks per new hire
+  $800k/year capacity recovery from reduced deployment overhead
+  
+Upside (25%):
+  Deploy time <3 minutes; standardised deploy tooling enables 
+  feature flags, blue-green, and rollout automation
+  $1.2M/year capacity recovery + 30% reduction in deploy-related 
+  incidents
+
+Downside (15%):
+  Migration takes 9 months instead of 6; pipeline disruption 
+  causes 1-2 incidents during transition; modest gain ($400k/year)
+
+EV ~ 0.6 × $800k + 0.25 × $1.2M + 0.15 × $400k = $840k/year ongoing
+
+COST
+
+Capital: 4 engineers × 6 months × $400k loaded = $800k
+Vendor: New platform-as-a-service licensing = $80k Year 1, $50k/yr ongoing
+Opportunity cost: Defers internal developer-tools roadmap by 6 months 
+                   (~$300k of efficiency improvements deferred)
+
+Total Year 1 cost: ~$1.2M
+Total Year 2+ cost: $50k/year vendor + replaced custom maintenance
+
+DECISION REQUIRED
+
+  - Approve 4-engineer team for 6 months starting July 1
+  - Approve vendor contract negotiation (target close: Aug 15)
+  - Approve scope freeze on internal-tools roadmap for the duration
+
+KILL CRITERIA
+
+  - If by month 2, pilot deploy times exceed 15 minutes, pause and 
+    reassess vendor choice.
+  - If by month 4, rollout produces >2 P1 incidents, pause and 
+    consolidate before continuing.
+  - If by month 6, less than half of engineering teams have migrated, 
+    re-evaluate timeline.
+```
+
+This is a strong memo because: the problem is concrete (47-minute deploys, $1.5M/year cost), urgency is explicit (hiring will compound it), three scenarios are shown, cost is honestly disclosed including opportunity cost, the decision is specific, and kill criteria let the company walk away cleanly if it goes sideways.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  problem[Problem framing + urgency] --> proposal[Specific proposal]
+  proposal --> scenarios[Base / Upside / Downside]
+  scenarios --> ev[Expected value]
+  cost[Cost: capital, time, opportunity] --> compare[EV vs cost]
+  ev --> compare
+  compare --> decision[Decision request]
+  decision --> kill[Kill criteria]
+  kill --> exec{Approve / reject}
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Leading with the solution | "We want to build X" | Lead with the problem the X solves. |
+| One scenario only | "Here's what will happen" | Show base/upside/downside with probabilities. |
+| No "why now" | The project isn't urgent | If you can't explain urgency, the project isn't ready. |
+| Hidden assumptions | "Trust me" | List assumptions explicitly; let readers challenge them. |
+| No kill criteria | "We'll figure it out" | Specify kill criteria upfront; it increases funding likelihood. |
+
+## Exercises
+
+1. Take the last engineering proposal you wrote (or one your team wrote). Score it against the five-section framework. Identify which sections are missing or weak.
+2. For a current project on your roadmap, write a one-page investment case using the structure above. Especially focus on the three-scenario analysis and kill criteria.
+3. Read a public business memo (Jeff Bezos' annual letters are great, [Ben Thompson's Stratechery](https://stratechery.com/) deep-dives). Note the structure they use to make arguments - most of them follow the problem-proposal-scenarios pattern even without explicit headers.
+
+## Recap & next
+
+- A good investment case has five sections: problem, proposal, scenarios, cost, decision + kill criteria.
+- Lead with the problem and "why now"; bury the solution.
+- Show base/upside/downside with probabilities; compute expected value vs. cost.
+- Kill criteria increase funding probability by making the bet recoverable.
+
+Next, **Risk: regulatory, security, reputational, key-person** - the categories of risk that show up in board decks and how engineering moves each.
+{% endraw %}
diff --git a/_courses/engineers-mba/05-capital-risk-decisions/04-risk-categories.md b/_courses/engineers-mba/05-capital-risk-decisions/04-risk-categories.md
new file mode 100644
index 0000000..f941567
--- /dev/null
+++ b/_courses/engineers-mba/05-capital-risk-decisions/04-risk-categories.md
@@ -0,0 +1,205 @@
+---
+chapter_id: 4
+chapter_slug: risk-categories
+chapter_title: "Risk: regulatory, security, reputational, key-person"
+chapter_summary: "Surveys the four major risk categories (regulatory, security, reputational, key-person), the risk register, and why engineering owns mitigation execution across most categories. Highlights the asymmetric economics of risk investment."
+---
+
+{% raw %}
+## What you'll learn
+- The four major risk categories tracked in board decks and how each materially affects the business.
+- How engineering work moves each category (and where engineering is the *only* function that can).
+- The risk register - what it is, who owns it, and how to read one.
+- The asymmetry of risk costs: small ongoing investment vs. catastrophic downside.
+
+## Concepts
+
+A *risk* is something that could happen that would damage the business. Boards track them. The CFO and General Counsel often co-own the risk register. Engineering frequently owns the *mitigation* for several categories whether or not they realise it.
+
+The four categories most relevant to software companies:
+
+### 1. Regulatory risk
+
+The risk of penalties, bans, or operational restrictions from government bodies. Examples:
+
+- **Data protection** - [GDPR](https://gdpr.eu/), CCPA, sector-specific (HIPAA for healthcare, FERPA for education, PCI DSS for payments).
+- **Antitrust** - Apple, Google, Meta have all faced significant regulatory actions affecting product design.
+- **Sector-specific** - financial services (SOX, FINRA, OCC), aviation (FAA), pharma (FDA).
+- **Trade controls** - export restrictions, sanctioned-country handling, data localisation.
+
+Regulatory risk is *categorical*. A single violation can produce penalties of 4% of global revenue (GDPR), product injunctions, or criminal charges for executives. Compared to operational issues, regulatory risk has the highest "low frequency, catastrophic outcome" profile.
+
+**Engineering's role**: Implementing controls (data deletion, consent management, access controls, audit logging, region pinning, content moderation). Engineering owns the *execution* of regulatory compliance even though legal owns the *strategy*.
+
+### 2. Security risk
+
+The risk of breaches, data leaks, or compromise. Categories:
+
+- **External breach** - attacker steals customer data, source code, internal systems.
+- **Insider threat** - current or former employee causes damage.
+- **Supply chain** - compromised dependency, contaminated build pipeline ([SolarWinds](https://www.cisa.gov/news-events/news/cisa-issues-emergency-directive-mitigate-compromise-solarwinds-orion-network), [xz-utils](https://en.wikipedia.org/wiki/XZ_Utils_backdoor)).
+- **Account takeover** - credential theft, session hijacking.
+- **Ransomware / availability** - extortion via denial of service.
+
+Security risk has shifted dramatically in the last decade. A decade ago it was an IT concern; today it's a board-level concern with regular cyber-insurance audits, named CISOs, and disclosure requirements for material breaches (SEC's 8-K disclosure rules).
+
+**Engineering's role**: Owns most of the implementation. Authentication, encryption, secrets management, vulnerability management, secure development lifecycle. The CISO sets policy; engineering executes.
+
+The asymmetry: a single breach can cost $10-100M+ in remediation, legal, customer churn, and reputation damage. Comparing this to the ongoing cost of security engineering ($1-5M/year for a typical SaaS company), the math heavily favours over-investment in prevention.
+
+### 3. Reputational risk
+
+The risk of public perception damage that affects customer acquisition, retention, talent, and capital access. Sources:
+
+- **Outages and incidents** - when your service is down on the front page.
+- **Security incidents** - even ones without legal consequence damage trust.
+- **Customer experiences** - a viral support failure or pricing scandal.
+- **Executive controversies** - public statements, social misconduct, financial impropriety.
+- **Product harms** - algorithmic bias, harmful content, dangerous defaults.
+
+Reputational damage is *slow* to build and *fast* to lose. A company can spend years building trust and lose it in a week. Recovery is asymmetric: building back trust takes 2-3x as long as the time to lose it.
+
+**Engineering's role**: Reliability (the most underrated reputational asset in B2B), transparency in incidents, public status pages, performance, accessibility, product quality. Every visible engineering failure (outage, bug, security issue) is a small reputational debit.
+
+### 4. Key-person risk
+
+The risk of operational disruption from losing a critical individual. Categories:
+
+- **Executive loss** - CEO, CTO, CFO departing or incapacitated.
+- **Single-point-of-knowledge** - one engineer who knows how a critical system works.
+- **Customer relationships** - one salesperson with 30% of the revenue book.
+- **Domain expertise** - one researcher who knows the ML model.
+
+Key-person risk is the form of organisational risk engineers most directly affect. A team where one person knows a critical system in depth and everyone else is several steps behind is high key-person risk.
+
+**Engineering's role**: Documentation, knowledge sharing, code review practices, on-call rotation diversity, internal training. Most engineering teams under-invest here because the work is invisible - until the person leaves.
+
+### Other relevant risk categories
+
+A few less commonly named but real:
+
+- **Concentration risk** - too much revenue from one customer, too much spend with one vendor, too much team dependency on one role. Diversification mitigates.
+- **Technical debt as risk** - accumulated debt that limits future agility. Slow erosion vs. visible failure.
+- **Geographic / political risk** - operating in jurisdictions that change rules; data residency requirements; sanctioned countries.
+- **Currency and macroeconomic risk** - exchange rate exposure, interest rate exposure, recession risk on the customer base.
+
+### The risk register
+
+A *risk register* is the formal document listing the company's tracked risks. Each entry typically has:
+
+- **Risk description** - what could happen.
+- **Likelihood** - qualitative (low/med/high) or quantitative.
+- **Impact** - financial cost if it occurs.
+- **Owner** - who's responsible for monitoring and mitigation.
+- **Mitigation status** - what's been done.
+- **Residual risk** - what's left after mitigation.
+
+Risk registers are usually owned by the General Counsel or CFO, reviewed quarterly, and presented to the board annually. Most engineers never see one. They should.
+
+A useful exercise: ask for the engineering-relevant rows of the risk register. The list of "things the company is worried about and your team owns" is often informative - sometimes startling.
+
+### The economics of risk investment
+
+Risk investment is structurally asymmetric. The downside of a major risk event ($10-100M+) dwarfs the cost of ongoing mitigation ($1-5M/year). Expected-value math almost always favours over-investment.
+
+| Risk | Mitigation cost (annual) | Catastrophic downside |
+|---|---|---|
+| Major data breach | $1-5M (security team + tooling) | $50-500M (legal, churn, brand) |
+| GDPR violation | $500k (controls + DPO) | 4% of global revenue |
+| Major outage | $2-3M (SRE team) | $5-20M direct + reputational |
+| Key engineer leaves | $200k (documentation + cross-training) | $1-5M (delay + rebuild knowledge) |
+
+The math is overwhelming. And yet, in steady state, companies often under-invest in risk because the mitigation cost is *visible and ongoing* while the downside is *invisible and possible*. The most expensive mistakes in software business history are mostly risk-event mistakes - Equifax, Target, Uber's pre-2018 controversies, the post-Twitter-acquisition exodus.
+
+### How risk shows up in board decks
+
+Board decks typically include 1-2 slides on risk. The format varies but usually includes:
+
+- Risk register summary
+- Recent incidents and learnings
+- Risk-related projects and investments
+- New or emerging risks
+
+Engineering's contribution to the risk slide is usually security/reliability/outage data. The board reads this looking for trends and recurring categories. Engineers should know what the company tells the board about their domain.
+
+## Walkthrough
+
+A worked engineering risk assessment. You're the tech lead for the team that owns customer authentication. The annual risk-register review is coming up.
+
+```text
+Risk: Authentication service has a single-point-of-knowledge.
+  Only one engineer (Alex) deeply understands the OIDC flow, federated 
+  identity, MFA edge cases.
+  
+  Likelihood of "Alex leaves": Medium. Alex is senior, marketable, 
+  potentially open to outside offers.
+  Impact: High. New customer onboarding stalls; production incidents 
+  in auth go unresolved; ~$2-3M of customer-acquisition slowdown.
+  Owner: Eng manager (you).
+  Mitigation status: 1 other engineer has shadowed; documentation 
+  partial; no formal cross-training program.
+  Residual risk: Medium.
+  
+Risk: Credential storage uses bcrypt at outdated cost factor.
+  All passwords currently hashed at cost factor 8; current best 
+  practice is cost factor 12 or argon2.
+  
+  Likelihood of "successful brute-force on stolen hashes": Low (no 
+  known breach), but rising over time.
+  Impact: Very high. Customer account takeover at scale; reputational 
+  damage; SOC 2 finding.
+  Owner: This team.
+  Mitigation status: Migration to argon2 scoped but not prioritised.
+  Residual risk: High.
+
+Risk: Auth service relies on a single third-party library no longer 
+  actively maintained.
+  ...
+
+[Continue for the team's risks]
+```
+
+This kind of exercise is unusual but valuable. It:
+- Forces the team to think about *what could go wrong* not just *what they're building*.
+- Surfaces investments that are easy to defer but high-EV.
+- Gives the team something concrete to bring to the next QBR.
+- Builds the engineering manager's relationship with the General Counsel and CISO, who own the broader risk function.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  categories[Risk categories: regulatory, security, reputational, key-person] --> register[Risk register]
+  register --> review[Quarterly review]
+  review --> mitigation[Mitigation investments]
+  mitigation --> tech[Engineering execution]
+  tech --> residual[Residual risk]
+  residual --> board[Board reporting]
+  board --> register
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Treating risk as legal/CFO's job | "Not my function" | Engineering owns execution of most risk mitigation. |
+| Under-investing in prevention | Mitigation is visible, downside is invisible | Run the EV math; over-investment in prevention usually wins. |
+| Risk theater | Documents without follow-through | Tie risk mitigation to specific engineering deliverables. |
+| Ignoring key-person risk | "He'd never leave" | Cross-train, document, rotate; cheaper than recovery. |
+| Risk paralysis | "Every change creates risk" | Risk-zero is impossible; manage risk, don't avoid all change. |
+
+## Exercises
+
+1. Ask your manager or finance partner for the engineering-relevant rows of the risk register. Read them. Note any you weren't aware of.
+2. For your team's largest production system, write a one-page risk register: 4-6 risks with likelihood, impact, owner, mitigation status. Share with your manager.
+3. Identify one key-person risk in your team (a system or process that only one person knows). Propose a 2-3 month mitigation plan: cross-training, documentation, code-review patterns. Most teams find this easy to do and high-leverage.
+
+## Recap & next
+
+- Four major risk categories - regulatory, security, reputational, key-person - show up in every board deck.
+- Engineering owns execution for most risk mitigation regardless of who owns policy.
+- Risk investment is structurally asymmetric: mitigation costs are visible and small; downside is invisible and catastrophic.
+- The risk register is the formal tracking document; engineers should know what their team's rows say.
+
+Next, **Time, optionality, and the cost of delay** - why speed often beats precision in decision-making.
+{% endraw %}
diff --git a/_courses/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.md b/_courses/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.md
new file mode 100644
index 0000000..1df035a
--- /dev/null
+++ b/_courses/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.md
@@ -0,0 +1,184 @@
+---
+chapter_id: 5
+chapter_slug: time-optionality-cost-of-delay
+chapter_title: "Time, optionality, and the cost of delay"
+chapter_summary: "Distinguishes two-way from one-way doors (Bezos), introduces cost of delay and real-options thinking, and shows when speed dominates precision. Targets the engineering bias toward over-deliberation on reversible decisions."
+---
+
+{% raw %}
+## What you'll learn
+- Bezos' one-way vs. two-way doors framework and why most decisions are more reversible than they feel.
+- Cost of delay as a first-class engineering economic concept.
+- Real options thinking - when *not* deciding is itself a valuable position.
+- When precision is worth waiting for, and when speed strictly dominates.
+
+## Concepts
+
+Most engineers spend more time than is rational deliberating decisions. The reason isn't laziness or fear - it's the reasonable instinct that *getting it right* matters. But this instinct overcorrects systematically. Many decisions in software are *highly reversible*, and treating them as permanent slows the team down without improving outcomes.
+
+The frameworks below - Bezos' two doors, cost of delay, real options - give a vocabulary for talking about speed-precision trade-offs in a way that exec teams understand.
+
+### Two-way doors vs. one-way doors
+
+[Jeff Bezos' 1997 letter to shareholders](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders) introduced the framing that still dominates:
+
+> "Some decisions are consequential and irreversible or nearly irreversible - one-way doors - and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don't like what you see on the other side, you can't get back to where you were before. We can call these Type 1 decisions.
+>
+> But most decisions aren't like that - they are changeable, reversible - they're two-way doors. If you've made a sub-optimal Type 2 decision, you don't have to live with the consequences for that long. You can reopen the door and go back through.
+>
+> Type 2 decisions can and should be made quickly by high-judgment individuals or small groups."
+
+The insight: most decisions are two-way doors but get treated as one-way doors. The result is slower decision-making than necessary, with no compensating improvement in outcome.
+
+Examples:
+
+| Decision | Door type | Often treated as |
+|---|---|---|
+| Hire a senior engineer | Two-way (some cost to undo) | One-way |
+| Choose between two SaaS vendors | Two-way (switching costs but doable) | One-way |
+| Rebrand the company | One-way | Two-way (mistakenly) |
+| Pick a tech-stack for a new service | Two-way | One-way |
+| Acquire a company | One-way | Often appropriate consideration |
+| Major architectural rewrite | One-way (effectively) | Sometimes too readily entered |
+
+The discipline: for two-way doors, make the decision *fast* - within hours, by the senior-most person available. The wrong answer can be reversed. The cost of slowness compounds. For one-way doors, slow deliberation is justified.
+
+### Cost of delay
+
+Every decision left unmade has a cost - the *opportunity cost* of the things that could have happened during the delay.
+
+For a software project, cost of delay is typically estimated as:
+
+```text
+Cost of Delay = (Expected monthly revenue impact when shipped)
+              + (Cost of resources idling)
+              + (Risk of competitive entry during delay)
+              + (Strategic positioning lost)
+```
+
+A project worth $2M/year that's delayed by a quarter loses $500k of revenue alone. If the delay also opens a window for competitors or causes a strategic narrative to shift, the cost can be much higher.
+
+Engineering decisions delayed for "let's think about it more" should be evaluated against the cost of delay. A decision worth $50k of optimisation isn't worth $200k of delay cost.
+
+Don Reinertsen's [*Principles of Product Development Flow*](https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009) is the canonical treatment. The key insight: most product/engineering organizations don't *track* cost of delay, even though it's often the largest single factor in project economics.
+
+### Real options thinking
+
+Sometimes the *right* decision is to defer the decision - to keep optionality open.
+
+A real option is the right (but not the obligation) to take an action at a future point. In engineering terms:
+
+- A staged migration is a real option - you can roll back at any phase.
+- A vendor-agnostic abstraction layer is a real option - you can switch vendors later.
+- A modular architecture is a real option - you can refactor pieces independently.
+- A "wait and see" on a hot new technology is a real option - let early adopters de-risk it.
+
+Real options have *value*. The value of optionality is roughly the probability-weighted upside of being able to take the option × the cost saved by not committing yet.
+
+Common engineering examples:
+
+- **Building abstractions for cloud-vendor portability.** Has cost (engineering complexity, performance overhead). Has value (preserves the option to switch cloud vendors). Worth it only if the probability and value of needing to switch exceeds the upfront cost.
+- **Microservices vs. monolith.** A monolith has lower optionality; microservices have more (each service can be rewritten independently) but higher complexity. The choice depends on your view of future change.
+- **Investing in a fast iteration loop.** Has cost (build/test/deploy infrastructure). Has value (preserves the option to experiment with the product). Almost always worth it.
+
+The danger of real-options thinking: it can justify *not committing* to anything. The discipline: pay for optionality only where there's a genuine probability the option will be exercised.
+
+### When precision is worth it
+
+Two-way doors should be entered fast. One-way doors deserve deliberation. But even two-way doors can sometimes justify slowing down:
+
+- **The cost of unwinding is high.** A "two-way door" that takes 6 months to reverse is effectively a one-way door over short horizons.
+- **The information is cheap and changes the decision.** If a one-hour conversation with a customer would settle the question, have the conversation.
+- **The decision pre-commits other expensive decisions.** Picking a database technology pre-commits to ops investments, hiring profiles, learning curves.
+- **High stakes with poor signal.** A high-impact decision where you have weak data warrants more analysis.
+
+The practical heuristic from senior engineers: *make the decision in proportion to how easily it can be unmade*. If the answer is "easily, in an afternoon," make it now. If "with 6 months of engineering work," slow down.
+
+### Speed as competitive advantage
+
+A consistent finding across competitive software: faster decision-making compounds. Companies that move 2x faster than competitors on small decisions accumulate a large advantage over years.
+
+The mechanisms:
+
+- More iterations against the market.
+- Less time spent in low-information deliberation.
+- Better signal-to-noise (because more decisions = more learning).
+- Stronger morale (people don't feel stuck).
+
+The downside risk of fast decision-making is making more "bad" decisions. But: if most decisions are two-way doors, the wrong call costs the time to make a new decision, not the time of being stuck.
+
+Bezos, Steve Jobs, Marc Andreessen, and Bret Taylor have all variously emphasised this. The implicit business model is: decision-making is a manufacturing process; the *velocity* of decisions is the rate of learning.
+
+### Where engineers struggle
+
+Engineers default toward "let's get this right" thinking. The reasons:
+
+- Engineering tooling (CI, code review, type systems) reinforces the value of getting things right.
+- Engineering culture rewards careful design over fast execution.
+- Engineering systems penalize the wrong call (incidents, debt, rework) more visibly than they reward fast decisions.
+- Status hierarchies in engineering favour thinkers over doers.
+
+The corrective: distinguish *decisions about systems* (where precision compounds) from *decisions about plans* (where speed compounds). A buggy system is permanent damage; a wrong plan can be replanned in a day.
+
+## Walkthrough
+
+A worked decision. Your team is choosing between two API design approaches:
+
+```text
+Option A: Stateful REST API with sessions
+Option B: Stateless API with JWTs
+```
+
+Junior engineer's instinct: research deeply, compare for two weeks, build proof-of-concept, RFC, discussion in architecture review.
+
+Senior engineer's analysis:
+
+1. **What kind of door is this?** Two-way. Either choice can be migrated later with moderate cost (a few months of engineering work).
+2. **Cost of delay?** The API blocks 3 other teams. Delay costs ~$50k/week of other-team idle time and slipped customer commitments.
+3. **What's the decision-quality gap?** Both options are workable. The difference in outcome is maybe 10-20% on operational characteristics. The decision-quality gap doesn't change with two weeks of further analysis.
+4. **What information would actually change the answer?** A specific customer requirement that mandates JWTs (federated identity) or a specific operational constraint (server-side revocation). These are findable in an hour, not two weeks.
+
+The senior engineer's call: "Spend one hour validating that JWTs satisfy the planned federation case. If yes, choose B. If no, choose A. Make the call by end of day."
+
+The probability that the *other* option was "correct" and would have produced materially better outcomes is low. The cost of a 2-week analysis to reduce that probability is high. Speed wins here.
+
+The same logic doesn't apply to choosing the database technology for a financial-records system: that's closer to a one-way door, with high cost of being wrong. Slow down for those.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  decision[Decision] --> door{Two-way or one-way?}
+  door -->|Two-way| fast[Make fast - minutes/hours]
+  door -->|One-way| slow[Make slow - weeks, broad consultation]
+  fast --> mistake{Was it wrong?}
+  mistake -->|Yes| reverse[Reverse cheaply]
+  mistake -->|No| compound[Learn and proceed]
+  slow --> commit[Commit deeply]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Treating two-way doors as one-way | Engineering preference for precision | Categorize the door first; speed the two-ways. |
+| Ignoring cost of delay | Visible cost is the project; delay cost is invisible | Estimate cost of delay explicitly. |
+| Real-options thinking everywhere | "We might need optionality" | Optionality has cost; pay only when probability of exercise is real. |
+| Slowing down to "consult more" | Risk-aversion | Most consulting doesn't change the decision; speed up. |
+| Treating speed as recklessness | Engineering culture | Speed is a *capability*. Recklessness is failure to assess door type. |
+
+## Exercises
+
+1. List 5 recent engineering decisions your team made. Classify each as one-way or two-way door. For the two-way doors, estimate the cost of how long it took. Identify any that took disproportionate time.
+2. For a current decision in your queue, write a 5-minute pros/cons. Make the call. Compare to how long the actual decision process is taking. Note the gap.
+3. Identify one place where your team has paid for real-options (e.g. a cloud-portability abstraction). Estimate the probability you'll ever exercise the option. If <30%, the cost may exceed the value.
+
+## Recap & next
+
+- Most decisions are two-way doors and should be made fast; reserve deliberation for one-way doors.
+- Cost of delay is a real economic concept usually under-measured in engineering organisations.
+- Real-options thinking justifies *not committing* - but optionality has cost; pay only when needed.
+- Speed in decision-making compounds; it's a structural competitive advantage at scale.
+
+Next, kicking off **Module 6 - The Technical Leader's Playbook (Capstone)**, starting with **Translating engineering work into business value**.
+{% endraw %}
diff --git a/_courses/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.md b/_courses/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.md
new file mode 100644
index 0000000..83c12c5
--- /dev/null
+++ b/_courses/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.md
@@ -0,0 +1,188 @@
+---
+chapter_id: 1
+chapter_slug: translating-engineering-to-business
+chapter_title: "Translating engineering work into business value"
+chapter_summary: "Establishes output-vs-outcome as the central translation distinction and maps common engineering metrics to business metrics (latency→conversion, reliability→NRR, etc.). Names when *not* to translate (foundational/table-stakes work) and the credibility-damaging anti-patterns."
+---
+
+{% raw %}
+## What you'll learn
+- The translation patterns that turn engineering output into business outcome language.
+- How to map engineering metrics to business metrics (latency → conversion, reliability → NRR, etc.).
+- Where pure engineering excellence is the right answer and translation is wrong.
+- The common anti-patterns that make engineers' translations land badly.
+
+## Concepts
+
+This entire course has been building toward this chapter. The skill is *translation*: rendering engineering work in language that the rest of the company can value. It's the difference between work being respected at the exec level and being invisible.
+
+The default engineering language is *output*: code shipped, features built, bugs fixed, latency reduced, deploys per day. Business language is *outcome*: revenue moved, customers retained, deals closed, costs reduced. The two languages talk past each other.
+
+A senior engineer's job - increasingly so as they move into staff, principal, or management roles - is to be fluent in both, and to translate one to the other in real time.
+
+### Output vs. outcome
+
+The cleanest framing.
+
+**Output** = what you produced.
+- "Shipped distributed tracing across all microservices."
+- "Reduced p99 latency from 800ms to 200ms."
+- "Refactored the auth service."
+- "Cleared 20% of the bug backlog."
+
+**Outcome** = what changed in the world because of the output.
+- "Reduced mean-time-to-resolve from 4 hours to 30 minutes; engineering team responds to ~12 fewer pages/month."
+- "Improved checkout conversion by 0.4%, contributing ~$1.2M of annualized revenue."
+- "Enabled the SSO/SAML feature the enterprise sales team needs to close $4M of stalled pipeline."
+- "Reduced customer-reported reliability incidents by 30%, contributing to NRR moving from 108% to 113%."
+
+Most engineering output has an outcome attached, even if no one measured it. The translation skill is identifying and articulating that outcome - and sometimes setting up the measurement upfront.
+
+### Mapping engineering metrics to business metrics
+
+Some translations are well-trodden. Engineers should know these by heart.
+
+| Engineering metric | Business metric it moves | How |
+|---|---|---|
+| p99 latency | Conversion rate, retention | Frustrated users abandon |
+| Uptime / reliability | NRR, GRR, churn | Outages → churn signals |
+| MTTR (mean-time-to-resolve) | Operational cost, customer support volume | Faster resolution → cheaper ops |
+| Onboarding time-to-value | Free-to-paid conversion | Users who don't see value churn |
+| API throughput | Customer scalability | Customers that hit limits cap their growth |
+| Infrastructure cost / unit | Gross margin | Cost-per-unit shows up in COGS |
+| Test coverage / deployment frequency | Velocity of feature delivery | Faster delivery → faster validation |
+| Security posture | Enterprise win rate | Security questionnaires gate enterprise deals |
+| Internal developer velocity | Engineering capacity | More features per engineer-month |
+
+These mappings aren't always 1:1, but they're directionally reliable. A senior engineer who can name the business metric their work is supposed to move is rare and valuable.
+
+### Where translation goes wrong
+
+Common patterns to avoid:
+
+**1. Translating output as if it were outcome.**
+
+> "We migrated 80% of services to Kubernetes."
+
+This is output, not outcome. What changed in the world? Until you can say "...which reduced infra cost by $400k/year and allowed us to onboard 3 new product teams without infra friction," it's not translation.
+
+**2. Quantifying without source.**
+
+> "This will improve our conversion rate by 5%."
+
+Where's the 5% from? If a senior engineer says this without a source, exec readers discount the entire memo. Use ranges with sources: "Industry data suggests latency improvements at this magnitude yield 0.3-1.5% conversion lift" with a link.
+
+**3. Translation that's worse than the source.**
+
+> "Reduced cyclomatic complexity by 15% by refactoring the order pipeline."
+
+This is engineering-to-engineering translation; it's not for an exec audience. Translate higher: "Refactored the order pipeline so that future changes ship in 2 days instead of 2 weeks; the next 3 features in the roadmap will benefit."
+
+**4. Cargo-culting business language.**
+
+> "This work drives synergies and ROI across the value chain."
+
+Don't. Specific, concrete claims always beat generic business-school phrasing.
+
+**5. Over-claiming the outcome.**
+
+> "Reduced incident rate by 50%, which is directly responsible for our NRR uptick."
+
+NRR has many drivers; claiming sole credit for a movement strains credibility. Better: "Reduced incident rate by 50%; among the contributing factors, customer success cited reliability improvements in 4 of the 7 expansion-account conversations this quarter."
+
+### When NOT to translate
+
+A counterintuitive point. Sometimes the right answer is "this work is foundational engineering excellence; trust us." Examples:
+
+- **Technical debt paydown** - sometimes the only honest framing is "we won't be able to ship anything in 18 months without this."
+- **Security hardening** - sometimes the framing is "the cost of *not* doing this is catastrophic; the cost of doing it is bounded."
+- **Refactoring legacy systems** - sometimes the framing is "the future of this product depends on this."
+
+Forcing every piece of engineering work into a contrived business-metric narrative weakens credibility. Some work doesn't have a tidy ROI; it's *table stakes*. Exec teams generally respect "this is table stakes work; here's why" when delivered with confidence.
+
+The distinction: feature work, performance work, scalability work usually has a translatable business outcome. Foundational work sometimes doesn't, and inventing one is worse than naming the foundational character honestly.
+
+### Building the translation muscle
+
+A few exercises that build the skill over time:
+
+1. **Pre-write the outcome.** Before starting a project, write the one-sentence business-outcome story for what success looks like. If you can't write it, you may not understand what you're building for.
+2. **Read sales calls.** Customer-success teams record calls. Listen to 5 of them in your team's space. Notice the language customers use to describe value. That language is your translation vocabulary.
+3. **Practice on your team's standup.** Once a week, replace "we shipped X" with "we shipped X, which means [business outcome]." It feels awkward at first; the awkwardness fades.
+4. **Read 10-Q filings.** Public companies translate constantly. Reading 3-4 SaaS company 10-Qs builds intuition for what business metrics matter and how they're framed.
+
+### Example: a year-end engineering review
+
+A worked example. You're a tech lead writing the year-end summary for your team.
+
+**Engineering-only version:**
+
+> "This year, our team shipped 4 major features (audit log, SSO/SAML, custom roles, API rate limits), reduced p99 latency by 60%, cleared 35% of the bug backlog, and migrated 12 services to the new deployment platform. We maintained 99.97% uptime."
+
+**Business-translated version:**
+
+> "This year our team's work contributed to three measurable business outcomes:
+>
+> 1. **$6.4M of enterprise pipeline unblocked.** Audit log, SSO/SAML, and custom roles were the three most-requested security features in enterprise RFPs. With these shipped, the deal team converted 4 of 6 stalled enterprise prospects (close-won $4.2M ARR), and the remaining 2 are now in active negotiation. (Reference: Q3 sales pipeline report.)
+>
+> 2. **Improved NRR from 109% to 114%.** Reliability work (60% p99 latency reduction, uptime 99.97%) was cited by CS as a top-3 retention factor in expansion conversations. The combined improvement contributes ~$2M of annualized revenue retention.
+>
+> 3. **Doubled team capacity for next year.** The deployment platform migration cut our mean PR-to-prod time from 47 minutes to 6 minutes. Per the onboarding survey, new hires now ship their first feature in 6 weeks instead of 12. Net effect: we can absorb 8 new engineers next year while shipping the same feature roadmap.
+>
+> Looking ahead: the three biggest engineering risks for next year are platform scale (we're at 70% of our hosting capacity), security tooling (one CISO-level audit signaled gaps in incident triage automation), and the auth migration (we still have one key-person dependency I'm working to reduce)."
+
+The second version is the same work, framed for the audience that funds the team and decides whether the work mattered. It also names risks honestly - which builds credibility for future asks.
+
+## Walkthrough
+
+The translation conversation in real time. A scenario.
+
+**Scene**: You're in a QBR. The CRO presents a slide showing churn ticked up in Q2. The room is dispirited. The CEO turns to you (CTO/VP Eng) and asks "what's engineering doing about churn?"
+
+**Bad answer (output):**
+
+> "We're focused on reliability and performance. We shipped distributed tracing this quarter."
+
+**Better answer (outcome):**
+
+> "Three things. First, the reliability work has reduced P0 incidents by 40% - and per CS, 3 of the 8 churned accounts this quarter cited reliability concerns, so we expect that to improve next quarter as customers see the change. Second, we shipped the API rate-limit fairness changes that unblocked the heaviest users - that was the most-cited frustration in churn interviews. Third, the bigger pattern in churn interviews is product breadth - customers leaving for competitors that have specific features we don't. We're prioritizing those for Q3 - three of the top five churn reasons should be addressed by end of Q3."
+
+The second answer maps engineering work directly to the question being asked, acknowledges what engineering doesn't yet solve, and signals action. The first answer answers a different question. The skill of the second is purely translation.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  output[Engineering output: code, features, metrics] --> question{Why should the audience care?}
+  question -->|Maps to business| outcome[Business outcome language]
+  question -->|Foundational, no easy translation| stakes[Frame as table-stakes / risk]
+  question -->|Doesn't map| pause[Step back: is this work justified?]
+  outcome --> audience[Right framing for the audience]
+  stakes --> audience
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Listing output without outcome | Default to what you know | Pre-write the business outcome before starting work. |
+| Cargo-culting business jargon | "I should sound businessy" | Use specific, concrete language. |
+| Over-claiming credit for outcomes | Engineering ego | Share credit; let CS confirm the link from churn to reliability. |
+| Forcing outcomes onto foundational work | "Everything needs a metric" | Name table-stakes work honestly; don't invent an ROI. |
+| Skipping the translation entirely | "Let leadership figure it out" | They won't. The translation is your job. |
+
+## Exercises
+
+1. For your last 3 shipped projects, write the business-outcome translation for each. Compare to how the projects were framed in your team's quarterly review. The gap is your translation opportunity.
+2. Listen to 3 customer-success calls about your product. Note the language customers use. Build a vocabulary list of business-outcome language that resonates with actual customers.
+3. For your team's next quarterly review, prepare a 5-minute presentation framed entirely in business outcomes. Run it past a non-engineering peer before delivering. Iterate.
+
+## Recap & next
+
+- Translation is the rendering of engineering output in business-outcome language.
+- Specific mappings (latency → conversion, reliability → NRR, etc.) cover most engineering work.
+- Avoid over-claiming credit, cargo-culting business language, and forcing outcomes onto foundational work.
+- Translation is a learnable skill that compounds: every time you do it, the next time is easier.
+
+Next, **Writing strategy & investment memos** - the long-form version of translation, in the document formats executives actually read.
+{% endraw %}
diff --git a/_courses/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.md b/_courses/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.md
new file mode 100644
index 0000000..4e9f041
--- /dev/null
+++ b/_courses/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.md
@@ -0,0 +1,265 @@
+---
+chapter_id: 2
+chapter_slug: strategy-and-investment-memos
+chapter_title: "Writing strategy & investment memos"
+chapter_summary: "Walks through the Amazon 6-pager and PRFAQ formats, the silent-read meeting discipline, and the FAQ as the highest-leverage section. Distinguishes when to use a memo vs a deck."
+---
+
+{% raw %}
+## What you'll learn
+- The Amazon 6-pager - what it is, why it's structured the way it is, and how to write one.
+- Working-backwards / PRFAQ - Amazon's product-design memo format, especially useful for new products.
+- When to write a memo vs. when to make a deck.
+- The discipline of writing for an audience that reads in silence.
+
+## Concepts
+
+The investment-case memo from [Chapter 5.3](/courses/engineers-mba/05-capital-risk-decisions/03-investment-case/) is the short form. For larger bets - new products, major strategic shifts, multi-year platform investments - the canonical format is the *long memo*. The best-known instance is the [Amazon 6-pager](https://www.businessinsider.com/jeff-bezos-amazon-six-page-memo-meetings-2018-4).
+
+The 6-pager isn't six pages because of magic. It's six pages because (a) it's enough space to think rigorously about a real decision, (b) it's short enough that the audience will actually read it, (c) the constraint forces the writer to cut everything that isn't load-bearing. Companies that adopt it (Amazon, Stripe partially, Coinbase, many others) report that decision quality improves measurably.
+
+### The Amazon 6-pager
+
+The structure is informal - Amazon doesn't publish a template. The pattern that emerges from reading hundreds of them:
+
+```text
+1. Context and problem statement (½-1 page)
+   - What is this about?
+   - What's the problem we're trying to solve?
+   - Why now?
+
+2. Goals and non-goals (½ page)
+   - What success looks like
+   - What we're explicitly NOT trying to do
+
+3. Background / current state (1 page)
+   - What's the world look like today?
+   - What's been tried? What's worked? What hasn't?
+
+4. Proposal (1-1.5 pages)
+   - What we're proposing to do
+   - Architecture or approach
+   - Phasing if applicable
+
+5. Alternatives considered (½-1 page)
+   - Other options we evaluated
+   - Why they were rejected (vital - this signals the analysis is real)
+
+6. Risks and mitigations (½ page)
+   - What could go wrong
+   - How we'd respond
+
+7. Cost and timeline (½ page)
+   - Capital, time, opportunity
+   - Major milestones
+
+8. Decision required (¼ page)
+   - Exactly what we're asking for
+   - Who needs to approve
+
+9. Appendix: FAQs (1-2 pages)
+   - Anticipated questions with answers
+   - Often the most useful section
+```
+
+The total is 6-8 pages. Not 16, not 4. The constraint is the discipline.
+
+### The meeting that follows
+
+A 6-pager isn't a document distributed for asynchronous reading. It's the input to a *meeting*. The meeting runs in a specific format:
+
+1. **Silent reading** - 20-30 minutes at the start. Everyone reads the memo, makes notes, prepares questions. No one talks. This is the part most people find awkward and is also the most important.
+2. **Discussion** - the rest of the meeting (60-90 minutes typically). The author defends, clarifies, and notes follow-ups. The audience pressure-tests the analysis.
+3. **Decision or follow-up** - the meeting ends with either a decision or specific items the author needs to revise.
+
+Why the silent reading: because most meetings are dominated by whoever speaks fastest and most confidently. The silent-read flips this - everyone has read the memo before opinions are aired, so the discussion is grounded in the same content. Junior contributors with good questions can ask them; senior contributors don't dominate by reciting from memory what only they have access to.
+
+### What makes a good 6-pager
+
+A few principles, learned the hard way:
+
+**Force the reader to disagree explicitly.** A memo that lists three alternatives, names why each was rejected, and explicitly identifies the assumptions that would change the answer makes it easy for a critic to push back: "I disagree with assumption X." Memos that hide the assumptions force critics to extract them, which produces longer, lower-quality meetings.
+
+**Use the FAQ aggressively.** The appendix FAQ is where you anticipate the hard questions. "Q: Why not just use [obvious alternative]? A: [4-sentence answer]." A strong FAQ section turns a 60-minute discussion into a 30-minute one because the obvious questions have already been answered.
+
+**Cut everything that doesn't change the decision.** Every paragraph should pull weight. The discipline of cutting is the source of the format's value.
+
+**Make numbers concrete.** "We expect significant adoption" doesn't help. "Based on current trial-to-paid conversion of 8% and 200 trials/month, we project $2-3M ARR in Year 1, with the most likely outcome around $2.4M." This is testable; the first isn't.
+
+**Use prose, not slides.** The 6-pager works because prose forces complete sentences and complete arguments. Slides hide arguments behind bullets.
+
+### The PRFAQ format
+
+For *new product* decisions, Amazon uses a variant called PRFAQ (Press Release + FAQ). The structure:
+
+```text
+1. The press release (1 page)
+   - The press release we'd write when this product launches
+   - Quote from a customer
+   - Quote from an exec
+   - Date of launch
+
+2. Internal FAQ (3-5 pages)
+   - Q: Why are we building this?
+   - Q: Who's the customer?
+   - Q: What's the experience?
+   - Q: How big could this be?
+   - Q: What are the risks?
+   - Q: Build vs buy?
+   - ... (continued)
+```
+
+The PRFAQ forces the team to *start from the customer outcome* - what does the world look like when this product is in market? - and work backward to the engineering plan. It's especially useful when the team is at risk of building features that won't add up to a coherent product.
+
+[Working Backwards](https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595) by Colin Bryar and Bill Carr is the canonical book on the format. Worth reading if you're going to write more than one.
+
+### When to use which format
+
+| Decision type | Format |
+|---|---|
+| Resource request, < 1 quarter | Slack message / 1-page memo |
+| Feature investment | Investment case ([Chapter 5.3](/courses/engineers-mba/05-capital-risk-decisions/03-investment-case/)) |
+| Multi-quarter project | Full 6-pager |
+| New product or major strategic shift | PRFAQ |
+| Tactical decision in a team | Verbal + decision log |
+| Org change | 6-pager + verbal communication plan |
+
+### Memo vs. deck
+
+A persistent question in many companies: should this be a deck or a memo?
+
+**Deck strengths:**
+- Visual elements (charts, diagrams)
+- Easier to skim
+- More familiar in many companies
+- Better for live presentation
+
+**Memo strengths:**
+- Forces complete arguments
+- Async-friendly (read once, return to it)
+- Critic-friendly (hard to hide weak reasoning)
+- Compresses argument density
+
+Decks are better for *communication*; memos are better for *decision-making*. The Amazon convention pushes decisions into memos. Many companies use both: a memo for the decision; a deck if the decision needs to be communicated broadly afterward.
+
+A useful test: if the document needs to convince a critical, time-constrained reader who reads silently and forms an independent opinion, write a memo. If the document needs to be presented live with discussion as you go, a deck may be the better tool.
+
+### The hidden discipline: writing forces thinking
+
+The most under-appreciated benefit of the 6-pager isn't communication - it's *the act of writing it*. Forcing yourself to write 6 pages of complete sentences exposes gaps in your thinking that bullet points can hide.
+
+Bezos famously wrote that he could "tell when a 6-pager has been written by someone who hasn't actually thought through the problem" - the prose breaks down, the FAQ is thin, the alternatives section is wave-of-hand. The reverse is true too: when you sit down to write a 6-pager and discover a gap in your reasoning, fixing the gap is the actual benefit.
+
+A senior engineer's productivity boost from this format is often invisible to others but visible to themselves: they make better decisions because they've forced themselves to think them through completely.
+
+## Walkthrough
+
+A worked outline. You're proposing a new product: an AI-powered code-review assistant.
+
+```text
+1. CONTEXT
+   We've shipped 47 features this year. Code review has emerged as 
+   the #1 cycle-time bottleneck (per Q2 dev velocity survey). Average 
+   review cycle is 36 hours. Six of nine engineering leaders cite 
+   review backlog as a top friction point.
+
+   AI-powered code review is now mature enough to ship (Year 1 of 
+   tools like Cursor, Cody, Copilot Code Review). Two key competitors 
+   announced offerings in Q2.
+
+   Why now: industry trajectory + internal pain + investor pressure 
+   to ship AI features visible to customers.
+
+2. GOALS AND NON-GOALS
+   Goals:
+   - Reduce review cycle time from 36h to <12h
+   - Catch common issues before human review (security, perf, 
+     accessibility regressions)
+   - Ship to internal teams in Q3; external in Q1 next year
+
+   Non-goals:
+   - Replace human review
+   - General code generation (separate effort)
+   - Support for languages beyond our top 5
+
+3. BACKGROUND
+   [1 page on current state, what's been tried, who's doing what]
+
+4. PROPOSAL
+   [1.5 pages on architecture, phasing, integration with current tooling]
+
+5. ALTERNATIVES CONSIDERED
+   - Buy a third-party tool (CodeRabbit, Greptile, etc.)
+     Reject because: data sensitivity, brand requirements, want 
+     ownership of the user experience for our customer base.
+   - Build only an internal tool
+     Reject because: customer asks suggest external product 
+     opportunity with $50M+ TAM.
+   - Defer
+     Reject because: competitors shipping; window closing.
+
+6. RISKS AND MITIGATIONS
+   - AI quality below expectations → ship as "suggestions only" 
+     mode initially; gate full automation behind a quality bar.
+   - Integration complexity with existing review tooling → narrow 
+     scope to GitHub-first, expand from there.
+   - Strategic competition from existing tools → invest in 
+     differentiation (security focus, languages).
+
+7. COST AND TIMELINE
+   8 engineers × 9 months → $2.9M loaded
+   Vendor (model providers, training infra) → $400k Year 1
+   Internal pilot Q3; external GA Q1 next year.
+
+8. DECISION REQUIRED
+   - Approve 8-engineer team starting July 1
+   - Approve $400k vendor budget for first year
+   - Designate a senior PM and senior staff engineer
+
+9. FAQ (1.5 pages)
+   - Q: Why 8 engineers? A: ...
+   - Q: Why now vs Q4? A: ...
+   - Q: How does this compare to [competitor]? A: ...
+   - Q: What's the kill criteria? A: ...
+   - Q: How do we measure success? A: ...
+```
+
+A full memo with each section filled out would be ~6 pages. The FAQ alone might be 2 of those pages. The format forces the proposal to engage with the obvious questions before the meeting, which makes the meeting shorter and more productive.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  decision[Major decision] --> draft[Author writes memo]
+  draft --> faq[Author writes FAQ - hardest part]
+  faq --> distribute[Distribute 24-48h before meeting]
+  distribute --> meeting[Meeting: silent read + discussion]
+  meeting --> revise[Revise or decide]
+  revise --> final[Final decision logged]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Sending the memo too late | Authors run late | Distribute 24-48h in advance; silent-read time eats into the meeting otherwise. |
+| Thin FAQ | "We'll address questions in the meeting" | FAQ is the highest-value section; invest in it. |
+| Hidden assumptions | "Everyone knows this" | Make assumptions explicit; reviewers can challenge them then. |
+| Skipping alternatives section | "Our proposal is obviously best" | Naming alternatives builds credibility; skipping them invites pushback. |
+| Memo for small decisions | Format inflation | Use 1-pagers or Slack messages for small things. |
+
+## Exercises
+
+1. Take a recent major decision your team made. Outline a 6-pager retrospectively. Notice which sections are hard to fill in - those are usually the parts of the decision that weren't analyzed.
+2. For your next significant proposal, draft a PRFAQ. The press release alone is a useful exercise: can you write a compelling launch story?
+3. Find a public Bezos shareholder letter and read it as a long-form memo. Note the structure, the use of specific numbers, the clear positioning. Bezos has been training the world in this format for 25 years.
+
+## Recap & next
+
+- The Amazon 6-pager and PRFAQ are the canonical long-form decision documents.
+- The format enforces discipline - forcing the writer to think through the problem completely.
+- Silent reading at the start of the meeting flips the dynamic: ground discussion in the same content, give junior contributors space.
+- FAQs are the highest-value section; invest in anticipating hard questions.
+
+Next, **Reading & contributing in exec reviews** - what actually happens in QBRs and board meetings, and how to participate effectively.
+{% endraw %}
diff --git a/_courses/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.md b/_courses/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.md
new file mode 100644
index 0000000..80fb0f3
--- /dev/null
+++ b/_courses/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.md
@@ -0,0 +1,244 @@
+---
+chapter_id: 3
+chapter_slug: reading-exec-reviews
+chapter_title: "Reading & contributing in exec reviews"
+chapter_summary: "Covers QBR mechanics, board-deck reading, the role of pre-meetings, when to interject, and how to read the room. Emphasises that QBRs ratify decisions formed in pre-meetings - not the other way around."
+---
+
+{% raw %}
+## What you'll learn
+- The anatomy of a Quarterly Business Review (QBR) and what the audience is actually evaluating.
+- How a board meeting works and how to read a board deck.
+- When and how to interject in exec reviews without overstepping.
+- The role of pre-reads and pre-meetings in shaping outcomes.
+
+## Concepts
+
+[Module 4 Chapter 2](/courses/engineers-mba/04-operating-a-software-business/02-operating-cadence/) introduced the operating cadence. This chapter goes deeper into the *mechanics* - the rhythm, etiquette, and unwritten rules of exec reviews.
+
+The reason it matters: most strategic decisions get made in these meetings or in the conversations that surround them. Engineers who can participate fluently extract disproportionate value for their teams and their careers. Engineers who can't either skip the meetings or attend them passively, missing the windows where their work could shape the strategy.
+
+### QBR anatomy
+
+A QBR typically runs over 1-3 days. The agenda is set by the executive team, distributed in advance, and contains pre-read materials for each session. The flow:
+
+```text
+Day 1
+  Morning: CEO opens, sets strategic context for the quarter
+  Mid-morning: Sales & marketing review (often the longest)
+  Afternoon: Product & engineering review
+  Late afternoon: Customer success / support review
+
+Day 2
+  Morning: Finance review, board prep
+  Mid-morning: Functional deep-dives (rotated topics)
+  Afternoon: Strategy discussions / what-if planning
+  Late afternoon: Decisions and follow-ups
+
+Day 3 (sometimes)
+  Working sessions on specific strategic topics
+```
+
+The format varies by company. Public companies often combine QBRs with board prep. Private companies typically separate them.
+
+What the audience is *actually* evaluating:
+
+- **Sales/marketing review** - Are we executing? Pipeline coverage, win rates, segments. Is the GTM motion working?
+- **Product/engineering review** - Are we shipping what matters? Roadmap progress, customer impact, technical risks.
+- **CS/support review** - Are we keeping the customers we won? NRR, support metrics, customer health.
+- **Finance review** - Are the unit economics improving? Spend trajectory, runway, financial outlook.
+- **Strategy discussions** - Are we on the right path? Course correction needed?
+
+Engineers presenting in QBR should anticipate: which question does *this part of the meeting* answer, and how does my work fit?
+
+### Pre-reads
+
+The pre-read is the document distributed 1-3 days before the meeting. It usually includes:
+
+- The agenda with timing
+- Each function's slide deck or memo
+- The board deck for board meetings
+- Specific decision asks
+
+The pre-read works *if people actually read it*. Most don't, fully. Most read the executive summary, skim the rest, and arrive at the meeting partially informed. This is sub-optimal but reality.
+
+The implication for presenters: assume your audience has skimmed but not absorbed your full content. The first 30 seconds of your presentation should re-establish context. Don't assume they remember the details of last quarter.
+
+### Pre-meetings
+
+The actual decisions in many companies are made *before* the QBR, in 1:1 pre-meetings. Senior leaders meet pairwise to align on positions, surface concerns, and build coalitions. By the time the QBR happens, much of the substantive conversation has already occurred.
+
+This isn't dysfunctional - it's how human organisations work above a certain size. The QBR is a *coordination* event where positions are aired publicly and decisions are made; the pre-meetings are where positions get formed.
+
+For senior engineers, this means:
+- The right time to influence a decision is *before* the QBR, in pre-meetings with the relevant decision-makers.
+- Arriving at the QBR with a new position no one has heard is often unsuccessful - the existing positions have already coalesced.
+- Building relationships with non-engineering leaders (CFO, CRO, CMO) is how positions get shaped pre-meeting.
+
+The first time many engineers realise pre-meetings exist, they're frustrated. "I thought the QBR was where decisions happen." The QBR is where decisions are *ratified*. The decisions are made in the side channels.
+
+### How to read a board deck
+
+A board deck is the document distributed to the board ahead of a meeting. Typical structure:
+
+```text
+1. CEO update (3-5 pages)
+   - Strategic narrative for the quarter
+   - Major events, wins, losses
+   - Forward outlook
+
+2. Financial performance (5-10 pages)
+   - The metric tree (Module 4 Chapter 1)
+   - Cohort analyses, segment breakdowns
+   - Variance to plan
+
+3. Functional updates (10-20 pages)
+   - Each major function (Product, Engineering, Sales, Marketing, CS)
+   - Major projects and outcomes
+   - Strategic risks and asks
+
+4. Decisions required (1-3 pages)
+   - Specific votes or approvals
+   - New hires of senior executives
+   - Acquisitions, partnerships
+   - Major capital commitments
+
+5. Appendices (variable)
+   - Supporting analysis
+   - Detailed financials
+   - Risk register
+```
+
+When reading a board deck (as an employee or board member), look for:
+
+- **Variance to plan** - where the company is hitting or missing commitments
+- **Trend lines** - are key metrics getting better or worse?
+- **New risks** - what wasn't there last quarter?
+- **Strategic shifts** - is the narrative changing? Why?
+- **Specific decisions** - what does the company want from the board?
+
+The board reads this looking for signal. Effective engineering contributions to the board deck *make signal more visible* - clear charts, specific numbers, honest risk reporting.
+
+### When and how to interject
+
+In a QBR or exec meeting, when should you speak up?
+
+**Almost always speak up when:**
+- You have a question or concern that's been raised in pre-meeting and now isn't being addressed
+- A factual statement is wrong (correct it briefly, without ego)
+- A specific number being cited needs context (offer it)
+- A decision is about to be made on incomplete information you can complete
+
+**Rarely speak up when:**
+- The discussion has reached agreement and you have a slight preference variant
+- The point is about your team and you've already had the relevant pre-meeting
+- The room is in a discussion you don't have material context for
+- The point is purely technical and the audience won't follow
+
+The skill is calibration. Senior engineers who interject too rarely become invisible; those who interject too often become exhausting. The right cadence varies by your role and the room.
+
+A useful heuristic: ask yourself before interjecting, *"will this materially change the decision being made?"* If yes, speak. If you're just adding a slight nuance, save it for after the meeting.
+
+### Reading the room
+
+Some practical skills:
+
+- **Who's running the meeting?** Different from who has the most authority - the meeting runner shapes the flow.
+- **Who's asking probing questions?** Those people are forming the decision.
+- **What's the energy level?** A QBR after a bad quarter has different dynamics than one after a great quarter.
+- **What's being avoided?** Sometimes the most important topic is the one no one's bringing up - and someone should.
+
+Engineers who learn to read these signals contribute more effectively. It's a skill that takes time to develop.
+
+### The "follow up offline" close
+
+Almost every meeting ends with "let's follow up on that offline." Take this seriously. The follow-ups are where the actual coordination happens between the formal meeting moments.
+
+A useful practice: end each meeting with a clear list of follow-ups, each with an owner and a deadline. Track them through completion. Most meetings drift because the follow-ups go uncataloged.
+
+## Walkthrough
+
+A worked scenario. You're a Staff engineer attending your first QBR. The agenda includes a "Product & Engineering Review" session where you'll present 5 minutes on your team's quarter.
+
+**Pre-meeting (3 days before):**
+- 1:1 with VP Engineering to align on what you'll present
+- 1:1 with PM partner to make sure the messaging matches their narrative
+- Quick check with CRO's office about any deal-specific stories worth highlighting
+
+**Your 5 minutes:**
+
+```text
+[10 seconds opening]
+"I'm going to cover three things our team shipped this quarter and 
+the business outcomes we've tracked from each. Then a forward-looking 
+risk I want the room aware of."
+
+[1 minute, outcome 1]
+"First, the SSO/SAML enterprise support. Three deals that had been 
+stalled since Q1 closed this quarter, totaling $2.8M ARR. The deal 
+team confirms SSO was named in the sales-stage notes as the blocker 
+for all three. Going forward, audit log is the next-most-cited 
+blocker - that's on our Q3 roadmap."
+
+[1 minute, outcome 2]
+"Second, reliability work. We reduced P0 incident rate from 2.1/month 
+to 0.7/month. CS reported that 3 of the 8 at-risk renewals this 
+quarter cited reliability concerns; by renewal, 2 of those had 
+explicitly stabilized and stayed. The third is still at risk for 
+other reasons but reliability isn't one anymore."
+
+[1 minute, outcome 3]
+"Third, the deployment platform migration is at 75% of services. 
+Average deploy time has dropped from 47 to 9 minutes. New-hire 
+time-to-first-feature is now 8 weeks instead of 12 weeks per the 
+last onboarding survey. We're on track to complete the migration in 
+Q3, freeing 1.5 FTEs of platform-team capacity for new product work."
+
+[2 minutes, forward look + risk]
+"Looking ahead, the biggest risk I want the room aware of is hiring. 
+We have 3 senior platform roles open and have been struggling to 
+fill them - average req-to-seated time has been 18 weeks vs target 
+of 12. If we can't close this gap by mid-Q3, the analytics product 
+launch slips by a quarter. I'd like to talk to recruiting leadership 
+about expanding the search."
+```
+
+The presentation is short, outcome-focused, and surfaces a risk before it becomes an emergency. The forward-looking ask creates a follow-up the room can act on. Five minutes well spent.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  prereads[Pre-reads distributed] --> premeet[Pre-meetings: align positions]
+  premeet --> qbr[QBR: surface and ratify decisions]
+  qbr --> followup[Follow-ups: coordinate execution]
+  followup --> next[Inform next quarter's plan]
+  decisions[Decisions get made] -.-> premeet
+  decisions -.-> qbr
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Skipping pre-meetings | "I'll cover it in the QBR" | The QBR ratifies what pre-meetings shape; you need both. |
+| Long technical presentations in QBR | Default to what you know | Translate to outcomes; lead with the business metric, not the tech. |
+| Quiet attendance | "I don't have anything to add" | If you have nothing to add, you may not need to be there. Earn the seat. |
+| Bringing operational details to strategic meetings | Mismatch of forum and topic | Save operational for MBRs; QBR is strategic. |
+| Missing follow-ups | No one tracks them | Catalog follow-ups with owners and deadlines; chase them. |
+
+## Exercises
+
+1. Attend your next exec meeting (or read the recording/notes). Track who interjects, when, and what for. Note the pattern of pre-meeting alignment vs. live discussion.
+2. For the next QBR you present in, write your 5-minute script in advance. Test it against a non-engineering colleague (CFO partner, PM lead). Iterate.
+3. Read your company's last board deck (if available). Read it the way a board member would - looking for signal, variance to plan, new risks. Note what jumps out.
+
+## Recap & next
+
+- QBRs are coordination events where decisions are ratified; pre-meetings are where positions are shaped.
+- Pre-reads are distributed widely and skimmed broadly; assume your audience has partial context.
+- Interject when it will materially change the decision; not when you have a slight preference variant.
+- Follow-ups are where execution happens; track them as religiously as the decisions themselves.
+
+Next, **Negotiating with sales, finance, product, legal** - the cross-functional vocabularies and how to map their incentives to yours.
+{% endraw %}
diff --git a/_courses/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.md b/_courses/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.md
new file mode 100644
index 0000000..d957cf7
--- /dev/null
+++ b/_courses/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.md
@@ -0,0 +1,214 @@
+---
+chapter_id: 4
+chapter_slug: cross-functional-negotiation
+chapter_title: "Negotiating with sales, finance, product, legal"
+chapter_summary: "Maps the incentives and vocabulary of sales, finance, product, and legal - reframing cross-functional 'conflicts' as differing-incentive trade-offs. Demonstrates decomposition as the productive negotiation pattern."
+---
+
+{% raw %}
+## What you'll learn
+- How sales, finance, product, and legal teams are actually incentivised, and what they're optimising for.
+- The vocabulary each function uses and how it maps to engineering vocabulary.
+- How to find positive-sum negotiations across functional lines.
+- The recurring conflict patterns and how to defuse them.
+
+## Concepts
+
+Cross-functional negotiation is the daily work of senior engineers. Sales wants a feature *now*; engineering wants it built *right*. Finance wants spending cut; engineering wants more headcount. Product wants more roadmap; engineering wants more time. Legal wants more guardrails; engineering wants to ship.
+
+The naive engineer-side framing is that these are *conflicts*. They mostly aren't - they're *trade-offs* between functions whose incentives are different. Understanding the incentives transforms many of these from adversarial conversations into collaborative ones.
+
+### Sales: incentives and vocabulary
+
+Sales reps work on *quota* - a target for how much new ARR they need to close in a period (usually a year, broken into quarters). Their compensation is heavily commission-based: typically 50% base + 50% variable, with accelerators above quota. The result: a salesperson is acutely focused on what closes deals *this quarter*.
+
+**Sales vocabulary:**
+- **ACV** - Annual Contract Value, the size of a deal annualised.
+- **Pipeline** - the forecast of deals at various stages.
+- **Commit / forecast** - the deals the rep is confident will close.
+- **Best case / pull-in** - deals that could close with stretch effort.
+- **Slipped** - a deal that won't close this quarter but might next.
+- **Stalled** - a deal that's not moving.
+- **Win rate** - close rate against an identifiable competitor or alternative.
+
+**What sales is optimising for:**
+- Close deals this quarter
+- Maintain pipeline coverage
+- Avoid blockers from any other function (engineering, product, legal)
+- Maximise commission
+
+**Where engineering and sales clash:**
+- Sales wants the feature for *this specific deal*. Engineering wants to build for the broader product.
+- Sales agrees to customisations. Engineering owns the maintenance forever.
+- Sales overpromises timelines. Engineering misses them.
+
+**How to negotiate productively:**
+- Translate engineering capacity into deal language. "We can ship audit log in Q3; that supports the 5 RFPs in your pipeline. Adding the federation feature requested by one customer adds 6 weeks - is that one deal worth $X of delay to the other 4?"
+- Use specific deal numbers when refusing custom work. "This customisation would consume 30% of our team for a quarter; it would block the SSO ship that 4 other prospects need. Net negative."
+- Build sales-team allies. The most effective senior engineers have a regular 1:1 with the sales leader or top AEs.
+
+### Finance: incentives and vocabulary
+
+Finance teams optimise for accurate forecasting, capital efficiency, and not surprising the board. Their incentives flow from the CFO down: hit the operating plan, beat consensus, manage cash.
+
+**Finance vocabulary:**
+- **Burn rate** / **runway** - covered in [Module 1 Chapter 3](/courses/engineers-mba/01-foundations-business-os/03-cash-profit-accruals/).
+- **OpEx / CapEx** - operating expense vs. capital expense (different P&L treatment).
+- **FTE** - Full-Time Equivalent (1.0 FTE = one full-time employee).
+- **Headcount budget** - the plan for hiring; usually quarterly.
+- **Above plan / below plan** - variance to commitment.
+- **Magic number, burn multiple, rule of 40** - covered in [Module 4 Chapter 1](/courses/engineers-mba/04-operating-a-software-business/01-saas-metric-tree/).
+
+**What finance is optimising for:**
+- Forecast accuracy (hitting commitments)
+- Capital efficiency (cost per unit of growth)
+- Cash runway (months of survival)
+- Predictability
+
+**Where engineering and finance clash:**
+- Engineering wants to hire 5 senior engineers. Finance wants to know if 3 mid-level would deliver 80%.
+- Engineering wants to spend $500k on cloud infrastructure. Finance wants the cost-per-customer breakdown.
+- Engineering wants to commit to a multi-year platform investment. Finance wants quarterly milestones.
+
+**How to negotiate productively:**
+- Bring finance into the conversation early. They hate surprises; they love being consulted.
+- Frame engineering decisions in financial terms. Headcount as capital; infrastructure as variable cost; platform investment as fixed-cost amortisation.
+- Use the metric tree vocabulary. "This will improve our magic number by 0.15 over 4 quarters."
+- Be specific about milestones and kill criteria. Finance will fund multi-year bets if the structure is right.
+
+### Product: incentives and vocabulary
+
+Product managers own the *what* and *why* of the roadmap; engineering owns the *how*. PMs are evaluated on shipping the right features that move the right business metrics. Their incentives include both internal (engineering velocity, sales enablement) and external (customer adoption, retention, revenue impact).
+
+**Product vocabulary:**
+- **PRD** - Product Requirements Document, the spec for a feature.
+- **OKR / KPI** - covered in [Module 4 Chapter 2](/courses/engineers-mba/04-operating-a-software-business/02-operating-cadence/).
+- **NSM** - North Star Metric, the single metric the product team optimises.
+- **Adoption / activation / engagement / retention** - funnel metrics for a feature.
+- **MVP / scope** - Minimum Viable Product; what's in vs. out.
+
+**What product is optimising for:**
+- Customer adoption and engagement
+- Business impact (NRR, conversion, etc.)
+- Shipping velocity
+- Strategic narrative
+
+**Where engineering and product clash:**
+- Product wants more features. Engineering wants more time per feature.
+- Product writes a PRD; engineering finds the requirements are ambiguous or contradictory.
+- Product wants to ship *something*. Engineering wants to ship *the right thing*.
+
+**How to negotiate productively:**
+- Treat the PM as your partner, not your customer. Engineering and product should be one team with one set of priorities.
+- When the PRD is ambiguous, push back early. "What's the success metric for this feature?" If they can't answer, the feature isn't ready.
+- Bring engineering options to product decisions. "We can ship the basic version in 3 weeks or the full version in 8 weeks. Which one moves NRR more?" Lets product decide on the trade-off.
+- Co-author the roadmap. Engineering input on what's possible and what builds toward the platform is critical to product's narrative.
+
+### Legal: incentives and vocabulary
+
+Legal teams optimise for *risk reduction*. Their job is to keep the company out of regulatory, contractual, and liability trouble. They are necessarily conservative; the cost of a mistake is asymmetric.
+
+**Legal vocabulary:**
+- **DPA** - Data Processing Agreement.
+- **SOC 2 / ISO 27001** - security certifications.
+- **GDPR / CCPA** - data-protection regulations.
+- **Indemnification / liability cap** - contractual limits on what the company owes if it screws up.
+- **Master Service Agreement (MSA)** - the standard customer contract.
+- **Open-source license** - copyleft, permissive, dual-license.
+
+**What legal is optimising for:**
+- Reduce regulatory risk (GDPR, sector-specific)
+- Limit contractual liability
+- Protect intellectual property
+- Avoid disputes
+
+**Where engineering and legal clash:**
+- Legal wants every feature reviewed for compliance. Engineering wants to ship.
+- Legal wants contractual customisations limited. Sales wants flexibility.
+- Legal wants every open-source license vetted. Engineering wants to use the best tool.
+
+**How to negotiate productively:**
+- Bring legal in *early*. Late-stage legal reviews kill momentum; early consultation builds shared understanding.
+- Distinguish "legal must" from "legal would prefer." Some things are non-negotiable (GDPR compliance); others are preferences (additional contract terms).
+- Build self-service legal resources. Approved open-source licenses, standard contract terms, pre-approved data-processing patterns reduce the friction.
+- Recognise the asymmetric cost of legal mistakes. A breach can cost the company $50M; a delayed product ships next quarter.
+
+### The pattern: incentives → vocabulary → positive-sum
+
+The pattern across all these conversations:
+
+1. **Understand the function's incentives.** What are they being measured on?
+2. **Learn their vocabulary.** Use their words; don't make them learn engineering's.
+3. **Find the positive-sum framing.** What can engineering do that *also* helps them?
+
+A senior engineer who can do this on demand is dramatically more effective at getting their team's needs met. Engineers who can't end up in adversarial conversations that the team perpetually loses.
+
+### The "they don't get it" framing
+
+A common engineering complaint: "Sales doesn't understand engineering." Or: "Finance doesn't understand the platform." Or: "Legal is blocking us."
+
+The reframe: each function is doing its job competently. Their incentives differ. Conflicts mean the trade-offs between functions are unresolved, not that the other function is incompetent.
+
+This reframe is hard to sustain when you're frustrated. But the engineers who do sustain it have dramatically better relationships across the company, and dramatically more influence as a result.
+
+## Walkthrough
+
+A worked negotiation. Sales wants to commit to shipping a specific federated-identity feature to land a $1.5M deal. The deal closes in 6 weeks. Engineering estimates the feature will take 12 weeks.
+
+**The wrong response (adversarial):**
+
+> "We can't ship in 6 weeks. Sales is overcommitting. We need to push back."
+
+**The collaborative response:**
+
+> "Let me understand the deal. What specific federation does the customer need? Okta, Azure AD, generic SAML? Is it for SSO only, or do they need group-syncing too?"
+>
+> [Customer needs only SAML SSO with Azure AD; no group syncing for now.]
+>
+> "OK, basic SAML SSO with Azure AD we can ship in 4 weeks. Group syncing and the broader federation we'd need 8-10 weeks for. Can the deal close with 'SAML SSO at GA, full federation roadmap Q3'?"
+
+The negotiation worked because:
+- The full ask was decomposed into components.
+- The narrow ask was achievable in the deal timeline.
+- The broader ask got a roadmap commitment.
+- Sales gets what they need to close; engineering ships honest scope.
+
+The conversation pattern: don't refuse the high-level ask. *Decompose* it. Find the part that's possible; commit to it. Set expectations for the rest.
+
+## How it fits together
+
+```mermaid
+flowchart LR
+  conflict[Surface conflict] --> incentives[Understand the function's incentives]
+  incentives --> vocab[Translate to their vocabulary]
+  vocab --> decompose[Decompose into components]
+  decompose --> positive[Find positive-sum option]
+  positive --> commit[Specific commitment]
+  commit --> relationship[Stronger working relationship]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| "They don't understand" framing | Adversarial reflex | Reframe as differing incentives, not differing competence. |
+| Refusing without alternatives | "Can't be done" | Decompose the ask; offer what's possible. |
+| Engineering-only language | Default vocabulary | Learn each function's words; use them. |
+| Late-stage involvement of legal/finance | Hoping they don't notice | Bring them in early; they'll be allies. |
+| Treating PM as customer | Vendor mindset | Engineering and product are one team; act like it. |
+
+## Exercises
+
+1. Have a 1:1 with a leader from a non-engineering function (sales, finance, marketing, legal). Ask what they're measured on. Listen for vocabulary. Identify one place where engineering work could help their metrics.
+2. For one ongoing conflict between your team and another function, list the *incentives* of the other function. Often the conflict makes sense from their angle. Then find a decomposed positive-sum option.
+3. Pick a function whose vocabulary feels foreign. Spend an hour learning their key terms. Sales and finance are usually the highest-leverage for engineers.
+
+## Recap & next
+
+- Sales, finance, product, and legal have distinct incentives and vocabularies; learning them is a high-leverage skill.
+- Most cross-functional conflicts are trade-offs, not adversarial encounters.
+- Decompose high-level asks into components; offer what's possible, commit to roadmap for the rest.
+- The "they don't understand" framing is usually wrong and damages relationships.
+
+Next, the course finale: **Continued learning roadmap** - what to read, listen to, and follow after this course.
+{% endraw %}
diff --git a/_courses/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.md b/_courses/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.md
new file mode 100644
index 0000000..169a003
--- /dev/null
+++ b/_courses/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.md
@@ -0,0 +1,198 @@
+---
+chapter_id: 5
+chapter_slug: continued-learning-roadmap
+chapter_title: "Continued learning roadmap"
+chapter_summary: "Provides a curated reading list (canonical books, newsletters, podcasts, S-1s/10-Qs, shareholder letters) and a sustainable monthly/quarterly learning cadence. Closes the course by reframing it as the foundation layer rather than an endpoint."
+---
+
+{% raw %}
+## What you'll learn
+- The canonical books to read after this course, in priority order.
+- The newsletters, podcasts, and operator playbooks worth tracking.
+- Why public S-1s and 10-Qs are some of the highest-quality business education available.
+- How to build a personal learning cadence that compounds.
+
+## Concepts
+
+This course covered the *core* of an engineer's business education in 30 chapters. It's enough to follow exec conversations, write investment cases, read board decks, and translate engineering work into business outcomes. It's not enough to be a deep expert in any one area.
+
+This chapter is the map for going deeper. The recommendations below are biased toward signal - books and resources that have stood up to time, not the latest viral business book.
+
+### The canonical books
+
+These are the works most-cited by senior operators across software and venture. Read in approximately this order:
+
+**Strategy (the foundation)**
+
+1. **[*Competitive Strategy* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Competitive-Strategy-Techniques-Industries-Competitors/dp/0743260880?tag=drin04-20) - Michael Porter (1980).** The Five Forces and competitive positioning, in the original. Heavy reading but every page is load-bearing.
+2. **[*The Innovator's Dilemma* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Innovators-Dilemma-Revolutionary-Change-Business/dp/0062060244?tag=drin04-20) - Clayton Christensen (1997).** Disruption theory in detail. Engineers often skip this because they think they get the gist - they usually don't.
+3. **[*7 Powers* <small>(Amazon affiliate link)</small>](https://www.amazon.com/7-Powers-Foundations-Business-Strategy/dp/0998116319?tag=drin04-20) - Hamilton Helmer (2016).** The modern canonical treatment of moats. Short, dense, exceptional.
+4. **[*Good Strategy / Bad Strategy* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Good-Strategy-Bad-Difference-Matters/dp/0307886239?tag=drin04-20) - Richard Rumelt (2011).** Why most "strategies" are just goals; how to write a real one.
+
+**Operating**
+
+5. **[*The Hard Thing About Hard Things* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Hard-Thing-About-Things-Building/dp/0062273205?tag=drin04-20) - Ben Horowitz (2014).** Operator wisdom from the trenches. Particularly good on hiring, firing, and leadership.
+6. **[*Working Backwards* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Working-Backwards-Insights-Stories-Secrets/dp/1250267595?tag=drin04-20) - Colin Bryar & Bill Carr (2021).** Amazon's operating playbook: PRFAQs, 6-pagers, OPI, working backwards.
+7. **[*High Output Management* <small>(Amazon affiliate link)</small>](https://www.amazon.com/High-Output-Management-Andrew-Grove/dp/0679762884?tag=drin04-20) - Andy Grove (1983).** Still the best book on management. From Intel's CEO who set the template.
+8. **[*Measure What Matters* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Measure-What-Matters-Google-Foundation/dp/0525536221?tag=drin04-20) - John Doerr (2018).** OKRs in detail; not a glamorous topic but the canonical reference.
+
+**Markets and customers**
+
+9. **[*Obviously Awesome*](https://www.aprildunford.com/obviously-awesome) - April Dunford (2019).** The positioning canvas, in 200 readable pages.
+10. **[*Crossing the Chasm* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Crossing-Chasm-3rd-Disruptive-Mainstream/dp/0062292986?tag=drin04-20) - Geoffrey Moore (1991, updated 2014).** The classic on technology-product adoption curves. Slightly dated but the framing still works.
+11. **[*The Mom Test* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Mom-Test-customers-business-everyone/dp/1492180742?tag=drin04-20) - Rob Fitzpatrick (2013).** Customer discovery without leading questions. Short and practical.
+12. **[*Competing Against Luck* <small>(Amazon affiliate link)</small>](https://www.amazon.co.uk/dp/0062435612?tag=drin04-20) - Clayton Christensen et al. (2016).** Jobs-to-be-Done in depth.
+
+**Finance for non-finance people**
+
+13. **[*Financial Intelligence* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Financial-Intelligence-Revised-Knowing-Numbers/dp/1422144119?tag=drin04-20) - Karen Berman & Joe Knight (2013).** Accounting/finance for the non-finance manager. Read this if "EBITDA" still feels like a foreign word.
+14. **[*Venture Deals* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Venture-Deals-Smarter-Lawyer-Capitalist/dp/1119594820?tag=drin04-20) - Brad Feld & Jason Mendelson (2019).** Term sheets, dilution, board dynamics. Required reading if you're at a startup.
+15. **[*The Snowball* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Snowball-Warren-Buffett-Business-Life/dp/0553384619?tag=drin04-20) - Alice Schroeder (2008).** Warren Buffett's biography. Not strictly business-school content but the best book on capital allocation thinking.
+
+**Adjacent / specialty**
+
+16. **[*Zero to One* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Zero-One-Notes-Startups-Future/dp/0804139296?tag=drin04-20) - Peter Thiel (2014).** Contrarian, opinionated, useful as a counterweight to default thinking.
+17. **[*Amp It Up* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Amp-Up-Leading-Hyper-Growth-Customers/dp/1119836115?tag=drin04-20) - Frank Slootman (2022).** Snowflake/ServiceNow CEO. Direct, no-nonsense operating philosophy.
+18. **[*The Strategy of Conflict* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Strategy-Conflict-Thomas-C-Schelling/dp/0674840313?tag=drin04-20) - Thomas Schelling (1960).** Game theory and strategic thinking. Dense; not for everyone, but every chapter rewards the work.
+
+### Newsletters and ongoing reading
+
+The half-life of business-strategy thinking is shorter than you'd think. Books cover the foundations; ongoing resources cover what's current.
+
+| Resource | Cadence | What it covers |
+|---|---|---|
+| [Stratechery](https://stratechery.com/) (Ben Thompson) | Daily | Strategy analysis of tech companies; the canonical modern source |
+| [The Diff](https://www.thediff.co/) (Byrne Hobart) | Daily/weekly | Capital allocation, valuation, finance-meets-tech |
+| [Not Boring](https://www.notboring.co/) (Packy McCormick) | Weekly | Strategic deep-dives, more retail-investor-friendly than Stratechery |
+| [SaaStr](https://www.saastr.com/) (Jason Lemkin) | Daily | SaaS metrics, GTM, B2B operating |
+| [The Generalist](https://www.thegeneralist.com/) | Weekly | Long-form company analyses |
+| [Lenny's Newsletter](https://www.lennysnewsletter.com/) (Lenny Rachitsky) | Weekly | Product management, growth, B2B/B2C operating |
+| [Reforge](https://www.reforge.com/blog) | Variable | Growth, retention, product strategy |
+| [Benedict Evans](https://www.ben-evans.com/newsletter) | Weekly | Strategy and macro tech trends |
+
+Stratechery alone is worth more than any single book on this list. Ben Thompson has been writing daily strategy analysis since 2013; the archive is a master class.
+
+### Podcasts
+
+If you commute or run, podcasts are an efficient way to absorb operator thinking.
+
+- **[Acquired](https://www.acquired.fm/)** - Deep-dive episodes (3-4 hours each) on individual company histories. Some of the highest-quality strategy content available.
+- **[Invest Like the Best](https://joincolossus.com/episodes)** - Patrick O'Shaughnessy interviews investors, operators, and thinkers. Strong for capital allocation.
+- **[Lenny's Podcast](https://www.lennysnewsletter.com/podcast)** - Product-management-focused interviews.
+- **[Founders](https://founders.simplecast.com/)** - Long biographical sketches of business leaders. Great for the historical context most operators miss.
+- **[The Twenty Minute VC](https://www.thetwentyminutevc.com/)** - Harry Stebbings; covers fundraising, growth, and the VC perspective.
+
+### Public S-1s and 10-Qs
+
+This is the highest-quality, lowest-cost business education available, and almost no engineer reads them.
+
+When a company goes public, it files an [S-1](https://www.sec.gov/cgi-bin/srqsb?text=form-type%3DS-1) (sometimes S-1/A for amendments) with the SEC. This is a 200-400 page document that lays out the business, financials, strategy, risks, and capital structure in detail. It's audited; it's signed by the executives; everything in it is legally relevant.
+
+Quarterly, public companies file [10-Qs](https://www.sec.gov/page/searchedgar-form-types-explanation); annually, [10-Ks](https://www.sec.gov/page/searchedgar-form-types-explanation). These contain the canonical financial data plus management discussion and analysis (MD&A) - exec-team commentary on results.
+
+Recommended reading list:
+
+- [Snowflake S-1 (2020)](https://www.sec.gov/Archives/edgar/data/1640147/000119312520245725/d427360ds1.htm) - usage-based pricing strategy, NRR-led growth narrative.
+- [HashiCorp S-1 (2021)](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001783029) - open-source-to-commercial business model.
+- [Stripe (not public yet, but their annual letters are public)](https://stripe.com/annual-updates/2025).
+- [Atlassian S-1 (2015)](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001650372) - self-service/PLG enterprise narrative.
+- [GitLab S-1 (2021)](https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001653482) - open-source plus enterprise tier.
+
+For any company you work for or aspire to work for, read their last 10-K. You'll learn more about how the business actually runs than any internal document will tell you.
+
+### Operator memos and shareholder letters
+
+A few are essential reading:
+
+- **[Jeff Bezos' annual shareholder letters](https://www.aboutamazon.com/news/company-news/2023-letter-to-shareholders)** (1997-2020). The collected version is its own book ([*Invent and Wander* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Invent-Wander-Collected-Writings-Introduction/dp/1647820715?tag=drin04-20)).
+- **[Buffett's letters](https://www.berkshirehathaway.com/letters/letters.html)** (1965-present). The capital-allocation master class.
+- **[Stripe's annual letters](https://stripe.com/annual-updates/2025)** (2019-present). Patrick Collison's writing is exceptional.
+
+Reading 5-10 of these gives you a feel for how operators think and communicate. The writing style alone is worth absorbing.
+
+### Building a personal learning cadence
+
+A practical structure that works:
+
+```text
+Weekly:
+  - Read Stratechery (15-30 min daily, or batched on weekends)
+  - 1 newsletter (Lenny, The Diff, Not Boring, etc)
+  - 1 podcast episode while commuting
+
+Monthly:
+  - 1 book from the canonical list (4-8 hours each)
+  - Read the 10-Q of one company in your space
+  - Reflect: what did I learn this month that changed my mind?
+
+Quarterly:
+  - Read 2-3 shareholder letters (Bezos, Buffett, Stripe)
+  - Update your "what I believe" notes
+  - Notice which beliefs from a year ago you now disagree with
+
+Annually:
+  - Read a long-form business biography (The Snowball, Steve Jobs, Bill Walsh)
+  - Re-read one book from the canonical list (Porter, Christensen, Helmer)
+  - Look at what your company committed to a year ago vs what it did
+```
+
+The compounding is striking. After two years of this cadence, you'll have read 20+ canonical books, hundreds of newsletters, dozens of podcasts, and several S-1s. The vocabulary, frameworks, and intuitions accumulate. Strategic conversations that used to feel foreign become legible.
+
+### What this course doesn't cover
+
+For honesty: this course is *introductory*. Deeper areas worth specialised study:
+
+- **Pricing science.** Specialised firms (ProfitWell, Stax, Simon-Kucher) and books ([Tom Nagle's *The Strategy and Tactics of Pricing* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Strategy-Tactics-Pricing-Implementing-Profitable/dp/0136106811?tag=drin04-20)).
+- **Org and management.** [*The Effective Executive* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Effective-Executive-Definitive-Harperbusiness-Essentials/dp/0060833459?tag=drin04-20) (Drucker), [*Multipliers* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Multipliers-Best-Leaders-Everyone-Smarter/dp/0061964395?tag=drin04-20) (Wiseman), [*An Elegant Puzzle* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186?tag=drin04-20) (Larson) for engineering specifically.
+- **Sales and GTM.** [*The Challenger Sale* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Challenger-Sale-Customer-Conversation-Control/dp/1591844355?tag=drin04-20) (Dixon & Adamson) for the sales-led motion.
+- **Finance and accounting.** Beyond Berman/Knight, [*Damodaran on Valuation* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Damodaran-Valuation-Security-Analysis-Investment/dp/0471751219?tag=drin04-20) for the deep version.
+- **Macroeconomics and monetary policy.** [The Diff](https://www.thediff.co/) covers this regularly; classic books include [*Manias, Panics, and Crashes* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Manias-Panics-Crashes-History-Financial/dp/0230365353?tag=drin04-20) (Kindleberger).
+- **Negotiation.** [*Getting to Yes* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Getting-Yes-Negotiating-Agreement-Without/dp/0143118757?tag=drin04-20) (Fisher & Ury), [*Never Split the Difference* <small>(Amazon affiliate link)</small>](https://www.amazon.com/Never-Split-Difference-Chris-Voss/dp/B0GX6BSY1X?tag=drin04-20) (Voss).
+
+### One closing thought
+
+The course's title - "The Engineer's MBA" - is intentionally provocative. A real MBA is two years of full-time work with case studies, group projects, and a network. This course is 30 chapters and 20-30 hours of your time.
+
+What it offers is the *fluency layer* - enough business vocabulary and structural understanding that the strategic conversations in your company become legible. That's worth a lot. The MBA-only crowd would tell you it's not enough; that's true if your goal is to become a CFO or a private-equity investor. If your goal is to be a more effective senior engineer, tech lead, or staff+ engineer who can hold their own in exec conversations and influence strategic decisions, this course is most of what you need.
+
+The compound benefit comes from sustaining the learning cadence over years. Start with one item on this list. See it through. Pick another. Build the habit.
+
+## How it fits together
+
+```mermaid
+flowchart TD
+  course[This course: foundation] --> canon[Canonical books: Porter, Christensen, Helmer, Grove]
+  course --> ongoing[Newsletters: Stratechery, The Diff, Lenny]
+  course --> filings[S-1s, 10-Ks, shareholder letters]
+  canon --> intuition[Built-up intuition]
+  ongoing --> intuition
+  filings --> intuition
+  intuition --> apply[Apply at work]
+  apply --> compound[Compound benefit over years]
+```
+
+## Common pitfalls
+
+| Pitfall | Why it happens | Fix |
+|---|---|---|
+| Starting too many books | Enthusiasm | Pick one; finish it; pick another. |
+| Reading too much without applying | Knowledge collecting | After each book, write one paragraph on what you'll change. |
+| Treating newsletters as news | Daily anxiety | Read them as ongoing education; let yourself fall behind sometimes. |
+| Ignoring S-1s and 10-Qs | "They look boring" | They're the highest-quality content available. Force yourself to read 3. |
+| Expecting the course's full benefit immediately | "I read it, I should know everything" | Compounding takes 2-3 years to show up in fluency. |
+
+## Exercises
+
+1. Pick three books from the canonical list. Read one in the next month. Each subsequent month, read another. After three months, look back at strategic conversations you've had - note how the vocabulary and frameworks now feel natural.
+2. Subscribe to Stratechery (free version is fine). Set a weekly time to read recent articles. After a month, notice how often the frameworks Ben Thompson uses match the ones in this course.
+3. Read the 10-K of your current employer (if public) or the S-1 of a company you admire. Note 3 things you didn't know about the business. Most employees never read these documents about their own employer.
+
+## Recap & next
+
+- This course is the *foundation* layer; deeper expertise comes from sustained learning over years.
+- Start with the canonical books in the priority order above; one per month is sustainable.
+- S-1s, 10-Qs, and shareholder letters are the highest-quality, lowest-cost business education available.
+- The compound benefit of a consistent learning cadence is dramatic; build the habit, not the burst.
+
+You've reached the end of *The Engineer's MBA*. The next step is not another course - it's applying what you've learned at work. Pick one thing from this course you weren't doing before. Try it next week. See what happens.
+{% endraw %}
diff --git a/_courses/engineers-mba/index.md b/_courses/engineers-mba/index.md
new file mode 100644
index 0000000..aa5b022
--- /dev/null
+++ b/_courses/engineers-mba/index.md
@@ -0,0 +1,81 @@
+---
+layout: course-index
+course_slug: engineers-mba
+permalink: /courses/engineers-mba/
+title: "The Engineer's MBA: Business fluency for technical leaders"
+image: engineers-mba.jpg
+description: "Hold own in exec/business reviews AND make better technical decisions with business context"
+last_updated: 2026-05-25
+depth: intermediate
+goal: "Hold own in exec/business reviews AND make better technical decisions with business context"
+time_budget: "20–30 hours"
+created_at: 2026-05-25T16:20:36Z
+modules:
+  - id: 1
+    slug: foundations-business-os
+    dir: 01-foundations-business-os
+    title: "Foundations: The Engineer's Business OS"
+    summary: "The minimum mental model - how a software business actually makes money and what its scoreboard looks like."
+    learning_objectives:
+      - "Read a P&L and explain each major line"
+      - "Distinguish revenue, cash, and profit and explain why they diverge"
+      - "Compute and interpret CAC, LTV, payback, and gross margin"
+      - "Recognize the major software business model archetypes and what each implies"
+  - id: 2
+    slug: strategy
+    dir: 02-strategy
+    title: "Strategy: Where to play, how to win"
+    summary: "The frameworks that structure strategy conversations - Porter, Christensen, moats - applied to companies engineers know."
+    learning_objectives:
+      - "Apply Porter's Five Forces to a real software company"
+      - "Distinguish types of competitive moats and how they erode"
+      - "Explain Christensen's disruption theory and recognize it in the wild"
+      - "Reason about build / buy / partner decisions strategically"
+      - "Use the three-horizons framework to evaluate a portfolio of bets"
+  - id: 3
+    slug: markets-customers-gtm
+    dir: 03-markets-customers-gtm
+    title: "Markets, Customers & Go-To-Market"
+    summary: "How software companies actually find, win, and grow customers."
+    learning_objectives:
+      - "Define an ICP and use JTBD to scope a product"
+      - "Articulate positioning that distinguishes your product"
+      - "Choose a pricing & packaging model that encodes strategy"
+      - "Reason about PLG vs. sales-led GTM trade-offs"
+      - "Read pipeline math and sales-funnel reports"
+  - id: 4
+    slug: operating-a-software-business
+    dir: 04-operating-a-software-business
+    title: "Operating a Software Business"
+    summary: "The metrics, cadence, and structures behind a running company."
+    learning_objectives:
+      - "Define and interpret the canonical SaaS metric tree"
+      - "Recognize a healthy operating cadence and what each forum is for"
+      - "Reason about org design trade-offs as a company scales"
+      - "Estimate the true cost of an engineer and a feature"
+      - "Apply real TCO and switching-cost thinking to vendor decisions"
+  - id: 5
+    slug: capital-risk-decisions
+    dir: 05-capital-risk-decisions
+    title: "Capital, Risk & Decisions Under Uncertainty"
+    summary: "How capital flows in a software company and how leaders choose between bets."
+    learning_objectives:
+      - "Reason about capital allocation the way an exec team does"
+      - "Read a cap table and understand dilution"
+      - "Frame an investment case the way a CFO will read it"
+      - "Categorize the major risks that show up in board decks"
+      - "Apply reversibility and cost-of-delay thinking to real decisions"
+  - id: 6
+    slug: technical-leaders-playbook
+    dir: 06-technical-leaders-playbook
+    title: "The Technical Leader's Playbook (Capstone)"
+    summary: "Putting it all together - how to read, write, and operate at the exec table."
+    learning_objectives:
+      - "Translate engineering work into business value language"
+      - "Write strategy and investment memos that executives will actually read"
+      - "Contribute usefully in QBRs, board prep, and all-hands forums"
+      - "Negotiate across sales, finance, product, and legal vocabularies"
+      - "Construct a continued-learning roadmap beyond this course"
+---
+
+Hold own in exec/business reviews AND make better technical decisions with business context
diff --git a/_data/quizzes/engineers-mba/01-foundations-business-os/01-why-businesses-exist.json b/_data/quizzes/engineers-mba/01-foundations-business-os/01-why-businesses-exist.json
new file mode 100644
index 0000000..e28cbb2
--- /dev/null
+++ b/_data/quizzes/engineers-mba/01-foundations-business-os/01-why-businesses-exist.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/01-foundations-business-os/01-why-businesses-exist",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A startup builds a product that customers love, gets glowing reviews, and grows rapidly. Two years later, it goes bankrupt while a worse-engineered competitor with better distribution thrives. What concept best explains this?",
+      "choices": [
+        "The competitor created more value.",
+        "Value creation and value capture are different; the startup created value but failed to capture enough of it.",
+        "Engineering quality is irrelevant to business outcomes.",
+        "The startup's transaction costs exceeded its revenue."
+      ],
+      "correct": 1,
+      "explanation": "Value creation (the gap between customer willingness-to-pay and opportunity cost of inputs) and value capture (the slice the firm keeps as price minus cost) are independent. The Linux/Red Hat/AWS pattern is the canonical example - Linux created enormous value; very few firms managed to capture much of it."
+    },
+    {
+      "id": 2,
+      "question": "Ronald Coase's transaction-cost theory of the firm says firms exist because:",
+      "choices": [
+        "Managers are more efficient than markets at every scale.",
+        "Hierarchies always outperform networks.",
+        "When the cost of coordinating work via market transactions exceeds the cost of doing it inside a managed organisation, work moves inside the firm.",
+        "Regulators require certain functions to live inside a single legal entity."
+      ],
+      "correct": 2,
+      "explanation": "Coase's 1937 insight: every market transaction has costs (search, negotiation, contracting, monitoring). When those exceed the cost of doing the same work under managerial direction, the work moves in-house. When they fall (as with SaaS or AWS), the work moves back out to the market. This silently drives every build-vs-buy decision."
+    },
+    {
+      "id": 3,
+      "question": "An engineer proposes a $300k project to reduce p99 latency on checkout from 800ms to 200ms. To frame this as a business case rather than an engineering case, the strongest move is to:",
+      "choices": [
+        "Argue that performance matters because users expect fast software.",
+        "Estimate the conversion-rate lift (e.g. 0.5% on $200M ARR) and present the resulting revenue impact alongside the cost.",
+        "Show benchmark graphs of the latency improvement.",
+        "Note that competitors have lower p99 latency."
+      ],
+      "correct": 1,
+      "explanation": "Engineering metrics (latency, throughput) only become business cases when translated into value-capture language: revenue enabled, cost reduced, churn avoided. 'Performance matters' is not a business case; '0.5% conversion lift on $200M ARR = $1M/year' is. The translation is the entire point of this course."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/01-foundations-business-os/02-reading-a-pnl.json b/_data/quizzes/engineers-mba/01-foundations-business-os/02-reading-a-pnl.json
new file mode 100644
index 0000000..59e3b60
--- /dev/null
+++ b/_data/quizzes/engineers-mba/01-foundations-business-os/02-reading-a-pnl.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/01-foundations-business-os/02-reading-a-pnl",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company reports 50% gross margin. Why is this typically a red flag for a pure-SaaS business?",
+      "choices": [
+        "50% gross margin is normal for SaaS; nothing unusual.",
+        "Typical SaaS gross margins are 70–85%; 50% suggests significant infrastructure costs, hidden services revenue, or a non-SaaS business model masquerading as SaaS.",
+        "Gross margin should always be near 100% for software companies.",
+        "It indicates the company is over-investing in R&D."
+      ],
+      "correct": 1,
+      "explanation": "Pure-software SaaS at scale is typically 70–85% gross margin because the marginal cost of serving another customer is mostly cloud infrastructure plus support. A 50% gross margin usually means: lots of professional services revenue (people-cost), significant pass-through hosting, hardware involvement, or the model isn't really SaaS. Gross margin is also a strategic constraint - it caps how much you can spend on R&D and S&M."
+    },
+    {
+      "id": 2,
+      "question": "Atlassian's FY24 P&L shows R&D at 47% of revenue and S&M at only 20%, while Salesforce shows R&D at ~15% and S&M at ~36%. Both are SaaS companies. What does this tell you?",
+      "choices": [
+        "Atlassian is more profitable than Salesforce.",
+        "Salesforce has weaker engineering than Atlassian.",
+        "The two companies have very different go-to-market strategies - Atlassian is product-led and self-service-heavy; Salesforce is sales-led and enterprise.",
+        "Atlassian's expenses are misclassified."
+      ],
+      "correct": 2,
+      "explanation": "The P&L ratios are the visible footprint of GTM strategy. A high R&D / low S&M ratio is the signature of a product-led, self-service motion: you invest in product to make sales unnecessary. A low R&D / high S&M ratio is the signature of a sales-led enterprise motion: you invest in account executives, marketing programs, and channel partners to win complex deals. Same industry, different strategies."
+    },
+    {
+      "id": 3,
+      "question": "A platform engineer building internal developer tools is reclassified from R&D to COGS by the finance team. Which is most likely to happen to the P&L?",
+      "choices": [
+        "Gross margin falls (because COGS goes up); R&D ratio improves.",
+        "Gross margin rises; R&D ratio worsens.",
+        "Operating income changes but no ratios are affected.",
+        "Revenue falls."
+      ],
+      "correct": 0,
+      "explanation": "Moving headcount cost from R&D into COGS increases COGS, which reduces gross profit and therefore gross margin. R&D-as-%-of-revenue drops, which can look like better R&D efficiency. The total operating income is unchanged (it's the same dollar of cost), but the *ratios* shift - which matters because investors and execs benchmark companies by those ratios. Finance teams sometimes argue over these classifications because they materially affect how the business is perceived."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.json b/_data/quizzes/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.json
new file mode 100644
index 0000000..8db0902
--- /dev/null
+++ b/_data/quizzes/engineers-mba/01-foundations-business-os/03-cash-profit-accruals.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/01-foundations-business-os/03-cash-profit-accruals",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company reports a $15M net loss on its P&L for the quarter, but its cash flow statement shows $22M of positive cash from operations. Which combination most plausibly explains the gap?",
+      "choices": [
+        "The P&L is wrong.",
+        "Stock-based compensation (a non-cash expense), growth in deferred revenue (customers prepaying for future service), and a small increase in receivables - net positive cash despite accrual loss.",
+        "Revenue recognition fraud.",
+        "The company issued bonds during the quarter."
+      ],
+      "correct": 1,
+      "explanation": "The cash flow statement reconciles accrual-basis P&L to actual cash movement. The biggest reconciling items for SaaS are SBC (non-cash compensation), deferred revenue (annual prepayments that create cash today for future-period revenue), and changes in receivables. Together these typically swing a high-growth SaaS company from net loss on accrual to positive cash from operations."
+    },
+    {
+      "id": 2,
+      "question": "Why does a SaaS company billing annual contracts upfront often have a *negative* cash conversion cycle?",
+      "choices": [
+        "Because software has no inventory and customers pay before service is delivered, while the company pays its own suppliers on standard 30–60 day terms.",
+        "Because revenue is recognised faster than cash arrives.",
+        "Because SBC reduces operating expenses.",
+        "Because deferred revenue is a current asset."
+      ],
+      "correct": 0,
+      "explanation": "Cash conversion cycle = DSO + DIO − DPO. Software has zero inventory (DIO=0). With annual-billing-upfront, DSO is effectively negative - customers pay before the company delivers. The company pays its bills on standard terms (DPO of 30-60 days). The result: the company is financed by its customers, one of the structural reasons SaaS is a beloved business model."
+    },
+    {
+      "id": 3,
+      "question": "An engineer is asked to evaluate the financial health of a private company before joining. Which statement should they read first to understand whether the business is generating its own fuel?",
+      "choices": [
+        "The income statement (P&L), because it shows profitability.",
+        "The balance sheet, because it shows assets and liabilities.",
+        "The cash flow statement - specifically the 'cash from operating activities' line - because it reveals whether the core business is generating cash regardless of accrual-based profitability.",
+        "The audit report, because it confirms the numbers are accurate."
+      ],
+      "correct": 2,
+      "explanation": "The 'cash from operations' line on the cash flow statement is the single most diagnostic figure for whether a business is sustainable. It strips out non-cash items (SBC, depreciation) and reveals whether the company is funding itself or burning capital. Many growth-stage SaaS companies have ugly P&Ls but positive operating cash flow - that's a structurally healthier business than the reverse."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/01-foundations-business-os/04-unit-economics.json b/_data/quizzes/engineers-mba/01-foundations-business-os/04-unit-economics.json
new file mode 100644
index 0000000..261eb1f
--- /dev/null
+++ b/_data/quizzes/engineers-mba/01-foundations-business-os/04-unit-economics.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/01-foundations-business-os/04-unit-economics",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company reports: ACV $24k, gross margin 75%, blended CAC $25k, annual logo churn 12%. What is the CAC payback period?",
+      "choices": [
+        "12 months",
+        "16.7 months",
+        "20 months",
+        "25 months"
+      ],
+      "correct": 1,
+      "explanation": "CAC payback = CAC / monthly gross profit per customer. Annual gross profit = $24k × 75% = $18k → monthly $1,500. Payback = $25,000 / $1,500 = 16.7 months. This falls in the healthy growth-stage range (12–18 months). 24 months is the rough industry bar; anything longer requires unusually cheap capital."
+    },
+    {
+      "id": 2,
+      "question": "Which is typically the strongest lever on LTV for a B2B SaaS company?",
+      "choices": [
+        "Reducing infrastructure costs to improve gross margin by a few points.",
+        "Reducing churn by a few percentage points.",
+        "Adding more marketing spend.",
+        "Hiring more sales reps."
+      ],
+      "correct": 1,
+      "explanation": "Because LTV = (ARPU × margin) / churn rate, churn enters the denominator. A drop from 12% to 8% extends average customer lifetime from 8.3 years to 12.5 years - a 50% increase in LTV. A few points of gross margin (75% → 80%) only adds ~7%. This is why reliability, performance, and integration depth investments are usually the highest-leverage engineering work in unit-economic terms."
+    },
+    {
+      "id": 3,
+      "question": "A founder quotes 'Our LTV:CAC is 8x' as evidence the business is great. What's the most important follow-up question?",
+      "choices": [
+        "What's the gross margin assumption - is this revenue LTV or gross-profit LTV?",
+        "Why isn't it 10x?",
+        "What's the company name?",
+        "Are competitors lower?"
+      ],
+      "correct": 0,
+      "explanation": "The most common LTV manipulation is computing LTV in *revenue* terms rather than *gross profit* terms - this inflates LTV by the inverse of gross margin (a 75%-margin company's revenue LTV is 1.33× its gross-profit LTV). The second-most-common is using a CAC variant (blended vs paid vs fully-loaded) that flatters the ratio. Always pin down both definitions before believing the number."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/01-foundations-business-os/05-business-model-archetypes.json b/_data/quizzes/engineers-mba/01-foundations-business-os/05-business-model-archetypes.json
new file mode 100644
index 0000000..4b0552c
--- /dev/null
+++ b/_data/quizzes/engineers-mba/01-foundations-business-os/05-business-model-archetypes.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/01-foundations-business-os/05-business-model-archetypes",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company reports 63% gross margin, 25% S&M as a percentage of revenue, and 125% net revenue retention. Which business model archetype is most consistent with this profile?",
+      "choices": [
+        "Pure subscription SaaS with an enterprise sales motion.",
+        "Usage-based / consumption (e.g. Snowflake-flavoured).",
+        "Marketplace with a take-rate model.",
+        "Transactional payments (e.g. Stripe-flavoured)."
+      ],
+      "correct": 1,
+      "explanation": "63% gross margin is below pure-SaaS range (70–85%) but above hardware/transactional (suggests usage-based COGS). 25% S&M is unusually low for SaaS because much expansion is automatic - customers' usage grows without negotiation. 125% NRR is the signature of usage-based expansion. These ratios collectively point to a consumption model."
+    },
+    {
+      "id": 2,
+      "question": "Why is the LTV concept misleading when applied to a usage-based / consumption business with NRR consistently above 100%?",
+      "choices": [
+        "Because consumption businesses don't have customers.",
+        "Because the standard LTV formula assumes steady-state ARPU; if ARPU grows over time (NRR > 100%), the formula either explodes toward infinity or understates the value depending on the assumption used.",
+        "Because LTV is only meaningful for hardware companies.",
+        "Because consumption businesses don't recognise revenue."
+      ],
+      "correct": 1,
+      "explanation": "LTV = (ARPU × margin) / churn assumes a customer pays the same ARPU forever. In a usage-based business with strong expansion, ARPU grows year-over-year. Applying the standard formula naively either treats this as 'negative churn' and explodes the LTV to infinity, or ignores expansion and severely undercounts it. Usage-based companies typically report 'net dollar retention' as the primary efficiency metric instead of LTV."
+    },
+    {
+      "id": 3,
+      "question": "A subscription SaaS company is considering moving to a usage-based pricing model. Which is the most likely *engineering-side* consequence the team should prepare for?",
+      "choices": [
+        "Reduced need for engineering staff overall.",
+        "Faster feature development.",
+        "Substantial investment in metering infrastructure (accurate, real-time usage capture and rating), plus increased focus on cost-per-unit since infrastructure cost now directly drives margin.",
+        "Migration to a different cloud provider."
+      ],
+      "correct": 2,
+      "explanation": "Usage-based billing requires precise, real-time metering - every API call, byte stored, or compute-second has to be captured, deduplicated, rated, and billed correctly. This is a non-trivial systems investment. Additionally, because COGS now scales with usage rather than being amortised across seats, infrastructure cost per unit becomes a first-order engineering concern. The model transition is multi-year for most companies."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/02-strategy/01-porters-five-forces.json b/_data/quizzes/engineers-mba/02-strategy/01-porters-five-forces.json
new file mode 100644
index 0000000..04abdb1
--- /dev/null
+++ b/_data/quizzes/engineers-mba/02-strategy/01-porters-five-forces.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/02-strategy/01-porters-five-forces",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineer is doing a Five Forces analysis of their employer, a vertical SaaS company selling exclusively to dental practices. They draw the industry boundary as 'B2B SaaS.' Why is this likely a critical error?",
+      "choices": [
+        "B2B SaaS is fine as a boundary; the analysis will work.",
+        "The industry boundary should be the set of substitutes the *customer* treats as interchangeable - for a dental SaaS, that's other dental practice management tools, not all B2B SaaS. The wrong boundary will produce a useless analysis.",
+        "B2B SaaS is too narrow.",
+        "Porter's framework doesn't apply to vertical SaaS."
+      ],
+      "correct": 1,
+      "explanation": "The most common Porter mistake is drawing the industry boundary too broadly. The boundary is the set of substitutes the customer considers - a dental practice does not see Salesforce as a substitute for Dentrix. Drawing the boundary as 'B2B SaaS' will produce nonsense forces because the customer's actual decision set is much narrower."
+    },
+    {
+      "id": 2,
+      "question": "Datadog operates in a market with high rivalry, low capital barriers to entry, and credible open-source substitutes (Prometheus, Grafana). What strategic response do these forces tend to push companies toward?",
+      "choices": [
+        "Raise prices to maximise short-term capture.",
+        "Build product *breadth* so customers consolidate on one platform rather than mixing vendors - this raises switching costs and reduces the substitution threat.",
+        "Exit the market.",
+        "Acquire competitors regardless of cost."
+      ],
+      "correct": 1,
+      "explanation": "When entry is easy and substitutes are credible, single-product differentiation gets eroded. Datadog's response has been to expand into APM, infrastructure monitoring, logs, security, and many adjacencies - once a customer uses 4+ Datadog products, the switching cost to a mix of OSS or competitors is enormous. Product breadth is a direct strategic response to the Porter profile."
+    },
+    {
+      "id": 3,
+      "question": "Cloudflare's industry structure has lower rivalry and higher entry barriers than Datadog's. Which of these structural factors most explains the difference?",
+      "choices": [
+        "Cloudflare has better marketing.",
+        "Cloudflare operates its own global edge network - a capital-intensive asset that few competitors can replicate. This raises the barrier to entry and limits the field of credible rivals.",
+        "Cloudflare's product is simpler.",
+        "Cloudflare's customers are larger."
+      ],
+      "correct": 1,
+      "explanation": "Cloudflare's global edge network requires significant capital to build and operate (data centres in 300+ cities, peering relationships, custom hardware). This capital intensity is a structural barrier - it limits how many companies can credibly enter the market. Datadog faces the opposite: an observability startup can be built with $5M and an open-source baseline. The capital requirements are part of the structural profitability difference."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/02-strategy/02-moats-and-advantage.json b/_data/quizzes/engineers-mba/02-strategy/02-moats-and-advantage.json
new file mode 100644
index 0000000..11ed7d9
--- /dev/null
+++ b/_data/quizzes/engineers-mba/02-strategy/02-moats-and-advantage.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/02-strategy/02-moats-and-advantage",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An exec claims 'our world-class engineering culture is our moat.' Why is this usually wrong as a strategic claim?",
+      "choices": [
+        "Because engineering culture is impossible to build.",
+        "Because operational excellence is rarely a structural moat - competitors can hire your engineers, copy your patterns, and adopt your tools. A real moat is a structural reason it's *hard* to compete with you regardless of execution speed.",
+        "Because culture is unmeasurable.",
+        "Because culture doesn't show up in financials."
+      ],
+      "correct": 1,
+      "explanation": "Operational excellence is a force multiplier on whatever moats you have, but it isn't a moat itself. The diagnostic question is: if a well-funded competitor poached your top 50 engineers tomorrow, would they catch up to you? If yes, the 'moat' was execution, not structure. Real moats - network effects, switching costs, scale, data, brand - persist even under heavy attack."
+    },
+    {
+      "id": 2,
+      "question": "Which combination of financial signals is most consistent with a company having genuine switching-cost and scale moats?",
+      "choices": [
+        "Falling gross margins, rising churn, S&M growing faster than revenue.",
+        "Stable or rising gross margins year-over-year, NRR >110%, logo churn under 7%, operating margin expanding as the company scales.",
+        "Rising revenue but no operating margin improvement.",
+        "Falling S&M ratio combined with falling revenue."
+      ],
+      "correct": 1,
+      "explanation": "Real moats leave fingerprints in financials. Stable/rising gross margins indicate pricing power. NRR >110% and low churn indicate switching costs or value-from-use. Operating margin expansion at scale indicates scale economies. A company claiming moats but showing none of these signals is usually marketing - the financials are the audit."
+    },
+    {
+      "id": 3,
+      "question": "Slack's collaboration product benefits from network effects. Which condition would most weaken this moat?",
+      "choices": [
+        "Slack adding more features.",
+        "Multi-homing: organisations and individuals routinely using Slack alongside Teams, Discord, or other channels simultaneously, so the cost of leaving any single network is low.",
+        "Slack increasing prices.",
+        "Slack improving reliability."
+      ],
+      "correct": 1,
+      "explanation": "Network effects are strongest when users *can't* multi-home. If every team you collaborate with is on the same platform, leaving means coordinating a mass move. If teams routinely use Slack for one project, Teams for another, and Discord for a third, the network advantage of any single platform is diluted. Multi-homing is the structural threat to network-effect moats in software."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/02-strategy/03-disruption-theory.json b/_data/quizzes/engineers-mba/02-strategy/03-disruption-theory.json
new file mode 100644
index 0000000..f79f374
--- /dev/null
+++ b/_data/quizzes/engineers-mba/02-strategy/03-disruption-theory.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/02-strategy/03-disruption-theory",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An incumbent enterprise software vendor dismisses a new low-cost entrant whose product is missing 60% of the incumbent's features. The incumbent's largest customers don't want the entrant's product. Why is this dismissal often a critical strategic error per Christensen's theory?",
+      "choices": [
+        "Because new entrants always win.",
+        "Because disruptors usually start out worse than the incumbent on the dimensions existing customers care about - that's the *signature* of disruption, not evidence the threat is small. The relevant question is whether the entrant's rate of improvement exceeds the rate at which the incumbent's customers' needs grow.",
+        "Because feature counts don't matter.",
+        "Because customer dismissal is itself a positive signal."
+      ],
+      "correct": 1,
+      "explanation": "The whole point of disruption theory is that disruptors *start* inferior. The rational incumbent response - ignore the worse, lower-margin product - is exactly what makes them vulnerable. The diagnostic isn't feature count today; it's the rate of improvement relative to the rate at which existing customers' needs grow. If the curves cross, the incumbent's customers start defecting and the cost structure makes a response infeasible."
+    },
+    {
+      "id": 2,
+      "question": "Was the iPhone a 'disruptive innovation' in Christensen's strict sense?",
+      "choices": [
+        "Yes - it disrupted Nokia and BlackBerry.",
+        "No - it was a high-end *sustaining* innovation in a new category. It entered at the top of the market with higher prices, better margins, and a feature-rich product, which is the opposite of low-end disruption.",
+        "Yes - any product that destroys incumbents is disruptive.",
+        "It doesn't apply because Apple is American."
+      ],
+      "correct": 1,
+      "explanation": "The iPhone is the classic example of how the term 'disruptive' is overused. It entered at the high end with premium pricing - a sustaining innovation in the smartphone category, not a low-end or new-market disruptor in Christensen's sense. The fact that it destroyed incumbents doesn't make it a disruption per the theory's definition. This distinction matters because the strategic responses to sustaining vs disruptive threats are completely different."
+    },
+    {
+      "id": 3,
+      "question": "An incumbent decides to respond to a disruptor by launching a 'disruptor-class' product as a separate division within the existing company. What does Christensen's theory predict?",
+      "choices": [
+        "Success - the company has access to capital and brand.",
+        "Failure most of the time - the corporate parent's resource allocation, customer feedback loops, and cost structure tend to leak into the new division and pull it back toward sustaining innovation in the parent's market.",
+        "Indifference - internal vs spin-out doesn't matter.",
+        "Success only if the new division is in a different country."
+      ],
+      "correct": 1,
+      "explanation": "Christensen documented many incumbents who tried this. The corporate parent has many gravitational pulls: shared sales teams (who push the incumbent's high-margin products), shared engineering processes (optimised for the existing market), shared resource-allocation processes (which kill low-margin bets). The result is that the internal disruptor often gets pulled upmarket and loses the disruptor's economics. Successful responses usually require genuine independence - sometimes physical and legal separation."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/02-strategy/04-build-buy-partner.json b/_data/quizzes/engineers-mba/02-strategy/04-build-buy-partner.json
new file mode 100644
index 0000000..922b95d
--- /dev/null
+++ b/_data/quizzes/engineers-mba/02-strategy/04-build-buy-partner.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/02-strategy/04-build-buy-partner",
+  "questions": [
+    {
+      "id": 1,
+      "question": "Stripe acquired Paystack and preserved Paystack's brand, leadership, and product autonomy. Atlassian acquired Trello and similarly kept it as a separate product. What does this pattern suggest about M&A success?",
+      "choices": [
+        "It's easier to leave acquired products alone than to integrate them.",
+        "When the value of an acquisition depends on culture, brand, or a distinct product DNA, preserving autonomy for an extended period is often the difference between value creation and destruction. Forced integration is the most common failure mode.",
+        "Acquired companies should always rebrand immediately.",
+        "Acquisitions only succeed in payments or project management."
+      ],
+      "correct": 1,
+      "explanation": "The acquired company's value usually depends on factors that integration can break: founder presence, distinct culture, beloved brand, autonomous roadmap. McKinsey-flavoured post-mortems on hundreds of deals consistently find that successful acquisitions preserve autonomy longer than feels comfortable. The Yahoo-era pattern of buy-and-fold is the classic value destroyer."
+    },
+    {
+      "id": 2,
+      "question": "An engineering team frames a strategic capability gap as 'we could build this in 12 months for $5M, vs. a partner option at $300k/year.' Why is the engineering team's framing likely incomplete?",
+      "choices": [
+        "The build estimate is too optimistic.",
+        "It omits time-to-market opportunity cost - 12 months of customers going elsewhere, of being absent from RFPs, of competitive positioning lost - which often dwarfs the dollar-cost of building or partnering.",
+        "The partner cost is unrealistic.",
+        "Engineering teams should not estimate."
+      ],
+      "correct": 1,
+      "explanation": "Engineers reflexively compute build cost as engineering salaries × months. The strategic question includes: what does the customer base look like 12 months from now if we ship vs don't ship? What deals close or don't close because we lack this capability? What does the competitive landscape look like? Once those factors are included, the partner option that gets you to market in 2 months is often dramatically cheaper than the build option even when annualised licensing exceeds the salary equivalent."
+    },
+    {
+      "id": 3,
+      "question": "Which acquisition rationale most cleanly applies to Microsoft's purchase of GitHub in 2018?",
+      "choices": [
+        "Defensive - to prevent GitHub from becoming a competitor.",
+        "Capability acquisition - buying the developer community, developer tools brand, and product surface area that Microsoft could not reasonably build organically in the relevant timeframe.",
+        "Time-to-market - GitHub had a feature Microsoft urgently needed in months.",
+        "Talent acqui-hire - Microsoft wanted GitHub's engineers."
+      ],
+      "correct": 1,
+      "explanation": "Microsoft could not have built GitHub's developer community or brand position organically - these assets are *capabilities* that took GitHub a decade to accumulate and were not for sale individually. The acquisition was about getting the capability (community + brand + product) intact. Time-to-market and defensive considerations contributed, but the dominant rationale was capability acquisition. The preservation of GitHub's autonomy under Nat Friedman and later leadership reflects the importance of keeping that capability intact post-deal."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/02-strategy/05-strategy-as-portfolio.json b/_data/quizzes/engineers-mba/02-strategy/05-strategy-as-portfolio.json
new file mode 100644
index 0000000..9a254fd
--- /dev/null
+++ b/_data/quizzes/engineers-mba/02-strategy/05-strategy-as-portfolio.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/02-strategy/05-strategy-as-portfolio",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A CFO insists every R&D project show a 24-month payback period. Why is this problematic when applied across the three horizons?",
+      "choices": [
+        "24 months is too short for any software work.",
+        "H1 (core) work can clear a 24-month payback bar, but H3 (transformative) bets - by definition uncertain, low-revenue, and long-horizon - cannot. Applying H1 ROI discipline to H3 systematically kills the long-term bets the company needs to seed its future H1.",
+        "Payback period is irrelevant in software.",
+        "CFOs should never set R&D criteria."
+      ],
+      "correct": 1,
+      "explanation": "Different horizons require different success metrics. H1 work is appropriately evaluated on revenue, margin, and payback. H3 should be evaluated on learning, validated assumptions, and risk-reduction. Forcing H3 to clear H1 ROI hurdles is the most common failure mode in large companies - it's why they consistently get out-innovated by startups whose investors apply venture-style metrics."
+    },
+    {
+      "id": 2,
+      "question": "An engineering team's roadmap consists of: reliability improvements, technical debt paydown, internal developer platform work, and new features for existing customers. What horizon mix is this?",
+      "choices": [
+        "Mostly H2 - the internal platform is innovative.",
+        "Almost entirely H1 - every item defends or extends the existing core business; none of it builds new markets, new customer segments, or genuinely new businesses.",
+        "Balanced across H1/H2/H3.",
+        "H3 - innovation in tooling is transformative."
+      ],
+      "correct": 1,
+      "explanation": "Engineering teams routinely classify internal platform work or rearchitecture as 'innovation' (H2/H3). It isn't - it's defending the core (H1). H1 work is essential and shouldn't be apologised for, but conflating it with H2/H3 hides the fact that the company has nothing in genuine new-business creation. Most engineering roadmaps are 95% H1, and the diagnostic worth running is whether *somewhere else* in the company someone is doing H2/H3 work."
+    },
+    {
+      "id": 3,
+      "question": "A company's earnings calls heavily emphasise H2/H3 initiatives, but its R&D spend, capex, and exec attention are 95% H1. How should you interpret this gap?",
+      "choices": [
+        "The company is being modest about its innovation work.",
+        "The H2/H3 narrative is mostly marketing - without resource allocation matching the rhetoric, the bets aren't real. This is a common warning sign that the company has rhetoric about innovation but is structurally trapped in core optimisation.",
+        "The company's accounting is unusual.",
+        "Earnings calls are unreliable signals."
+      ],
+      "correct": 1,
+      "explanation": "Resource flow is the audit on strategy rhetoric. A company can talk about transformation in every earnings call but if 95% of capital, engineering capacity, and executive time goes to the current core, the new bets aren't actually being made. This gap is one of the most useful diagnostic patterns in reading a company from the outside - and one of the most common warning signs for the inside."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.json b/_data/quizzes/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.json
new file mode 100644
index 0000000..e32df40
--- /dev/null
+++ b/_data/quizzes/engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/03-markets-customers-gtm/01-icp-and-jtbd",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A company's stated ICP is 'growing B2B SaaS companies.' What's the most important diagnostic question to ask?",
+      "choices": [
+        "How much marketing spend is allocated to this ICP?",
+        "Is this an *operational* ICP - narrow enough that the CEO and a junior salesperson can independently describe the same customer in a sentence, and the segment can be turned into a filterable list - or is it an aspirational slogan?",
+        "Are the customers in this ICP profitable?",
+        "What's the LTV?"
+      ],
+      "correct": 1,
+      "explanation": "An ICP needs three properties to be operational: (1) firmographic + technographic + behavioural criteria precise enough to filter a list, (2) diagnostic (where you actually win) rather than aspirational (where you wish you'd win), and (3) sharable - internally consistent so all functions optimise for the same customer. 'Growing B2B SaaS' fails all three; it's a slogan, not an ICP."
+    },
+    {
+      "id": 2,
+      "question": "What's the most important distinction between an ICP and a persona?",
+      "choices": [
+        "ICPs are larger than personas.",
+        "ICPs describe the *company* you sell to (firmographic, technographic, behavioural); personas describe *individual people* in the buying decision (economic buyer, technical buyer, champion, end user). A product can have one ICP and multiple personas simultaneously.",
+        "Personas are for marketing; ICPs are for sales.",
+        "ICPs are deprecated; personas are modern."
+      ],
+      "correct": 1,
+      "explanation": "Conflating these is a common, costly mistake. A B2B SaaS company has *one* ICP and *several* personas - a VP/CIO (economic), a director of platform (technical), a senior engineer (champion/user). Marketing targets the technical buyer and champion; sales handles the economic buyer; product designs for the end user. The ICP keeps everyone aligned on which *company* we're solving for; personas describe how to message each role."
+    },
+    {
+      "id": 3,
+      "question": "Why does the Jobs-to-be-Done framework tend to expose competitive threats that personas miss?",
+      "choices": [
+        "JTBD has more data.",
+        "Personas describe *demographics and roles* shared with competitors who serve the same persona. JTBD describes the *outcome* the customer is trying to achieve - and the competitive set expands to *every* product that achieves that outcome, including products in adjacent categories.",
+        "JTBD ignores buyer behaviour.",
+        "Personas only apply to consumer markets."
+      ],
+      "correct": 1,
+      "explanation": "A CRM and a workflow tool might serve identical personas (sales manager at mid-market SaaS) but be in different categories. If both perform the job 'free up time from manual pipeline data entry,' they're competing - even though personas wouldn't reveal it. JTBD's competitive frame is broader and more accurate because customers compare any candidate that performs the job, regardless of category. This is the same insight that drives Christensen's disruption framing."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.json b/_data/quizzes/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.json
new file mode 100644
index 0000000..2ab773e
--- /dev/null
+++ b/_data/quizzes/engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/03-markets-customers-gtm/02-positioning-and-narrative",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A product team writes a positioning statement that opens 'We are the leading X platform.' What's the most likely flaw using Dunford's positioning canvas?",
+      "choices": [
+        "The word 'leading' is illegal.",
+        "It skips the foundational step of identifying competitive *alternatives* - what the customer does today if they don't buy this product. Without that, the unique attributes, value, best-fit customer, and category claims are all unanchored.",
+        "Platform is too narrow a category.",
+        "X should be replaced by a brand name."
+      ],
+      "correct": 1,
+      "explanation": "Dunford's framework starts with competitive alternatives precisely because every other element depends on them. Without knowing what the customer currently does (spreadsheets, in-house build, do-nothing, named competitor), you can't define what's *unique* about your offering, what *value* it creates, who finds it valuable, or which category frame fits. 'The leading X platform' is the kind of statement that's true of every B2B SaaS company and informative of none."
+    },
+    {
+      "id": 2,
+      "question": "Engineering ships a public API with OAuth and webhooks. Marketing positions the product as 'enterprise-grade with strict access controls.' What does this inconsistency typically produce?",
+      "choices": [
+        "Customers ignore the API and the positioning works fine.",
+        "Confusion in the market and a positioning that reflects the engineering reality more than the marketing claim - customers experience the product, not the homepage, and 'platform with permissive integration' will be how the product gets known.",
+        "Higher conversion rates.",
+        "No effect, since marketing and engineering are independent."
+      ],
+      "correct": 1,
+      "explanation": "Engineering decisions silently encode positioning. A public API + OAuth + webhooks positions the product as a *platform* that participates in ecosystems. The marketing claim of strict access controls reads as inconsistent - and customers experience the product. When there's conflict between engineering reality and marketing rhetoric, the reality almost always wins because that's what customers actually use. Alignment between the two is one of the more under-managed product disciplines."
+    },
+    {
+      "id": 3,
+      "question": "A startup considers creating a new market category vs. reframing an existing one (e.g. Slack's 'channels for work' reframe vs. trying to coin a new category from scratch). Which is generally lower-risk and why?",
+      "choices": [
+        "Creating a new category - first-mover advantage.",
+        "Reframing an existing category - the customer already understands the base category and the reframe gives the product a defensible niche within it, without requiring market-education investment to teach customers a new word for a thing they didn't know existed.",
+        "They're equivalent.",
+        "Whichever has more keywords."
+      ],
+      "correct": 1,
+      "explanation": "Category creation requires market-education budget, sales-motion patience, and significant air-cover. Most attempts fail because customers won't pay for an 'unknown thing from a new vendor.' Reframing - taking an existing, understood category and giving it new boundaries (Slack: 'channels for work,' Datadog: 'observability' from 'monitoring') - leverages existing customer understanding while still creating differentiation. Reframing is usually the right play unless the existing categories genuinely don't describe what you do."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.json b/_data/quizzes/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.json
new file mode 100644
index 0000000..8670c41
--- /dev/null
+++ b/_data/quizzes/engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/03-markets-customers-gtm/03-pricing-and-packaging",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company decides to add usage-based pricing alongside its existing seat-based model. What engineering investment is most directly required?",
+      "choices": [
+        "More marketing pages.",
+        "Real-time, accurate metering of usage events (idempotent, deduplicated, attributable to the right account); a rating engine that converts usage to charges per the price sheet; plus billing aggregation and cost-control features (caps, alerts) to prevent customer sticker-shock.",
+        "A new front-end framework.",
+        "Migration of all customers to a new CRM."
+      ],
+      "correct": 1,
+      "explanation": "Usage-based pricing is a deep engineering commitment. You need every billable event captured exactly once, attributed to the right account, rated per pricing rules, aggregated for billing, with cost-control surfaces so customers don't get $50k surprise bills. Companies routinely underestimate this work by 2-3x. The pricing page can be updated in an afternoon; the metering and rating infrastructure is a multi-quarter project."
+    },
+    {
+      "id": 2,
+      "question": "Why does B2B SaaS pricing typically use three tiers with feature differentiation rather than a single tier with simple seat-based pricing?",
+      "choices": [
+        "Three is a marketing-conventional number.",
+        "Price discrimination - different customer segments have different willingness-to-pay for the same underlying capability. By bundling features that enterprise customers genuinely require (SSO, audit logs, advanced RBAC) into a higher tier, the company charges more to larger customers without changing the list price for the same feature.",
+        "Engineering can only build three tiers.",
+        "Customers demand three tiers."
+      ],
+      "correct": 1,
+      "explanation": "Tiering implements price discrimination. Enterprise customers need SSO/SAML, audit logs, and advanced security; SMBs don't. By packaging those features into a top tier, the company captures more revenue from customers with higher WTP (enterprise) while not pricing out customers with lower WTP (SMB). Customer perception of fairness requires *different bundles*, not the same bundle at different prices. Three tiers is canonical because it gives a 'just right' middle option (Goldilocks) that most paying customers select."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team is asked to ship a free tier 'with limits' in two weeks. What's the most important non-obvious risk?",
+      "choices": [
+        "Free tier customers might be unhappy.",
+        "Without race-free, enforceable, code-level limit enforcement (not just a UI banner), the free tier rapidly becomes the de facto product as customers find ways to use it for full workloads - destroying paid conversion and creating a long-tail of free abusers.",
+        "Marketing won't have time to update the page.",
+        "Customers will demand annual contracts."
+      ],
+      "correct": 1,
+      "explanation": "A free tier is an architectural commitment, not a marketing choice. Limits must be enforced at the code level - atomic counters, server-side validation, race-resistant rate limiting. A UI-only enforcement gets bypassed via API in days. The downstream effect is cumulative: free becomes the de facto product, paid conversion drops, and S&M ROI collapses. Companies routinely underestimate the engineering work to make a free tier *actually free* rather than *promised free*."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/03-markets-customers-gtm/04-gtm-motions.json b/_data/quizzes/engineers-mba/03-markets-customers-gtm/04-gtm-motions.json
new file mode 100644
index 0000000..50da8a5
--- /dev/null
+++ b/_data/quizzes/engineers-mba/03-markets-customers-gtm/04-gtm-motions.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/03-markets-customers-gtm/04-gtm-motions",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A PLG company has saturated its self-serve segment ($5k ACV customers) and wants to move upmarket to enterprise ($250k+ deals). Which is most likely to be the hardest part of the transition?",
+      "choices": [
+        "Updating the website.",
+        "Building the new engineering surface required by enterprise customers - SSO/SAML, audit logs, advanced RBAC, custom deployment options, compliance certifications (SOC 2, HIPAA), plus an entirely new account-management apparatus - and hiring/operating a sales-led motion that the company's culture isn't built for.",
+        "Hiring a CMO.",
+        "Translating the documentation."
+      ],
+      "correct": 1,
+      "explanation": "The PLG-to-enterprise transition affects every function. Engineering must build the enterprise feature surface (SSO, audit, RBAC, security certifications) that PLG customers don't need. Sales must hire account executives and sales engineers. Customer success transitions from help-doc-driven to white-glove. Pricing adds custom contracts. Marketing shifts to account-based. The cultural change is profound - companies that 'used to be PLG' frequently lose their developer-friendly DNA in the process. Atlassian and Figma are notable counterexamples that did this slowly and carefully."
+    },
+    {
+      "id": 2,
+      "question": "Which combination of homepage signals most strongly suggests a sales-led GTM motion?",
+      "choices": [
+        "A big 'Sign up free' button and visible pricing.",
+        "A big 'Contact sales' button, hidden pricing ('available on request'), Fortune 500 customer logos prominently featured, and analyst-report citations (Gartner, Forrester).",
+        "A free tier with credit card capture.",
+        "A pricing page with three transparent tiers."
+      ],
+      "correct": 1,
+      "explanation": "The sales-led signature is hidden pricing (because each deal is custom), 'Contact sales' as the primary CTA (because the buying motion routes through sales), enterprise customer logos (social proof targeting the same buyer), and analyst-report citations (which influence procurement and IT committees). These are visible within seconds of landing on the page - GTM motion is one of the easiest things to identify from the outside."
+    },
+    {
+      "id": 3,
+      "question": "A SaaS startup wants to operate both a free PLG motion and a sales-led enterprise motion simultaneously ('hybrid'). What's the most common reason this strategy fails?",
+      "choices": [
+        "Customers are confused by the dual model.",
+        "The company under-resources both motions - investing partway in PLG engineering (onboarding, telemetry, in-product expansion) and partway in enterprise engineering (SSO, audit, custom deployment) - and produces a worst-of-both result, with neither motion succeeding fully.",
+        "Hybrid motions are illegal under SEC regulations.",
+        "Pricing pages can't display both."
+      ],
+      "correct": 1,
+      "explanation": "Hybrid is harder than either pure motion because it requires investment in both sets of engineering capabilities, both sales motions, both marketing approaches, and both customer success models. Companies trying to run hybrid with one engineering org sized for a single motion ship a half-baked free tier and a half-baked enterprise tier. The hybrid winners (Datadog, HashiCorp, Atlassian) invested fully in both - and it took years."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.json b/_data/quizzes/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.json
new file mode 100644
index 0000000..3fabc02
--- /dev/null
+++ b/_data/quizzes/engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/03-markets-customers-gtm/05-funnel-and-pipeline-math",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A company has 100 open opportunities, $50k average ACV, 25% win rate, and 90-day sales cycles. What's the sales velocity?",
+      "choices": [
+        "$1.4M per day",
+        "~$14k per day, or roughly $1.25-1.3M per quarter from current opportunities",
+        "$250k per quarter",
+        "$5M per year"
+      ],
+      "correct": 1,
+      "explanation": "Sales Velocity = (Opportunities × ACV × Win Rate) / Sales Cycle = (100 × $50k × 0.25) / 90 = ~$14k per day. Over a 90-day quarter, that's ~$1.25-1.3M. The formula's value is in exposing the four levers: increasing any single one of (opportunity count, ACV, win rate) by 25%, or decreasing sales cycle by 25%, has the same impact on velocity. Engineers usually focus on win-rate via features; cycle-length is often the easier lever."
+    },
+    {
+      "id": 2,
+      "question": "A B2B SaaS company has pipeline coverage of 2.5x quota at quarter start. What's the practical implication?",
+      "choices": [
+        "Coverage is healthy; nothing to worry about.",
+        "Coverage is below the standard 3x minimum. Given typical conversion rates of ~30% from opportunity to closed-won, the company likely lacks enough pipeline to hit quota. The quarter is at risk before it starts, regardless of execution quality.",
+        "It means the company is over-investing in marketing.",
+        "Coverage ratios are made up; ignore them."
+      ],
+      "correct": 1,
+      "explanation": "The 3x coverage rule comes from typical conversion math: if your win rate at the opportunity stage is ~30%, you need at least $30M of pipeline to close $10M. Below 3x, the math doesn't add up - even perfect execution won't close enough. When coverage drops below 3x, sales scrambles to add pipeline, marketing gets pressured, and product gets pulled into 'ship something this week to unblock this deal.' Engineers feel this pressure through the chain quickly."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team ships a major feature this quarter. Revenue doesn't change. Three months later, leadership questions whether the feature mattered. What's the most reasonable engineering response?",
+      "choices": [
+        "Admit the feature didn't work.",
+        "Point to *leading* indicators that the feature should have moved - signup activation, time-to-first-value, demo-request volume, deal velocity, win rate against named competitors - and show whether those moved. Revenue is a lagging indicator that typically takes 2-4 quarters to reflect product investments.",
+        "Claim the feature was about technical excellence and shouldn't be measured.",
+        "Suggest ripping the feature out."
+      ],
+      "correct": 1,
+      "explanation": "Engineering work primarily affects leading indicators - signup-to-activation, engagement depth, demo requests, win rate. Those move within weeks. Revenue is the lagging indicator that aggregates them, and it typically lags by 2-4 quarters. The mistake is to evaluate engineering on the lagging indicator at a 3-month interval. The correct pattern: identify the leading indicator the feature was *intended* to move, measure it, and use that to evaluate the work. If no leading indicator was named upfront, that's the deeper problem to fix going forward."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.json b/_data/quizzes/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.json
new file mode 100644
index 0000000..09508af
--- /dev/null
+++ b/_data/quizzes/engineers-mba/04-operating-a-software-business/01-saas-metric-tree.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/04-operating-a-software-business/01-saas-metric-tree",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A SaaS company reports NRR of 130% and GRR of 88%. What does the combination tell you?",
+      "choices": [
+        "The company is failing to retain customers.",
+        "The company loses ~12% of last year's revenue to churn and contraction (GRR captures losses only, capped at 100%), but existing customers expand by ~42% net (the gap between GRR and NRR), so the expansion engine is exceptional but the underlying retention is mediocre - typical of usage-based businesses where high-growth accounts dominate.",
+        "GRR and NRR should be equal.",
+        "The metrics are gamed."
+      ],
+      "correct": 1,
+      "explanation": "GRR captures only losses (churn + contraction). NRR includes expansion. The gap (NRR − GRR) reveals the strength of the expansion engine. A 130/88 combination is common in usage-based businesses where a few large accounts grow rapidly while smaller ones churn. Either component alone is incomplete: NRR alone hides churn; GRR alone misses the growth engine. Both together give a structurally honest picture."
+    },
+    {
+      "id": 2,
+      "question": "A SaaS company has YoY revenue growth of 30%, GAAP operating margin of -15%. What's its Rule of 40 score, and what's the interpretation?",
+      "choices": [
+        "45 - excellent, growing fast.",
+        "15 - well below the 40 benchmark. Either growth needs to accelerate or burn needs to come down; the current combination doesn't justify the burn rate. Most public-company analyst notes flag this as a concern.",
+        "30 - fine because growth is strong.",
+        "Rule of 40 only applies to private companies."
+      ],
+      "correct": 1,
+      "explanation": "Rule of 40 = growth rate + operating margin = 30 + (-15) = 15. The Rule of 40 premise is that high growth justifies high burn, and high profitability justifies slower growth - but the *sum* should exceed 40. At 15, neither is high enough to justify the other. The corrective action is either to accelerate growth (hard) or cut burn dramatically (controllable) - usually both. Analysts use Rule of 40 to evaluate public SaaS companies in nearly every research note."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team improves p99 latency from 2 seconds to 200ms. Six months later, leadership asks 'what did this do for the business?' Which SaaS metric is most likely to have moved measurably as a direct result?",
+      "choices": [
+        "Rule of 40 (it doesn't measure latency).",
+        "Net Revenue Retention (NRR) and Gross Revenue Retention (GRR) - better performance reduces churn risk and reduces contraction events from frustrated customers. Magic Number can also improve indirectly via shorter sales cycles.",
+        "Burn multiple.",
+        "ARR (latency doesn't affect revenue directly)."
+      ],
+      "correct": 1,
+      "explanation": "Latency improvements show up in retention metrics - customers don't downgrade or churn from products they're using and enjoying. NRR and GRR both improve via reduced contraction and churn. Indirect effects include better win rate (faster product wins demos) and shorter sales cycles (technical reviews go faster). The connection is real but slow - 2-4 quarter lag is typical, which is why engineering work should be evaluated on leading indicators (retention trend, churn cohort analysis) before the metric tree fully reflects it."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/04-operating-a-software-business/02-operating-cadence.json b/_data/quizzes/engineers-mba/04-operating-a-software-business/02-operating-cadence.json
new file mode 100644
index 0000000..ec38333
--- /dev/null
+++ b/_data/quizzes/engineers-mba/04-operating-a-software-business/02-operating-cadence.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/04-operating-a-software-business/02-operating-cadence",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineering team writes an OKR: 'Objective: Improve reliability. KR1: 99.95% uptime. KR2: Reduce incidents.' What's most likely wrong with this OKR?",
+      "choices": [
+        "The objective is too short.",
+        "These are steady-state KPIs disguised as OKRs - 99.95% uptime is an ongoing operational target, not a change goal with a baseline and a defined improvement. A real OKR would have specific baselines, specific targets, and represent a *change* the team is committed to driving (e.g. 'Reduce P0/P1 incidents from 2.3/month to <1/month').",
+        "OKRs must have exactly 3 key results.",
+        "Reliability is not measurable."
+      ],
+      "correct": 1,
+      "explanation": "The KPI/OKR distinction is foundational. KPIs are steady-state operational metrics with relatively stable targets ('we maintain 99.95% uptime'). OKRs are change goals: a baseline, a target, and a theory of how the change will happen. Writing KPIs as OKRs is the most common OKR failure mode - it produces 'OKR theater' where targets are met by definition because they're the operational baseline. A real OKR would have concrete numerical change from baseline."
+    },
+    {
+      "id": 2,
+      "question": "A senior engineer is invited to present at the upcoming QBR. The CTO says '5 minutes on what your team did this quarter.' Which is the most effective framing?",
+      "choices": [
+        "List shipped PRs, percent of tests fixed, services migrated.",
+        "Frame outcomes against business metrics - incident reduction → NRR contribution, SSO ship → unblocked enterprise pipeline, platform migration → next-quarter capability - and surface risks and asks in business terms.",
+        "Walk through architectural diagrams.",
+        "Apologize for what didn't ship."
+      ],
+      "correct": 1,
+      "explanation": "QBR audiences are cross-functional - sales, marketing, finance, customer success. They need engineering outcomes translated into business terms they understand. 'We reduced incidents 50%' is more useful when framed as '...which contributed to NRR uptick.' 'We shipped SSO' is more useful as '...which unblocked $4M of stalled enterprise pipeline.' The translation is the difference between engineering work being valued at the exec table and being invisible."
+    },
+    {
+      "id": 3,
+      "question": "When does engineering have the highest-leverage opportunity to shape what gets funded for the next 12 months?",
+      "choices": [
+        "In the weekly engineering standup.",
+        "During the Annual Operating Plan (AOP) cycle - typically September-November for January fiscal years - where headcount, budget, infrastructure capex, and strategic priorities are negotiated bottom-up and approved by the board. Once the AOP is set, course-correcting requires re-justifying changes against the agreed plan.",
+        "At the next all-hands.",
+        "During the quarterly board meeting."
+      ],
+      "correct": 1,
+      "explanation": "The AOP is the single biggest annual decision point. Headcount, budget, R&D allocation, and strategic priorities for the year are negotiated during this cycle. Once approved, changes require re-justifying against an agreed plan - which is much harder than shaping the plan in the first place. Engineers who only see the AOP as 'what we're given to work on' miss the most valuable opportunity to influence their own next 12 months. Active participation - drafts, asks, strategic bets - is where senior engineers add disproportionate value."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/04-operating-a-software-business/03-org-design.json b/_data/quizzes/engineers-mba/04-operating-a-software-business/03-org-design.json
new file mode 100644
index 0000000..c46ba3d
--- /dev/null
+++ b/_data/quizzes/engineers-mba/04-operating-a-software-business/03-org-design.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/04-operating-a-software-business/03-org-design",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A company decides to migrate its monolith to microservices. They reorganise the codebase but leave team structure unchanged - the same 4 teams will continue to own all the new services. What does Conway's law predict?",
+      "choices": [
+        "Success - microservices and monoliths can coexist.",
+        "Likely failure - without team boundaries that match service boundaries, services end up jointly owned, unclearly owned, or owned-by-default-by-the-team-that-touched-it-last. This typically produces 'distributed monolith' anti-patterns that are worse than the original monolith.",
+        "Doesn't matter - Conway's law is informal.",
+        "Success because the codebase change is enough."
+      ],
+      "correct": 1,
+      "explanation": "Conway's law says the system architecture mirrors the communication structure of the organisation. If 4 teams continue to own all services with no clear team-to-service ownership, you get the worst of both worlds: distributed deployment with shared ownership confusion. The successful pattern is to align team boundaries with service boundaries - each team owns a service, its API contract, and its on-call. Architecture changes without org changes typically fail or take much longer than expected."
+    },
+    {
+      "id": 2,
+      "question": "An engineering manager has 14 direct reports. What's the most likely operational consequence?",
+      "choices": [
+        "Faster decision-making because fewer layers.",
+        "The manager loses depth on each individual report - career conversations, feedback quality, and stretch-opportunity matching all suffer. Span of 5-9 is the empirical sweet spot for engineering management; beyond that, sub-leads typically emerge informally.",
+        "Higher salary for the manager.",
+        "Better team cohesion."
+      ],
+      "correct": 1,
+      "explanation": "Engineering management span empirically caps around 8-9 direct reports. Beyond that, the manager can do logistics but cannot give depth: 1:1s become superficial, feedback gets generic, and stretch opportunities aren't matched well. Informal sub-leads emerge to handle the gap, effectively creating a hidden layer. The right fix is usually to add a layer with proper management - though that has its own costs. Flat-as-a-virtue advocates often discover this scaling cliff between 8 and 12 reports."
+    },
+    {
+      "id": 3,
+      "question": "A new CEO arrives and announces a major reorganisation within 90 days. What should employees most reasonably suspect?",
+      "choices": [
+        "The reorg is well-justified by strategy.",
+        "The reorg may be primarily a leadership-signaling exercise rather than a strategy-driven change - strategic reorgs typically follow 6-12 months of leadership embedding, customer research, and explicit problem identification. 'Reorg within 90 days of arrival' is a common pattern that often does more damage than it solves.",
+        "Engineering will love it.",
+        "The board demanded it."
+      ],
+      "correct": 1,
+      "explanation": "Reorgs should be tied to specific strategic shifts and have a 12-month-measurable outcome. New-leadership-within-90-days reorgs are typically about leadership presence and identity rather than strategy. They cost 6-12 months of velocity, create attrition, and rarely deliver the promised benefit. Healthy reorgs come after the leader has spent time understanding the business, talked to customers and teams, and can articulate a *specific* problem the reorg solves. Without that, the reorg is often more pain than gain."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.json b/_data/quizzes/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.json
new file mode 100644
index 0000000..c4fd4b4
--- /dev/null
+++ b/_data/quizzes/engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/04-operating-a-software-business/04-headcount-and-cost-of-engineer",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineer with $200k base salary, $30k bonus, $80k equity grant, and standard benefits - what's the approximate fully-loaded annual cost to the company?",
+      "choices": [
+        "$200,000 - base salary is the relevant number.",
+        "About $400-450k - adding employer taxes, full benefits, allocated overhead (HR, IT, finance, recruiting, real estate), and a share of engineering management time pushes fully-loaded cost to roughly 1.5-2x the direct compensation.",
+        "About $310k - just direct comp.",
+        "$1M because of equity dilution."
+      ],
+      "correct": 1,
+      "explanation": "Fully-loaded cost includes the visible direct compensation (~$310k in this case) plus employer payroll taxes (~$18k), full benefits (health, 401k match, life, disability - ~$25-35k), and allocated overhead (HR, recruiting, IT, finance, real estate, plus a share of engineering management and tooling - ~$50-70k). The factor is typically 1.5-2x base comp. Engineers planning project costs almost always use comp instead of fully-loaded, which underestimates capital commitment by ~50%."
+    },
+    {
+      "id": 2,
+      "question": "A VP of Engineering says 'we'll hire 5 senior engineers to ship the feature by Q3.' Assuming a 16-week req-to-seated time and 4-month ramp, when are those hires actually productive?",
+      "choices": [
+        "Within 4 weeks.",
+        "Approximately 8 months from when reqs open - 4 months to seat (req → offer accepted → start), then ~4 more months until productive net-positive contribution. By that time, Q3 is past and the gap has compounded.",
+        "Immediately after onboarding.",
+        "In ~12 weeks total."
+      ],
+      "correct": 1,
+      "explanation": "Hiring senior engineers is a 6-9 month investment, not a quarterly fix. 12-20 weeks from req open to seated (depending on level and market), then 4-6 months until net-positive contribution. New senior engineers spend the early months learning systems and producing code that requires significant review and rework. 'We'll hire to fix this' is rarely a real plan for current-quarter problems - it's an investment in next year's capacity."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team has 6 engineers. The manager budgets 100% of their time for the new feature roadmap. Why does this almost always fail?",
+      "choices": [
+        "Engineers should work less.",
+        "Capacity (the theoretical max) differs from velocity (sustained delivery) by 30-50% on most teams - time goes to on-call, support, bugs, meetings, hiring, mentoring, document writing. Budgeting at capacity guarantees over-commitment; budgeting at observed velocity with a 30-40% buffer for non-feature work matches reality.",
+        "Engineers refuse to work weekends.",
+        "The CEO will reject the plan."
+      ],
+      "correct": 1,
+      "explanation": "Capacity vs velocity confusion is the most common cause of engineering over-commitment. A team of 6 has theoretical capacity ~15,000 person-hours/year but observed velocity on feature work is typically 6,000-8,000. The rest is operational: on-call, support tickets, bugs, code reviews, meetings, hiring, mentoring, documentation. Planning at capacity guarantees a quarterly miss. The right pattern: plan at *observed* velocity, leave 30-40% buffer for non-feature work, and revisit assumptions if velocity changes."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.json b/_data/quizzes/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.json
new file mode 100644
index 0000000..6d9318e
--- /dev/null
+++ b/_data/quizzes/engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/04-operating-a-software-business/05-build-vs-buy-economics",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineering team compares 'Auth0 for $50k/year' to 'build internal auth for $200k of engineering work.' Why is this comparison usually misleading?",
+      "choices": [
+        "Auth0 is too expensive.",
+        "It compares Year-1 build cost to a single year of subscription, omitting (a) ongoing maintenance - typically 0.5-1 FTE/year of an internal auth system, (b) the long tail of features the vendor already has (MFA, federation, audit logging, compliance), and (c) opportunity cost of those engineers not building product. The 3-year TCO of build is typically 5-10x the simple Year-1 comparison.",
+        "Auth0 doesn't support enterprise customers.",
+        "Internal auth is always cheaper."
+      ],
+      "correct": 1,
+      "explanation": "Engineers consistently underestimate the build case because they compare upfront build cost to a single year of vendor pricing. The full 3-year TCO of an internal auth system, including maintenance (security patches, OIDC/SAML evolution, MFA support, audit logs), edge-case handling, and opportunity cost, is typically $1.5-2M+ - vs. a few hundred thousand for the vendor. Build occasionally wins (e.g. when the capability is core to differentiation), but the naive Year-1 comparison gets the answer wrong by an order of magnitude."
+    },
+    {
+      "id": 2,
+      "question": "Why are vendor decisions in deeply regulated or commoditised categories (payments, identity, email delivery, error tracking) almost always 'buy' rather than 'build'?",
+      "choices": [
+        "Vendors lobby successfully.",
+        "These categories have high regulatory/compliance overhead (PCI DSS for payments, SOC2 for everything, GDPR/HIPAA depending on data), accumulated engineering complexity that no in-house team can replicate (fraud detection, deliverability, identity federation), and significant operational expertise that's commoditised by specialists - so building costs 5-10x the vendor option and never reaches feature parity.",
+        "Buying is always cheaper.",
+        "Engineering teams can't write secure code."
+      ],
+      "correct": 1,
+      "explanation": "Categories like payments and identity have decades of accumulated engineering complexity: PCI DSS Level 1 certification, card-network agreements, fraud-detection ML, settlement and chargeback handling, federation protocols (SAML, OIDC), and edge cases that are invisible until they bite. Vendors amortise this across thousands of customers; internal builds amortise it across one. The build case loses on TCO and on capability - the internal version is usually a worse version of the vendor product, at higher cost."
+    },
+    {
+      "id": 3,
+      "question": "A company depends heavily on a single SaaS vendor for a critical-path capability. The vendor announces a 4x pricing increase at next renewal. The company's options are limited because they have 2 years of integration accumulated. What's the structural lesson?",
+      "choices": [
+        "Always use open-source.",
+        "Critical-path single-vendor dependencies are a structural risk that should be actively managed - through thin abstractions over the vendor (matching your domain not their API), a tested second-source even if not used daily, and contractual protections (price caps, deprecation notice, data portability). The 'we can switch when we need to' assumption is rarely accurate because switching costs accumulate over time.",
+        "Vendor decisions don't matter long-term.",
+        "Only use vendors that promise never to raise prices."
+      ],
+      "correct": 1,
+      "explanation": "Single-vendor critical-path dependencies become semi-permanent because switching costs compound: data migration, integration re-work, training, parallel operation, and risk of the new vendor being worse. By renewal time, the customer is trapped. Mitigation requires upfront work: thin abstractions matching your domain (not vendor APIs), a tested but unused second source, contractual price caps and data-portability clauses, and active vendor relationship management. The 2022-2024 era taught many companies these lessons the hard way as vendors raised prices."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/05-capital-risk-decisions/01-capital-allocation.json b/_data/quizzes/engineers-mba/05-capital-risk-decisions/01-capital-allocation.json
new file mode 100644
index 0000000..0e348af
--- /dev/null
+++ b/_data/quizzes/engineers-mba/05-capital-risk-decisions/01-capital-allocation.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/05-capital-risk-decisions/01-capital-allocation",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A project has consumed $5M of engineering investment so far. The original justification has weakened, and finishing the project would require another $3M. A staff engineer argues 'we've already spent $5M; we have to finish it.' What's the rigorous capital-allocation response?",
+      "choices": [
+        "Finish the project - sunk costs matter.",
+        "Re-evaluate forward: the $5M already spent is gone regardless of decision. The relevant question is whether the *remaining* $3M is the best use of $3M, compared to alternative projects competing for the same capital. Past investment is informational (about feasibility) but not financially relevant to the go-forward decision.",
+        "Cancel any project that gets re-evaluated.",
+        "Continue because momentum matters."
+      ],
+      "correct": 1,
+      "explanation": "Sunk-cost trap is one of the most consistent capital-allocation errors. The $5M spent is gone whether you continue or cancel. The decision should compare 'remaining $3M to finish this' against 'remaining $3M to fund the next-best alternative.' The fact that we've spent money doesn't change the forward economics. Past investment is informational (tells you what you've learned, what's been built) but isn't financially relevant. Strong leadership teams have the discipline to walk away from a project they've invested heavily in when the forward analysis says so."
+    },
+    {
+      "id": 2,
+      "question": "Why do prioritisation frameworks like RICE (Reach × Impact × Confidence / Effort) often disappoint in practice?",
+      "choices": [
+        "They're too complex.",
+        "The scores are largely fabricated, the framework doesn't model dependencies or sequencing, it doesn't capture strategic value separate from user impact, and it implies objectivity in what is fundamentally a judgement call. Teams that succeed with these frameworks treat them as conversation tools (force the relevant questions) rather than decision rules (the score decides).",
+        "They're proprietary to specific companies.",
+        "They produce too many ideas."
+      ],
+      "correct": 1,
+      "explanation": "RICE and similar frameworks fail because the scores aren't defensible - there's no rigorous way to compute 'Impact: 7 of 10' that the team won't game. They also don't model the things that actually matter: project sequencing, strategic value (which can be high even when user impact is low - e.g. a platform investment), risk profile, or capital constraints. The best use is as *conversation* tools that force teams to articulate reach, impact, and confidence - not as decision rules that produce a number to defer to."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team requests $4M for an AI-powered feature with high uncertainty (could be 10x ROI or 0). Compared to a $1.5M reliability project that's a clear 5x ROI. How should a rational exec team typically size these bets?",
+      "choices": [
+        "Both at full ask.",
+        "Asymmetric bet sizing: fund the reliable, high-ROI reliability project at its full $1.5M, and fund the high-variance AI project at a *smaller* initial investment with explicit kill criteria (e.g. $1.5M with re-evaluation at 6 months). This preserves optionality on the AI bet while not over-committing capital on something that might not work.",
+        "Fund the AI project, cancel the reliability project.",
+        "Treat them identically because both are 'engineering work.'"
+      ],
+      "correct": 1,
+      "explanation": "Smart capital allocation sizes bets asymmetrically by conviction. High-conviction, clear-ROI projects can be fully funded. High-variance bets should be funded in stages with explicit kill criteria - small initial investment to learn, expansion only if early signals are positive. This preserves capital for the projects that are working and lets you walk away from the ones that aren't. The naive 'fund everything fully' approach destroys capital because it can't pivot when high-variance bets reveal themselves as misses."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/05-capital-risk-decisions/02-fundraising-101.json b/_data/quizzes/engineers-mba/05-capital-risk-decisions/02-fundraising-101.json
new file mode 100644
index 0000000..42f8fb3
--- /dev/null
+++ b/_data/quizzes/engineers-mba/05-capital-risk-decisions/02-fundraising-101.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/05-capital-risk-decisions/02-fundraising-101",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A startup raises a Series B of $30M at $200M pre-money. What's the post-money valuation and the new investors' ownership?",
+      "choices": [
+        "$200M post, 30% ownership.",
+        "$230M post, ~13.04% ownership (investment / post-money = $30M / $230M).",
+        "$170M post, 17.6% ownership.",
+        "$230M post, 30% ownership."
+      ],
+      "correct": 1,
+      "explanation": "Post-money = pre-money + investment = $200M + $30M = $230M. Investor ownership = investment / post-money = $30M / $230M = 13.04%. Founders prefer to anchor on pre-money (sounds smaller); investors prefer post-money (sounds larger). Same arithmetic. Existing shareholders are diluted by 13.04% (their ownership multiplied by 86.96%), unless an option pool refresh shifts some of that dilution to them as well."
+    },
+    {
+      "id": 2,
+      "question": "A company is acquired for $50M. The total preferred stack across rounds is $60M (with 1x liquidation preference). What do common shareholders typically receive?",
+      "choices": [
+        "Their pro-rata share of $50M.",
+        "Approximately $0 - preferred holders have first claim with 1x liquidation preference, so they absorb the entire $50M (recovering $50M of their $60M, with $10M shortfall to preferred itself). Common shareholders, including founders and employees with options, get nothing from this exit.",
+        "$50M minus a small percentage fee.",
+        "Common gets paid before preferred in distress."
+      ],
+      "correct": 1,
+      "explanation": "Preferred stock with 1x liquidation preference gets paid first at exit, up to their invested amount. With $60M of preferred stack and a $50M exit, preferred holders absorb the entire $50M (still short their full investment). Common shareholders get $0. This is why understanding the preference stack is critical - a $50M exit can be a wipeout for employees with options. The risk is real and frequently underestimated by employees who assume any exit produces value for everyone."
+    },
+    {
+      "id": 3,
+      "question": "An engineer is offered 0.10% equity in a Series B company. The current 409A is $2.50 and the Series B preferred price was $11.50. What's the most useful follow-up information to evaluate the offer?",
+      "choices": [
+        "The CEO's background.",
+        "The total preferred stack (affects exit math), expected future dilution rounds before exit, vesting schedule and cliff, the strike price of these options (relative to 409A), and the company's revenue/growth trajectory toward a credible exit scenario. The 0.10% is a *starting* number that will be diluted further before exit.",
+        "The office location.",
+        "Whether equity is preferred or common."
+      ],
+      "correct": 1,
+      "explanation": "Equity offers should be evaluated with: (1) the preference stack (does the exit produce common-share value?), (2) expected future rounds and resulting dilution (your 0.10% becomes 0.07% after one more round), (3) vesting (a 4-year cliff means you only realize equity if you stay), (4) strike price (cost to exercise), (5) credible exit math (revenue × multiple → valuation). 'Just look at the percentage' misses most of the math that determines actual outcome."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/05-capital-risk-decisions/03-investment-case.json b/_data/quizzes/engineers-mba/05-capital-risk-decisions/03-investment-case.json
new file mode 100644
index 0000000..5302f0d
--- /dev/null
+++ b/_data/quizzes/engineers-mba/05-capital-risk-decisions/03-investment-case.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/05-capital-risk-decisions/03-investment-case",
+  "questions": [
+    {
+      "id": 1,
+      "question": "Why does specifying *kill criteria* in an investment-case memo counterintuitively increase the probability of funding?",
+      "choices": [
+        "It doesn't.",
+        "Kill criteria demonstrate honest engagement with downside risk, pre-commit the team to walking away if signals are bad, and limit the worst-case loss without limiting the upside. Approvers are more comfortable funding bets they know they can stop cleanly - vs bets that turn into 'sunk cost' projects that resist cancellation.",
+        "Approvers like specific numbers.",
+        "Kill criteria are legally required."
+      ],
+      "correct": 1,
+      "explanation": "Approvers worry about funding a project that becomes unkillable - that consumes resources for years past its useful life. Specifying kill criteria upfront (specific, time-bound, observable signals) makes the bet recoverable. It also signals that the proposer has thought about failure modes honestly, which builds credibility for the upside case. Many engineers skip kill criteria thinking they look weak; they're actually one of the strongest signals of a well-reasoned proposal."
+    },
+    {
+      "id": 2,
+      "question": "An engineer writes an investment-case memo showing only the 'base case' outcome of their proposal. Why is this typically a weak memo?",
+      "choices": [
+        "It's too short.",
+        "Showing only one scenario hides the range of plausible outcomes and the assumptions behind them. A rigorous memo shows base/upside/downside with rough probabilities, lets the approver pressure-test each, and produces an expected-value comparison to cost. Single-scenario memos look like marketing pitches rather than honest analysis.",
+        "Base cases are forbidden.",
+        "Memos must use 3 colors."
+      ],
+      "correct": 1,
+      "explanation": "Showing one scenario is marketing, not analysis. Real proposals carry uncertainty: how likely is the optimistic outcome? what does the downside look like? Three-scenario memos with rough probabilities force the proposer to engage with the uncertainty and let the approver evaluate whether to take the bet given the range. Single-scenario memos often hide the assumptions that would change the answer if challenged."
+    },
+    {
+      "id": 3,
+      "question": "Which is the most important section of an investment-case memo for the executive who has 5 minutes to read it?",
+      "choices": [
+        "The technical architecture appendix.",
+        "Section 1 (the problem and 'why now') plus section 5 (decision required + kill criteria). Most executive readers skim sections 1-4 and look for the decision at the bottom; if section 1 doesn't establish a problem worth solving urgently, the rest doesn't matter.",
+        "The risk register.",
+        "The author's biography."
+      ],
+      "correct": 1,
+      "explanation": "Executive readers under time pressure look for two things: 'what's the problem and why does it matter now?' and 'what's the decision I need to make?' Sections 1 and 5 carry that load. The middle sections (proposal, scenarios, cost) provide the evidence - but if section 1 doesn't establish urgency and section 5 isn't crisp about the decision, the memo fails regardless of the analysis quality. Write the memo with the time-constrained skim-reader in mind."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/05-capital-risk-decisions/04-risk-categories.json b/_data/quizzes/engineers-mba/05-capital-risk-decisions/04-risk-categories.json
new file mode 100644
index 0000000..4d06ad7
--- /dev/null
+++ b/_data/quizzes/engineers-mba/05-capital-risk-decisions/04-risk-categories.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/05-capital-risk-decisions/04-risk-categories",
+  "questions": [
+    {
+      "id": 1,
+      "question": "A company spends $3M/year on its security team and tooling. Some executives question whether this is too much. How should the spend be evaluated economically?",
+      "choices": [
+        "$3M is high; cut it.",
+        "Run the EV math: a major breach typically costs $50-500M in legal, customer churn, and brand damage. Even at low annual probability (say 2-5%), expected annual loss is $1-25M - comparable to or exceeding the $3M mitigation. The asymmetry strongly favours over-investment in prevention, and most companies under-invest because mitigation costs are visible/ongoing while downside is invisible/possible.",
+        "Cybersecurity is a marketing expense.",
+        "Compare to other companies."
+      ],
+      "correct": 1,
+      "explanation": "Risk economics is structurally asymmetric. The annual cost of a security team and tooling is visible and bounded ($1-5M typical). The downside of a major breach (Equifax-class, Target-class) is $50-500M+ and frequently includes regulatory penalties, class-action settlements, customer churn, brand damage, and executive turnover. Even modest breach probabilities make the EV of investment overwhelmingly positive. The most expensive risk mistakes in tech history have mostly been under-investment in prevention because the downside felt distant."
+    },
+    {
+      "id": 2,
+      "question": "An engineering team has one engineer who's the only person who deeply understands the production database failover procedure. The engineer is well-compensated and engaged. Is this still a risk worth mitigating?",
+      "choices": [
+        "No - the engineer is happy.",
+        "Yes - key-person risk doesn't depend solely on the engineer's intent to stay. Health events, family circumstances, sudden recruiting offers, or burnout can all remove a critical person without notice. The cost of cross-training, documentation, and rotation is modest ($200k of investment); the cost of incident recovery without that knowledge is $1-5M and significant time-to-recovery. Mitigation is high-leverage.",
+        "Only if the engineer says they're leaving.",
+        "Document everything in Slack."
+      ],
+      "correct": 1,
+      "explanation": "Key-person risk is independent of intent. People leave or become unavailable for many reasons that don't show in current engagement signals: health events, family changes, sudden outside offers, burnout, retirement. The mitigation (cross-training, runbooks, rotation, periodic drills) is cheap compared to the recovery cost when the person becomes unavailable unexpectedly. 'He'd never leave' is one of the most expensive assumptions in operational risk management."
+    },
+    {
+      "id": 3,
+      "question": "Where does engineering typically have the most direct ownership in the risk register?",
+      "choices": [
+        "Only key-person risk for engineering teams.",
+        "Engineering is the *primary executor* of mitigation across most risk categories - security (auth, encryption, secrets, vuln management), regulatory (data deletion, consent, audit logs, region pinning), reputational (reliability, transparency, incident response), and key-person (cross-training, documentation). Legal/CFO/CISO set policy, but engineering implements.",
+        "Engineering owns nothing on the risk register; legal owns it.",
+        "Only outage risk."
+      ],
+      "correct": 1,
+      "explanation": "The risk register is typically owned by General Counsel and CFO at the policy level, but engineering executes the controls. Security risk → engineering builds encryption, auth, SDLC. Regulatory risk → engineering implements GDPR deletion, consent, data residency. Reputational risk → engineering owns reliability, performance, incident transparency. Key-person risk → engineering owns documentation, cross-training, rotation. Engineers who understand which of their team's work *also* counts as risk mitigation gain a much clearer picture of the team's strategic value."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.json b/_data/quizzes/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.json
new file mode 100644
index 0000000..474965c
--- /dev/null
+++ b/_data/quizzes/engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/05-capital-risk-decisions/05-time-optionality-cost-of-delay",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineering team is deliberating between two SaaS vendors for two weeks. Both meet requirements; switching cost between them is moderate. How should this decision be characterized using Bezos' framework?",
+      "choices": [
+        "One-way door - vendor selection is permanent.",
+        "Two-way door - both options can be switched to the other with moderate cost. Treating it as a one-way door (slow deliberation) imposes the cost of delay (typically project blocks, idle time, slipped commitments) without compensating decision-quality improvement. A senior engineer should make this call quickly and unwind if wrong.",
+        "Two-way door but only if the team is small.",
+        "It's not a real decision."
+      ],
+      "correct": 1,
+      "explanation": "Bezos' insight: most decisions are two-way doors but get treated as one-way doors, slowing the team without improving outcomes. Vendor selection where both options work and switching is doable is a textbook two-way door. The cost of two weeks of deliberation (project blocks, slipped commitments, decision fatigue) usually exceeds the marginal decision quality gained from extra analysis. Make the call fast; unwind if wrong."
+    },
+    {
+      "id": 2,
+      "question": "A project worth $4M/year is delayed by one quarter due to analysis-paralysis on a moderate technical decision. What's the approximate cost of delay?",
+      "choices": [
+        "Zero - delay doesn't cost anything if the project eventually ships.",
+        "Roughly $1M of direct revenue (one quarter at $4M/year run-rate), plus opportunity cost of resources idling, plus competitive risk if a rival ships during the delay, plus strategic positioning lost. Cost of delay is often the *largest* single factor in project economics and is routinely under-measured.",
+        "Just the engineering salaries during the delay period.",
+        "About $100k."
+      ],
+      "correct": 1,
+      "explanation": "Cost of delay = expected revenue impact during delay + idle resource cost + competitive entry risk + strategic positioning loss. For a $4M/year project, a one-quarter delay costs ~$1M of direct revenue alone - usually 10-100x more than the 'cost' of the engineering decision being deliberated. Most organizations don't track cost of delay explicitly, which is why projects routinely slip without anyone framing the economic impact. Reinertsen's Principles of Product Development Flow is the canonical treatment."
+    },
+    {
+      "id": 3,
+      "question": "An engineering team builds an abstraction layer to keep the code portable across cloud providers, in case they need to switch. Years pass; they never switch. How should the abstraction be evaluated?",
+      "choices": [
+        "It was a great decision - optionality is always worth it.",
+        "Real options thinking justifies the abstraction only if the *probability of exercising* the option exceeded the cost of building and maintaining it. If the switch never happens (and was unlikely from the start), the abstraction's value was lower than its cost - paid for optionality that didn't pay off. Optionality is valuable but not free; pay for it when the option is likely to be exercised.",
+        "Cloud abstractions are always required.",
+        "Switch immediately."
+      ],
+      "correct": 1,
+      "explanation": "Real-options thinking can justify deferring or hedging decisions - but optionality has cost (engineering complexity, performance overhead, ongoing maintenance). The value of optionality is roughly the probability of exercising the option × the value of exercising. If probability is low and the abstraction is expensive, the option costs more than it's worth. Multi-cloud abstractions, vendor-portability layers, and similar 'just in case' investments need a real probability story; otherwise they're paid optionality with no expected payoff."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.json b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.json
new file mode 100644
index 0000000..5ad3905
--- /dev/null
+++ b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/06-technical-leaders-playbook/01-translating-engineering-to-business",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineer presents 'We migrated 80% of services to Kubernetes' as a team achievement at a QBR. What's the most useful critique?",
+      "choices": [
+        "Kubernetes is a bad choice.",
+        "This is output, not outcome - it describes what was done but not what changed for the business. The translated version would be 'Migrated 80% of services to Kubernetes, which reduced infra cost by $X, cut deployment time from N to M minutes, and enables [next capability].' Until the consequence in business terms is articulated, the work is invisible to non-engineering audiences.",
+        "80% is too low.",
+        "Containers are deprecated."
+      ],
+      "correct": 1,
+      "explanation": "Output vs. outcome is the single most consistent engineering communication pattern. Output is what you produced; outcome is what changed in the world. Engineering audiences understand 'migrated to Kubernetes' immediately. Exec/cross-functional audiences need the business-outcome translation: cost saved, capability enabled, time recovered, capacity created. Without translation, engineering work is invisible at the exec level - which directly affects funding, prioritization, and recognition."
+    },
+    {
+      "id": 2,
+      "question": "Why is it sometimes the *right* call to NOT translate engineering work into business-outcome language?",
+      "choices": [
+        "Translation is always required.",
+        "Some work is genuinely foundational - technical debt paydown that enables future shipping, security hardening with bounded cost vs catastrophic downside, refactoring legacy systems before they break. Forcing every project into a contrived ROI narrative weakens credibility; naming table-stakes work honestly ('this is foundational; the cost of not doing it is catastrophic') is sometimes the more credible framing.",
+        "Engineers shouldn't have to explain themselves.",
+        "Translations always fail."
+      ],
+      "correct": 1,
+      "explanation": "Most engineering work translates cleanly to a business outcome (latency → conversion, reliability → NRR, features → ARR). But foundational work - debt paydown, security hardening, legacy refactor - sometimes doesn't have a tidy quarterly ROI; the rationale is 'we won't ship anything in 18 months without this' or 'the cost of not doing this is catastrophic.' Forcing these into contrived ROI narratives strains credibility. Strong leadership respects 'this is table stakes; here's why' when delivered confidently with clear reasoning."
+    },
+    {
+      "id": 3,
+      "question": "An engineer claims 'reducing incident rate by 50% directly caused our NRR to improve.' Why is this typically a credibility-damaging claim?",
+      "choices": [
+        "Engineers aren't allowed to discuss NRR.",
+        "NRR has many simultaneous drivers - pricing changes, customer success activities, product features, competitive landscape, account expansion. Claiming a single direct cause oversimplifies and invites pushback. The credibility-preserving framing attributes contribution rather than causation: 'reliability improvements were cited in N of M expansion-account conversations this quarter,' which is verifiable and honest.",
+        "Incident rates don't affect retention.",
+        "50% is impossible."
+      ],
+      "correct": 1,
+      "explanation": "Over-claiming a direct causal link between one engineering metric and one business metric is a common engineering credibility error. NRR moves because of many simultaneous factors; claiming sole credit invites legitimate pushback ('but pricing also changed, and customer success added two new motions'). The honest pattern: cite *contribution* with evidence - 'CS cited reliability in N of M expansion conversations' - which is testable, defensible, and credible. Over-claiming once damages future credibility on later, accurate claims."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.json b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.json
new file mode 100644
index 0000000..ec3976b
--- /dev/null
+++ b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/06-technical-leaders-playbook/02-strategy-and-investment-memos",
+  "questions": [
+    {
+      "id": 1,
+      "question": "Why does Amazon's 6-pager meeting format begin with 20-30 minutes of silent reading?",
+      "choices": [
+        "To save speaker preparation time.",
+        "To flip the dynamic that dominates most meetings, where whoever speaks fastest and loudest controls the discussion. With silent reading, everyone arrives at the discussion having engaged with the same content; junior contributors can ask grounded questions; senior contributors can't dominate by reciting from memory. The conversation is grounded in the memo, not in opinions formed before the memo existed.",
+        "Because Amazon's offices are noisy.",
+        "Because writing is more efficient than speaking."
+      ],
+      "correct": 1,
+      "explanation": "The silent-read is the most underrated component of the 6-pager format. It ensures everyone in the meeting has actually engaged with the proposal before discussion. Without it, the discussion would be dominated by whoever read the memo (sometimes only the author) or by whoever speaks fastest. With it, the discussion is grounded in the document - and the document becomes the shared reference rather than people's pre-existing opinions. Most companies that try the format find this single discipline transforms decision quality."
+    },
+    {
+      "id": 2,
+      "question": "Which section of a 6-pager is most often under-invested but adds the most value?",
+      "choices": [
+        "The cover page.",
+        "The Appendix FAQ - the section anticipating hard questions and answering them in writing. A strong FAQ converts a 90-minute discussion into 30 minutes because the obvious questions are already addressed. It also forces the writer to engage with the proposal's weaknesses before the audience does, which strengthens the proposal overall.",
+        "The cost section.",
+        "The proposal section."
+      ],
+      "correct": 1,
+      "explanation": "The FAQ is the highest-leverage section because (a) it converts meeting time from clarification to substantive discussion, (b) it forces the author to anticipate hard questions and address them before pushback, and (c) it builds credibility - a strong FAQ signals 'we've thought hard about this' more than any other section. Most first-time 6-pager writers under-invest here, leading to meetings that get bogged down in basic clarification. The FAQ should be the longest single section, often 1-2 pages of 6-8 total."
+    },
+    {
+      "id": 3,
+      "question": "When is a deck more appropriate than a memo for a decision?",
+      "choices": [
+        "Always - decks are easier to skim.",
+        "Decks are stronger for *communication* (presenting a finalized story to a broad audience with visual elements). Memos are stronger for *decision-making* (a critical, time-constrained reader forming an independent opinion). Some companies use both: a memo to decide, a deck to communicate the decision afterward.",
+        "Memos are obsolete; always use decks.",
+        "Whichever is shorter."
+      ],
+      "correct": 1,
+      "explanation": "The distinction tracks audience and purpose. Decks excel at presenting a finalised story with visual elements live, on stage, to a broad audience. Memos excel at forcing a critical reader to engage with complete arguments and form an independent assessment - the format prevents hiding weak reasoning behind bullet points. The Amazon convention pushes decision-making into memos; communication afterward often uses decks. Choosing the format is itself a decision: ask 'is this for decision or communication?'"
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.json b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.json
new file mode 100644
index 0000000..65be2c8
--- /dev/null
+++ b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/06-technical-leaders-playbook/03-reading-exec-reviews",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineer attends their first QBR with a new, important position they want to advance. They've never raised it with leadership before. What's the most likely outcome?",
+      "choices": [
+        "Their position will be adopted because QBRs are designed for this.",
+        "The position will likely be tabled or rejected without serious discussion - positions are typically shaped in 1:1 pre-meetings with relevant decision-makers, and by the time the QBR happens, alignment has already formed. New positions arriving cold at the QBR are usually unsuccessful. The right pattern is to socialize positions in pre-meetings first.",
+        "The position will be adopted unanimously.",
+        "Only juniors should attend QBRs."
+      ],
+      "correct": 1,
+      "explanation": "QBRs are coordination/ratification events, not the venue where most strategic decisions are formed. Senior leaders meet pairwise in pre-meetings to align on positions before the public meeting. Engineers who bring novel positions to the QBR for the first time often find them dismissed or tabled - not because the position is wrong, but because the room hasn't had time to integrate it. The leverage point is the pre-meeting: build relationships, share thinking, refine positions, then the QBR is where alignment is publicly stated."
+    },
+    {
+      "id": 2,
+      "question": "A senior engineer is presenting a 5-minute team update at QBR. They lead with 'we shipped 47 PRs this quarter and reduced flaky tests by 30%.' What's the most likely effect on the audience?",
+      "choices": [
+        "The audience will be impressed by the technical detail.",
+        "The audience (CRO, CFO, CEO, CMO) doesn't engage with engineering metrics - they engage with business outcomes. 'We reduced incidents by 50%, which CS cites as contributing to NRR recovery' connects to their world. PR-count and test-flakiness metrics are output, not outcome - engineering-internal vocabulary that produces audience disengagement at exec forums.",
+        "Sales will ask for more flaky-test reduction.",
+        "The CFO will increase R&D budget."
+      ],
+      "correct": 1,
+      "explanation": "QBR audiences are cross-functional. Engineering-internal metrics (PRs, test flakiness, refactoring) don't connect to the mental models of CRO, CFO, CMO, CEO. The translation skill from Chapter 6.1 is critical here. Same work, framed in outcome language: 'We reduced incidents 50% - CS says reliability concerns dropped out of 3 of 8 at-risk renewals.' The work is the same; the framing makes the difference between the audience engaging or disengaging."
+    },
+    {
+      "id": 3,
+      "question": "When should a senior engineer interject during a strategic exec discussion they're attending?",
+      "choices": [
+        "Whenever they have any opinion.",
+        "When the interjection will *materially change the decision being made* - correcting a factual error, providing missing context for a number being cited, surfacing a concern that's been pre-raised but not yet addressed, or noting a critical risk the room is about to miss. Interjections that add slight nuance without changing the decision should wait for after-meeting follow-up.",
+        "Never - junior engineers should remain quiet.",
+        "Only when asked."
+      ],
+      "correct": 1,
+      "explanation": "Calibration matters. Interjecting too rarely makes engineers invisible at the exec table; interjecting too often makes them exhausting. The right heuristic: ask 'will this materially change the decision being made?' If yes, speak. If you're adding nuance that doesn't change the outcome, save it for offline. Senior engineers earn credibility by interjecting at the right moments - and equally, by *not* interjecting at the wrong ones."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.json b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.json
new file mode 100644
index 0000000..c869758
--- /dev/null
+++ b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/06-technical-leaders-playbook/04-cross-functional-negotiation",
+  "questions": [
+    {
+      "id": 1,
+      "question": "Sales commits to a feature for a $1.5M deal closing in 6 weeks. Engineering estimates 12 weeks. What's the most productive engineering response?",
+      "choices": [
+        "Refuse the ask and tell sales they overcommitted.",
+        "Decompose the ask: what specifically does the customer need? Identify the narrow scope deliverable in 6 weeks (e.g. SAML SSO with one IdP) and commit to that, with the broader scope (full federation) committed on a defined roadmap. Sales gets the deal; engineering ships honest scope; the customer gets a credible roadmap.",
+        "Tell sales the deal isn't worth it.",
+        "Build a different feature instead."
+      ],
+      "correct": 1,
+      "explanation": "Naive 'we can't ship that' responses make engineering look like a blocker and don't solve the deal. The productive pattern is decomposition: most large feature asks contain a narrow critical-path component that's deliverable quickly and a broader scope that takes longer. Commit to the critical path on the deal timeline; commit to the broader scope on a roadmap. This pattern works for most engineering-sales conflicts and builds engineering's credibility as a problem-solver rather than a blocker."
+    },
+    {
+      "id": 2,
+      "question": "Why is the framing 'finance doesn't understand engineering' usually counter-productive when there's a budget conflict?",
+      "choices": [
+        "Finance does understand engineering perfectly.",
+        "Each function is competently doing its job under its own incentive structure. Finance is incentivised on forecast accuracy, capital efficiency, and cash runway - they're not wrong; they have different priorities. Reframing the conflict as 'differing incentives, not differing competence' enables productive negotiation; the 'they don't understand' frame escalates the conflict and damages the relationship.",
+        "Engineering should never argue with finance.",
+        "Finance is always wrong."
+      ],
+      "correct": 1,
+      "explanation": "Cross-functional conflicts are almost always trade-offs between functions optimising different things, not incompetence on one side. Finance is measured on forecast accuracy and capital efficiency; their conservatism on hiring is rational from their incentive structure. Engineering is measured on shipping and capacity; the desire for headcount is rational from its incentive structure. The conflict is real but doesn't reflect anyone's incompetence. Reframing this enables productive negotiation; the 'they don't understand' framing prevents it."
+    },
+    {
+      "id": 3,
+      "question": "When is the right time to bring legal or compliance into a project that touches data-protection requirements?",
+      "choices": [
+        "After the feature is built, for the security review.",
+        "At the *start* of design, before architectural decisions are baked in. Late-stage legal review can require expensive rework (data residency, audit logging, consent management are architectural). Early consultation lets legal partner with engineering on design rather than block at the end. Legal is often happy to be brought in early and frustrated to be brought in late.",
+        "Never - engineering should handle compliance.",
+        "Only if a customer requests it."
+      ],
+      "correct": 1,
+      "explanation": "Late-stage legal involvement creates the worst experience for both sides: legal sees a near-complete feature with embedded compliance issues that require rework; engineering sees its work blocked at the finish line. Early consultation - at the design stage - lets compliance requirements shape the architecture, makes legal a partner rather than a blocker, and dramatically reduces rework. The pattern generalises: bring conservative, risk-managing functions in *early*, not *late*. They'll be more useful and less obstructive when they're partners from the start."
+    }
+  ]
+}
diff --git a/_data/quizzes/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.json b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.json
new file mode 100644
index 0000000..86fe1d3
--- /dev/null
+++ b/_data/quizzes/engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap.json
@@ -0,0 +1,41 @@
+{
+  "chapter_id": "engineers-mba/06-technical-leaders-playbook/05-continued-learning-roadmap",
+  "questions": [
+    {
+      "id": 1,
+      "question": "An engineer wants to deepen their understanding of moats and competitive advantage beyond what this course covered. Which book is the most direct modern follow-up?",
+      "choices": [
+        "Zero to One - Peter Thiel.",
+        "7 Powers by Hamilton Helmer - short, dense, and the modern canonical treatment of moats. Builds on Porter's foundational work but updated for software-era examples and competitive dynamics.",
+        "The Lean Startup - Eric Ries.",
+        "Atomic Habits - James Clear."
+      ],
+      "correct": 1,
+      "explanation": "Hamilton Helmer's 7 Powers (2016) is the most directly relevant follow-up to the moats material in this course. It's short (200 pages), dense, and exceptionally well-structured. It covers the seven structural powers (scale economies, network effects, switching costs, cornered resource, counter-positioning, process power, branding) with software-era examples. Porter's Competitive Strategy is the foundational work; 7 Powers is the modern compact version that builds on it."
+    },
+    {
+      "id": 2,
+      "question": "Why are public-company S-1 filings (and 10-Ks, 10-Qs) considered some of the highest-quality, lowest-cost business education available?",
+      "choices": [
+        "They're famous.",
+        "They're audited, legally binding 200-400 page documents that lay out the business, financials, strategy, risks, and capital structure in detail - signed by executives and verifiable. They're free to access via SEC EDGAR. Reading 3-4 S-1s from companies in your space teaches more about how those businesses actually run than any internal company document.",
+        "They're easy to read.",
+        "They contain trade secrets."
+      ],
+      "correct": 1,
+      "explanation": "S-1s and 10-Ks are required disclosure documents - every claim, number, and risk factor is legally signed off. They contain extensive MD&A (Management Discussion and Analysis) where executives explain results in their own words. They're free at sec.gov. Almost no engineer reads them, which is unfortunate because they offer the single highest-quality business education available - and one well-spent afternoon with a relevant S-1 builds intuition that's hard to acquire any other way."
+    },
+    {
+      "id": 3,
+      "question": "An engineer who completes this course wants to build a sustainable learning cadence. Which structure is most likely to produce long-term compounding benefit?",
+      "choices": [
+        "Read 30 books in the next 3 months, then stop.",
+        "A consistent monthly cadence: 1 canonical book per month, weekly newsletter (Stratechery), 1 podcast episode per commute, quarterly reading of S-1s/letters. After 2 years, you'll have absorbed 20+ canonical books, hundreds of newsletters, and several S-1s - and the strategic vocabulary and frameworks will feel natural in conversation.",
+        "Watch 10 YouTube videos per week.",
+        "Take another course."
+      ],
+      "correct": 1,
+      "explanation": "The compounding benefit of a sustained learning cadence is dramatic, while burst-reading produces little durable benefit. The practical structure: 1 canonical book per month, daily/weekly newsletter reading (Stratechery is the highest-leverage), podcast on commute, quarterly S-1/shareholder-letter reading. Over 2 years, this produces both depth (20+ canonical books) and breadth (newsletters, podcasts, primary-source filings). The vocabulary, frameworks, and intuitions accumulate; strategic conversations that used to feel foreign become legible. Start small; build the habit."
+    }
+  ]
+}
diff --git a/_typos.toml b/_typos.toml
index 9f80930..c861c09 100644
--- a/_typos.toml
+++ b/_typos.toml
@@ -30,6 +30,11 @@ Skelton = "Skelton"
 # Ceaser is the deliberate name of a CSS easing tool by Matthew Lein
 # (matthewlein.com/ceaser/), not a misspelling of Caesar.
 Ceaser = "Ceaser"
+# Common business names and acronyms used throughout The Engineer's MBA.
+CMO = "CMO"
+Collison = "Collison"
+Feld = "Feld"
+Hashi = "Hashi"
 # "teh" appears in instructional course content as a literal example of
 # a common typo. The surrounding double quotes make typos's regex skip
 # fail because the example is unquoted code.
diff --git a/images/engineers-mba.jpg b/images/engineers-mba.jpg
new file mode 100644
index 0000000..4f9df2a
Binary files /dev/null and b/images/engineers-mba.jpg differ
diff --git a/images/engineers-mba.png b/images/engineers-mba.png
new file mode 100644
index 0000000..750fb55
Binary files /dev/null and b/images/engineers-mba.png differ