Michael argues that achieving the desired business outcomes hinges upon the interactions between five sub-systems:
Org Structure – the structure of power and authority to facilitate decision making
Incentive Systems – rewards for individual and group performance
Work Systems – how people get work done in the organization
Collaboration Systems – systems to overcome the friction to collaboration introduced by the org structure
People Systems – hiring, firing, development, HR systems – both tactical and strategic
This perspective strongly resonates with me, and looking at various organizations through this lens reveals a very interesting opportunity. In many organizations, these systems are managed in one of two ways:
Either in a completely grassroots, ad-hoc, organically evolving manner. (the Shadow IT phenomenon comes to mind)
Or in a completely top-down manner, being wholly owned and operated by a functional department (IT, HR, etc.) with sole authority to make changes to the system.
Neither of those approaches work well. While the former often leads to increased variability and complexity that poses massive constraints on scaling the systems, the latter often leads to stale, disjointed systems with very limited flexibility and adaptability. In both cases, over time, the systems become less effective in driving the desired business outcomes.
If you are a software developer, this may start to sound all too familiar. Because, the problems the exist in organizational systems and the way they are managed, are very similar to problems the exist in software systems and the way they are managed.
Fortunately, this also means that we can draw on the parallels in the software world for potential solutions, to enable the broader community of employees to contribute to the on-going evolution of these systems while at the same time, not jeopardizing their structural integrity and effectiveness.
Enter the role of a “system architect”, as the good folks at Spotify describe it (they call it a “system owner”):
“The System [Architect] is the go-to person for any technical or architectural issues related to that system. He is a coordinator who guides people who [modify] that system to ensure that they don’t stumble over each other. He focuses on things like quality, documentation, technical debt, stability, scalability and [change management] process. The System Architect is not a bottleneck or an ivory tower architect. He does not personally have to make all decisions, or [make all modifications], or [handle all change management efforts]… We also have a Chief Architect role, a person who coordinates work on high-level architectural issues that cut across multiple systems. He reviews development of new systems to make sure they avoid common mistakes, and that they are aligned with our architectural vision”.
One of the key challenges with adopting this systems approach to the various organizational components, is that it significantly raises the bar for the role that the “traditional” owners of those systems are expected to play in the ongoing evolution and management of those systems. However this, in my mind, is an investment that is well worth making.