Like any manager who is responsible for multiple teams, one of the jobs I often find myself doing is shaping how the teams work within each other and between each other.
In my head I often have a simple schematic view of the ideal setup. At one level there should be a good deal of freedom around how any group should work within itself. But when it comes to interactions between groups there should be simplicity and rigidity.
I should add that the reality is often very different to this ideal, and people who have worked with me will probably not recognise it. As I say—it’s an ideal to strive for, and it’s in my head. But it is based on an idea of two extremes.
At one extreme a small team that is stable and communicates continually can afford to have unique practices that it adjusts continually. The stabilty of the group make-up and the continuous communication allow for individuals’ to do things in a way that best suits their personal preferences, and for that to change often. (If a team isn’t stable and communicates continually I would wonder how much of a team it really is.)
At the other extreme, when there are people (or groups of people) that interact less frequently, and communication with them is less frequent, then much more reliance needs to be placed on processes that are easy to understand and change rarely.
The complications occur because people and information do move between teams often. Perhaps one team will review the code of another, or individuals will tend to move over to another team due to shifts in demand. In these cases having common processes and ways of working inside teams becomes much more important.
But in the end, where the bulk of work is what we call “knowledge work”, it’s preferable if we can structure things as much around the people, not put the people around the structure.