I was thinking, since I’ve done some work on a few systems, that I should capture some notes. Guidelines really since I plan to create a few more :)
Here is an example of one system I recently created: Lean startup methodology applied to successful enterprise technology adoption
So here are the notes in summary, in the doodle at left, for easy reference.
Below I’ve added a few points in elaboration.
This is just a very simple take on the things I think that matter. As you can see I scribbled them down on a whim in one of my favourite apps: Paper by FiftyThree.
Before I elaborate on the notes, a few words on systems. Systems thinking is not new and nor is it entirely clear what it is. Just look at the Wikipedia entry on systems thinking to see the myriad sources and references in the article.
So for the purposes of this post I see it as the combination of guidelines that govern a broad base of activities and outcomes and the thinking that goes into making this effective.
1. Outcomes/strategy over process
Key for me is not to get bogged down in the process part. Make it as simple as possible. The more complex the environment or activities the more steps the process will need but should have no more than necessary. Things to focus on is the main purpose, strategy and the outcomes you wish to guide achievement of.
2. Behaviour over technology
Technology and process (the latter already referred to in 1 above) are key components of systems but people, the third, is probably the most important. It’s also the least controllable and therefore the one that requires the most attention. And when it comes to people, it’s their behavious we want to be most attentive to and how to work with them or mould them.
3. Loose principles not rules
Ties in a little with point 8 but worth separating. What I mean here is that it’s important that your guiding principles are open to change. Just as the system should guide iterative thinking (see point 4) the system itself should be open to changing from learning what works and doesn’t. Rules can be put in place but they should not be hard and fast, hence the preference for loose principles.
4. Fail fast and learn
I would steer clear of this practice if it verged on the unethical or being done without the right intentions (good points here on that: Why Silicon Valley’s ‘Fail Fast’ Mantra Is Just Hype). But I do totally believe that a system should allow you to reach points of awareness as quickly as possible about what is not working, so you can abandon the practice and learn from it.
5. Build feedback loops
This ties in with the previous point about learning. The system should have mechanisms that allow you to learn about what is working or not as soon as possible. This is as much about measurement as about capturing learning in effective and shareable ways and then passing that on to all concerned.
6. Be visual and brief
I’m a big fan of design thinking which almost by definition requires some visual element. I’m also a huge fan of doodles to capture insights and share and simplify the complex easily. I just think in this day and age of attention deficit, that drawings and infographics that are effective (no mean feat) are more able to convey critical information than reams of documentation. Ideally they work in tandem, a little like this post. Keep this in mind when capturing your system.
7. Interdependence
No part of a system really works independenly of other parts. All are connected in a web of productivity. Some elements may be two or three steps removed from the other but there should always be awareness of what the levers of interdependence are and how all the parts go to making an effective whole. Systems thinking is after all about holistic thinking.
8. Descriptive not prescriptive
Again this is about not beeing too hard and fast about the behaviours you want your system to guide. The more it describes ways of tackling activities where the user is given freedom to create his or her own optimal path the better. Unless there is a particulary structured or routine activity where it is critical for it to be repeated precisely for quality purposes, you should leave openings for interpretation of different approaches.
Hope this is useful and happy systems building :)