Tag: systems thinking

Context is the System – What AI Prompting and Systems Thinking Have in Common

There is a quote I want to come back to, from Elisabeth Hendrickson:

“The word ‘context’ is shorthand for the cumulative effect of all the past decisions that we cannot change now.”

Lately I’ve been thinking about it from a completely different angle. Not in the retrospective sense of “how did we get here”, but in a prospective sense. What context do I need to provide, so that someone, or something, can make a good decision going forward?

That someone, in this case, is an AI.

Vision – Mission – Capacity – Learning

If you interact with a human colleague, the VMCL model describes the layers of context and information a human has, that you don’t need to include in your communication.

I mentioned in earlier posts the VMCL model from Drs. Cabrera. Vision, Mission, Capacity, Learning. On a larger scale this context is the vision. On a slightly smaller scale this is the mission, what is the next step towards reaching the vision. Capacity is the next smaller scale for the context, what do I need to do now to fulfill the mission. And Learning is the continuous feedback loop. To understand if we have the right capacity to fulfill the mission. If the mission is on track and if it’s still the right mission, and where are we in our vision?

What information do I need to provide for someone, or something, to fit my V, M and C?

When providing instructions to a human colleague, they have some level of V, M and C already and can decide based on this context. An AI has none of that shared context. Which is exactly the problem.

Throwing the Problem Over the Fence

When people start using AI tools, the typical first instinct is to just type the problem. Short, direct. “How should I structure this service?” or “What’s wrong with this test?”

And the AI responds. It always responds. And it’s not wrong. It’s just… generic. Because it has to be. It knows absolutely nothing about you, your system, your team, your constraints, your past decisions. All it has is the few lines you gave it. In case of coding agents, it has access to the code base and construct more context out of that.

You threw the problem over the fence, without providing much or any context. And now you expect wonders.

Enter Systems Thinking

In Systems Thinking, one of the first exercises when analyzing a situation is a Context Scan. You put your situation in the center and ask: what is around it? What is part of the picture even if it doesn’t seem obvious at first glance? Zoom out and see relations on a larger scale.

The idea is that you cannot understand an element without understanding the system it lives in. A microservice is not just a microservice. It is a piece of software with a team behind it, a deployment pipeline, a set of consumers, a data contract, a history of decisions, and constraints coming from outside. Take it out of that context and it becomes something generic and probably useless. Put it back in, and suddenly it becomes specific, with all its quirks, trade-offs, and necessities.

An AI has no idea about any of that. Unless you tell it.

Context is the System Prompt of Reality

When you provide context to an AI, you are essentially describing the system the solution has to live in. You are not just giving more information, you are drawing the boundaries. You are saying: here is what is relevant, here is what is not. Here are the actors, the constraints, the goals. Here is what we tried before and why it did not work.

Compare these two prompts:

“How should I structure my Auth module?”

vs.

“We run a multi-tenant SaaS platform, currently Auth is part of a Django monolith. The team is four engineers, experienced in Python and some Go. We want to move towards service isolation but have no dedicated platform team and limited ops capacity. What are realistic options for extracting Auth?”

Same question. Completely different answer. Not because the AI knows more, but because you have described the system and its constraints.

What Context Actually Means Here

Not every detail matters equally. The useful context dimensions for technical prompts are similar to what you would map in a Systems Thinking exercise:

Boundaries/Distinctions – What is in scope, what is not. What constraints are non-negotiable? Elements – What does your current system look like? Tech stack, team size, existing components? Relations – What depends on what? What would break if you changed this? Perspectives – What is the goal here? MVP, production-critical, proof of concept? Who is the user of this solution?

Sound familiar? It should. It is basically a light-weight systems analysis, just expressed as a prompt.

The Cost of Missing Context

Without context, the AI optimizes locally. It gives you a solution that looks fine in isolation, but might be completely incompatible with your situation. You implement it. Something doesn’t fit. You prompt again. The AI corrects. Something else doesn’t fit. Rinse, repeat.

