Standardization

Different teams use different tech stacks just because they can, and they have a misplaced interpretation of team autonomy. They will face difficulty in helping each other or working on certain components together. This, in turn, drives the need for so-called “complicated subsystem teams,” “platform teams,” “stream-aligned teams,” and other forms of component teams, all with segregated ownership and many dependencies to deal with. Teams that regularly discuss and share ownership of the architecture and technology stacks will standardize more. This reduces cognitive load when they are working on more components and share ownership.

Of course, one could opt for an alternative in which there is an architectural board or similar that will govern the technology stack for others to comply with. This approach would become a bottleneck in decision-making for many. In that sense, this approach will most probably slow down decision-making and, thus, value delivery. On top of that, this approach might take away the ownership and responsibility of the masses and offer it to a few, who, in turn, will become the policy police.

Note: This doesn’t mean you should look for a single technology stack for everyone or avoid switching to a better, newer technology. However, switching should be done in alignment with many, and as such, you won’t overload too many people at once. This allows time for everyone to become familiar with progress. At the same time, we urge you not to think too much in terms of “full rewrites” but rather in “refactoring” (or evolutionary design, as mentioned earlier. See: https://refactoringmanifesto.org/).