Je fais trois constats quand je réfléchis aux sujets de travail en équipe et aux outils qui permettent d’être productif et efficace ensemble :

a. Internet regorge de nouveaux outils

Les outils de gestion de projets et de productivité sont toujours plus adaptés à des besoins qui évoluent, ont des designs de plus en plus propres et des prix toujours plus attractifs. Une balade sur ProductHunt ou les groupes facebook dédiés aux startups montre la grande activité sur ces sujets.

b. les frontières peuvent être poreuses entre les différents outils 

Chaque produit – selon le canevas NPE – a une fonctionnalité maîtresse, la plupart du temps cependant sont développées des fonctionnalités annexes qui viennent le compléter (l’exemple récent d’Asana avec ses deux nouvelles briques “Portfolio” et “Goals”).

c. Ces outils sont inconnus de recrues issues du monde de la grande entreprise.

Elles prennent parfois un bain glacé de nouveauté en arrivant dans une startup, ce qui constitue un défi à la fois pour elles et pour nous dans l’atteinte de ces deux objectifs : réussir l’onboarding et obtenir des résultats avant la fin de période d’essai

Photo d’un TOTEM

Chez TOTEM par exemple, notre suite coeur d’outils peut sembler restreinte : Slack pour la communication instantanée, la G-Suite pour tous types de supports de travail, Asana pour la gestion des projets, Lattice pour le suivi des OKR, Salesforce pour la gestion du portefeuille, Airtable pour les POC, Notion pour la gestion des connaissances. Pour autant, la nouveauté et le nombre étonnent souvent les nouvelles recrues, surtout celles qui sont habituées à des set-up plus traditionnels. Pour découvrir d’autres set-ups d’outils, n’hésitez pas à aller faire un tour sur l’article des 20 outils utilisés par les équipes de Partoo.

Avoir de nombreux outils dans une startup est très commun, n’est pas forcément un problème mais peut être dangereux. 

Comment éviter le brouhaha que ces outils – bien qu’ultra performants – peuvent amener dans une organisation et comment au contraire en faire des exhausteurs de performance collective ? Voici mon expérience sur les moyens d’y arriver.


1. Identifier le besoin

Le besoin peut être évident ou survenir après un certain temps de “souffrance”, qui laisse sentir une perspective d’amélioration :

  • il faut qu’on améliore la façon de collaborer et de communiquer entre BU
  • il nous faut rendre accessible et facilement trouvable tout le savoir de la boîte
  • il faut qu’on gagne du temps sur la récupération des factures et le recoupement avec l’extrait des comptes chaque mois
  • il faut qu’on puisse tenir l’avancée sur les OKR de la boîte à jour et la rendre lisible en un coup d’oeil (cf. article sur le sujet dans Tribes)

Vous l’aurez remarqué, ces phrases ne commencent jamais par : “il nous faut un outil pour…”, c’est un écueil fréquent. L’outil est un moyen pour résoudre un problème dans la boîte, mais c’est l’identification de ce problème qui est la plus critique. C’est donc à la racine du problème qu’il faut remonter : pourquoi on est bloqué, quel est le problème sous-jacent ?

C’est une fois le besoin ou le problème identifié qu’on cherche une solution. Cette solution n’est pas forcément un nouvel outil. 

La réponse au besoin n’est pas forcément un outil

Par exemple, les devs chez nous avaient besoin de raccourcir la phase de validation de leur code et d’obtenir des retours plus rapides de leurs business contributors. Auparavant il leur fallait planifier une session de démo avec le BC en question, pas évident étant donné les agendas. Ils ont depuis créé un channel #demo sur Slack, où ils postent des vidéos de la fonctionnalité développée et ping les business contributors qui réagissent bien plus vite.

On en passe donc par une phase de clarification : comment souhaite-t-on concrètement répondre à ce besoin ? Faire du benchmarking, récupérer des retours d’expérience dans d’autres boîtes, sur des forums permet d’identifier très facilement 5-10 méthodes et outils qui pourraient faire ce qu’on veut.

Grâce à ce travail, le plus gros, on a identifié le but à atteindre. Reste à connaître les autres éléments importants : quel temps avons-nous pour résoudre le problème, quelle est exactement la valeur qu’on cherche à récupérer d’un tel projet, peut-on la quantifier.

2. Construire la solution 

En fonction des ressources disponibles dans l’équipe (collaborateurs, budget) et du temps qu’il est possible d’allouer à la résolution du problème, les solutions identifiées vont être plus ou moins pertinentes.

L’exemple des OKRs

