Standardization

Amazon and Netflix popularized an idea of two-pizza teams owning their entire lifecycle. Part of this idea was that teams also have some freedom to decide in usage of certain technology or even programming language if needed. This was opposite to forcing all teams to use the same technology. Especially if such decisions are made top-down by external architects.

As it often happens, the larger software industry understood this as if each team can choose their preferred tech stack without any negative consequences. Almost as if technology standardization within a single product is mostly irrelevant.

So, the more common form of product development groups have different teams use different tech stacks just because they can, and not because they need to. 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. It becomes much harder to share ownership, leading to the argument of being cognitively overloaded with so many technologies in different components.

On the opposite side, 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/).