The tool the team lead could describe in perfect detail had been unshipped for eleven months.

They were not undisciplined. They were carrying a clear picture of a working tool inside their head, protected from every competent stranger who would have broken it in the first ten minutes. The clarity was the trap.

The team lead who knew exactly what they were building

The team lead was seven years in, senior enough to have earned latitude, principled enough to want the tool to be genuinely good before anyone touched it. Five-person team, internal developer platform. If you asked them in month three what it would do, they would sketch the architecture on a whiteboard in about ninety seconds and it would sound obviously correct. If you asked them in month eleven, they would sketch the same architecture, but the whiteboard would have more caveats on it, and their sentences would end quieter than they started.

Every sprint added one item to the polish column. Every one-on-one contained the phrase we are close, we just need to fix onboarding. Onboarding had been close to fixed for five months. Their standups had grown quiet in a way I have now seen too many times to miss.

Why the eleven-month vision was more fragile than a two-week one

A tool inside one head for eleven months is not a mature tool. It is a compressed spec that has been silently drifting against a reality nobody in the team is checking against. Every week the team did not ship, the lead's internal picture and the actual codebase grew further apart, and neither of them was being tested against a competent stranger's confusion. The team was polishing the version of the tool that lived in the lead's head, and shipping would have required admitting that version and the codebase were now different objects.

The cost was not the eleven months of engineering. The cost was that by month eleven, the lead could no longer see what the tool was originally supposed to be. They could only see the specific compromises they had made against a spec that had drifted, and they were defending those compromises to themselves in a room with no windows.

कर कटावरी तुळसीच्या माळा · Hands on Hips, Tulsi Beads Around

कर कटावरी तुळसीच्या माळा । ऐसें रूप डोळां दावीं हरी ॥ १ ॥ ॥ ध्रु. ॥
ठेविले चरण दोन्ही विटेवरी । ऐसें रूप हरी दावीं डोळां ॥
कटीं पीतांबर कास मिरवली । दाखवीं वहिली ऐसी मूर्ती ॥ २ ॥
गरुडपारावरी उभा राहिलासी । आठवे मानसीं तेंचि रूप ॥ ३ ॥
झुरोनी पांजरा होऊं पाहें आतां । येईं पंढरीनाथा भेटावया ॥ ४ ॥
तुका म्हणे माझी पुरवावी आस । विनंती उदास करूं नये ॥ ५ ॥
The line I keep returning to is झुरोनी पांजरा होऊं पाहें आतां — I am wearing away into a cage of bones. Tuka is not being poetic. He is naming a specific state that happens when a person holds a clear picture of a thing inside their head for too long without letting the thing meet the world. The vision itself starts to consume the body that carries it. And then he asks, urgently, for the meeting to happen: विनंती उदास करूं नये — do not treat this request with indifference.

A team lead in month eleven of an unshipped internal tool is in exactly this state. The unshipped-ness is not a failure of discipline. It is the observable symptom of a vision that has been unmet by reality long enough to start costing its carrier. The abhanga is a request for the collision between the internal picture and the external world to happen, quickly, before the picture itself is lost.

What I tried before I understood this

For two years I gave the same advice to every team lead in this position, and it was almost right, and it did not work. I told them to ship to twenty non-building colleagues within eight weeks. The colleague-panel approach.

The reason it did not work was social, not technical. Twenty colleagues is a real ask. It requires the team lead to interrupt twenty other people's sprints, absorb twenty streams of critique, and defend the tool while it is still visibly rough. Most team leads chose the rational response: they narrowed the panel to three friendly colleagues who would forgive the rough edges. Which produced the wrong signal, because friendly colleagues do not read the tooltip wrong. They know what the tool is supposed to do. They read the intent, not the interface.

The second thing I tried was worse. I made the internal beta mandatory at eight weeks, org-wide. Team leads complied by shipping a stripped-down version that could not embarrass them, receiving the feedback that the stripped-down version was thin, and returning to their real tool for four more months of polishing. The mandate made the theatre more expensive; it did not close the vision-to-reality gap.

The correct diagnosis was that the eight-week SLA was solving for a fear the team lead had, not for a signal the team needed. The fear was this tool is not ready for people to see it. The signal the team needed was this tool does not do what we think it does. Those are different problems, and the eight-week beta was expensive theatre that answered the first one while ignoring the second.

Ship the telemetry before you ship the tool

Here is the reframe that closed the loop for the teams I now work with. The internal beta stops being an event and becomes an instrument. The instrument goes into the codebase in week one, before the tool has any users at all, and it starts recording the moment the team lead first runs their own build.

Instrument every command the tool exposes. Every button, every keybinding, every CLI subcommand, every failure state. Ship the tool behind a feature flag to the five-person building team on day one and let them use it as their daily driver, with the instrumentation writing to a dashboard the whole team watches in standup. Not to measure them. To measure the tool.

The dashboard is not adoption metrics. It is a specific set of numbers that surface the vision-to-reality gap without requiring a single colleague to be interrupted. Time from first-run to first successful task. Number of retries on the same command within thirty seconds (the muscle-memory misfire signal). Which help-doc pages are opened and immediately closed (the docs that did not answer the question). Which flags are passed in orders the team never anticipated. Which error messages get googled by the team members using their own tool.

By week two, the team has a live picture of what the tool actually does when a competent user (themselves) hits it. The picture is uncomfortable in a way no design review can produce, because it is their own hands misfiring on their own tool. That discomfort is the signal the eight-week colleague beta was trying to buy, delivered at ten days, at zero social cost, using only the team's own daily use.

When the team invites the first ten non-building colleagues in week three, they arrive to a tool where the top five ergonomic gaps have already been fixed, because the dashboard made them impossible to ignore. The colleagues do not spend their first hour on gaps the team already knew about but had not felt urgent enough to close. They spend it on the surprises no telemetry can predict: the workflows the team never imagined, the mental models nobody on the team holds, the assumptions the docs make silently. That is the signal only humans produce, and now the team is spending human attention on it instead of on tooltip typos.

What Tuka's line means now

झुरोनी पांजरा was a specification for what happens to a person carrying an unmet vision. The prescription was collision: विनंती उदास करूं नये — do not treat this request with indifference, do not let the meeting between the internal picture and the external world be deferred. The abhanga did not specify what the collision surface had to be. In 1650 it was the sangha standing in a temple. In 2005 it was twenty colleagues on a calendar. In 2026 it is a dashboard the team watches every morning, showing them their own tool refusing to behave the way they thought it would. The vision meets the world every day at standup. The urgency does not have to be manufactured; it is on the screen.

The one instrument to add this week

Do not build the full dashboard yet. Add one metric: time from tool launch to first successful primary task, per session, per team member, logged every time. Nothing else. Post the median to the team channel every Monday morning. If the number is under two minutes and stable, your tool is closer to shipped than you think and you should invite ten colleagues this week. If the number is over ten minutes or trending up, the tool is not what the team thinks it is, and no amount of further polishing will close the gap; you need users, and you need them soon. Either way, you have replaced we are close, we just need to fix onboarding with a number that either confirms or refutes it every seven days. The picture in the team lead's head now has a co-witness.

Chetan Dhandal