Je vois beaucoup de mauvais OKR (objectifs et résultats clés). Habituellement, ce ne sont que des KPI (indicateurs de performance clés) portant le nom d'OKR. Vous les connaissez parce qu'ils ont tendance à être quelque chose comme

Objectif : livrer le produit x

Résultat clé : le produit x est en production

Objectif : favoriser l'adoption du produit y

Résultat clé : 5 équipes intégrées au produit y

Dans cet article, j'ai décidé d'écrire ma définition de ce à quoi ressemble un bon OKR. Ma pensée a évolué à partir de ce que j'ai appris il y a longtemps dans des discussions, des articles de blog et des livres dont je me souvenais à moitié, et est maintenant basée sur mon expérience de les utiliser pour fixer des objectifs d'équipe au cours des dix dernières années environ.

Objectifs

L' objectif est de nature narrative et exprime l'orientation stratégique et l'opinion sur la réalisation de ce résultat, et pas seulement le résultat général que vous recherchez.

Par exemple, je me suis souvent retrouvé dans le rôle de diriger des équipes qui font partie d'un effort de migration vers un cloud public. Pour une entreprise de toute taille/complexité, une migration vers un cloud public est une initiative pluriannuelle. Ainsi, bien que je puisse avoir un objectif permanent : « déplacer l'entreprise vers le cloud » ou « accélérer l'adoption du cloud » ou autre, je ne fixe généralement pas un objectif aussi large.

Au lieu de cela, je regarde ces travaux potentiels que nous pensons devoir faire, les problèmes que nous rencontrons avec l'accès au cloud, et j'essaie d'identifier le prochain élément clé de la stratégie sur lequel nous devons nous concentrer. Par exemple, une année, l'objectif était quelque chose comme :

