We care a lot about "ownership" in our teams. In fact, its one of our core values. But I don't think we define it the way you mean here. To us, it means putting

We care a lot about "ownership" in our teams. In fact, its one of our core values. But I don't think we define it the way you mean here. To us, it means putting care, professionalism, and follow-through into the feature or release you're working on (as others have mentioned). Did you put thought into your design and seek feedback before you started coding? Did you confirm your assumptions about how things work now? Did you write/update tests? Did you write/update documentation? After release/deployment to production, did you verify acceptance criteria and monitor performance? That's what we mean when we say "ownership". Your question implies a single person owning a specific feature or system component ad infinitum. That's generally a bad idea. Yes, some people will naturally have more experience/expertise in some areas. Yes, those people should be called to review PRs/releases in those areas. But your long-term goal should be to increase your bus factor[1] and spread knowledge. It is a win-win: it improves velocity and reduces risk for your org, while also giving your engineers a chance to learn and grow professionally. Long-term silos of ownership shouldn't be your goal. [1] https://en.wikipedia.org/wiki/Bus_factor https://en.wikipedia.org/wiki/Bus_factor