I recently took a course in Systems Thinking through the MIT xPRO online learning program, and I found it very useful. The class gave me a good foundation on how various systems work, as well as a language I can use to broadly describe technical and non-technical systems.

I was actually able to apply some of this knowledge at work through a workshop I made up called a “System Shock”. The context of the workshop was that Q125 at Cocoon was one of the most hectic / busiest quarters in the company’s history, and as a result our EPD team was shipping a ton of projects at the same time.

With Systems Thinking, it’s always about controlling desirable emergent behaviors from the system. This means that each project, scoped and spec’d on its own, needs to ultimately work as expected with other projects, even if no one thought about how the two projects should really fit together.

The funny thing about having ~8 concurrent projects, all of which have tight deadlines, is that you tend not to think about this since you’re so locked in on completing your own project.

The workshop

So using the stuff I learned from this class, I created System Shock, which is a workshop designed to find the gaps and cracks between projects. These are the slides I shared with the team before starting.

I put a very heavy emphasis on not worrying about drawing a technical diagram, only focusing on abstract boxes and arrows to diagram out different behaviors between projects. Each box represented a project we worked on this quarter, each oval represented some foundational element of our system that could be affected (the “System Context”), and each arrow represented some way each project affected another entity in the system.

We started off with just an empty diagram of boxes, and gave a 1-min soapbox to every Project DRI to explain their project to the group. Then we spent 10-15 minutes drawing the arrows between projects.

We used Figjam to map out all of the interactions, and it was a beautiful, chaotic orchestration of thoughts. All of the text in this photo is redacted for obvious reasons, but you can see how complex the behavior of just our Q1 projects were just from a high-level point of view!

After we mapped out everything, we spent the remainder of the time (20-25 minutes) just quietly looking at the diagram of interactions, and writing down things to QA/test on the right. We were able to create a lot of tickets and assign them to the right owners.

The great thing about these tickets is that they were designed to involve two or more projects, which meant natural opportunities to learn about other projects / pair program on fixing issues together.

Was it worth it?

In the end, we figured that this exercise was highly interactive and had high engagement when we explained it well, which is really great especially considering our company is mostly remote. However, it does require some degree of follow-through to make sure tickets are assigned and completed by the right people.

I think we did this exercise a little too late in the quarter, so ideally it’s something you do as more of a pre-mortem than a post-mortem after the quarter is over. Ideally most of these cases are captured before projects are completed and not retroactively patched afterwards.

Overall, the team really loved the exercise and I’m planning on doing it more frequently in the future. If there is a better name for this exercise (because I’m sure there’s a version of this that already exists, this hardly seems like a novel workshop to me), please feel free to email me and I can add an additional note to reference it!