This is the fixes that fail pattern from Systems Thinking. Local interventions that create new problems elsewhere, because the broader system was never part of the picture. You end up spending more time in a feedback loop than if you had taken five minutes to describe the situation upfront. Even then, some iteration is most probably inevitable.

This is Not New. You’ve Done It Before.

Any experienced engineer does this instinctively before making a decision. They ask about the context. What is the load? What is the team’s experience? What is the timeline? What have you already tried?

They don’t jump to a solution. They build the mental model first. That is Systems Thinking in practice, even if nobody calls it that.

When working with AI, the same principle applies. The model is not going to ask you follow-up questions unless you set it up to do so. You need to front-load the system description.

Set up your AI agents to ask for more context before they start. Like with every tool, the context makes it more useful.

The System of a Button

Buttons are all over the screen I’m looking at. There will be buttons on the screen you read this. There’s buttons in your house, in your car, everywhere. And every button is more than just a button. A button is a complex system. “Come on, now you exaggerate!”, you might say. Let me explain.

A button has a purpose. When you press or click the button, something should happen. From the action of pressing the button, follows a reaction. Or rather more than one reaction. The button should trigger some expected behavior of the system that it is a part of. The person pressing the button has the reaction that triggers an expectation of something to happen.

How quickly does the reaction happen? Is there some sort of feedback expected? Pressing a button that turns on a device like a light bulb, the reaction should follow instantly. Sometimes the reaction of the attached system is delayed. Does the user know about this? Does it trigger a behavior of the user to re-press the button? What happens when the button is pressed again?

The existence of the button alone creates this expectation. When I press this button something happens. Either we know exactly what happens, or we don’t know it. A button clearly marked as “on/off” sets the expectation when pressing the button (action) the attached device is turned on or off (reaction).

Also the button has a reaction to being pressed. A feedback, some haptic feeling to it. Even virtual buttons are often designed to give some sort of feedback. The user interacting with the button expects not only a reaction of the button being pressed or clicked, but also some kind of feedback that the pressing of the button has happened successfully. If you have ever touched a screen with a flat static button behind it, where there is no feedback at all, you don’t know if you have touched it or not.

A button also has a distinction. You can usually tell what the button is and what it is not. The big red thingy is the button, everything around is not. Is it fitting in the vicinity? Does the color, size and form fit the system? Is the button clearly marked as what it does?

In IT designers and developers can influence the border of the button. Sometimes the button is a visual representation in a larger layer. And not only a click on the button, but also in the vicinity of the button counts as interaction with the button. The is / is not border has been moved. Expected or not is a matter of design and experience.

A button consists of many parts. With a real button, of course it does. The housing, the wires, the mechanism to register the button being clicked, the movable part, the parts that push back the button. Also virtual buttons have many parts. There are properties of color and size. Does it show a border, some bevel effect. What action is linked with it. The reaction needs to defined, e.g. changing the color, playing a “click” sound.

And then there are the perspectives. There is the person installing the button to provide a person. Where do they put the button. In real world examples it relies on where the system resides in relation that the button interacts with. You need cables, a place to mount it, etc. There is the view of the person using the button. Is it clearly marked what the button is doing? Can they reach the button? What is their expectation when pushing the button? The list goes on.

You can even take the perspective of the button. Where does it sit? Does it have wires attached properly? Is it visible? Does every part move as expected?
Or the perspective of the system the button should interact with. Is the button properly wired? Does it provide the right type of signal to trigger what it should trigger? Does the button expect some feedback?

Pressing a button is an experience. The rule of industrial design is that great design is invisible. When the user can flawlessly use a button, getting the reaction they expect, even find the button where they expect it. If something is off, the experience is impacted.
Sure, there are buttons that are highly visible for a purpose. Even then the design is intentional.

The next time when you press a button, place a button or test a button. Think about what is attached to it.

Empathy – Understanding Motivation in Systems

