Systemic consulting refers to an approach in which teams and organizations are not changed through direct instruction, but through targeted interventions. A central concept here is connectivity: an intervention is only effective if it docks onto the existing structures, language and resources of the system. Sustainable change comes from within, not from external instructions.
Key Takeaways
- Systemic interventions fail if they have no connectivity: A team is a closed communication system that only accepts external impulses if they dock onto the team’s existing language, resources and experiences.
- Direct advice fizzles out because it is not sustainable: changes that are imposed from outside usually return to the old state after the support ends.
- One-to-one meetings often work where meetings fail: if you fail to generate resonance in the team, you can first build awareness of a problem through individual contact and thus gradually create a basis for collective change.
- Systemic consultants must actively observe their own entanglement: Those who become part of a system for too long lose the ability to irritate it, which is why regular supervision is a quality characteristic of experienced coaches.
- Systemic thinking can also be applied internally: Managers and team members can provide impetus, for example through sociometric constellations that make the proverbial pink elephant visible and discussable.
What does systemic mean in the context of software teams?
Systemic describes the view of people who communicate with each other, organize themselves and thus form their own structure. A software team is just such a communication system: with its own dynamics, its own language and its own patterns.
The approach originates from sociological systems theory. It examines how systems develop, how they differentiate themselves from one another and how they keep themselves alive when people interact. Coaches, consultants and therapists use this knowledge to support groups differently and make changes more effective.
For software engineers, this is more relevant than it initially sounds. Anyone who writes code always has to deal with people. And it is precisely there, at the interface between technology and team, that it is often decided whether a change will take effect or fizzle out.
Why teams resist change from outside
Teams develop a kind of immunity to external impulses. They have their own dynamic and don’t like it when someone from outside interferes. Change can only be forced through directives, and that is precisely the wrong approach from a systemic perspective.
Anyone who has ever worked in a deadlocked team knows this. You want to change something, a little bit happens and then everything slides back to its original state. The lever doesn’t work.
Vera Hofheinz uses a systemic term to explain the reason for this: connectivity. A system is porous to the outside, it exchanges information with its environment, but an impulse only works where it can dock.
Like a key that fits into a lock, we try to find something in the system where this intervention can dock. Connectivity is an important criterion as to whether an intervention can become something.
Vera Hofheinz
How do you find the connection to a team?
Access is gained through the language and experience of the people, not through your own solution. Instead of asking what the team should do, the systemic view first looks at what the team is already doing, what it has good experiences with and what resources it has.
The approach is iterative, similar to the agile world. You take a step, observe where you have ended up and reorient yourself. Observe, listen, form hypotheses: many hypotheses result in what can be tried out.
This path often leads to interventions that are not obvious at first glance. The leverage often lies at the relationship level. Who is good with whom, who feels excluded? Starting there with small things brings more than the seemingly obvious factual solution.
A concrete example: bringing software quality into the team
An intervention begins with observation, not with personal conviction. Christoph Jung and Vera describe a case from a project on the subject of software quality.
A software engineer really wanted to introduce metrics because he thought they were important. He brought it up in the retros, tried again and again, and got no response. There was a lack of connectivity.
Instead of pushing further, he observed again: how do people develop software, what do they talk about, what is important to them? It became clear that there was simply no awareness of internal code quality, test-driven development and test automation.
The effective intervention was a change of setting. No longer the big retro, but individual discussions. He started counting bugs together with one person and looking at how much time it costs when bugs only reappear a month or two later. It took a while for an awareness to emerge. Only then was a different approach possible.
The lesson here is that change imposed by directives is rarely sustainable. It is imposed from outside and eventually fizzles out again. If you involve people and allow awareness to grow within the team, you sow a seed that lasts.
Change doesn’t fail because of you if the first attempt doesn’t take off
The systemic view also changes the attitude of those who intervene. If an intervention does not take effect immediately, that is no reason to doubt yourself. It is an indication that something has not yet been seen or observed.
This takes the frustration out of the work. In the early years of agile consulting, well-intentioned recommendations often bounced off without anyone understanding why. The reflex to blame this on their own failure was strong.
The systemic view turns this around. If an impulse doesn’t work, it means going back to observation, sharpening hypotheses and looking for a new connection point.
Where the systemic approach reaches its limits
Systemic work is not a panacea or magic. Before diagnosing a boundary, it is worth looking at your own blind spots. But there are situations in which coaching no longer helps.
Escalated conflicts are one such case. At the upper levels, when a conflict has been smouldering unresolved for a long time, the logic of the parties involved is reversed. Then it is no longer their own improvement that counts, but only that the other party does not win. This is where a systemic coach is no longer the right person. Mediation is then needed, or the aim is to accompany a separation.
On the other hand, those who think systemically at an early stage are less likely to get into such dead ends. When people are used to looking at things from multiple perspectives and using their ability to reflect, problems don’t become entrenched so quickly.
Working systemically means observing yourself
Those who work systemically not only look at others, but always remain their own observers. Self-reflection is part of the craft. You have to observe yourself and be prepared to change yourself.
In practice, the role is rarely pure. Agile coaches and scrum masters are often expected to deliver performance. The client expects a team on track, and this pressure is transferred.
Then it helps to ask yourself an honest question: What am I doing here right now? Am I helping the team or am I just passing on the pressure that I feel myself? Sometimes the right answer is to clarify the assignment with the client instead of putting more pressure on the team.
Another risk arises over time. If you stay with a client for a long time, you become part of the system yourself. The question then arises as to whether you can still go to the meta-level and irritate enough. Because a good impulse can be irritating, it can make the system bubble. If you are too much a part of it, you may no longer be prepared to do so.
Supervision is recommended as an antidote. Experienced HR coaches should have themselves supervised so that someone from the outside can see whether their own issues are interfering with the work.
Can you set impulses from within the system yourself?
Yes, change doesn’t necessarily have to come from outside; you can create momentum from within the system, both as a manager and as a team member.
One impulse can be to bring in an external moderator for the next meeting to look at a topic with the team. Or to use a method that makes positions visible.
Vera cites the sociometric constellation as an example. The team spreads out around the room to answer a question, such as how important software quality is to them. Everyone has to position themselves. Suddenly, things that were previously the famous pink elephant in the room can be discussed: everyone knows it’s there, but no one addresses it.
One restriction remains. Anyone who is part of the system has to weigh up how much irritation is allowed. Too much disruption from within can backfire. But the basic rule is: it also works without external impetus.
The resources are already in the team
The systemic view of a client assumes that the resources for development are already available. A team has the ability to solve its own problems, otherwise there would be no point in coaching.
Nevertheless, sometimes it takes someone to make a difference in perception. Who shows: This is where you are, this is where you want to go, what does this gap mean for you? Enabling this reflection is the real task.
The good thing about it is that it can be learned. Becoming aware of your own impact and always taking the outside position is practice. Some companies therefore send all managers on a basic systemic training course. There you learn how to look at an organization, make decisions and conduct staff appraisals. At some point, the team no longer needs the external coach for this reflection.
