Starting dev of some product, you might have a lot of generalists. They make the original architecture and design decisions, do the first implementations of fea

Starting dev of some product, you might have a lot of generalists. They make the original architecture and design decisions, do the first implementations of features, etc. It's their baby. Later on, the company identifies laser-focus areas where specialists are appropriate, and you contract or hire some. The original devs (the generalists) will have knowledge about why something was built a certain way, and might react strongly when the specialist advises deep changes to the program to help it scale up. That's the messy part of the transition: There's kind of the implication that past decisions weren't correct. It's easy for people to get emotionally involved and take personal offense. Example: Backup product. Design started in the late 90s. By late-aughts, multiple CPUs were obviously a serious thing. New guy was brought in, and set on the project of re-architecting the core program into a more asynch data processing model. 6 or 8 months later, the changes were working for base cases, but the senior devs threw an absolute hissy fit focused on how much of their code was changed. We should've banded together and fixed the edge cases. Instead, we spent years fighting over the structure of the program, and that dev transferred to another group. Bringing in security-focused employees worked out better. Their changes were more around the edges of the various programs, rather than in their cores. Fewer toes stepped on, fewer disagreements.