Well put. I would add that this doesn't necessarily mean that you yourself are the one actually completing the task. Part of this is knowing who the right pers

Well put. I would add that this doesn't necessarily mean that you yourself are the one actually completing the task. Part of this is knowing who the right person is for the job and delegating appropriately. The requester (often somebody non-technical who doesn't know who's best-suited for what type of work) usually doesn't care who does the work, as long as it gets done right and on time. Even if someone comes to you with a task that some might consider "outside of your domain", it's better to try to help solve these problems (e.g. through connecting with the right people or stepping outside of your comfort zone) than to refuse the work because it's not "part of your job". I've often worked with engineers in the latter camp and they do not become go-to's. I've found that a willingness to take on work, a friendly attitude, both towards superiors and co-workers, and the ability to complete tasks well and on-time (with the help of others) has often resulted in me being a "go-to" engineer.