Independent Executors
Jade Rubick here describes the Independent Executors pattern for team organisation. It strongly reflects how I like to think about team independence, autonomy, empowerment, and collaboration. A key quote describing the way independent executors operate is that they "ask, but never expect other teams to do work for [them]". Let that sink in.
When an organisation operates as a maze of dependencies between work-in-progress parallelised across many teams, the dependencies take control, and communication between teams devolves into priority haggling, instead of being about delivering the actual work. That slows everything down, sometimes grinding to a halt. If teams are set up as independent executors instead, they know full well where there are dependencies, and they know how to resolve them using their own means if the team they depend on cannot do it. This, too, can be seen as slowing things down, but the "grinding to a halt" bit won't happen. It also means that deadlines don't work, because they may all too often just assume that all dependencies will be resolved by others' delivery.
Of course, this means a more holistic approach to planning the work in teams, and requires greater expertise (seniority) in team members that need to have more than just an idea of what that other code base is doing. That can also be less than ideal, as any sufficiently complex software architecture will tell you. The independent executors model cannot just be imposed on unsuspecting teams struggling to operate in a complex environment.
Taking yet one step back, what is needed from the environment to enable teams to operate as independent executors? In one word: clarity. In some more words: clear priorities that just make the answer to the question of which project is currently the most important one completely obvious. Any team that directly contributes to that most important thing is guaranteed to get support. Any team that cannot directly or indirectly support that project can either resolve the dependencies on other teams for itself, or focus on its tech debt, take some training, or whatever. Not to forget, no team not currently contributing to the "most important thing" can be expected to deliver to any deadline (self-imposed or externally given) that involves relying on dependencies. Essentially, this is the approach using thematic goals, defining objectives, standard operating objectives, and measurements (straight from Lencioni).
Providing that clarity takes courage, from the top. It's a leadership responsibility. Period.
Tags: work