Team Norms Need Redesigning When the Context Changes

Working agreements tend to be written once, when a team forms, and then outlive the structure they were written for. A team of six sharing a channel and a calendar needs little more than a few habits about interruptions, code review and who decides what, and those habits hold because everyone carries the same context, which is also why nobody thinks to write them down.

Growth changes the context before it changes the habits. Once an organisation moves from one team to several, Team Topologies offers a useful vocabulary for what each pair of teams now needs from the other: collaboration, where two teams work closely for a limited period to discover something together; X-as-a-service, where one team consumes what another provides with minimal interaction; and facilitating, where one team helps another build a capability and then steps back. I find that each mode implies a different set of behaviour rules, and a team that applies the norms of one mode to a relationship in another pays for it in friction that tends to be read as personality.

Take the norm of answering any question immediately, which suits collaboration and is a generous default for a young team. Applied to a platform team serving a dozen consuming teams, the same norm turns every engineer into a help desk and lets the platform’s roadmap be set by whoever asked most recently, while the consuming teams, having learned that asking directly gets results, never develop the habit of reading the documentation that would shrink the queue.

Tuckman’s stages (from an earlier article) are often read as a path a team travels once. A change of topology, even with the same people in it, tends to return a team to forming, because the relationships that define its work have changed, and storming follows when the old norms meet the new relationships. Teams with a high degree of trust can pass through this quickly enough that it barely registers, but leaders who expect a team to carry on performing straight through a reorganisation are often surprised by a dip that is the predictable cost of re-norming.

One practical consequence is to treat a change of topology as the trigger for revisiting working agreements, rather than the calendar. The conversation can be short, and I find it most productive when it names the interaction mode between each pair of teams before discussing any individual rule: which relationships need availability, which need a contract, which need an agreed point at which one team steps back. Written down, those rules give the next reorganisation something to be measured against.

The leverage point is different for every team. Finding it is the work.