Rendre (nom de l'entreprise) Cloud Ready

Cet objectif était large et englobait des travaux qui concernaient directement l'activation et l'utilisation du cloud public, mais il couvrait également des travaux qui poussaient nos applications à être davantage natives du cloud via la conteneurisation et d'autres améliorations sous-jacentes, qu'elles migrent vers le cloud à ce moment-là. ou non. Cet objectif a exprimé l'opinion que, que nous allions tout déplacer vers le cloud public ou non, les pratiques sous-jacentes qui sont nécessaires si vous voulez avoir une architecture et des opérations "cloud natives" sont importantes à faire avancer.

J'ai une exception à la rédaction d'objectifs qui expriment une opinion, et c'est lorsque j'ai un objectif qui exprime une valeur et un domaine d'intérêt permanents. Pour moi, c'est toujours "l'excellence opérationnelle". Chaque année, j'établis un OKR d'excellence opérationnelle qui balise les projets critiques nécessaires pour résoudre des problèmes tels que, par exemple, la migration Python 3, la réduction de la charge de travail dans les systèmes critiques ou d'autres domaines majeurs axés sur l'opérabilité et la fiabilité. Je fais cela parce que je veux souligner que ce travail est aussi important pour moi que d'autres initiatives clés, et en outre que je m'attends à ce que toutes mes équipes se concentrent sur cela, peu importe ce qu'elles font d'autre.

Principaux résultats

Les objectifs expriment une stratégie de haut niveau avec une sorte d'opinion ou d'énoncé de valeurs. Les résultats clés fournissent des signaux agrégés et des mesures de la façon dont vous vous attendez à voir l'impact ou les progrès vers la réalisation de cet objectif.

La tentation des résultats clés est de les rendre plus liés au travail effectué qu'à l'impact. Si vos principaux résultats concernent tous les systèmes d'expédition, la finition de projets ou le respect des jalons de livraison, vous mesurez simplement si vous faites ou non ce que vous avez estimé pouvoir faire. Et ce n'est pas mal, exactement, mais il a deux inconvénients.

Le premier inconvénient est qu'il ne permet pas beaucoup de flexibilité dans la façon dont vous atteignez votre objectif, et c'est assez limitant ! L'une des frustrations des ingénieurs face à la planification est qu'elle peut être très rigide. Lorsque vous parlez d'un processus annuel d'élaboration d'OKR larges, vous essayez non seulement de prédire ce que vous ferez dans l'année, mais aussi quels projets sont les plus importants à réaliser. Si les circonstances changent et qu'il s'avère que vous n'avez pas besoin de déplacer tout le monde vers EKS, mais que vous devez plutôt déplacer un groupe de personnes vers ECS, par exemple, votre KR de "migrer 100 applications vers EKS" devient immédiatement rouge, et vous devez le réécrire en faveur du "déplacer 50 applications vers EKS et 50 applications vers ECS" tout aussi rigide. Dans la mesure du possible, je pense qu'il est préférable d'écrire des KR qui permettent une flexibilité dans la façon dontils sont atteints tout au long de l'année.

Cela nous amène au deuxième inconvénient des KR de sortie de travail : ils ne tiennent pas compte de l'impact. Il s'agit d'un angle mort particulier des équipes d'ingénierie de type plate-forme, qui se concentrent sur la construction et la livraison d'une chose qu'elles pensent devoir construire et livrer sans s'arrêter pour se demander si c'est la chose la plus utile pour aider leurs utilisateurs à atteindre leurs objectifs. Lorsque vous rédigez des KR qui portent sur l'impact (réduisez le temps d'intégration d'une nouvelle application cloud de 2 semaines à 2 jours (ou, de 50 %, ou...)), vous obligez les gens à se poser la question : comment mon travail va-t-il livrer impacter?

Il y a en fait un troisième inconvénient aux KR de sortie de travail, celui qui ressort davantage lorsque vous dirigez de plus grandes organisations. Ma règle personnelle des OKR est : pas plus de 5 objectifs, chacun avec pas plus de 4 à 5 KR. Quelle que soit l'unité de surveillance la plus cohérente que vous ayez, essayez de vous en tenir à cela, que votre équipe compte 50 ou 500 personnes. Lorsque vous essayez de représenter un large portefeuille de travaux dans de nombreuses équipes diverses, vous n'avez pas de place à perdre. un KR sur quoi que ce soit de moins qu'une initiative majeure, et les KR de sortie de travail peuvent être un gaspillage d'un précieux spot de KR.

Vous allez avoir des KR de sortie de travail, c'est inévitable. Il y a des choses qui doivent être faites, et le travail de les faire est suffisamment difficile pour que vous vouliez mesurer cela comme un progrès à rapporter. Mais ne soyez pas paresseux ! Examinez chaque résultat de travail KR et demandez-vous vraiment s'il existe une meilleure façon de mesurer cela qui repose davantage sur l'impact que sur la livraison pure.

Tout cela est dur

Cela revient à mon point initial : les OKR sont difficiles. Vous devez avoir une opinion stratégique pour rédiger de bons objectifs, et vous devez avoir de bonnes idées sur ce que vos clients veulent, ce que votre équipe pourrait offrir et ce que vous pourriez être en mesure de mesurer pour créer de bons KR. Vous devez comprendre potentiellement un très grand nombre d'équipes et de projets pour créer des OKR à la fois inspirants et agressifs, mais pas impossibles.

Et puis, bien sûr, il y a tous les cas d'exception qui vous tentent. J'ai une exception pour l'excellence opérationnelle, et une fois que vous commencez là, il est tentant d'ajouter de plus en plus d'exceptions. Nous devrions toujours avoir un OKR pour la culture d'équipe/l'embauche/le développement des talents. Nous ne pouvons pas omettre de reconnaître la fonction X, nous devons donc créer quelque chose de spécial pour ce groupe. Je ne peux pas dire que mon modèle de 4 à 5 O chacun avec 4 à 5 KR dépasse vraiment quelques centaines, ou avec chaque type d'entreprise. Et il y a probablement des équipes qui n'ont tout simplement pas besoin d'OKR, en raison de la nature de leur travail, du contrôle sur la façon dont elles sont mesurées, de leur taille, etc.

C'est la chute des OKR. Ils sont difficiles, mais vendus comme quelque chose que tout le monde devrait faire, donc tout le monde les fait mal, et la plupart des gens ne voient aucune valeur en conséquence. Vous n'êtes pas obligé de faire des OKR (sauf si vous travaillez pour moi, auquel cas vous pourriez le faire). Si vous n'allez pas au moins essayer de vous mettre au travail pour en écrire de bons, vous ne devriez pas les faire ! Mais si vous faites le travail, ils vous obligeront à réfléchir de manière plus stratégique à vos objectifs et à poser des questions difficiles sur l'impact que vous espérez obtenir avec eux et sur la manière dont vous le mesurerez. Les bons OKR racontent une histoire sur ce qui est important, ils vous aident à inspirer les gens à réfléchir à la raison pour laquelle ils travaillent sur ce sur quoi ils travaillent, et je pense qu'ils portent un peu d'énergie qui vient de voir comment tout cela s'emboîte dans un forme succincte.