"You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block." Absolutely. In some ways, this is my

"You can mitigate this type of territorial response by convincing them to disassociate their identity from a code block." Absolutely. In some ways, this is my biggest job as "manager". I try and rotate the team so that no one has "ownership" of a particular feature (we're self organizing but I try and coach people appropriately ;)). Sure, Bob may have been the person that originally penned a particular method, but refactoring is a fact of life, and it's likely that, if I've done my job right, over time any member of the team should be able to do a given refactor. What helps is that you explicitly have someone who worked on a particular block of code not fix any bugs related to it. Give it to someone else. They'll figure it out and make any changes. Have people pair on initial design/architecture (or have specs authored/tweaked by the whole team) so it's never solely one person's vision of how feature X should work. I've found the best programmers have a zen-like state of detachment with code they've written. Very good, but not great, programmers seem to tie up too much of their identity with their code; transitioning them from "good to great" almost always inevitably requires detachment.