Business Acumen for Senior Engineers

Introduction

At some point in a senior engineer's career, the hard problems stop being technical. The next promotion, the project that finally gets funded, the architectural decision that actually sticks — all of them depend less on what you can build and more on whether you can reason about why to build it, what it costs, and who needs to be on board.

This series is the operating literacy most engineers pick up piecemeal after a painful meeting or a cancelled project. It assumes you already know how to design systems. It doesn't assume you know how to read a P&L, estimate a customer acquisition payback period, or translate "we need a three-week freeze on deploys" into language a VP of Sales will absorb.

Why Another Series About "Soft Skills"?

This isn't a soft-skills series. The skills here are operating skills — the ones a CFO, PM, or CEO uses every day. Engineers absorb them slowly by osmosis, often wrongly, usually late. The gap shows up in specific moments:

• A principal engineer pitches a six-month rearchitecture and can't answer "what's the ROI?"
• A tech lead proposes a multi-region active-active setup for an internal B2B app.
• A staff engineer launches a new internal platform that two consumer teams refuse to adopt.
• A senior IC writes a 40-slide deck for a 15-minute exec review and loses the room on slide 3.

All four of these are recoverable. None of them are fixed by "writing better code."

The Shape of the Series

Six chapters. Read in order if you're new to these ideas; jump around if you're filling a specific gap.

1. Why Senior Engineers Need Business Acumen — the signals that it's time to level up beyond the code, and what changes at senior/staff/principal that makes operating literacy non-optional.
2. Reading a P&L and Unit Economics — the three financial statements, SaaS P&L structure, CAC / LTV / payback / NRR, and which of these engineering actually moves.
3. Business Models and Their Architectural Consequences — SaaS, marketplace, ads, freemium, enterprise, fintech. What each model demands of the system, and the multi-tenancy trilemma.
4. Cost-Aware Engineering — FinOps, cloud-cost anatomy, real optimization levers vs theater, dev velocity as a cost, and build-vs-buy decision frameworks.
5. Stakeholder Mapping — Mendelow's Power/Interest grid, the salience model, RACI, hidden stakeholders, and why most "technical failures" are stakeholder-management failures in disguise.
6. Presenting Technical Work to Non-Technical Audiences — the Minto Pyramid Principle, SCQA, the Amazon 6-pager, translating architecture into revenue and risk, and the first-60-seconds rule.

How to Read It

Each chapter stands on its own, but they reinforce each other. The financial chapters (2 and 4) give you the vocabulary to make a case; the model chapter (3) tells you what case you should be making; the stakeholder and communication chapters (5 and 6) determine whether anyone actually listens.

The goal is not to turn you into a product manager, a CFO, or a consultant. It is to make you dangerous enough in those rooms that your technical recommendations get funded, adopted, and defended on their merits.

---

Next in the series: Why the skills you built over your first ten years stop being the bottleneck — and what replaces them.