In the Systems Seeing Adventure we used an Empathy Map on Day 9. This is a nice tool to look at a system from other perspectives. In this case from other humans. My current favorite approach to systems thinking is the DSRP-method. The P stands for Perspective. The idea is to use the perspective of any element of the system to improve its model. Empathy can be used for human perspectives.
Donella Meadow’s used actors and their motivation to describe the empathy part. Why is an actor in a system and what is their goal and motivation participating in the system?

Empathy helps to understand other participants in the system. What is their job, what is their goal? This can also go to a more personal level. What is their story? Where do they come from? What experience do they have? How does that influence their behavior as part of the system?

Important note: You don’t have to share the opinion, motivation or goal of the other person. There is emotional and cognitive empathy to distinguish.
Cognitive Empathy: Understanding someone’s thoughts and perspective, like seeing their point of view.
Emotional Empathy: Sharing and feeling another person’s emotions, almost as if they are your own.
For Systems Thinking the Cognitive Empathy aspect is mostly relevant. You can take the point of view of an a$$hole to understand why they act like they do, but you don’t have to share the same feeling. That’s a huge difference.

When you apply this lens it is also important to understand, what part of the system do they see? What part of the system is relevant for them. What other elements might they see that you don’t see? Does this information has an impact on the system? These are a lot of unknowns and speculation might be necessary. Sometimes it’s already helpful to know that there is an unknown component to some element of the system that drives its behavior.

In my example in the exercise the other week, I filled out the empathy map for an administrator at my energy net provider. They need to check a circuit diagram, the completeness of information and certificates of the used electrical elements.
This is all they see for my specific problem. They are not aware of all the other context for me. So I need to treat this person as such. What is their motivation? Their job should be to ensure that home solar power plants installed in people’s houses are not endangering the safety of the energy network. Well, that is their job description. Their motivation to do the job is probably to earn money. Where do they come from? What is their background?
They see dozens of these documents a day. What is the difference in my document? How could this impact my way of communication? In my case, I tried to explain them the specific context and why in this case I can provide the information rather than the electrician as usual.

This way I discovered an impact on somebody else’s system, by understanding how my context might be an issue for them. I could also not care a bit, and just throw around angry emails. Does it help me? No! Does it help the other person? They probably already get angry emails and calls with people not understanding. It will make them less willing to solve my situation. And I can relate to that.

If I look at my professional background, especially in the first 10 years were I worked in this huge project. As a Release Test Manager I worked together with so many different roles and people. What helped me back then was to understand what each roles motivation was. This helped me a lot to understand the whole project. And that way I could better “bend” the system to my needs when necessary.

My advice is to learn more about the other roles in a company that you work with. Understanding what they need to do their job helps you to provide the relevant information. That way they are not blocked, coming back to you, disturbing you in another task, playing ping-pong with tickets. And maybe you find a better way to provide the information they need.

For the emotional empathy aspect: Put your ego aside for a moment and think about the others. Maybe they had a rough day and are in a bad mood. They are only people. Just like you. And they also only want to do their job. You don’t need to become their counselor. Just have some empathy.

Systems Seeing Adventure – Day 10 and 11 – Telling it backwards

In case you wonder what this Systems Seeing Adventure is all about, there is this post from Ruth Malan explaining it. It’s about a 31 day systems seeing adventure. So I decided to take you with me on this journey.
Welcome to the next block of applying different lenses to situations, to better analyse the system.

Day 10: Circle of Cares and Concerns

Explore the concerns and orientations of various people or groups (“stakeholders”) who impact, and are impacted by, this situation you’re exploring.

The template gives some structure to this exploration.

  1. Put the situation at the center.
  2. Identify stakeholders who are directly involved, and why and how they care about the situation, and impact its unfolding. Identify their cares and concerns as they relate to the situation, and how they impact it.
  3. Move out a level to who else cares, and consider how they are related to (and influence) directly involved stakeholders. What are their cares and concerns (as relevant to the situation)?

I produced another piece of beauty here. My drawing and writing skills are splendid. Anyway, I’m distracting.

