The problem with "having a great understanding of a system" is that it's hard to pin down, to define what that actually means. You can always use that as an excuse, if you are gatekeeping a poorly constructed system and resisting change.
If you require "full understanding of our system" for me to add some new functionality in a module, then chances are pretty good that your system has a bunch of problematic dependencies, no?
The article seems to be about "invasive and risky changes" (that's from the article). In this case I expect some level of gate keeping by people familiar with the system. If people doing the gate keeping aren't familiar with whatever they keep, then that's the first thing to work on.
> If you require "full understanding of our system"
I wrote "familiar enough", and "good understanding", not "full understanding". "enough" and "good" will of course depends on the context.
Considering this:
> then chances are pretty good that your system has a bunch of problematic dependencies, no?
In practice you need to understand some level of the context in which your module exist, hopefully not all of it, though of course it would be better to be able to just focus on the module itself. By "system" I don't necessarily mean the whole, complete infrastructure, it can be the module.
My point was that if people are blocking changes because of lack of understanding of something, the solution would be to actually get some level of understanding.
Edit: also, I assume good faith from gate keepers.
If you require "full understanding of our system" for me to add some new functionality in a module, then chances are pretty good that your system has a bunch of problematic dependencies, no?