Causal Loop Diagrams For Understanding Organizational Dynamics

Just last week I spoke at two conferences on Organizational Complexity and Its Effects on Scaling.

The talks went pretty well and I ended them up presenting three most commonly seen (by me) team structures that create an "interesting" dynamics.

Here they are:

This one is seen very often in gaming companies.

There is absolutely nothing wrong with reusing an engine (platform), that's actually a great idea. What I'm talking here is about the managerial decisions on forming teams around these architectural layers.

In this case a set of consumer-facing teams will be building "their" features (products) on top of a shared platform "owned" by another team (teams). If this is your case, you often hear terms like: "engine teams" or "platform teams" or sometimes "system teams".

It is exciting (for a system thinker) to observe how unaligned those two types of teams can be. How much information needs to be handed over from the consumer teams to the platform teams to get "their" back-end part right. How much over-processing and over-production can be created on the back-end side. And how hard it is at times to get the whole thing fly to production, once all teams say "we're done!"

Beware of the system dynamics such structures create.

This is a very common example for so-called "web" companies that had emerged in the pre-mobile era, had built their product(s) on web and later on then started the mobile adoption.

For such companies it is not uncommon to create the pure "mobile teams". And with a good intend: hard focus on mobile technologies, fast delivery of the apps, separation of responsibilities, reusing existing "ready" APIs... There are many good intentions why to separate the mobile teams form the rest of the "old" organization. And the road to waterfall is paved with them.

In such setting you often hear terms like "mobile teams", "iOS teams", "Android teams", "web teams", "API teams" - such names being used to identify specific teams, backlogs, product owners, roadmaps. As of course it is rational to let each of those teams do their own "scrums".

Guess, how flexible, rapid and agile such a constellation is when suddenly you need to launch a new product on both platforms: web and mobile!

Beware of the dynamics such locally optimized constellations creates.

And lastly, this. The company embraced the idea of "full-stack", "feature" development teams - where each teams has all required specialization to be building the product features end-to-end.

But since the product is huge, it is of course rational to try simplifying the complexity by the old roman principles: divide and conquer. Anyone seen Romans recently?..

Indeed, it does feel right to break up a huge product into areas - that small that each can be "managed" by one product owner with a small development teams. Then each team has its easy-to-facilitate planning, review and a retrospective meeting. A ScrumMaster can be fully dedicated to the team and everyone is fully focused...

...Focused on a small piece of an overall big picture that no one is able to grasp anymore. The company turns into an unassembled puzzle. And it takes several layers of managers to start seeing the bigger picture... That's often an illusion of management, because no one is capable of understanding an unassembled puzzle.

Be ware of the dynamics your rational decisions create.

Among the many thinking tools, there is one called "Causal Loop Diagrams". Or the CLDs.

It is a way of modelling dynamics of a system through "variables" and their "relationships". The next illustrations should give you some high-level idea:

Modelling is a powerful way to get engaged in meaningful discussions.

And we all know from Alistair Cockburn's insights that no other way of communication beats several people talking while sketching on a whiteboard:

So, you wonder how you can get "you management" reconsider the structural decisions they have been making? Mobile teams, platform teams, small-product teams... That's hard and everyone needs to have her own epiphany to change her mind.

This takes time. But this as well can be facilitated and hopefully speed-up. For example, why not running an small in-house workshop with your decision-makers to let them explore some of the dynamics at play?

You don't have to call it a "system dynamics workshop" as this can scare mindfulness out of some of your people. Call it a retrospective. Call it a beer game. Call it anything you want. The goal is to get people talking about meaningful stuff.

The CLDs (or any other system thinking tool you know) might be of your great helpers.

As well as some food and beer to follow.