Par exemple : tenir l’avancée sur les OKR de la boîte à jour et la rendre lisible en un clin d’oeil

  • on peut le faire sur un Google Sheet
  • on peut le faire sur outil polyvalent, exemple Notion ou Asana depuis peu
  • on peut le faire sur un outil spécialisé, type Lattice

Chez TOTEM nous avons d’abord fait le choix de nous approprier la méthodologie OKR sans outil spécifique. Nous avions un template de GSheet qui nous permettait de récolter les propositions de chaque contributeur, qui étaient retravaillées à l’échelle de leur BU, puis intégrées aux OKR globaux. Nous avons suivi les OKR ainsi pendant deux trimestres. 

Nous avons donc :

  1. testé la méthodologie : structuration des OKR en début de trimestre et leur suivi pendant le trimestre avec GSheet
  2. validé la méthodologie OKR dans l’équipe et identifié comment nous souhaitions l’utiliser,
  3. identifié que le suivi était difficile en l’état et les mises à jour aussi
  4. identifié aussi que les lancements de trimestre étaient douloureux avec ce set-up et que nous perdions une à deux semaines avant de vraiment rentrer dans le dur.

Nous ne souhaitions pas investir plus de temps pour améliorer notre GSheet, mais plutôt pour peaufiner la rythmique trimestrielle et nous concentrer sur le business.

Nous avons travaillé sur une rythmique trimestrielle plus efficace, permettant en 4 semaines de dresser le bilan du trimestre qui s’achève, dessiner la direction pour le trimestre à commencer, aligner tous et toutes sur les actions à prendre et paramétrer le tout pour suivi.

Le choix de l’outil : Lattice

Nous avons trouvé un outil qui permettrait de répondre au reste des besoins : une meilleure diffusion, lisibilité et mise à jour des OKR.

Nous avons gardé le template GSheet pour récupérer la proposition individuelle de chacun en lien avec les objectifs globaux communiqués en amont pour le trimestre. 

L’ensemble est centralisé en début de trimestre par le CEO dans l’outil que nous avons choisi : Lattice. En “paramétrant les OKR”, il s’assure de la cohérence des initiatives de chacun avec la direction fixée, vérifie que la charge est correcte et bien répartie sur les bonnes personnes. Celles-ci sont ensuite responsables de mettre à jour hebdomadairement leur avancement sur l’outil, conçu pour permettre une vue d’ensemble très rapide.

La réponse apportée (le quoi, après le pourquoi et le comment) est donc un mix entre l’amélioration de nos process internes et la mise en place d’un outil, que nous avons finalement décidé d’adopter. 

Car adopter un nouvel outil ce n’est pas seulement la ligne de coût mensuelle supplémentaire sur le cash burn, c’est surtout les heures passées à obtenir l’adhésion sur l’outil, les heures de formation des différentes équipes sur l’outil (et donc l’identification d’une méthodologie de formation efficace adaptée à la taille de l’entreprise), le temps de rodage de tous, et ce qu’il change dans l’organisation de manière plus générale. Tout cela se pèse et se pondère.

3. Inscrire le nouvel outil dans l’existant

a. Bien connaître sa géographie

Comme je le disais en introduction, il peut se trouver une certaine porosité entre les différents outils choisis. Super important donc : inscrire tout nouvel outil dans le paysage des outils déjà en place, clarifier auprès de tous son utilité et surtout comment on va l’utiliser par rapport aux autres outils.

C’est arrivé chez nous avec la mise en place de Notion. Nous avons identifié que c’était le bon outil pour répondre au besoin suivant : rendre accessibles et facilement trouvables tous les standards RH de la boîte d’une part, et tous les contenus métier d’autre part. Nous l’avons choisi pour la flexibilité d’organisation des contenus et pour sa feature phare : la recherche. D’ailleurs si ce sujet de la gestion de la connaissance vous intéresse, consultez aussi l’article de Thibault.

Nous avons aussi vu qu’il pourrait remettre en question le bien-fondé d’Asana et Lattice tant il est puissant. Cela nous a poussés à clarifier dans notre organisation le rôle de chacun de ces softs et faire en sorte qu’il n’y ait pas de redondance. Le résultat a été au-delà de nos prévisions : il a permis d’installer Notion dans l’équipe qui en a rapidement adopté l’usage et les règles mais il a en plus rendu l’usage d’Asana beaucoup plus performant.

Ici on comprend bien que la décision sur un nouvel outil doit être réfléchie au-delà du simple bénéfice direct qu’il apporte. Il faut une vision globale du fonctionnement de l’équipe, de ses besoins et bien connaître les usages, les routines et les outils déjà en place