This tool is a nice way to focus on the empathy and motivational part of people involved in the process. Looking at what these roles or people care about and what they are concerned about will help to understand the situation even better. Why is someone focusing on certain aspects? Either they especially care about this or are concerned about this and try to mitigate this.

In my example I have a sales person in the loop. Nothing against sales people, they are important for companies to make money and pay salaries. In my case, they want to sell their product to me. Their motivation is to earn the most they can make from me, from what I sensed, if the solution makes sense or not. At least in most cases. But in turn I can add this concern to myself in the picture, that I get offered a very expensive non-solution.

To look at motivations of actors in a system with the lenses of cares and concerns is a helpful approach to understand them in a more distinct way. This can help to better explain certain actions or reactions.

Also adding the second level of cares and concerns is helpful. Because these are then drivers for the people in the first level. This can explain even better why they care or are concerned. And in the analysis stage it helped me to find more motivations and reasons for their behavior.

Taking into account this additional level of actors in the system broadens the view. It looks at influences to the system that might not be directly part of the system in the first place. Like adding a new dimension to it. It’s collecting relevant information for your model, while not necessarily adding more complexity to it.

Intermezzo: Sensemaking and Framing

There is a bunch of quotes on page 18 of the slide deck around sensemaking. And the key message I took from some is, that detecting the problem is key to understanding the situation. When you come into a new situation, the first step is to find out about the core problem, the problem that is at the center of the situation.

Day 11: Narrative History: Unwinding Threads

Pick up a thread in the situation (in your verbal or visual narrative, or in your experience of it), and write a few paragraphs exploring how it came to.

What were the various paths of influence and unfolding? What are some stories of the history that you were there for, or have heard others tell? While you have time (in the 15-20 minute window), pick up other threads and explore those and notice interconnections.

I don’t want to bore you with the details of my interaction with the administrator of the energy net provider. Looking at the history of this single thread and going further back, how it even came to this interaction, is like going through a specific path through the situation.

I may have not done the exercise as intended. I was telling the story backwards in time, like in one of my favorite chapters of the Kangaroo Chronicles. The author Marc-Uwe Kling is telling the story backwards, starting with the end of an evening. And step by step he goes back in time during the evening, and one weird situation after another is explained how it began.
So I went back from status quo step by step. That way I focused on where I came from in this specific situation. As I know myself, if I start in the beginning, I will loose focus. Telling the story backwards has helped me.

I picked up one other thread. And while the second thread was not directly connected in the situation as it evolved, there were some interconnections. And if some decisions would have been made differently earlier in the situation, these threads would probably changed place. And everything would have been different. To stop speaking in riddles. If I would have decided that the “professional” solutions were worth the money, they would have taken care of registering the installation with the net provider. They would have had all certificates at hand, as the components installed would have been of a different – let’s call it – category, where these certificates are treated with more implicitness. Then I would have not come into the situation to communicate with this person at all. That person would then have been second level in the care and concern circle from Day 10.

There was a quote from the fantastic Elisabeth Hendrickson on that page, where I picked out this sentence:

The word “context” is shorthand for the cumulative effect of all the past decisions that we cannot change now.

Elisabeth Hendrickson

Putting Lipstick on the Pig: The Downside of Automation

One issue that I see every now and then is that we tend to automate things because we can. I’m guilty of that myself. Ever since I started writing scripts and tests and tools and what not, I started to automate things. Because I can.

Don’t get me wrong, automating things is useful and a fantastic opportunity to reduce stupid work. But ever so often we automate the given process and are happy. We forget the chance to maybe optimize the process. We automate processes that are too tedious, error-prone, and binding too much capacity. Instead of asking why is the process the way it is, we start drafting what we need to automate.

First, why does the process look like it does? What does the process achieve? Where does it come from? Are there any relations that are not obvious?

Second, are there steps that we can optimize easily? And I speak from optimizing the process, not automating yet. Can we simplify a form? Can we remove unnecessary steps? Are all steps still relevant? Too often we deal with legacy in our processes. We have always done it that way. One of my favorite quotes, and I’m guilty of using it myself too often.

Third, should we automate every step of the process? Are there restriction that require human interaction? I’m currently working in medical device context, I have some experience in other regulated environments as well. Sometimes there are steps that need a human in the process. Sometimes it’s a step where some human evaluation is not the worst to have.
In general this step goes back to the Jeff Goldblum statement in Jurassic Park.

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

Fourth, continuing on the “think if you should” statement, what parts of the process need automation the most. Why are these steps so awful to use by a human? Do they have to be so awful? Isn’t there something that we could do about it? Yes, this is a repetition of “second”, but we – at least I – tend to settle too quickly with, “let’s automate”.

Fifth, is the effort of automation really worth it? There is a rather old chart from xkcd that helps quickly to evaluate how much time you save by automation. On the other hand, sometimes it’s worth automating, even if the immediate ROI is not positive.

Sixth, use the automation to spot more potential for process automation. When I automate a test case, then I’m also doing exploratory testing. The perspective of automation is a wonderful opportunity to evaluate a system. Use the chance to spot issues in the process. You don’t need to automate everything, maybe there are details that can be adjusted in the process without really changing it.
An example I had some time ago was automating documentation updates. The automation was supposed to work across two or three documents. The only issue was that the part of the document to update looked slightly different across the documents. One chat with the colleague who was in charge of the documents and three edits later, that part had the same structure and I could use the same script in all three places.

Seventh, implement the automation. Finally. We could have saved so much time and just automate it from the start. But then we would have lost a great potential to optimize the process. Processes need refactoring as well.
I’m currently working on a huge refactoring of a central process. The process reached a state where every step was defined in detail. That was the same point like in programming, when a function does what it should, then you can start refactoring.

When you define a new process, think about automation from the beginning, and design steps in a way that are easier to automate.

Happy Automation!

Systems Seeing Adventure – Day 6-9: Looking at a situation from different lenses

I have decided to bundle a few days together. The reason is, that I now need to come up with a situation that the rest of the adventure is using for the exercises. So I need to find something that I can share publicly. On the other hand I want to look at a work-related situation as well. So I will have a simpler situation for the blog, and a more complicated one for myself. In the posts I will share examples with the public situation, but also share insights from the work situation.

Day 6: Describe Focal Situation

Think of a situation you’d like to explore with a systems lens as we practice various systems approaches and views. It’s good (since these 15-20 minutes of daily journaling add up) if it’s something that matters to you to explore and understand, and begin to shape responses to.
Write a few paragraphs describing the situation.

As public scenario I will use my endeavor to get solar panels for our house. The project has come to some point of closure finally, so it should provide enough material for the exercises.

  • Terraced house
  • Roof facing WSW
  • Three large roof windows – not much roof area left
  • Old fuse box – no space for necessary electrics
  • Got three calculations from companies with unreasonable offers
  • The fourth company suggested to place as many balcony power plants as possible and have an electrician registering it as full solution

The work example I chose is our Software Development Life Cycle. As this is company internal, I can not share any explicit information. But I can share general insights.

Day 7: Context Scan

Consider the broader context of the situation you identified (in the previous activity). One way to make this visual: Put your situation in a circle (named abstraction) at the center of your page. What’s around it? What is the “context” for this situation?

Not everything might be readable, sorry.

Insights

One thing I realized again is that visualizing is helping with thinking about more and more topics for the situation. Putting it on a flat map reduces a bit the ability to visualize all connections. While drawing I remembered how interconnected and intertwined certain topics are, even though you can treat them as kind of individual streams. Looking at individual streams would be a change of perspective. This would keep the rest of the system, but change the importance of certain connections.

For example looking at the new product of manufacturer for balcony power plant solutions will keep mostly all other topics relevant. This product needs to provide advantages over the offers and needs a solution for the fuse box situation. But as I know now, it also has impact on the energy network provider, as some specific certificate is necessary to provide.

