In a blog post he wrote last year on “The organizational debt“, Fabian Schiller discusses the flaws in organizations. He reasons from an interesting point of view, as he compares organizational debt to technical debt.
Technical debt is something done wrong within an application – at the start, it might only seem like a small issue, but this problem will in fact continue creeping deeper into the system, while the negative impact will slowly but gradually start surfacing. Fabian Schiller believes that organizational debt, such as bad rules, wrong decision-making or a warped strategic direction could lead to similar kinds of problems on an organizational level. In this case, even small decisions that point in the wrong direction could turn into a reinforcing system that will collect a rapidly increasing amount of debt. This may lead to a situation where – over time – the impact of small decisions could overrule that of more important decisions.
Now, some people in the organization might react by saying, “This sounds like the time for drastic change – with a few good, but strong decisions we might be able to fix our organizational debt.” Sorry, but I don’t think that this is a good idea. I generally don’t doubt that drastic decisions can succeed, but I do believe that there is a better way for tackling this issue.
I want to stick to Schiller’s comparison with technical debt. In big legacy systems, we are very concerned about change, as we fear not being able to foresee the outcome. We never know the system as a whole and often we can’t even begin to imagine what kind of errors might be introduced with change. A very simple and effective way of changing something in this case is to test the waters step by step – making small changes on the way, improving things a little, and then re-visiting them every time. With that sort of discipline, we might not change the world within a few days, but we keep improving on a daily basis. Plan, Do, Check, Adapt. At the beginning, such small steps might drive you mad – the reason for that being that most people are so impatient. But from the bottom of my heart, I do believe that persistency can succeed.
As I’m thinking about small and big changes, I have another point in mind: What if our changes for the better actually lead us in the wrong direction. Well, we won’t know until we try and then prove it. In software development, we often only make small changes, so we are aware of the cause of change. When I said “until we prove it”, I meant that we have to check our results. We have to check whether our initiated change actually led to the intended result or not. In order to be able to check the result, we need something that will show the new, emerging effects. Furthermore, we need something which will enable us to get an overall picture of the coherences. This is exactly what we do in software development. Here, we simply call it Scrum!
If you want to let yourself be inspired by one aspect from this blog to ponder about for the next 30 days, please let it be this: “Make everything a little bit better, over and over again”.
- Beratung
-
-
IM FOKUS
- Die 10 Top-Gründe für borisgloger Wir reden nicht nur, wir lösen jeden Tag Probleme bei unseren Kunden.
- Warum Sie mit uns remote genauso effektiv arbeiten können Wir gestalten virtuelle Zusammenarbeit als aktivierendes Erlebnis.
- Warum das Arbeitsmodell der Digitalisierung Agile heißt Die Digitalisierung verändert, wie wir arbeiten und wie wir Arbeit organisieren.
-
- EXPERTISE
Expertise
-
- METHODEN
Methoden
-
- BRANCHEN
Branchen
-
-
- Academy
-
-
IM FOKUS
- Lernen Sie von den agilen Praktiker:innen Zeit für neue Skills? Wir geben Ihnen die Instrumente aus dem agilen Werkzeugkasten an die Hand.
- Future Skills Conference by bg Die relevantesten Trends und Trainings zur Befähigung Ihrer Talente in der agilen Transformation – kompakt und digital vermittelt am 18.10.2023 von unseren Agilitätsexpert:innen.
- Werden Sie Agile Coach Steckt in Ihnen ein Agile Coach? Dann haben wir ein Angebot für Sie.
-
- TRAINING
Trainings
-
- COACHING
Coaching
-
- DIGITALES LERNEN
Digitales Lernen
-
-
- Über uns
-
-
-
- UNTERNEHMEN
Unternehmen
-
- PUBLIKATIONEN
Publikationen
-
- EVENTS
Events
-
-
- CSR
- Karriere
- Publikationen
- Kontakt
- AT
- DE
- EN
Eine Antwort zu “Dealing with organizational debt”
I would go a step further: recognizing technical parts which fail is often easier, because there are already established methods for measurement of performance / functionality / …
And a technical component is easily replaced by another technical solution (let’s say, the next try). But when dealing with organizational debt, the components typically consist of humans – and these parts are not easily replaced.