Code ownership might not be a pressing concern when a small team of around 10 developers works on the same system. However, as the engineering team scales to 500, with hundreds of developers contributing to the same system, the dynamics change significantly. This was a challenge my organization faced from two years ago till now — a lesson learned through firsthand experience. How Does Code Ownership Affect Software Engineering Teams So Negatively? As an engineering leader, how do I handle this challenge? Builders do not own the code Builders and owners are often different people. Builders are responsible for implementing features, but code ownership typically falls to someone else. In an ideal world, builders and owners should be the same group of people. A dedicated team owns a specific domain. But, in a shared code-based environment, everyone is a builder across many domains. The code base is co-owned by many teams. Builders may not know the history of the code, we expect everything to magically work, but often, it doesn’t. We find ourselves in this mode when there is no clear ownership of the codebase: touch the code, ship the feature into production, and then leave the “code” to the next builder — along with technical debt. What Could Happen when Code Ownership is Not Transparent? The system becomes error-prone and unstable, leading to low confidence in shipping new features. Most production issues arise because builders lack a complete understanding of the domain. Small code changes can unknowingly break other parts of the system. Different builders repeatedly reinvent the wheel, wasting time and resources. The software development lifecycle (SDLC) becomes tedious and slow. Even minor changes require running full end-to-end tests, which can take over 20 hours — further compounding the issues above. Why Does This Happen? Shared Code Ownership Without Collaboration = No Ownership No Ownership of Code = No Ownership of Bugs When the on-call team tries to reach out to the domain owner for a production issue, after talking to three different teams, it ends up that no one understands the code. Confusion on Responsibility Another common scenario is that a recent builder (who has touched the code recently) gets on the support call, but the builder realizes two more teams have touched the same code recently. Who should fix the bug, then? Tremendous Business Rules Baked into Shared Common Modules There is no boundary between the business layer and the infrastructure layer. It is risky to touch one line of code in any file if the builder does not know the already baked-in business rules added by other builders. Everyone Touches the Same Code Without Talking to Each Other Under the pressure of deadlines, we tend to quickly finish projects without “wasting” time on communications. As a builder, spending time in meetings with domain owners is not something favorable. No One Owns Tech Debts Gradually, the code design is not aligned across different builders. We start seeing very strange implementations, and everyone knows the system’s stability is a problem, but who should own the tech debts? Teams Hesitate to Own Code Owning code means having more responsibilities. Teams tend to push away ownership. A typical statement is like: “My team does not have the full picture (of this feature), please reach out to someone else if you have any questions.” How to Resolve the Problem Properly? First of all, if I had a magic wand, I would assign owners’ names to each line of code. If an owner leaves, their successor’s name should be assigned automatically. Pursue Good Code Isolation and Strive for a Decoupled System. Embrace the design of microservices, where ownership is tied to each microservice. For those managing monolithic applications, define domain modules within the monolith and identify an owner for each module. When We Have to Work on a Shared Code Base … Microservices can help address code ownership issues, but they are not always the best solution for every organization. Engineering teams often align with different business stakeholders, which ties directly to funding and resources. It is not uncommon for multiple teams to maintain the same code domain to support different business workflows. For example, SSO (Single Sign-On) is a shared service that supports multiple product lines. There are two approaches to managing code ownership: Centralized Ownership: One team owns the SSO service domain and handles all requirements from various product teams (stakeholders). Decentralized Ownership: There is no centralized team for the SSO service. Instead, different builders, responsible for their respective stakeholders, work on the same code domain independently. This represents the shared codebase model. Decentralized Ownership: From No Owner to Co-Owners Builders must take responsibility for creating sustainable, high-quality code. Team leaders play a crucial role in fostering collaboration and maintaining a high standard for code quality. In the Co-Ownership World, One Team Owns the Foundation, Others Embrace Collaboration In a co-ownership model, one team focuses on building the foundational elements — base classes, templates, and interfaces — while other teams align with the design and collaborate to build their features. Using the SSO service as an example: one team sets up the identity service, creating the foundation for enabling SSO across two internal services and one external service. Other teams then follow the established design pattern to roll out SSO for additional domain services. As a Builder, Respect the Owners/Co-Owners Hold review meetings between builders and owners. Reviews should happen at multiple stages of the development cycle, from the project kickoff time-point to the post-release period. Team Collaboration Is Crucial Especially for Projects with Tight Deadlines As a builder, proactively reach out to the owners and seek their insights. As an owner/co-owner, provide support to the builder, do not limit your role to that of a gatekeeper. Otherwise, builders will stop communicating with you. Your Code is Your Asset Take care of your assets, don’t let them become your debt. Be proud to own and maintain high-quality, sustainable code. Code ownership might not be a pressing concern when a small team of around 10 developers works on the same system. However, as the engineering team scales to 500, with hundreds of developers contributing to the same system, the dynamics change significantly. This was a challenge my organization faced from two years ago till now — a lesson learned through firsthand experience. How Does Code Ownership Affect Software Engineering Teams So Negatively? As an engineering leader, how do I handle this challenge? Builders do not own the code Builders and owners are often different people. Builders are responsible for implementing features, but code ownership typically falls to someone else. In an ideal world, builders and owners should be the same group of people. A dedicated team owns a specific domain. But, in a shared code-based environment, everyone is a builder across many domains. The code base is co-owned by many teams. Builders may not know the history of the code, we expect everything to magically work, but often, it doesn’t. We find ourselves in this mode when there is no clear ownership of the codebase: touch the code, ship the feature into production, and then leave the “code” to the next builder — along with technical debt. What Could Happen when Code Ownership is Not Transparent? The system becomes error-prone and unstable, leading to low confidence in shipping new features. Most production issues arise because builders lack a complete understanding of the domain. Small code changes can unknowingly break other parts of the system. Different builders repeatedly reinvent the wheel, wasting time and resources. The software development lifecycle (SDLC) becomes tedious and slow. Even minor changes require running full end-to-end tests, which can take over 20 hours — further compounding the issues above. Why Does This Happen? Shared Code Ownership Without Collaboration = No Ownership No Ownership of Code = No Ownership of Bugs When the on-call team tries to reach out to the domain owner for a production issue, after talking to three different teams, it ends up that no one understands the code. Confusion on Responsibility Another common scenario is that a recent builder (who has touched the code recently) gets on the support call, but the builder realizes two more teams have touched the same code recently. Who should fix the bug, then? Tremendous Business Rules Baked into Shared Common Modules There is no boundary between the business layer and the infrastructure layer. It is risky to touch one line of code in any file if the builder does not know the already baked-in business rules added by other builders. Everyone Touches the Same Code Without Talking to Each Other Under the pressure of deadlines, we tend to quickly finish projects without “wasting” time on communications. As a builder, spending time in meetings with domain owners is not something favorable. No One Owns Tech Debts Gradually, the code design is not aligned across different builders. We start seeing very strange implementations, and everyone knows the system’s stability is a problem, but who should own the tech debts? Teams Hesitate to Own Code Owning code means having more responsibilities. Teams tend to push away ownership. A typical statement is like: “My team does not have the full picture (of this feature), please reach out to someone else if you have any questions.” How to Resolve the Problem Properly? First of all, if I had a magic wand, I would assign owners’ names to each line of code. If an owner leaves, their successor’s name should be assigned automatically. Pursue Good Code Isolation and Strive for a Decoupled System. Embrace the design of microservices, where ownership is tied to each microservice. For those managing monolithic applications, define domain modules within the monolith and identify an owner for each module. When We Have to Work on a Shared Code Base … Microservices can help address code ownership issues, but they are not always the best solution for every organization. Engineering teams often align with different business stakeholders, which ties directly to funding and resources. It is not uncommon for multiple teams to maintain the same code domain to support different business workflows. For example, SSO (Single Sign-On) is a shared service that supports multiple product lines. There are two approaches to managing code ownership: Centralized Ownership: One team owns the SSO service domain and handles all requirements from various product teams (stakeholders). Decentralized Ownership: There is no centralized team for the SSO service. Instead, different builders, responsible for their respective stakeholders, work on the same code domain independently. This represents the shared codebase model. Centralized Ownership: One team owns the SSO service domain and handles all requirements from various product teams (stakeholders). Decentralized Ownership: There is no centralized team for the SSO service. Instead, different builders, responsible for their respective stakeholders, work on the same code domain independently. This represents the shared codebase model. Decentralized Ownership: From No Owner to Co-Owners Builders must take responsibility for creating sustainable, high-quality code. Team leaders play a crucial role in fostering collaboration and maintaining a high standard for code quality. In the Co-Ownership World, One Team Owns the Foundation, Others Embrace Collaboration In a co-ownership model, one team focuses on building the foundational elements — base classes, templates, and interfaces — while other teams align with the design and collaborate to build their features. Using the SSO service as an example: one team sets up the identity service, creating the foundation for enabling SSO across two internal services and one external service. Other teams then follow the established design pattern to roll out SSO for additional domain services. As a Builder, Respect the Owners/Co-Owners Hold review meetings between builders and owners. Reviews should happen at multiple stages of the development cycle, from the project kickoff time-point to the post-release period. Team Collaboration Is Crucial Especially for Projects with Tight Deadlines As a builder, proactively reach out to the owners and seek their insights. As an owner/co-owner, provide support to the builder, do not limit your role to that of a gatekeeper. Otherwise, builders will stop communicating with you. Your Code is Your Asset Take care of your assets, don’t let them become your debt. Be proud to own and maintain high-quality, sustainable code.