The lesson I learned from this small situation applies in a multitude to the work situation I chose. In the solar power example I have about a handful of other actors involved (net provider, electrician, sales people, myself). With my company’s SDLC the amount of actors alone is x-time higher, all with their individual motivation. The context is so much larger, as the SDLC is a rather central part of the company, which is a system by itself. It gets complex (intertwined) enough by its central nature. The interfaces with other processes, the amount of rules that need to apply, the amount of people involved more or less in the process is sheer endless.

Day 8: Sketch the Situation

Continue exploring the situation you described. Draw the situation, using words and images, but keep it informal and sketchy. The situation sets the general frame (so we aren’t bringing the whole world into our picture).

I gave it my best to draw something. As I said the other day, drawing or sketchnoting is not my strength. Here you can see why.

My insights for today are mostly, that when sketching the situation you reduce certain things to graspable elements of the situation. Virtual elements are too hard to draw, so you focus on the more or less real world things.

I’m not sure yet, if this is a good or a bad thing. Maybe it’s a way to put a filter on the situation. The instructions went on and tell about how elements of the system interact and what they care about and their concerns. I tried to not over-clutter the image. This takes away a lot of information that I had written down or put in the other diagram, and especially this is by far not what I have in mind for the situation. There are a lot of relations and interconnections, that would leave that drawing in a state where you can not see, understand or read anything. So I would say, a bit of focus is good. I definitely did not focus on all the most relevant bits and pieces, but then also the question, most relevant from which perspective.

For my SDLC problem I re-focused a lot from individuals to groups, or representing only some element from complicated relations. But there were too many parts and parties involved. I tried my best, but I was not happy.

Day 9: Practice Empathy

Pick one of the people in your situation sketch (Rich Picture, if you did that in the previous activity), and explore their experience of this situation, using an Empathy Map (see instructions on the image.)

I would say that I am half good with empathy and understand motivations of people in systems. Doing it with this Empathy Map helped to organize thoughts a bit better.

Insights

Mostly it was a confirmation that I’m on the right track with what I’m doing already. Splitting another person into all these different perspectives is really helpful. As I’m talking about a situation that is now solved, I can look back at the interaction with this person. And filling out the empathy map helped me re-evaluate the communication that happened. And I think I felt empathy for the person from the first email on that reached me. I tried to explain the situation from my point of view as good as possible, as I was aware that this most probably not a standard case. When I found out that I had no idea what I actually needed to provide at one point, I asked them politely for any example and thanked them, explaining my next steps. Would I have not felt empathy for the person and understood their situation, I might have reacted differently.

I believe that I have empathy for different roles, mostly at work but also many other areas. From a systems thinking point of view, taking different perspectives is essential. Empathy is the key to take perspectives of other people. The empathy map helps with that in a more formal way, what will work more “naturally” with practice.

In Systems Thinking you can also take the perspective of any other element or relation or distinction. For non-human elements of a system empathy is restricted. But I guess it will also help to a good degree to evaluate non-humans this way. I will think more about this and come back to you.

That’s it so far with the exercises. I found it very interesting to use different lenses for a change. I will practice more with those when looking at other systems.

Systems Seeing Adventure – Day 5: Attending (more) Closely

If you want to know more about the System Seeing Adventure, check out this link.

My TL;DR: of this session is: What seems simple is rather complex, if you only look close enough.

Today’s task was to look at a picture and note what we see. The system and the interactions. How is it communicated and conveyed.

The picture to look at can be found here. I will post you a picture of my notes at the bottom. You can probably not read too much about it. But I will add my notes here.

The first thing that I noticed was the beautiful tetraptych on the top, setting the flow of the story. The four pictures start the flow of water. A hand is opening a faucet to fill a kettle with hot water.

Steam evaporates from the kettle. Evaporated water builds clouds. When clouds are saturated it starts to rain. Rain hits the ground. Water flows into a river. Water vanishes from the river by seepage through layers in the river bed. The river hits a reservoir. What I think is a water tower, the water is distributed through pipe systems of larger size into a pipe system of a smaller size, and out of another faucet again.

