The Ego-Less Architect: Letting Go of "My Way" in Favor of the "Right Way"

The before-start checklist on a 737 names the action, never the rank. It says fuel pumps, on. It does not say the captain decides whether the fuel pumps are on. Twenty years of accident reports went into trimming that card down to the items that kill you if you skip them, and the trimming was done by people who would never fly the airframe. The card carries no ego. When I moved from airplanes to backend systems, I assumed I had carried that habit across with me. I had not.

I found out from a pull request. A junior engineer took a repository pattern I had pushed across the team for two years and, on one service, replaced it with a flat set of query objects reading straight from Eloquent. My first move was to leave a comment explaining why the repository layer mattered. I had the explanation loaded before I finished the diff. Then I actually read his version. It was forty lines shorter, the tests ran faster because there was no interface to mock, and the service had exactly one consumer, so the abstraction I loved was buying nothing. He was right. I had been defending a pattern that fit the system I learned it on, not the one in front of me.

There is a real case for holding your line. A senior architect carries patterns that paid for themselves over years of incidents. When I insist on idempotency keys on every write that crosses a queue, that is not taste, that is a retried webhook double-applying a payment, a row I can still point at. Folding to every clever rewrite from someone who has not yet carried a pager for their own decisions is how a codebase grows six different ways to do the same thing. A team that can read each other's services without a map ships faster than a team of individually brilliant dialects. Sometimes "my way" is just the way already tested against production, and caving on it costs you later, at the worst hour.

So the question is not whether to hold a line. It is how to tell a tested conviction apart from a habit I have grown fond of. The two feel identical from the inside. Both arrive as certainty. The test I use now is whether I can name the specific failure the pattern prevents, here, in this system, at this load, with this team. Idempotency keys pass instantly: without them, the retried webhook charges the card twice, and I can show you the duplicate. The repository layer failed. I could name the failure it prevents in the abstract, in a system with three consumers and a planned database swap. I could not name it for one service with one consumer and no swap on the roadmap. When the justification only holds in general, what I am defending is the abstraction, which means I am defending me.

That check is doing the work the word "ego-less" usually fakes. It is not humility as a personality trait. It is something I can run against a single decision: can I attach this conviction to a concrete failure in the system being built right now, or only to systems I built before.

Try one thing the next time you are about to defend your design in review. Before you write the comment, write the failure it prevents in one sentence, in terms of this codebase. If the sentence comes out as a principle instead of a consequence in this repo, delete the comment and approve theirs.