![]() Better for CollaborationĪs Yelp gets larger, it’s no longer feasible for everyone to memorize the core competencies of other teams. We also have Slack integrations for ad-hoc issue triage. Our monitoring and alerting systems can hook into the Ownership service to automatically alert the right team when an incident is reported. Better for Triaging IssuesĪlerting the right team to triage an incident as quickly as possible is critical to maintaining our uptime SLAs. Teams that are dependent on these services also get a good understanding of what they can expect and when. They can choose which bugs to fix, what features need to be built and what services can be deprecated. Knowing what services a team is accountable for allows that team to better plan their roadmap for maintaining those services. Teams are responsible for their own short and long term planning. ![]() Here are some reasons behind our thinking: Better for Planningĭecision-making at Yelp happens in a distributed and decentralized manner. Why does Yelp value Ownership?Īpart from being able to measure the effectiveness of a team, we generally think it is a good idea to know who owns certain code or infrastructure. When teams split, merge or get renamed, we expect the Ownership information to be updated to reflect the new teams that were formed. Eventually, we settled on requiring that owners are canonical engineering teams (more on how we keep track of canonical teams later). However, these definitions of ownership can be vulnerable to reorganizations (engineers moving teams or companies) or creative naming resulting in fictional teams owning code (the owner named “Super Friends plus Julia” was hard to track down to a real team!). It could be a single engineer, engineering team, or engineering org. Until now we have had different ways of defining an owner at Yelp. And this is how the Ownership microservice was born. These metrics can then be aggregated by team, organization, or even the entire Engineering division, so that we can identify areas that we can collectively improve. Once an entity has an owner, we can collect metrics on that entity and derive the health score (i.e., effectiveness) for that owner. But how do we know what a team is responsible for? We needed a way to assign an owner to something (let’s call this an entity) that we want to measure. In order to measure the engineering effectiveness of Yelp, we need to measure the effectiveness of its organizations and the teams that make up those organizations. EE has been investing in building tools that can communicate these changes and provide insights into what might make product teams more effective in shipping code quickly and safely. Core teams need to communicate infrastructure changes, manage the deprecation of libraries and tools, and evangelize new tooling to other teams at a regular cadence. In this prior blog post, Kent talked about how the Engineering Effectiveness (EE) organization was created at Yelp to reduce communication complexity between core teams and product teams.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |