Rule of three: if someone asks the same question or protocols three times, then they should document it. "often does not respond or respond by just doing the w

Rule of three: if someone asks the same question or protocols three times, then they should document it. "often does not respond or respond by just doing the work in place of the other engineers (rainchecking the problem)." This suggests that the documentation takes longer to write than the solution. Documentation isn't always as helpful as many people think. It gets out of date unless maintained and can be worse than reading the code. Someone can sit and think for three hours how to explain it to someone else. Or they can just change code in a bunch of places The solution we use is that everyone is expected to read the code. We ask when something can't be found, or ask the why. It's usually easy to say "oh that code is in the X module, not Y" rather than dig up actual specs and making sure it's correct. If it's something like an API guy blocking a FE guy, FE should start reading API code. If this is a recurring problem, hire a systems analyst, whose dedicated role is to answer such questions, handle code reviews, be mentally up to date with all changes and basically act as living documentation.