This is very interesting. This is similar to how Big Tech runs tech projects in a vastly different way than the “good practices” for agile/scrum commonly adopte

This is very interesting. This is similar to how Big Tech runs tech projects in a vastly different way than the “good practices” for agile/scrum commonly adopted by the industry at large. e.g. https://blog.pragmaticengineer.com/project-management-at-big-tech/ https://blog.pragmaticengineer.com/project-management-at-big... Similarly the article on OKRs describes small but critical adjustments from the OKRs cannon (Measure What Matters) that only scale-ups and Big Tech seem to know about. Everyone else too often tries to: 1. Cascade OKRs down from the top, sometimes outside Product & Engineering (in teams that are more process- than project-based like sales), killing team-level autonomy in the process. 2. Write Objectives for time consuming activities, rather than having a non-OKR work / BAU section that captures it. This makes it much harder for other teams to rely on OKRs to understand the context of what’s changing and to have key cross-team alignment conversations. 3. Focus on OKR tracking and scoring, possibly through a dedicated tool. This misses the point that the primary value of a plan is in the planning, not the deliverable, and risks making OKRs a performance management tool (at which point teams discuss KRs endlessly to sandbag rather than setting stretch goals and moving on). But when you say the local implementation looks both overkill and misguided compared to what works at other tech shops, people point to the OKR book as what drives their own implementation. :)