The Architect Who Would Not Let Go

Identity-welded ownership of a system prevents the system from evolving past its builder.

The hook

Three months ago I sat in an architecture review that lasted 90 minutes and produced zero decisions. The system in question was a payment reconciliation service, built in 2021 by a principal engineer still on the team. It works. Fourteen million transactions a month. But two staff engineers had a solid proposal for what comes next, and the person who built the original would not stop saying "my design."

आहे ते सकळ कृष्णाचे अर्पण · All of This Is Already Offered to Krishna

आहे ते सकळ कृष्णाचे अर्पण । न कळतां मन दुजे भावी ॥
तुका म्हणे काळे चेंपियेला गळा । मी मी वेळोवेळा करीतसे ॥
Everything already belongs to the whole; but the ego, without realizing, keeps claiming "I, I" repeatedly, and this claiming is the chokehold that kills.

What I keep seeing

The product roadmap now requires multi-currency support, real-time settlement visibility, and integration with three new payment providers: Adyen, Checkout.com, and a domestic UPI aggregator. The current architecture, a monolithic Kotlin service with a single PostgreSQL database and a rigid state machine, cannot accommodate any of these without significant surgery.

The two staff engineers proposed something reasonable: decompose the state machine into an event-sourced model using Kafka, extract provider integrations into separate adapter services, move settlement calculations into a dedicated stream processor. They had capacity estimates, a migration plan, and a rollback strategy. Solid work.

The principal who built the original spent the entire review explaining why the existing architecture "already handles this." Every objection started with "but my design accounts for..." or "when I built this, I specifically..." The possessive pronoun did a lot of work in that meeting. I have been that person, by the way. Early in my career I held onto a service I designed well past the point where it needed to change, because letting it change felt like admitting the original was wrong. It was not wrong. It was done.

The mechanics

Systems have a natural lifespan determined by the assumptions baked into their original design. A payment service built in 2021 assumed a single currency, a single payment provider, and batch settlement windows of T+1. These were not mistakes. They were correct constraints at the time.

But assumptions calcify into architecture. The single-currency assumption lives in the database schema: amount stored as a BIGINT in paise, no currency column. The single-provider assumption lives in the state machine: states named after the provider's specific webhook events. The batch settlement assumption lives in the cron job that runs at 2 AM IST. Changing any one of these requires changing all three, because the assumptions reinforced each other during the original design.

This is normal. Every system accumulates assumptions that eventually stop matching reality. Kent Beck's formulation is clean: "Make the change easy, then make the easy change." The question is never whether a system needs to evolve. The question is whether the people around it will let it.

Where Tuka comes in

Tukaram's abhanga is not about generosity. It is a mechanical diagnosis. Everything already belongs to the whole (आहे ते सकळ कृष्णाचे अर्पण). The system was always the org's, not the architect's. The engineer did not create it from nothing; they assembled it from the org's requirements, the team's labor, the infrastructure the platform team maintained. The possessive claim was never accurate. It was a story the ego told.

The second line is the cost of that story: "मी मी वेळोवेळा करीतसे" (saying "I, I" again and again). Tukaram calls this काळे चेंपियेला गळा: death's grip on the throat. The architect who cannot release ownership of the design is strangling the system's ability to breathe. The system does not die from external pressure. It dies because the person closest to it will not let it change.

What I would actually do

Rotate system ownership every 18 months, formally, in your team's RACI chart and on-call schedule. The engineer who designed a system should not be the person who approves its successor; they should be a consultant, not a gatekeeper. When you run an architecture review for a system older than two years, the original architect presents the current constraints and then leaves the room for the proposal discussion. Their input is historical context, not veto power. This will feel disrespectful to senior engineers who take pride in their work. That discomfort is the point. The system belongs to the org, not to the person who typed the first line of code. Every "but my design" is a hand tightening around the throat.

Chetan Dhandal