Earlier quoted context omitted.
There's also often a messy transition period where a team goes from a bunch of generalists to more specialists. This can be extremely rocky for all involved as often generalists have lots of historic operational knowledge and strong opinions, but the new specialists come with external knowledge of best practices and how to scale. It is important that historic knowledge is respected for the context it provides, while…
>often generalists have lots of historic operational knowledge and strong opinions *citation needed Edit: to be clear, in my experience the specialists that aren't also generalists on some level are the least productive on the team because they have trouble participating outside their knowledge domain. Maybe I have worked at the wrong places though...
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.