There is a way to do this that doesn't involve (possibly unethical) knowledge hording, such as having skills in areas that the team you would typically be on wouldn't have. But skills that still enhance your role. For example, I've always been employed as a Unix (now Linux) sysadmin / engineer / devops whatever. Basically my team creates system build standards, installs and maintains infrastructure. However I also know systems level C programming for the past 30 years. What this means is that when a system is showing a high load, but tools such as top aren't pinpointing any given process, I can run strace on those processes and observe a lot of fork/exec short-lived child processes due to inefficient code. Then I can help the developers make the code better. Or, again using strace, diagnose why a third party vendor's license manager crashes on startup (it kept a few configuration related XML files opened read/write, and when disk full events happened one of the XML files went zero bytes which caused the app to crash on startup because it wasn't coded properly to handle exception conditions from the XML library it used).
I've also thrown out a few sorely needed web utility apps with Javascript, low level server-side code interfacing with specialty equipment, and various data conversion and analysis tools that were useful for specialized in-house software. Oh, and I used my C programming skills to let a developer know why their code went into an infinite loop when porting it from big endian to little endian architecture (they didn't account for a null terminator when copying a string in a loop, overwriting the counter variable on the little-endian machine but the bug went unnoticed on the original big-endian host).
Summary -- be a pinch hitter in addition to your day job.