Chai Breaks: The Secret Ingredient for Teamwork in South Asian IT — Epoche B2
A daily ritual, and what it actually does At ten past four every afternoon, roughly fourteen people from our software team go down three floors to a tea stall by the gate of our building off Sarjapur Road in Bengaluru, and stand there for fifteen minutes. Nobody schedules it. The stall charges twelve rupees for a glass of tea and twenty for a filter coffee, which in this city is a real choice and not a formality — the pantry upstairs is permanently divided between the chai drinkers and the kaapi drinkers, and the argument is older than the company. From the outside it looks like fifteen minutes lost. Having watched it for three years, I think it is the most productive quarter of an hour in our day, and I want to be precise about why, because the reason is not the one people usually give. I should be precise about the strength of that claim too. I have not measured anything. What I have is a tally of specific problems that were resolved on the steps and that I can trace, and the number is small enough to count on two hands over three years. Nothing below establishes that the break causes productivity; what the rest of this essay tries to do is identify the conditions under which the useful exchanges happened, so that someone can judge whether their own office has them. How it started It began as an instruction rather than a custom, which is worth recording because it means the thing can be created deliberately. We were four weeks into a delivery for a client in Frankfurt. The daily standup — the short meeting agile software teams hold each morning, in which each person says what they did yesterday and what they will do today — had degenerated into a sequence of status reports delivered to the team lead. And two sub-teams had quietly built the same input validation logic twice, which is the characteristic symptom of a team in which information travels vertically and not laterally: both groups had told the lead what they were doing, and neither had told the other. Our team lead, Priya, put a fifteen-minute break in everyone's calendar at 16:10 and asked us to take it together. Half of us thought it was a morale exercise of the kind that gets announced and then dies in a month. The first mechanism: who talks to whom What the break does, before anything else, is change the pairs of people who speak to each other, and the reason that matters is structural rather than sentimental. In a standup you report upwards, and you report finished work. On the steps outside the tea stall you complain about unfinished work, which is far more useful, because unfinished work is the only kind anyone can still help with. An example I watched. Rohan, who looks after our database, mentioned on one of these breaks that a particular query was taking eleven seconds and he could not see why. Aisha, who works on the front end and had never been in a meeting with him, said she had hit the same thing on a previous project and it had turned out to be a missing index. It took her forty seconds to say and it saved him most of a day. The size of that effect is not a matter of opinion, and it is worth spelling out because it shows why one sentence from the wrong department can be worth a day. Without an index, a database answering a query that filters on some column has no choice but to examine every row in the table: the work grows in proportion to the number of rows, $n$. An index is a separate sorted structure — in practice a B-tree, a shallow, very wide branching tree — that lets the engine find the matching rows by descending from the root, so the work grows in proportion to $\log n$ instead. For a table of ten million rows, $\log_2(10^7) \approx 23$, meaning the engine follows roughly twenty-odd steps rather than reading ten million rows. That is the difference between eleven seconds and a few milliseconds, and it is why the fix is invisible until someone names it: nothing in the query is wrong. The reason the useful sentence came from a front-end developer rather than from another database engineer is the part that generalises. Mark Granovetter's 1973 paper on weak ties is usually summarised as "acquaintances are useful", which loses the argument. Granovetter's evidence came from professional and technical workers in Massachusetts who had recently changed jobs: among those who found the job through a personal contact, only a small minority had been seeing that contact often, and most had seen them merely occasionally or rarely. His explanation is structural. Strong ties tend to close into triangles — if you are close to two people, those two are very likely to be close to each other — so strong ties cluster, and everyone inside a cluster is exposed to broadly the same information. It follows that a strong tie can almost never be a bridge , the only path between two otherwise unconnected groups. Bridges are made of weak ties, and non-redundant information can only arrive across one. Applied here: Rohan's close colleagues are the other back-end engineers, who had already looked at his query and seen what he saw. Aisha was in a different cluster, which is precisely why she held something he did not. Ronald Burt later reframed the same geometry from the individual's side, calling the gaps between clusters structural holes and arguing that the advantage goes to whoever spans them. A tea stall is a cheap machine for making people stand next to someone across a structural hole. That exchange could not have happened in a meeting, because nobody would have invited a front-end developer to a database discussion — the invitation list to a meeting is drawn from the cluster, which is exactly the wrong sampling frame. The second mechanism: things that were never said aloud The second effect is slower and harder to point at, and it is not about non-redundant expertise but about ordinary facts that nobody thought to state. Two of our QA engineers spent a month unable to align their test cycles, which everyone treated as a scheduling