# Software teams own experiences not repos Created On: 01-10-2023 11:32 am Type: #note/evergreen🌲 Topics: [[Software Engineering]], [[Ownership]] --- Most software engineering teams or squads focus on delivering specific value or impact at different levels through the solutions, services, or domains (will default on this term, but let it be interchangeable) they own. The value that they create through these domains often has targeted consumers in which benefit from their investment. In most cases, those benefits are aligned with and or derived from organizational goals. The interesting thing is that the above statement is idealistic. A lot of engineering teams tend to narrowly focus on their stakeholders and limit the potential for broader stakeholder impact. This often manifests in very "technically driven" places where teams scope of ownership is reduced to concept of the services they own. The challenge is that we need to challenge to think about evolving the definition of the stakeholder "experiences" that they own as opposed to the repos, domains, services, etc. that they own. This "experience" approach drives a stronger sentiment of understanding indexing stakeholders - "what is the end-to-end experience of our solutions and who does that impact?" It additionally bolsters the team to take greater ownership and advocacy for the areas that they're now are realizing are part of this "experience". One tangible example of this I can point to was at [[01 Ibotta]]. There were a lot of engineering teams missed the impact and value that they created in the data engineering and analytics teams within the organization. The demarcation line between the squad and the data lake was their business event emission. I advocated that we should strive for teams to own experiences, which should encompass more downstream stakeholders.