But this approach optimizes for short-term efficiency (“It’s faster for me to do it”) at the cost of poor long-term scalability (the team never learns how to do whatever it is that needs to be done). This mindset also tends to lead to all-or-nothing expertise. All-or-nothing expertise A group of people that is split between people who know “everything” and novices, with little middle ground. This problem often reinforces itself if experts always do everything themselves and don’t take the time to develop new experts through mentoring or documentation.
Kinda contradicts the policy in Ch 1 where a central team does the refactor? The central team doing the refactor are the experts; teams owning the code don't need to ramp up, creating all-or-nothing expertise.
