For teams to be really effective in a distributed setup, devolve responsibility to smaller units where possible. If everyone’s asking everyone before taking every single decision, it creates noise in the system. This is model A in the above diagram. A better model; model B above; is to create smaller decentralised pods inside the team. These pods can be as small as two people and no larger than four people. Here are some characteristics of effective pods.

• Align the pods to an outcome. It could be to deliver a feature or an epic. 

• Nominate a directly responsible individual (DRI) for each outcome. This person is a “first amongst equals” (FaE) and can help take tough calls for the pod in case it comes to that.

• Pods operate autonomously and the larger team encourages each pod to make their own decisions with help from their DRIs. 

• To encourage knowledge sharing and to bust silos, keep the pods short-lived. When you achieve the outcome, disband the pod. Any longer than a month and you should question the existence of the pod.

• Apart from the DRI, you can rotate people across pods even before delivering the outcome, if that’s something you want to do. While more people will be able to engage with the corresponding part of the codebase, you may lose the benefits from expertise and continuity.

• Radiate information across the team so everyone’s up to speed with what’s happening on each pod and so you don’t create walled gardens of information.

So now if you really need help, you have a smaller, more focussed group of people to reach out to. The result - lesser noise and fewer interruptions in the system.