Context, assumptions and why communication sucks

What a weird title. Let me unfold.

What is context in terms of systems thinking? Nothing, actually. There is no “context” in systems thinking. The context is part of the system. We just tend to pack it up, store it away and try to look at problems in an isolated way. How often have you heard or even given the answer: “it depends”? It depends on the context. Of course it depends on the context. The context is part of the problem that you try to solve.

Off-the-shelf IT solutions are taking a problem out of context, making an assumption and providing a solution for it. When you embed the solution in your system, it either fits, you have to adjust your system to fit the solution, or you need to invest to adjust the solution to your system. How often have you seen a solution actually fit? That’s why it’s good to have configurable solutions to adapt to different systems or contexts.
I have worked several years ago in a company that provided a solution with a high degree of flexibility and adaptability. Testing this thing was a pain. As we had a still manageable number of customers, we tested the individual implementations, rather than the framework. Because with every configuration possibility you increase the number of different possible implementations. So much fun! (That is sarcasm, in case you haven’t noticed.)

There are approaches to solving a problem where you break down the problem and tackle it bit by bit. And then there are context and assumptions. And then there is communication, or rather the lack of. In IT we are doing this every day. Service or micro-service architecture, multiple teams working on a product, multiple people working in a team. Different teams helping with creating a solution to one problem. That’s our daily business.

The biggest problem is communication and context. As I wrote, we store the context away. We try to solve a part of the problem in isolation. Because the rest is just context. It doesn’t matter. Neatly packed in a node in our system, marked as “context”. Assumptions are so much neater, and can even be adjusted to our solution. Guess what, in the end the parts have to fit. And when part A doesn’t integrate with part B, that’s not good. The solution for A or B can be wonderful. If they don’t fit, it won’t work. There is a strong relation between a solution and its context. Context matters! It even matters so much, that you can ruin whole projects by making assumptions.

Assumptions are made, communication stays superficial, protocols are being ignored, there are no guidelines to follow. Pure freedom! Freedom to fail!

If possible, include the context in your solution. Especially when the context sits down the hall, or is just a Slack-chat away. If you implement against a potential future customer, there is also context. But the context is on your end. When you make assumptions, state them clear. If you provide a solution for integration, create an integration guide with your assumptions. Prepare to adjust assumptions.
When you have split up creating the solution in teams of the same group or company, then talk. When assumptions are made, check back. I know that communicating with people can be terrible. And I make the best assumptions, because my assumptions are always correct. No, they are not.

Avoid assumptions, unpack the context and talk with each other!