Ces adaptations peuvent constituer un changement important pour les équipes. Aussi avant de mettre en place un nouvel outil est-il important de les préparer, de leur montrer les améliorations attendues, de les rendre enthousiastes. On y reviendra.

b. Construire l’usage et la rythmique associés et les ancrer

Grâce à la réflexion qu’a amenée l’arrivée de Notion, Asana n’est plus pollué des infos et des modes opératoires que l’on retrouve désormais dans Notion. Nous nous en servons pour la gestion des projets intra comme inter équipes et la transmission à tous des roadmaps et leur actualisation régulière (information non statique). La rentabilité d’Asana sur la performance s’en est vue grandement augmentée, et les routines liées à cet usage unique et délimité se sont imposées d’elles-mêmes.

Dire à quoi sert un outil, c’est aussi et surtout dire à quoi il ne sert pas. Voici par exemple ce que nous avons décidé en interne pour l’utilisation de Notion :

Une fois que l’usage (qu’est ce qu’on fait avec) est clair, il reste à ancrer la routine (qui se sert de l’outil et quand).

Car un outil, aussi puissant soit-il, n’a aucune utilité s’il n’est accompagné d’une routine dans l’équipe qui soit bien observée. Salesforce est une machine de guerre, mais si aucun sales ne renseigne ses opportunités ni ne les met à jour sur une base régulière, il n’y a rien à en tirer, ni pour eux, ni pour le manager qui cherche à connaître la valeur de son pipe.

4. Accompagner la prise en main par tous

La mise en place commence par une bonne communication

Les équipes peuvent parfois attendre l’outil de pied ferme, parfois elles n’en voient pas l’intérêt et redoutent son arrivée #yetanothersaas

Cela ne veut pas du tout dire qu’il est justifié / n’est pas justifié de mettre en place l’outil. 

Dans un cas comme dans l’autre, une bonne communication sur l’arrivée de l’outil, ce qu’on en attend (pour éviter les déceptions et casser les réticences) est essentielle. 

Cela permet en tout état de cause de checker que le besoin a bien été identifié et que les fonctionnalités de l’outil telles que présentées convainquent les équipes de sa capacité à y répondre. En théorie le sujet a été bien bossé si l’outil a été validé, mais communiquer tôt dans le projet permet d’être sûr qu’on n’est passé à côté de rien. 

Les meneurs du projet peuvent mettre toutes les chances de leur côté en préparant bien l’arrivée de l’outil et en déterminant précisément les différentes phases de mise en place.

Quelques idées pour y parvenir :

  • Faire un rétroplanning et se fixer un objectif de temps pour d’adoption par les équipes de l’outil
  • Faire du teasing 
  • Planifier une formation sur quelques personnes qui deviendront des championnes
  • Rédiger une présentation, des modes opératoires sur les fonctionnalités clé et les principales actions qui vont être effectuées sur cet outil
  • Planifier plusieurs sessions de formation pour onboarder tout le monde
  • Identifier des ambassadeurs qui vont aider à la diffusion
  • Créer un mouvement autour de l’outil, l’inscrire dans la culture en créant des expressions, des gimmicks, des memes, des emojis
  • Vérifier l’adhésion un semestre plus tard grâce à un sondage par exemple
  • Vérifier l’efficacité réelle grâce à l’étude des indicateurs de succès qu’on aura identifiés

Cette liste n’est pas exhaustive et je serai très intéressée d’avoir d’autres bonnes pratiques à tester 😉

Pour la mise en place de Notion, des ambassadeurs se sont désignés dans chacune des grandes équipes et travaillent avec moi à évangéliser sur la rédaction et la consultation des contenus dans leurs équipes respectives. 

Nous nous voyons une fois toutes les deux semaines pour faire le point, et utilisons Asana pour suivre l’avancement de nos projets d’évangélisation et de documentation respectifs.

Une petite espièglerie que nous avons mise en place : dès que nous voyons un contenu destiné à Notion sur le Drive ou Asana, nous le déplaçons sur Notion, mais nous ne le supprimons pas encore d’Asana ou du Drive, nous laissons une tâche ou un document, qui ne contiennent que le lien vers la page Notion où l’info est désormais disponible.

****

J’espère que cet article pourra vous être utile, je serai ravie d’échanger si vous rencontrez une problématique de cette nature, n’hésitez pas à me contacter. Si vous souhaitez partager vos méthodes pour conduire le changement, la stack d’outils de votre entreprise, n’hésitez pas à proposer votre contribution à Tribes !