I agree, but ability to code well may help you to guide others. In case that you can code, you may create diagrams as well. You can also create presentations fr

I agree, but ability to code well may help you to guide others. In case that you can code, you may create diagrams as well. You can also create presentations from code. You can point out what is important to solve given problem and use code as example, show some diagrams that describes given process, describe facts and knowledge that you used to solve this problem. I still like to code, but today I do it mostly in form of some kind of presentations, this might be informal presentation for developers/operations for given use case, this might be presentation describing deployment/infrastructure/architecture, but in general purpose is to guide less experienced engineers to use efficient methods of solving problems instead of just smashing code together. Based on my experience, communication barriers are biggest issue in big corporations and it's crucial to communicate your knowledge to others in approachable way, even if solution is technically not optimal. It's described so it can be improved later. However sophisticated solution that is not documented, may technically work better, but it's maintenance nightmare. Has anyone ever liked situation, where you get alert about production incident and you have no idea how to fix it, because you don't understand what happened? This is a people problem, not technical problem, because you cannot understand everything and either someone will explain system to you or you may have no idea how to react. People that understand people problems will ensure that there's always proper documentation and processes to follow, so no-one is stuck. Technical master will create greatest technical solution, but eventually systems fail and that's where the problem begins, if others don't really understand them.