#23: SystemOps
On building the organisational architecture for systems work.
I’m Luke Craven; this is another of my weekly explorations of how systems thinking and complexity can be used to drive real, transformative change in the public sector and beyond. The first issue explains what the newsletter is about; you can see all the issues here.
Hello, dear reader,
tl;dr: SystemOps is an approach to building organisations that enable their people to think and work in systemic ways. As more organisations emerge that frame their work as systems or complexity practice, we will need more SystemOps.As I’ve written before, it is really easy to get people excited about complexity and systems thinking. It’s much harder to turn that excitement into real, enduring change. The challenge for all systems practitioners is to shift and reimagine the institutions in which we work to enable more systemic and complexity-friendly practice.
If, like me, you work in a design-related field, you’re probably familiar with the term DesignOps. DesignOps is an umbrella term for work that aims to build strong design teams and enable them to thrive; orchestrating and optimising the processes that shape how teams work, collaborate with others, and deliver value. Large design-led organisations (like AirBNB or Atlassian) typically invest in established DesignOps teams to embed these practices at the enterprise-level.
Recently, I’ve been thinking about how organisations that do systems practice work probably need to invest in SystemOps. The aim of SystemOps, much like its namesake, is to orchestrate and optimise the constraints that enable people to think and work in systemic ways.1 SystemOps practitioners create, collect and connect different constraints to produce an organisational architecture for systems work. There are obviously many elements that go into building this architecture and the shape of SystemOps will and should look very different from one organisation to the next. But my experience is that there are some common challenges that SystemOps needs to focus on to be successful:
the relational challenge: how should the individual parts (individuals, teams, functions, activities) relate to each other, in the context of the whole? This includes things like how people organise, how they collaborate, how decisions get made, and what it means for people to be held to account for the decisions they make.
the learning challenge: how should reflection, learning and continuous improvement be enabled and embedded in different processes, systems and partnerships? This includes things like how projects are governed to enable experimentation and failure, how learning is supported at each level of an organisation, and working to build a culture of measurement that encourages flexibility and agility.
the strategic challenge: how should we ensure that an organisation is focused on the right things at the right time? This includes things like how risks are assessed, how investment and activity are prioritised, and how strategic choices are cascaded through an organisation.
These are three lenses I use to enable different SystemOps conversations. While I find it useful to separate them, they support and reinforce each other. The right kind of learning environment can enable the right kind of strategic choices, for example, just as the right relationships can support engaged learning and reflection. All of this will look different depending the size and focus of the organisation in which you work. I approach this as a leader in a large systemic design team, but I draw inspiration from other pathbreakers in this space, including Lankelly Chase, TACSI, and the Plymouth Alliance, among many others.
In each of these examples, SystemOps is as much a mindset as it is a defined role for an individual or team. Anyone can benefit from recognising the need to orchestrate and optimise the constraints that enable people to think and work in systemic ways. At the same time, as more organisations emerge that frame their work as systems or complexity practice, I expect that defined SystemOps roles will become more common. While we wait, there are still some big questions to answer: What could these roles look like in practice? Which of my four systems strengths would people need to fill them? How might we approach SystemOps as its own systemic design challenge? If these are questions you are interested in, please let me know! 🙏
Not unrelated miscellany…
The good folks at Human Learning Systems are releasing their next report, which they will be launching at this webinar on June 17. Head along to hear from practitioners on how they have been using the Human Learning Systems approach to transform the way in which they work.
Mat Walton (first profiled here) has recently published a new paper that explores how critical systems thinking can be used to support collaborative practice, drawing on three case studies from a New Zealand public health context.
Collaboration for Impact are hiring a Network Weaver to support their work in social impact. The role will connect, convene, catalyse and coordinate a network of passionate change makers to maximise their impact on some of Australia’s most complex problems. Sounds like a SystemOps role to me…! 😝
By the way: This newsletter is hard to categorise and probably not for everyone—but if you know unconventional thinkers who might enjoy it, please share it with them.
Find me elsewhere on the web at www.lukecraven.com, on Twitter @LukeCraven, on LinkedIn here, or by email at <luke.k.craven@gmail.com>.
Dave Snowden’s most recent publication, the Field Guide to Managing Complexity, includes a typology of constraints that I have found useful in imagining what SystemOps could be. The field guide outlines a number of different types of constraints, including governing /enabling, internal/external, connecting/containing, rigid/flexible/permeable, and dark. Some of Snowden’s earlier thinking on constraints and scaffolding is available here, here and here.