Ownership is critical for efficiency and quality
The best engineers/directors own their space. Ownership here isn’t about empire building but for very practical outcomes. I can flag them a bug/request some changes, and forget about it.
Most of the time, they are extremely efficient and will just get the problem fixed because they understand that the planning overhead is not worth it (filing tickets, sending cross team OKR requests, planning sprints etc.). If they can’t immediately address it, they will prioritize based on what’s best for the company without playing politics or asking for things in return. If they are not the right person to fix it, they won’t just bounce back the request but forward it to the right person, avoiding an additional back and forth.
Interestingly, this type of ownership can be exerted at all levels, including at junior ones (e.g. it includes having the right tests, appropriate monitoring, safe rollout mechanisms, polishing the process etc.). Strong ownership is the fastest way to build trust with peers – which also results in the fastest growth from my experience.
The reason I enjoyed my time in YouTube Ads is because my org was full of solid ICs with a strong sense of ownership – this means that we were just fixing problems, building infrastructure and shipping code with little (process and/or cognitive) overhead. The same is true today in my team at Databricks – we agree on our north stars/principles, so we are just shipping things (side note to mention that we still have bazillion things to do and that I’m still hiring in Amsterdam 🙂)
On the other side, teams that are constantly trying to attribute bugs/feature requests to other teams are the most difficult to work with in my experience 🙁
[LinkedIn post](https://www.linkedin.com/posts/tumichel_softwareengineering-ownership-overhead-activity-7226965361672224768-OY3c?utm_source=share&utm_medium=member_desktop