There is a reason why your team builds software – most likely, you are either building a product for external customers or supporting technology solutions for internal stakeholders within the organization. Systematic reuse cannot be achieved if we focus exclusively on technologies. Focus on capabilities, more specifically, business capabilities instead.
This is a simple but significantly useful perspective to adopt. Capabilities are tangible units of functionality – regardless of implementation technologies used or systems that they are part of. When capabilities are identified, you can make more informed decisions about whether or not it is a reuse candidate. This is also handy every time there is a discussion on which part of a functionality should reside in a server component or a presentation component etc. Capabilities, when aligned with business needs, gives you the right level of abstraction when considering refactoring efforts. Are we refactoring the right capabilities from a legacy codebase? is this a capability that is useful as-is or is it only relevant within the context of a specific business process? is the current implementation assuming (aka coupling) too much about a business capability?
These are extremely relevant questions – and notice how we haven’t talked about technology implementation decisions. That is on purpose – if we are not careful, impatient technology choices could adversely constrain business capabilities. Once you are clear on the capabilities – technology decisions and need for variability, agility, and other quality attributes can be made appropriately.