A number of years ago, my team hired an experienced individual who was quite invaluable to our team despite the fact that their experience was in a different pr

A number of years ago, my team hired an experienced individual who was quite invaluable to our team despite the fact that their experience was in a different problem domain and a different technology stack. The reason they were still useful was because they had a good understanding of what we might call "systems management software". That is, if you need to write software to manage a set of heterogeneous systems distributed across a networked environment, this person had a lot to offer. (Unfortunately management did not recognize this person's value to the rest of the team until they had already accepted a better job at another company, but that is a different story.) It seems that there are three different ways one can "specialize": problem domain (e.g. business accounting), solution domain (e.g. "systems management software", "data science"), or tool-set (e.g. J2EE). Each form of specialization has its trade-offs, but it strikes me that tool-set specialization is particularly likely to get one stuck working on frustratingly complex legacy systems. My attitude about specialization vs. generalization (that I think resonates with the OP) is not whether we should specialize, but when. To my mind, specialization is a necessity, and it does increase one's income, but it also incurs the risk that the specialization will become obsolete before you are ready to retire. When you look at risk-adjusted lifetime earnings[1], it seems to me that the most reasonable strategy is to delay specialization as long as possible. [1]Warning: statement made without real numbers.