Speaking with the language of Donella H. Meadows as I told you shortly on Day 3 of the adventure, I see a lot of stocks, inflows and outflows.

The flow is meandering over the page from right to left and left and right like a river flows through the landscape.

It combines human-made systems (faucet, water reservoir and pipes) with natural systems (clouds, rain, river).

And one last observation was, that 15 minutes pass quickly when you pay attention to something and dive deeper into it.

My friend Vernon is also doing the challenge and he wrote about it on LinkedIn.

He first noticed that the image was in black & white. A detail I have completely missed.

As one of the first examples in Thinking in Systems: A primer, by Donella H. Meadows is thinking about a bath tub, I approached this challenge not entirely impartial. It’s ten years since I read the book, but the water flow example is one of the best entry topics to systems thinking that I know of, and it stuck with me.

Take a bath tub or the gutter of a house and think about all the elements, the stocks, the inflows and outflows. Think about the whole and its parts. The relations and perspectives. And where does the system has its boundaries?

Time for a cup of tea!

Systems Seeing Adventure – Day 4: Ackoff on Systems

If you want to know more about the System Seeing Adventure, check out this link.

The task for Day 4 is watch and sketchnote the TED talk by Dr. Russ Ackoff on Quality Improvements of Systems. I have tried sketchnoting in the past and it was not very successful. This talk by Dr. Ackoff was just a rapid fire of smart statements worth noting down. I had to stop and rewind the tape multiple times. The fascinating conclusion is though, that I learned nothing new from the talk. It was more the way he put it that blew me away.

I leave you with a photo of mostly unreadable bits of wisdom of the talk. I can only recommend to watch it.

The tasks didn’t end there. The next question was: “How does Ackoff define systems? What other distinctions would you add?”
You’ll find that answer in the right bottom corner of this “sketchnote”.

  • A system as a whole contains of parts that make up the behavior and properties of the whole.
  • The parts are interdependent. A system cannot be separated into independent parts.
  • A system is a product of the interactions of its parts.

From a DSRP-model view I would add distinctions and perspectives. Distinctions to clearer define the system, what is the whole, what it is not. And the different perspectives of the system. Ackoff mentioned the customer / consumer for the context of this talks topic. There are many more perspectives in a system that help to describe the system and its elements.

And the last task is: “What insights do you draw out, and how do those relate to the systems in the situation you’re exploring?”

For me the talk was a confirmation of what I’m writing about for the last four weeks or so. You have to always take the whole system into account when you want to improve something. Taking out some aspect, trying to treat it independently and “improving” it will not work in most cases.

One quote also stuck with me.

Better to do the right thing wrong, than the wrong thing right.

If my QAs and Regulatory folks hear that, they might start to hyperventilate. That’s why we have validation and verification as a must in the medical device context. Validation to build the right thing and verification to build it right.

Also quick shout-out to my favorite podcast: AB Testing with Alan Page and Brent Jensen. Ackoff defined “Quality is meeting or exceeding the expectation of the customer / consumer.” This is what Modern Testing principle #5 is stating as well. “We believe that the customer is the only one capable to judge and evaluate the quality of our product.”
Other aspects of this talk also reminded me a lot of the Modern Testing principles.

I will try to revisit the statements from the talk again sometime soon to get more insights on some. In those 10 minutes was just too much for my small brain to process in such short time.

System Seeing Adventure – Day 3: Explore System Concepts

The task on day 3 is to explore system concepts and make concept cards out of them. I will pass on this drawing challenge and rather focus on the write-up here.

I’m aware of two system concepts that helped me the last 10 years. A decade ago I read the book “Thinking in Systems” by Donella H. Meadows. The basic elements that were used in this approach are stocks, inflow and outflow. There are actors, feedback loops and motivations. With those few elements it is possible to describe a lot of systems in a simple way.

