Autonomy and alignment

To butcher a proverb: “go fast alone; go far together”

We talk a lot about “breaking down silos”. I’m not sure it’s such a great analogy given silos exist to keep things separated for good reason. Even if we mean “break down the barriers between parts of the business that need to work together,” I’m not sure it’s much better. In my experience at least, a better analogy is to “bridge the gap,” between different parts of the organisation.

I’d say we routinely conflate “autonomy” with “independence.” If truly independent teams are possible, then it’s likely we have either mostly seperate businesses, or people duplicating efforts working on undifferentiated capabilities that could be outsourced or bought off-the-shelf altogether.

If you’ve ever integrated with a 3rd-party, you’ve encountered a truly independent team. No doubt in doing so, you’ve either had to modify your own processes to match theirs, or paid through the nose to have them modify the system to meet your needs and the whole thing has taken a lot longer than anticipated.

Whether we call them silos, or autonomous teams, or independent parts of the business, my observation is that people create these structures in an attempt to go fast. There is a great fear that collaboration will lead to dependencies and then everything will grind to a halt. I’ve watched people and businesses go to extraordinary lengths to keep teams separated and avoid slowing down. And it works. The problem is, that it only works for a while. Eventually, things ironically start to slow down.

At the point at which things start to slow down, the reflex is to presume there are inefficiencies creeping in. That its an execution problem. That too much of your precious, expensive resources time is spent planning, collaborating with other teams, and generally not enough time spent delivering.

The next step is introducing delivery managers or project managers to remove all that “overhead.” Specialist roles dedicated to intermediating in order to keep the bulk of the teams separated, independent, and above all, on task and moving fast! Before you know it you have a Project Management Office ("PMO").

I’ve also seen the next step be to collapse all teams into one, large monolithic team swimming in information and cognitive overload. People treated like fungible resources moving from one task to another. Like a PMO, it looks great on paper and might even work out while you’re working-through some very obvious, pre-defined backlog. But like silos and like project manager setups, eventually you’ll start to slow down.

Both ends of the spectrum have upsides and downsides. The question is then, how do we help people and teams build domain expertise, feel and be empowered to make decisions, reduce (not eliminate) dependencies, manage the cognitive load, create opportunities for movement between teams, develop trust and safety to experiment and fail, all pull in the same direction, and go as fast as possible?

Im my experience, it’s not that complicated but it’s hard work because it relies as much, if not more, on behaviour as it does on structure. We foster shared identity, culture, and practice; we train and empower boundary spanners who can bridge the inevitable gaps that appear between teams; we nurture long-lived teams who can build expertise in coherent, bounded domains; and we use dynamic teaming principles for agility and contribution where and when it matters most.

Autonomy shouldn’t be measured by the amount of collaboration required. Autonomy is more about a team’s ability to commit to doing substantial work while minimising the number of other teams who also need to commit to doing substantial work.

Counter-intuitively, increased collaboration leads to shared understanding, identification of blind spots. More collaboration often results in a reduction in near term scope that can actually overcome the need for your collaborators to commit to substantial work. Proactive, constructive collaboration reduces harmful dependencies and leads to more, not less autonomy.

Right sizing teams, aligning them to business outcomes, and keeping them all rowing in the same direction is non-trivial. But the antidote to silos isn’t a monolithic team, and the antidote to a monolithic team isn’t micro teams either.