Course/mba

_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 %}

_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 %}