La cascade des OKRs est mauvaise pour les startups

"Avoir des objectifs améliore la performance. Mais passer des heures à cascader des objectifs du haut vers le bas de l'entreprise ne le fait pas. Cela prend beaucoup trop de temps et il est trop difficile de s'assurer que tous les objectifs sont alignés."
Lazlo Bock, Ancien VP des Opérations RH @ Google

Cette citation à elle seule pourrait résumer tout l'article. La cascade des OKRs est l'une des premières questions que nous posent les équipes qui adoptent Tability, et ma réponse est toujours une variante de « vous ne voulez probablement pas faire ça ».

Cascader séduit vu d'en haut, mais semble pénible vu d'en bas

Cascader semble formidable en théorie – imaginez pouvoir suivre chaque objectif du sommet jusqu'à la base de l'entreprise et voir comment chaque équipe contribue au bien commun. Nous y gagnerions une telle clarté ! Et c'est sûrement aussi un excellent moyen de garder tout le monde aligné puisque tout est connecté.

Magnifique.

Mais les entreprises ne ressemblent guère à une rangée de dominos (ni à une équipe de football – clin d'œil). J'ai déjà écrit sur les inefficacités de la cascade des OKRs, mais je veux ici souligner d'autres problèmes :

• Les humains sont généralement mauvais pour faire des prédictions
• Les OKRs devraient servir à créer des conversations, pas du travail de maintenance

Il faudrait être un stratège exceptionnel pour faire fonctionner la cascade des OKRs. La moindre erreur au sommet peut envoyer le reste de l'organisation droit dans un mur. Un mauvais résultat clé peut rapidement faire boule de neige et amener toute l'entreprise à poursuivre les mauvais résultats.

Avec la cascade, vous devez être excellent pour prédire ce qui va fonctionner. Et c'est précisément pour cela que ce n'est pas un modèle à suivre.

Des entreprises comme Netflix, Airbnb, Amazon mènent des centaines d'expériences chaque mois parce qu'elles savent qu'elles se trompent – même avec des centaines des esprits les plus brillants concentrés sur leurs problèmes. Il n'y a aucune chance qu'une startup tirée dans tous les sens puisse prendre des décisions parfaites, et il est d'autant plus important pour elle d'être agile et flexible.

Cela nous amène au second problème de la cascade des OKRs. Elle nous pousse à traiter nos objectifs comme un graphe en réseau. Les managers s'attendent à pouvoir explorer toute l'entreprise en détail à tout moment. Chaque changement dans les OKRs déclenche une danse autour des tableurs et des documents pour réparer les relations. Résultat : votre équipe se préoccupe plus de gérer le graphe que de discuter des OKRs elles-mêmes.

Franchement, c'est une autre forme de micro-management.

Traitez vos OKRs comme des vecteurs, pas comme des graphes

Une meilleure approche consiste à traiter chaque équipe comme son propre vecteur. Vous pouvez ensuite utiliser les OKRs comme un moyen simple de voir la direction de chaque équipe et de vous assurer qu'elles convergent toutes vers un objectif commun.

‍

Les OKRs fonctionnent mieux lorsque vous les utilisez comme un outil de communication plutôt que comme un moteur de reporting. Le framework offre à votre organisation un langage commun pour parler de concentration et de progression entre les différentes fonctions. Profitez-en pour créer des boucles de rétroaction rapides entre les outputs et les outcomes.

Organiser des revues de progression hebdomadaires (OKRs + roadmap) est un excellent moyen d'arrêter de s'inquiéter des mauvais objectifs. Le désalignement apparaîtra naturellement après quelques itérations, et les corrections sont faciles à apporter.

Le but de ce processus n'est pas la perfection. C'est l'agilité.

L'alignement ne doit pas signifier un contrôle strict sur le travail de votre équipe. Il signifie avoir de la clarté dans toute votre organisation. Abandonnez la cascade si vous voulez permettre à votre équipe d'avancer vite, et remplacez-la par de meilleures façons de vous synchroniser sur la progression.

La technologie, c'est bien, mais nous aussi

Il est toujours tentant de résoudre chaque problème avec plus de code et de fonctionnalités. Pourquoi ne pas construire un graphe ? Pourquoi ne pas injecter du machine learning ? Pourquoi ne pas suggérer des dépendances ?

Pour nous, la réponse est que nous pensons que les humains ont toujours l'avantage quand il s'agit de donner du sens à des données complexes. Parfois, il vaut mieux garder les choses simples et remplacer la complexité par les bonnes conversations.

Pour aller plus loin

• Regardez la conférence de Whitney O'Banner Bottoms Up With OKRs.
• Lisez notre article sur le coût de la cascade des OKRs.
• Découvrez comment traiter vos OKRs comme du code.