You all will agree that ownership is a trendy word lately in teams, management, etc... And it makes sense, since we all know it's a big driver to improving productivity, retention, and commitment from employees.

But at the same time, ownership can have tons of nuances depending on the company and the culture, and it's not that easy to explain or transmit, it's like creativity, rather than trying to teach it, you better have the environment to spark it.

Then, what does ownership mean in our Engineering department?

• It means moving from "it's not my code, it's not my responsibility" mantra, to, taking action in someone else responsibility for the best of the organization.

• It means taking the initiative to solve anything in the way we, as a team believes is best.

• It means sharing a sense of responsibility for both the product and the code.

That sounds great, right? but the reality is that for a long time, we have been talking about how vital is ownership in our team and preaching about it, but we realized this concept was still very ambiguous for a lot of people and maybe we need some alignment around it. How can we strive for high ownership if maybe we all are not on the same page with what it means?

For that, we decided to create a little model where we list all the basic responsibilities that a team has, called core responsibilities, and then an external layer called awareness, where we listed all the items that go in the direction of advocating the ownership that we are looking for in on our department.

And you maybe are wondering now, is there a list that represents the ownership concept in engineering teams? The answer is clearly, NO.

It's quite normal that you cannot map a concept like this to a list, as that will go directly against the concept itself. We know for sure our teams will face challenges that are not listed here, but we expect them to tackle those with this new Ownership and Shared Responsibility mindset we are establishing.

With this list, we are setting up our basic expectations not only for the Core layer but also for the Awareness layer, and with time and practice align this vision of ownership across our teams.

Our current model:

Core

The engineering team is solely accountable for these topics:

• Development lifecycle from when a feature is requested until it’s done
  • Request capture
  • Planning
  • Analysis
  • Design
  • Development
  • Testing/QA
  • Deployment
  • Instrumentation
  • Maintenance
  • Removal/Decommission
• Infrastructure
  • All environments: dev, testing, staging, production.
  • Design
  • Provisioning
  • Maintenance
  • Decommission
• Production systems
  • Monitoring
  • Alerting
  • Uptime
  • Incidents
• Breaking dependencies (Dependencies that make your product fail)
  • Payment gateways
  • Mail relay
  • Any external dependency requires a circuit breaker
• Direct cost
  • Infra
  • SaaS
  • Tooling

Awareness

The team has shared responsibility on these topics:

• Indirect costs
  • Marketing campaigns
  • Transaction costs
• Non-breaking dependencies (Examples depending on the team)
  • Google Tag Manager
  • Google Analytics
• Team boundaries & escalation points
  • Where is the limit of what we handle, who handles it from that point, and when to escalate to them
• Knowledge of the business model and flows
• Awareness of the product roadmap
• Awareness of the user flows
• Product lifecycle From creation to decommissioning
• Awareness of external provider options SaaS or external contractor vs developing it in-house