Shared Understanding Takes Work

Together with Ivan Udovin, I helped coach So Stuffy, a competitive programming team. In these competitions, participants solve algorithmic problems and implement their solutions in code. Part of my work was helping a participant explain an idea clearly enough for a teammate to program it. Disagreements within the team also needed attention.

That experience gives me a simple question to ask: once one person has understood the solution, what has everyone else understood? There is work between an individual's insight and a result the team can produce. It is easy to overlook that work when the person with the idea already sees how everything fits together and regards explaining it as a formality.

Imagine that one participant has worked out an algorithm. Another is ready to write the code but does not understand why it will work for a particular valid input. The first repeats the explanation more briefly and with greater confidence. The second is no closer to understanding. Both are capable, but a necessary part of the reasoning still belongs to only one of them.

It is tempting to judge their abilities: one cannot explain, or the other is slow to understand. I find it more useful to locate the point where their assumptions diverged. Perhaps the person proposing the algorithm checked the disputed case mentally and omitted it from the explanation. Perhaps a term means something different to each of them. Confidence will do little to resolve either problem.

Once you have found an answer, the intermediate steps can become hard to see. Explaining it requires recovering part of that path. The listener needs room to stop you at a point that no longer feels difficult to you. Their question may also reveal a real gap in the idea. In that case, explaining helps both people improve the solution.

The aim is enough shared context to continue the work and examine an important assumption. People can contribute different kinds of expertise without knowing every detail of one another's work. Different approaches are useful when people can explain what they depend on. Shared understanding makes those differences available to the team.

I use a similar standard for discussions in development teams. Does a colleague know what they can decide independently after the conversation? Do they understand when the agreement will stop applying? A nod at the end of a meeting does not establish either. I learn more when someone describes their next step and explains why they intend to take it.

A manager can be tempted to become everyone's permanent interpreter. Every disagreement comes back to them, and work pauses until they intervene. That can feel like evidence of their importance. I see it as a reason to examine how the team shares context. Some of what people need may be concentrated in one person's head.

Helping can mean working through a specific misunderstanding together and leaving an explanation others can use. Sometimes a shared example is enough. Sometimes a term needs a more precise definition. The useful result is that participants can handle the next similar question themselves.

Discussion also needs a stopping point. A team can agree on a small action, carry it out, and see where expectations differ. Doing something together tests understanding and helps distinguish useful clarification from a conversation that no longer changes the work.

I count the time spent explaining as part of the team's work. It pays off when people can proceed without a permanent intermediary. At that point, one person's strength becomes something their teammates can actually use.