Changer de rôle et de changer de boîte en même temps est un double challenge mais cela me forçait à compter sur mon équipe et passer du temps à observer

Hier, j'ai fêté mes six mois en tant que manager. 

Je pense que j’ai eu le double challenge de changer de rôle et de changer de boîte en même temps. 

Dans ma tête, j’étais tellement convaincu qu’une réussite professionnelle ne veut pas dire devenir manager. Et quand j’ai eu l’opportunité, ça m’a troublé un peu parce que c’était un peu l’inverse de ce que je m’étais toujours dit. 

Donc, lorsque je passais les entretiens, je me suis concentré à fond sur le changement de rôle et pas assez sur le changement de boite.

J’ai pris tellement de temps à réfléchir sur « Est-ce que c’est pour moi ou pas ? » que j’ai oublié que je changeais de boîte. 

• Du coup, ce qui m’a pris un peu de temps au début, c’est l’adaptation à une nouvelle boîte. Chez Doctolib on est dans les 2000. 
• Chez Getaround, même s’il y avait le rachat de Drivy en Europe, on n’avait pas fusionné des équipes, du coup, à Getaround Europe, on était autour de 100. 

Juste la différence entre la taille des boîtes me prenait du temps à m’adapter et aussi, il faut commencer à créer des relations avec des collègues, ça peut être mon équipe mais aussi des gens d’une autre équipe et tout un nouveau produit à comprendre. 

L’avantage de ce processus de découverte c’est que ça m’a obligé à ne pas micro-manager car tout était nouveau pour moi.(les nouveaux managers peuvent avoir une tendance de micro-manager certaines choses parce qu’ils ont du mal à lâcher le travail en tant que IC.) 

Vu que c’était un nouveau produit avec de nouveaux utilisateurs dans un nouveau domaine ; j’ai dû poser des questions aux gens au sein de mon équipe parce que je ne captais rien par rapport à plein de trucs. 

Avec un peu de recul, c’est peut être même une bonne chose de changer à la fois de rôle et de boîte en même temps. 

Comme ça je dois vraiment compter sur les gens de mon équipe, et j’ai beaucoup de confiance en eux grâce à ça parce qu’ils connaissent mieux le produit que moi. Ils connaissent mieux certains types d’outils que moi, et ça aide beaucoup.

Au fond, je pense que le plus important pendant les premiers mois c’est de prendre le temps d’observer et de ne pas te lancer dedans trop vite. 

Dès qu’on est vraiment onboardé et que l’on passe le cap de “En onboarding” à “ je suis opérationnel”, c’est hyper dur de revenir en arrière, voir impossible. 

Après ce temps en observation, il faut avoir un impact, il faut montrer que je suis capable. Basé sur mon temps à observer, j’ai remarqué qu’on pourrait mieux structurer l’équipe, et comment on s’occupait des projets, sur quelles fonctionnalités travailler.

J’ai remarqué que l’équipe devrait être un peu plus structurée comme les product designers ou les PM. Eux, ils ont des domaines de produits qui sont assez réduits. En UX writing on est moins nombreux, du coup nous étions 100% transversaux. Mais en fait trop. Nous n’avions pas besoin d’être 100% transversaux non plus. 

Le fait de prendre du temps à observer, j’ai pu identifier comment:  

• Je pouvais avoir un impact, par rapport aux gens au sein de mon équipe pour mieux gérer le travail, 
• Mais c’est aussi l’impact vis-à-vis des stakeholders parce que j’ai pu montrer que je ne suis pas forcément là pour juste continuer à faire comme on a fait avant. 
• Ça implique de proposer d’autres moyens pour que notre équipe puisse collaborer avec d’autres personnes dans la boîte. 

Pour finir, je m’en rends compte aujourd’hui, mais en fait assez naturellement je réalise des cycles d’observations de ⅔ mois où à la fin je vais présenter quelque chose un peu structurel autour de la collaboration entre notre équipe et le reste du produit.