👨🏻 Brother Talk — Phase 15, Off the Record

The leadership phase. This is where you stop being measured by what you build and start being measured by what you decide and who you lift. Let me tell you what actually changes.

Brother, this is the phase where the job quietly transforms, and a lot of brilliant engineers miss the transition. Up to now, your value was your output — the pipeline you built, the bug you fixed, the system you optimized. At the principal level, your value becomes your judgment and your leverage: the decisions you make that hundreds of others build on, and the engineers you make better. That's a different game, and the skills that got you here (heads-down building) are not the skills that get you further. Let me give you the mindset shifts that took me too long.

Write it down. Always. This is the highest-leverage habit of the whole role. I cannot overstate this. When you make a real decision, write the ADR — context, decision, alternatives, consequences, and the magic line: what would make us revisit this. Do it even when nobody asks. Here's why it's transformative: a decision in someone's head is re-argued every quarter, drifts as memory fades, and dies when that person leaves. A decision in an ADR is legible — new people onboard on the reasoning, disagreements get resolved by pointing at the documented tradeoff instead of arguing personalities, and you can change your mind on purpose when the assumptions change. The engineers whose decisions are written down become the engineers people trust with bigger decisions, because their thinking is inspectable. The ones who decide in Slack threads stay stuck re-litigating. Be the first kind.

"Best" is a junior word. Banish it. There is no best database, no best streaming engine, no best table format — there's only best for this workload, with these weights, given this team. The moment you catch yourself or someone else saying "X is the best," the principal move is to ask "best for what?" and pull out the weights. The lab proves the point mechanically: the exact same two options flip winners when you change the weights. So the real work of a decision isn't picking the option — it's agreeing on the weights, and once the room agrees on those, the choice usually falls out and the argument evaporates. Most "technical disagreements" are actually unspoken disagreements about weights. Surface the weights and you resolve the fight.

Don't build what isn't your differentiator. This is the discipline that saves the most wasted years. Engineers love to build — it's fun, it's impressive, "we could write our own X" feels powerful. And it's usually a trap. Your org's edge is its product, not its message bus or its orchestrator or its table format. Every month spent building and operating commodity infrastructure is a month not spent on what makes you uniquely valuable. Adopt Kafka, adopt Iceberg, adopt Dagster — and build the thin layer on top that encodes your standards (the SDK, the contracts, the templates). That layer is your differentiator and it's cheap to own. "We could build it" is almost never the same as "we should." Saying no to building is a senior skill that feels like weakness and is actually strength.

Migrations: the cardinal sin is the big bang. I've watched migrations destroy quarters and bruise careers, and it's almost always the same mistake: flip the switch, pray, and discover in production all the things that didn't transfer. The safe way is boring and it works: dual-write so old and new run together, validate parity obsessively until the numbers match for a soak period, cut over a little at a time with the old path still warm, keep rollback at every step, and decommission the old thing last, only after the new one has proven itself. It takes longer. It's less exciting. And it's the difference between "we migrated to the lakehouse last year, it was smooth" and "the migration is the reason three people left." Patience and reversibility are the migration superpowers. Boring migrations are successful migrations.

Learn to speak to executives, because your best work dies if you can't sell it. Here's a painful truth: a brilliant architecture that leadership doesn't fund or approve is worth nothing. And leadership does not speak Flink. They speak cost, risk, time, and reliability. "We should adopt Iceberg because of snapshot isolation and hidden partitioning" is a sentence that gets you a blank stare. "This cuts our query bill 40%, reduces data incidents, and takes one quarter with a safe rollback" is a sentence that gets you a yes. Translating your deep technical judgment into the language of business outcomes isn't selling out — it's the skill that lets your judgment actually matter. Practice it.

Scale yourself, or become the bottleneck. The trap of being good at decisions is that everyone brings you every decision, and you become a human bottleneck who's in forty meetings and resentful. The escape is standards and reference architectures: encode your judgment once, as the blessed way to build an ingestion pipeline or a lakehouse table, with the ADRs behind it, so teams make good decisions without you in the room. That's how one principal's judgment reaches a thousand engineers — and it's literally a JD success metric ("engineers create pipelines without reinventing architecture"). The goal isn't to make every decision; it's to make most decisions unnecessary by setting good defaults.

The deepest principal skill, and the rarest: simplify without making fragile. Anyone can add complexity; anyone can cut corners. The hard, valuable thing is removing complexity while keeping the guarantees — making a system simpler to operate without making it break. Because a system lives for years and gets operated thousands of times, and the boring simple thing that any on-call can reason about beats the elegant complex thing that needs a PhD at 3 a.m. (P00's operability, one last time). When you can look at a sprawling design and find the simpler one that's just as correct, you're doing the thing that defines the level.

Career truth: the transition from "great engineer" to "principal" is the transition from answers to judgment, from building to deciding and lifting. It's uncomfortable because the feedback loop is slower and the work is less tangible. But it's where the leverage — and the title — lives. Write the ADRs. Surface the weights. Build only your differentiator. Migrate safely. Speak to the business. Set the standards. Lift the people. That's the job.

Build the toolkit. Write three real ADRs from this track. Then come to P16, where you compose everything — all sixteen phases — into the five capstone systems the JD asks for. The graduation.

— your brother 👨🏻