As someone who agrees with the article and also agrees that the listed antipatterns you listed are bad, I've observed that following these two steps you suggest

As someone who agrees with the article and also agrees that the listed antipatterns you listed are bad, I've observed that following these two steps you suggested can help actually help build personal moats: 1. Writing documentation is helpful for everyone, but it is more helpful in building a moat for the writer than it is for the reader. When I document hard-to-learn processes, I drill the process into my memory in a way that the followers of the process are glad have avoided -- a win-win! And by seeing the results of people attempting to follow my documentation, I get valuable feedback on how adaptable my processes are to others, which helps me easily adapt the processes to new situations even for myself. 2. Avoiding processes that rely on a hero avoids building useless moats. It's good to avoid processes that rely on a hero. Teams should try to replace hero roles with repeatable processes as much as possible, but after doing this, often there are some hero roles left. These are roles are usually done by people with an ability to do critical but unforeseeable one-off tasks in a way that's very hard to train or hire others for. I'd need to hire a team to replace each of these people! As someone who wants to build a personal moat, I actually want to work on teams that do this kind of "hero role pruning", because in those teams, any hero role I happen to fall into is one with actual value that's hard to replace. --- If I were to mesh together the article, your response, and my responses here to create a more nuanced criticism about the article, it would be that the moat one builds should come from things that are naturally hard for other people to do, not by one artificially making things harder for other people.