What I’m more a fan of at the moment is the DSRP approach from Derek and Laura Cabrera. I stumbled over their podcast via some LinkedIn suggestion, which was one of the best things that happened to me in 2024. DSRP stands for Distinctions, Systems, Relationships and Perspectives. You can organize information with those four patterns to form mental models.

Distinctions means “what is” and “what is not”. You describe the boundaries of the system, of the model, of certain elements. The approach of “what is not” is very helpful to distinct elements of the model, because it can define the “other” better which in turn sharpens the edges of “what is”.

Systems stands for elements of the model. It is divided into “whole” and “parts”. Every element can be split into its parts. But the element is also a part of a greater whole. This is about zooming in and out of a system. Being aware of the parts of any element helps to recognize more details.

Relationships is about the action and reaction between elements. Many elements of a system will have relation to other elements. That is where complexity gets visualized, when you realize just how many elements are connected in any system. This part helps to identify when element A does something (acts), how does element B react to this.

Perspectives is about point of view of the system. The perspective can be from anywhere in and around the system. It can be from an observer position or from any element that has been described above. You can take the perspective of a relation and view the system from there. It’s about identifying perspectives of the system that help to improve the mental model.

These four patterns will always co-exist. As the systems you observe also describing them is complex. But with the patterns it will become easier to dissect a model and understand more of it.

I recently thought about the dimension of time in the model and if it’s just a form of perspective or not.

These are my thoughts on the day 3 exercise of exploring system concepts.

System Seeing Adventure – Day 2: Draw your Org (incl. my take on orgs)

The task on day 2 is not only to draw your org, but draw it in three different ways. The org to draw I choose was my company in its current state.

Next step: Draw your org – 3 different ways

That was harder than imagined.

Next step: Jot down what you learned about your org.

  • Rather team-centric view
  • For some non-tech related functions I have no idea how they are organized
  • One view was trying to emulate what was recently presented, but with team focus

Next step: What first occurred to you to draw?

I mostly started with my team. I chose a rather egocentric perspective. In one attempt I started top-down approach, but then lost count of “departments” and moved on to the next one.

Learning for me: The view of the org that I have in mind is hard for me to draw. In my mind there is this web of relations and dependencies, with people and their tasks, and whom do I need to approach for what. Putting that into 2D is really hard for me, especially with a time constraint. I will think more about that.

Update from day 2 + 1:

It seems I missed yesterday’s morning walk more than I expected. On today’s walk I gained a lot of insights on the org structure and why it didn’t work to draw it.

I put myself into a box and tried to draw the org as we usually draw orgs. You know these organigrams and hierarchies. But these are only boxes that HR draws and packs. But reality looks different. Companies are complex adaptive systems, if you want or not. No matter how much command and control you apply, people will adapt. So what does that mean for my org.

Despite having a bunch of boxes where people are put in, this does not even closely reflect how we are working. Besides these hierarchical teams and structures you have guilds, working groups, virtual teams, meetings, and many more elements. e.g the Quality Engineers are put individually into teams, but we also form a loose guild and exchange. When we have to work on special topics like addressing non-conformities (remember: regulated environment) we form working groups from members across several functions. There are the security champions, our InfoSec team’s virtual extension into the module teams. There are regular meetings across functions for many topics, one e.g. change control board.

Some of these additional elements of the organization form based on plan and command, because they need to happen. Others form more organically, because people are willing to support. Organizations are not static.
You might know that the addition or removal of one person creates a new system. Depending on the change this can be adjusted more or less quickly. Changing more than one element will add more time and friction to that. But the system will adapt to the changes and find a way. Happiness of people has been left out of all this on purpose.

No matter how structured your org might look on paper, there are many more layers that happen inside. These are more or less formal, more or less under command and control, but they happen all the time despite the form of the organization. And I would even go that far and say that these structures are more important to the success of an organization than the “official hierarchy”. But as always, these are too messy to put “on paper”. And some of these cannot be forced to happen, at least not when they are supposed to be “successful”.

Design a site like this with WordPress.com
Get started