I think maybe I have a different takeaway. The point is to make yourself non-critical. That does not necessarily mean copious amounts of documentation or beautiful diagrams. I don't mean to read too much into your message but there is such a thing as a pedantic documentation. There's a saying in my team: in almost all cases, "short beats precise".
If i were in your shoes, I would ask feedback from my colleagues: am I communicating in a way that works for my teammates? Am I too verbose? Does my doc look intimidating? Are they not interested? What would interest them and could I get to the point faster? Maybe talk about your goals? Maybe your teammates or you manager are not bought in to the idea that people should relinquish their criticality. Maybe they like being like a little sovereign on their chunk of infrastructure, and don't like wasting time learning a system that they see as not theirs, in which case there's a goal alignment problem.
I'm saying this assuming that you can expect competent and helpful feedback. It may or may not be the case, it's up to you to assess. However you sound like you're already in blaming mode, and I would encourage you not to be. Maybe you're not communicating in a way that works for them. Maybe they need to be convinced that it's worth their time in the first place. If you determine that your colleagues are a lost cause because they do not have the interest or skill, don't waste your time trying to craft the perfect comms either.
Beyond documentation it also means paying super close attention to design. The best systems I've seen were designed with the utmost clarity of purpose, about what they were and what they weren't. It was clear what the important things were and how we were measuring towards these goals. From there, the design flows naturally and the code didn't need much documentation.
I've also seen piles of hacks that made up for their shoddy, misguided, over-engineered design by abundant documentation, which was necessarily hard to understand because the design sucked. There was just no salvation possible through eloquence. Crystal clear design is something that is a lot easier to communicate and share ownership of.
If i were in your shoes, I would ask feedback from my colleagues: am I communicating in a way that works for my teammates? Am I too verbose? Does my doc look intimidating? Are they not interested? What would interest them and could I get to the point faster? Maybe talk about your goals? Maybe your teammates or you manager are not bought in to the idea that people should relinquish their criticality. Maybe they like being like a little sovereign on their chunk of infrastructure, and don't like wasting time learning a system that they see as not theirs, in which case there's a goal alignment problem.
I'm saying this assuming that you can expect competent and helpful feedback. It may or may not be the case, it's up to you to assess. However you sound like you're already in blaming mode, and I would encourage you not to be. Maybe you're not communicating in a way that works for them. Maybe they need to be convinced that it's worth their time in the first place. If you determine that your colleagues are a lost cause because they do not have the interest or skill, don't waste your time trying to craft the perfect comms either.
Beyond documentation it also means paying super close attention to design. The best systems I've seen were designed with the utmost clarity of purpose, about what they were and what they weren't. It was clear what the important things were and how we were measuring towards these goals. From there, the design flows naturally and the code didn't need much documentation.
I've also seen piles of hacks that made up for their shoddy, misguided, over-engineered design by abundant documentation, which was necessarily hard to understand because the design sucked. There was just no salvation possible through eloquence. Crystal clear design is something that is a lot easier to communicate and share ownership of.