OKRs from a development team’s perspective
&gt; Objective – Increase Customer Retention<p>&gt; Key Result #1 – Lifetime Customer value increase from $N to $N+5<p>&gt; Key Result #2 – Decrease Customer Churn Rate by 10%<p>I&#x27;m a developer on a team. How am I supposed to know why customers are churning? I&#x27;m three levels removed from talking to customers when they cancel. I don&#x27;t have a deep relationship to know how to add value to them.<p>Someone needs to do the research, analysis, and leg work of finding potential areas to exploit. And then someone needs to have at least some amount of vision or inspiration about how to solve that problem. Or do whatever trendy new &quot;design sprint feedback loop&quot; brainstorming session someone is tweeting about. This is the kind of stuff I hear designers and &quot;product people&quot; talking about wanting to do.<p>If you want to do that work and <i>then</i> loop in the engineering team to talk about feasibility and planning that seems fine, but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results.<p>(Until these questions can be satisfactorily answered to developers, OKRs are going to be perceived as a buzzword, flavor of the month process air-dropped in because someone saw a blog post about it)