Comment by austin-cheney

I ran a program like this once for a military unit of 240 organized into 25 teams my second time in Afghanistan. There is only one way this works. Everything else will result in failure. Steps provided in order of priority.

* Receive buy in from senior leadership. This has to be more than just some assigned task. Senior leaders must really have your back because the underlings will fight you and resist. Some example might have to be made of some of them. Better one or two of them than you in the position of authority. It really helps when this sentiment is communicated to the team directly by the senior leadership.

* You have to really own it. Accept all failures and successes personally. Be willing to go down with a sinking ship, because that ship is yours. This needs to be visibly obvious to all directly from your communications to impacted personnel without you explicitly stating as much. It should also be absolutely crystal clear that if you are going to drown on this sinking ship there will be a shake up and many of them are going with you. This is one of those rare times when rumors can work in your favor.

* Roll out supporting automation. Write custom ESLint rules and/or TypeScript interfaces to enforce your priorities and integrate them into your build checks on creation of pull requests.

* Your only two technical priorities are the architecture of patterns and the minimum baseline of documentation. It is unlikely you willing be writing this component library on your own so your job is more to provide the definitions. The military would refer to this as a scheme of maneuver and the corresponding documentation would be base orders and fragmentation orders. It is very important to think about this in terms of acceptable baselines, component relationships, and documentation clarity. This is much harder than it sounds.

Good luck.