OKR #5 : run et build : pourquoi les mélanger épuise ton organisation ?
Le run et le build ne se pilotent pas de la même façon. Les mélanger épuise l'organisation et empêche la transformation. Voici comment les séparer concrètement.
Tu passes tes journées à éteindre des incendies : un client mécontent, un recrutement qui tarde, une réunion qui déraille. Et le soir, tu te demandes pourquoi tu n'as pas avancé sur ce qui compte vraiment, la structure, la vision, le futur que tu es censé construire.
C'est un problème de confusion entre deux univers qui n'ont rien à voir : le run et le build.
Tant que tu n'as pas séparé les deux, ton organisation s'épuisera à bien exécuter sans jamais vraiment se transformer.
Deux univers, deux logiques
Le run, c'est le présent. C'est ce qui rapporte de l'argent aujourd'hui : l'exécution, les process, la performance opérationnelle, les ventes, le service client, la livraison, la paie. Sans run solide, pas d'entreprise viable. Le run se mesure avec des KPI, des indicateurs qui disent si ce qui tourne tourne bien.
Le build, c'est le futur. C'est ce qu'on construit pour que l'entreprise de demain existe : la structure, les managers, la culture, les nouveaux marchés, les process qui n'existent pas encore. Le build se pilote avec des OKR, des objectifs qui disent où on va et des résultats clés qui diront si on y est arrivé.
Ces deux univers ont des logiques radicalement différentes. Le run s'améliore de façon itérative, le build se construit par transformations successives. Le run se mesure chaque semaine, le build se revoit chaque mois.
Ce qui se passe quand on mélange
Quand run et build coexistent dans les mêmes instances, les mêmes outils, les mêmes conversations, c'est toujours le run qui gagne. Parce que le run est urgent, parce qu'il a des conséquences immédiates si on ne s'en occupe pas, parce qu'il crée de l'adrénaline.
Et le build attend. Il attend le bon moment, il attend que le run soit stable. Mais le run n'est jamais vraiment stable dans un scale-up post-levée.
Résultat : l'entreprise s'épuise à bien exécuter sans jamais se transformer. Le fondateur continue de porter parce que la structure qui lui permettrait de s'appuyer sur les autres n'a jamais été construite. Et un an après la levée, les mêmes problèmes existent, juste à plus grande échelle.
Comment séparer les deux concrètement
La séparation run/build n'est pas philosophique. Elle est opérationnelle. Elle se fait à trois niveaux :
Les instances. Le run a ses propres réunions, courtes, hebdomadaires, centrées sur les KPI et les alertes opérationnelles. Le build a ses propres réunions, mensuelles, centrées sur les OKR et les engagements. Jamais les deux dans la même réunion.
Les outils. Le run se pilote avec un tableau de bord KPI mis à jour en continu, le build se pilote avec les OKR et leurs résultats clés, revus chaque mois. Jamais les mêmes métriques dans les deux espaces.
Les personnes. Les instances de run réunissent ceux qui opèrent, les instances de build réunissent ceux qui construisent. Ce n'est pas la même liste, même si certaines personnes apparaissent dans les deux.
Un exemple concret
Thomas, fondateur post-Série A, 35 personnes. Avant la séparation, ses réunions hebdomadaires mélangeaient tout : les chiffres de la semaine, les problèmes RH, les décisions produit, et les discussions sur la stratégie. Tout le monde repartait épuisé et rien n'avançait vraiment.
Après la séparation : le lundi matin est dédié au run, 45 minutes, KPI de la semaine, alertes, décisions opérationnelles urgentes. Le premier mercredi du mois est dédié au build, 2 heures, revue des OKR, avancement des jalons, ajustements stratégiques.
Deux espaces distincts, deux rythmes distincts, deux types de conversations distincts.
Thomas a récupéré du temps. Ses managers ont commencé à porter vraiment. Et le build a commencé à exister.
Ce que tu fais dès lundi
Regarde ton agenda de la semaine dernière. Pour chaque réunion, demande-toi : est-ce que c'était du run ou du build ? Si la réponse est "les deux", tu as trouvé ton premier chantier. Sépare ces réunions en deux instances distinctes avec des ordres du jour différents.
pour aller plus loin
Run et build ont chacun leur outil de pilotage. La distinction KPI et OKR : OKR #6.
Tu veux distribuer la responsabilité du build à tes managers : OKR #7.
Tu veux organiser le cycle complet dans le temps : OKR #9.
