I always try to de dispensable. We have weekly KT. And we take turns in doing Ops. We also do KT for others roles. As a rough example, we have DBAs, but we make

I always try to de dispensable. We have weekly KT. And we take turns in doing Ops. We also do KT for others roles. As a rough example, we have DBAs, but we make sure devs know how to do the basics of their work too. Whenever you do something someone else can't, assign someone else for next time immediately. Never do the same job twice. It seems faster do just do it, but it's not as soon as the third time happens. But the real trick is test frameworks that give you rapid access to test all areas of the system with new code or inputs. So if the question is "what if?" The worst case answer, if I am not there, is "try it". N.B. You must be able to test performance impact. This is expensive, you need prod support systems you can hack at and put back to the original config quickly. The ability to restore any test system to a know state (even systems you don't know much about) is critical. So you can try stuff out and then leave it how it was. In emergcies when there is no time to test. Experience matters. If you are answering "what if?" with "try it" people get experience. It seems faster to answer "what if?" with "I am sure that" but long run that results in two problems, knowledge silos, and a delay in answering until you are at work or awake. That can kill you, especially if you are expert in more than one thing. If you want backup in a multinational company that runs 24/7 you need one person to answer any question in each timezone. If you can answer a question "immediately" but others can test the theory in 12 hours, that's often faster. You need sleep. In a small company you may not have 24 hours resources, but if the questions cost more than a wage in a foreign company, hire people. Even for day to day stuff this enables you to work around the clock. Get managers to do the math and presume answering any question or doing any task is never immediate, on average its >12 hours, because sleep. It's also good to avoid doing what you know best (that's hard) but it's better to tell people how, than to do it. If you want to avoid questions, don't just tell them how, tell them why, and how you found out. There is a social problem to deal with too. Often people think something is "not my job" deal with that early with collective ownership of the whole solution. There is a problem of permission, sometime only DBAs can touch the database, work on that by giving confidence that others can do DBA work in test systems. There is a real problem that some people try to be indispensable for their own job security. Fire such people early, or move them to new roles in the company early. People are generally as smart. They will learn given learning opportunities. They will want to learn if the alternative is 12 hours of testing!