Dealing with organizational debt

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".