Selected Concepts

Communication is the work

Product management is taking orders like a waiter at Denny's. Design hands off a comp. Engineering builds it without understanding it. Users laugh at first, then awkwardly say, "Oh, this is what you built?" Everyone points at someone else. Team members are solving different problems in their heads, and no one has stopped to confirm they are building the right thing.

Domain fluency is the multiplier

An engineer proposes showing riders how "late" their bus is. Operations people exchange looks: "Do you know what headway-based service is?" He doesn't. He's been building transit software for a year without learning that high-frequency routes have no meaningful schedule. His feature would display nonsense to hundreds of thousands of riders. Technical skill means nothing if you're solving the wrong problem.

Discovery saves time

Teams say they don't have time for discovery, then somehow find time for rework. They ship a feature nobody uses, fix the edge cases nobody asked for, and call it "iteration." That isn't a bias to action. It's fear that thinking looks like doing nothing, so they ship something.

The AI model is an eager intern, not the decision-maker

AI assistants generate plausible code fast. They have no idea whether it fits your system. A 2025 study gave experienced developers AI tools for real tasks: they were 19% slower on average. Why? They accepted bad suggestions without review, followed broken code paths, and spent more time recovering from AI mistakes than they saved. Never ship what you haven't verified yourself.

Agile theater ships nothing that matters

The ceremonies exist. The artifacts are there. But constraints are imposed top-down. The board says "Done" when features haven't left QA. The retro produces action items no one tracks. Velocity climbs while the product stagnates. Engineers lose trust. Stakeholders get a distorted picture. Users keep waiting for old bugs to get fixed. Real Agile reduces risk through fast feedback. Agile theater is just pretend work.

Infrastructure ignorance creates unexplained failures

The code was fine. A container was starved for memory. The disk was full. The database hit a connection limit. From the outside: flaky behavior and weird timeouts. Without a mental model of how requests flow from DNS to load balancer to app to database, you're guessing. Even if you are in a "throw it over the fence" organization, you need to understand the infrastructure that runs your code.

Estimation surfaces risks, not deadlines

An estimate is a forecast, not a contract. The point isn't precision. It's getting the team to the same page so the sprint doesn't collapse under a weight nobody saw coming. When one person says "one point" and another says "five points," stop. That gap is more valuable than the number. Big estimates are warnings: the work may need splitting, the goal may be vague, or there's a dependency everyone's pretending doesn't exist.

Invisible work leads to nonexistent promotions

A lot of work that proves you're operating at a higher level never shows up in sprint reports: mentoring new hires, stabilizing a flaky system, writing the runbook that saves everyone's weekend. In many organizations, if you don't create artifacts—design docs you authored, architectural diagrams, incident postmortems where you led the response—that work didn't happen. The promotion committee can't evaluate what they can't see.

Remote work is a trade, not a loophole

You get no commute, more control, and flexibility in your day. In return, your team needs reliability, visibility, and responsiveness. Going offline for two hours at 10 AM without telling anyone isn't flexibility. When you routinely disappear mid-day with no signal, people stop trusting you with anything time-sensitive. That trust, once lost, is hard to rebuild.

A must-read for engineers who want to actually ship things that matter.`