1. Recurring Traits
1.1. Skills & Temper
1.1.1. They built a business backbone
1.1.2. Pride is more than justified
1.2. Perfectionism
1.2.1. "I'll share it when it's finished"
1.2.2. High standards
1.3. Data-Centric Monolith
1.3.1. Coupling
1.4. Lack of safety
1.4.1. Refactoring without tests?
1.4.2. Open heart surgery habits
1.4.2.1. Only few are entitled to do it
1.4.2.2. Bomb Squad attitude
1.5. Solo programming
1.5.1. Their convention is THE convention
1.5.2. Nobody knows the full story
1.5.3. Lack of peer feedback
1.6. Increased responsibility
1.6.1. Pressure
1.6.2. Not enough time to finish things
1.6.3. Hidden Use Cases
1.6.4. Possible Bias: career path
1.7. Company Culture
1.7.1. Mistakes are in the cards. Can we handle them?
1.8. Bad explainers
1.8.1. Problem and existing solution are hard to separate
1.8.2. Continuous parenthesis mode
1.9. Dismissal of new stuff
1.9.1. At the end, you'll always need a database.
1.9.2. No time for real experimenting
1.10. Minions
1.10.1. What are we learning?
1.10.1.1. Second hand domain knowledge
1.10.1.2. Tons of arbitrary conventions
1.10.2. Eternal apprenticeship
1.10.2.1. Good, but not good enough to take over
1.10.2.2. The ones that need to change things eventually quit, or are labelled as "troublemakers"
1.10.2.3. Feedback, but no peer feedback.
2. Countermeasures
2.1. Project Scope
2.1.1. Managing Risk
2.1.1.1. Existing Expertise not necessarily an asset
2.1.1.2. Domain will need to be re-learned
2.1.1.3. EventStorming
2.1.2. Defining Roles
2.1.2.1. Existing experts available on call
2.1.2.2. No contradictory roles.
2.2. Oganization & Culture
2.2.1. Prevention
2.2.1.1. Collective Code Ownership
2.2.1.2. Pair Programming
2.2.1.3. Focus on Learning
2.2.2. Correcting the situation
2.2.2.1. Business-Driven Big Picture
2.2.2.1.1. EventStorming
2.2.2.1.2. Kanban
2.2.2.2. Enforcing Delegation
2.2.2.2.1. Fine-Grained Management 3.0 Delegation Poker