Structurer notre département de logiciel.

En date d’aujourd’hui (26 octobre 2022), notre beau département de développement logiciel est composé de 32 personnes incroyables:

Ça commence à faire un peu de monde, et on ne peut plus vraiment se permettre de laisser les structures d’équipe se former organiquement comme dans nos débuts. Comme on a dû le faire à plusieurs reprises au courant de la forte croissance d’oxio, il était temps de sortir la planche à dessin et de mettre notre jus de cerveau sur ce défi plutôt humain et organisationnel. Comment est-ce qu’on organise ça, un département de développement? Il n’y a pas de réponse unique, ça dépend absolument de ce qu’on veut optimiser. Allons voir ça de plus près.

Quand tu n’as qu’un marteau, tout semble être un clou. Nous sommes fondamentalement obsédés par l’optimisation, il est alors naturel qu’on ait attaqué l’organisation du département comme un problème d’optimisation de ressources. On ne change pas une formule gagnante. En toute honnêteté, je ne crois pas qu’on puisse changer cet aspect de notre personnalité de toute façon, mais je m’égare un peu.

Bref, on retourne à la base: on veut optimiser quelles métriques, au juste? Je te réponds avec une assurance absolue:

Tu peux me croire sur parole, mais laisse moi tout de même t’expliquer le rationnel derrière ces choix.

Il est possible d’argumenter que la productivité, ou plus spécifiquement le débit de mise en production dans le cas du logiciel, est l’un des plus grands avantages compétitifs d’oxio, car c’est une recette que les gros joueurs en place peuvent difficilement répliquer speed as a habit.¹ La capacité de passer rapidement de l’idéation à la mise en production favorise non seulement une innovation soutenue, mais également une validation rapide d’hypothèses d’affaires. C’est la nature même d’un start-up qui rend cette dynamique possible: peu d’employés, structure organisationnelle légère, grande autonomie des employés, processus légers, culture de performance, etc., et il est impératif que la croissance d’oxio entrave au minimum cette génération constante de valeur pour nos clients. L’objectif est donc de conserver les avantages d'une start-up, même lorsqu’on ne pourra plus se considérer comme tel.

Premier postulat: notre structure d’équipe doit favoriser la productivité de ses membres et participer à la maintenir sur le long terme.

La prise de responsabilité (accountability en anglais) des membres de l’équipe est un élément clé chez oxio. On martèle constamment nos collègues du même message: absolument tout doit avoir un propriétaire unique! Que ce soit une donnée, une fonctionnalité, un système, un produit ou une équipe, le propriétaire doit toujours être clair et facilement identifiable. La responsabilisation ne se limite donc pas aux employés en position de leadership; c’est un requis pour tous.

Les conséquences positives d’une telle pratique sont tangibles et variées. Par exemple, enlever l'ambiguïté par rapport au responsable d’un système concentre et simplifie grandement la communication, autant au sein des équipes de développement qu’avec les autres départements. Assigner un seul responsable à chaque fonctionnalité a également pour effet d’assurer un suivi rigoureux de son développement et de sa mise en production. La responsabilisation permet aussi de clarifier qui est chargé d’assurer la qualité et la maintenance d’une fonctionnalité ou d’un système tout au long de son cycle de vie.

Deuxième postulat: on doit encourager une culture où chaque individu se sent responsable et fier de gérer une partie des produits de l’entreprise. La structure des équipes doit nécessairement favoriser cette culture.

L’autonomie c’est d’abord une puissante source de motivation chez beaucoup de professionnels performants. Peu importe le poste, c’est super motivant de savoir qu’on pourra faire notre job avec le plus de liberté et le moins de friction possible. Dans le cadre du travail, cette autonomie est souvent un pré-requis pour oser prendre des initiatives ambitieuses, et elle donne de la latitude pour innover.² Peu importe son rôle dans l’entreprise ou son niveau de leadership, c’est la personne avec le plus de contexte qui est libre de prendre ses propres décisions. Être autonome dans son travail, c’est aussi ne pas avoir à demander la permission à son patron pour chaque initiative qu’on juge bonne pour le succès de son projet. On comprend qu’offrir ce haut niveau d’autonomie ne peut fonctionner que s’il y a 2 autres éléments sous-jacents: une solide confiance envers le jugement et la capacité d’exécution des membres de son équipe, et une organisation qui valorise la prise de risques calculés.

Il y a aussi un lien fort entre l’autonomie d’une équipe (ou de ses membres) et sa vitesse d’exécution. Plus une équipe est autonome, plus elle pourra mener à terme une initiative de bout-en-bout, de façon cohésive et efficace. Dans le cas inverse, plus une équipe aura de dépendances sur d’autres équipes, départements ou processus, plus elle rencontrera d'embûches et de bloquants dans la réalisation de ses tâches.

Troisième postulat: notre structure d’équipe doit favoriser l’autonomie de chaque équipe en plus de chacun de ses membres.

Maintenant qu’on sait ce qu’on veut favoriser dans nos équipes, reste à trouver les meilleures façons d’y arriver. Notre philosophie pour construire nos équipes est grandement influencée par 2 méthodes de l’industrie: les Squads de Spotify³ (méthode bien connue) et les Team Topologies⁴ (méthode bien étoffée mais moins connue). Au final, on arrive avec une version adaptée et optimisée pour oxio, qui sera d’ailleurs portée à évoluer itérativement avec nos apprentissages.

Disons qu’on a tout d’abord une belle petite gang de 15-20 développeurs et qu’on cherche à les séparer en équipes de façon logique et optimale, basé sur nos critères plus haut. Je me lance directement avec cette opinion incendiaire: ce qu’on ne voudra jamais faire, c’est de séparer ces ressources en silos fonctionnels. Par exemple, dans l’optique où on veut favoriser la productivité, la responsabilisation et l’autonomie, séparer nos ressources en 3 équipes, dont une équipe de développeurs frontend, une équipe de développeurs backend et une équipe d’infrastructure cloud, serait une idée terrible!

Cette séparation en silos est premièrement un frein à la productivité, car elle implique de passer le flambeau à 3 équipes différentes avant d’amener une fonctionnalité en production. Chaque équipe peut bien être super productive dans son silo, mais ce qui importe au final c’est le débit de mise en production des fonctionnalités. Deuxièmement, ces équipes ont des échéances, des priorités et des incitatifs différents, et nécessitent alors une extra dose de gestion de projet pour synchroniser et amener à terme chaque initiative. On comprend alors qu’aucune de ces 3 équipes n’est réellement autonome pour mener à terme une initiative, car elles sont dépendantes l’unes de l’autres pour amener de la valeur en production. Troisièmement, on comprend également que la responsabilisation devient extrêmement difficile à mettre en application, car le développement, la mise en opération, la maintenance et le debugging des fonctionnalités dépend de plusieurs équipes, donc personne n’est réellement responsable du bon fonctionnement de l’entièreté du système. Certaines organisations voudraient régler ce problème en créant plus de silos fonctionnels (QA, support en production, opérations, etc.), mais ça ne peut se faire qu’au détriment de la productivité et de l’autonomie des équipes.

Ok c’est dit, on ne fait pas ça. Maintenant, ce qu’on fait, c’est d’abord d’identifier les plans de fractures qui permettent de segmenter des ressources en plusieurs équipes et d’assurer une forte cohésion dans leur mission et un faible couplage avec les autres équipes. Plusieurs segmentations peuvent être justifiables pour atteindre ce but, comme les domaines d’affaires, les types d’utilisateurs finaux, les requis de conformité, etc., mais on tente d’opter le plus souvent pour une fragmentation par domaine.⁴ Par exemple, notre équipe de Billing est responsable de tout ce qui a trait au système de facturation et est 100% autonome pour gérer sa mission. Ils sont les seuls à pouvoir designer, développer, tester, mettre en production, maintenir, et supporter les fonctionnalités de leur système, et toute dépendance avec des équipes externes est maintenue au minimum. Lorsqu’une communication avec d’autres équipes est nécessaire, le tout se fait idéalement de façon asynchrone pour minimiser les bloquants. Par exemple, on favorise de communiquer instantanément par messages Slack plutôt que d’organiser un meeting synchrone plus tard. Ces équipes développent aussi une expertise pointue dans leur domaine et deviennent extrêmement productives, car elles baignent dans les mêmes eaux pour une période prolongée. Un autre avantage non négligeable de la segmentation par domaine d’affaire est d’assurer une charge mentale plus basse que si la segmentation était par expertise technique. Un membre de l’équipe chargée de l’inventaire n’a pas à se soucier de comment les paiements par crypto-monnaies sont supportés, par exemple, tandis qu’une séparation frontend/backend pourrait obliger quelqu’un à maîtriser ces 2 domaines différents dans le cadre de son travail.

Je vous donne un exemple concret pour imager tout ça: on veut bâtir une fonctionnalité qui permet de diagnostiquer la qualité du service Internet d’oxio pour un code postal donné et d’afficher le résultat dans une application web destinée aux agents de support technique. C’est Dominic, développeur de renom, qui amorce la tâche au niveau du backend en créant les APIs nécessaires. Maintenant qu’on voudrait attaquer les parties frontend et infrastructure de la fonctionnalité, la structure des équipes et leur niveau d’autonomie aura un impact significatif sur ce qui se passera ensuite. J’entrevoie les scénarios potentials suivants:

Je n’ai parlé que des influences de la structure d’équipe sur l’autonomie et la productivité, mais l'exercice est le même lorsqu’on y ajoute la responsabilisation. Si la tâche est développée par 3 équipes, comment est-ce que la responsabilité est partagée? Si elle est développée par 3 personnes différentes d’une même équipe, est-ce plus évident? Dans le 3e cas, Dominic en est le responsable sans aucune ambigüité.

Maintenant, de quoi sont composées les équipes? Quels rôles sont nécessaires pour leur bon fonctionnement? La réponse: tous les rôles nécessaires pour que l’équipe soit autonome et productive! Tu comprends, là?!

Dans le cadre du développement de nos produits, il y a plusieurs intervenants en jeu: développeurs logiciel, spécialistes de l’assurance qualité, designers de produit et gestionnaires de produits. Tous ces intervenants doivent se retrouver dans la même équipe afin de partager la même mission et les mêmes échéances, bref les mêmes incitatifs. C’est la combinaison des aptitudes multi-disciplinaires des membres de l’équipe qui la rendent autonome et efficace. Comme chaque fonctionnalité ou système s’inscrit dans le cadre d’une seule équipe (qu’on appelle une squad), c’est celle-ci qui en est responsable pour l’entièreté de son cycle de vie. Aucune ambigüité.

Je poursuis avec une opinion forte qui ne fait pas l’unanimité dans la communauté: on embauche uniquement des développeurs full-stack. La raison devrait vous venir très intuitivement maintenant: parce que c’est une façon d’optimiser la productivité, la responsabilisation et l’autonomie des développeurs au sein de leur équipe. Effectivement, un développeur qui est performant en frontend, backend et en infrastructure pourra mener une tâche de bout-en-bout jusqu’en production de façon autonome, sans jamais devoir transférer la responsabilité à un autre collègue développeur. Jamais besoin d’attendre qu’un développeur backend implante un certain API, ou qu’un développeur d’infra supporte un nouveau service cloud, tu le fais toi-même! Se débloquer soi-même, ça joue beaucoup sur la productivité. D’ailleurs, comme nos développeurs peuvent se retrouver dans différents fuseaux horaires, c’est bien pratique de limiter les cas de synchronisation.

On suit d’ailleurs la même philosophie du full-stack pour nos autres rôles au sein du département: les gestionnaires de produits (product managers) agissent également en tant que responsables de produits (product owner), nos spécialistes en assurance qualité font des tests manuels et automatisés, et nos designers de produits travaillent autant sur l’interface que sur l’expérience utilisateur. Nous sommes conscients qu’il pourrait devenir difficile de conserver cette contrainte en grossissant la taille du département, mais nous allons travailler activement à garder cette dynamique le plus longtemps possible!

Quelle grosseur d’équipe est optimale, finalement? Ça dépend de la complexité de la mission de l’équipe et de la charge mentale nécessaire pour englober tout son fonctionnement. De notre côté, on vise à former des petites équipes de 6-7 personnes qui comprennent:

Un détail: les rôles en désavantage numérique peuvent être membres de plusieurs équipes qui partagent une mission similaire, en fonction de leur charge de travail. On doit idéalement les assigner à des squads qui ont une forte cohésion entre elles, de sorte à minimiser leur charge mentale et maximiser leur productivité. Par exemple, il est logique pour une de nos designers de produits de faire partie des deux squads Inventory et Product Catalog, car ces 2 systèmes sont essentiellement des modules de configuration dédiés à des administrateurs, donc ont une forte similitude.

D’ailleurs, on garde nos équipes volontairement petites, de sorte à nous contraindre à travailler uniquement sur les priorités qui contribuent le plus aux objectifs d’affaires. La vie est courte pour dépenser du temps et de l’énergie sur des fonctionnalités qui ne favorisent pas directement le succès de nos produits. La petite taille des équipes amène également une contrainte supplémentaire: on doit mettre beaucoup d’efforts à penser à nos segmentations par domaines d’affaires de sorte à minimiser la charge mentale de chaque équipe. Dans le cas contraire, une équipe pourrait se voir “accumuler” plusieurs domaines d’affaires différents avec le temps, nécessitant de plus en plus de connaissances pointues, de changements de focus et impactant finalement leur charge mentale. Bref, après avoir testé plusieurs configurations et grosseurs d’équipes, restreindre le nombre de développeurs a mené à une productivité accrue, principalement causée par le développement d’une expertise par les membres, en plus de la nécessité d’optimiser nos processus de travail, notre communication et nos choix technologiques. La nécessité est mère de l’invention, comme disait l’autre.

Comme les spécialistes en assurance qualité, les designers et les gestionnaires de produits sont distribués dans les équipes de développement pour assurer leur autonomie, ils se retrouvent bien souvent seuls au quotidien à posséder leur expertise. Il devient alors plus difficile pour eux de partager leurs apprentissages et de mettre en commun les bonnes pratiques de leur domaine.

C’est dans cette optique que des meetings horizontaux récurrents peuvent être organisés par les spécialistes d’un même rôle dans le but d’échanger sur leurs enjeux et de produire une documentation et des outils centrés sur leur expertise. Le partage de connaissances peut également booster la productivité des spécialistes qui mettent constamment à jour leur coffre à outils.

Si vous avez bien suivi jusqu’à présent, vous vous attendez alors à ce que la responsabilité de gérer l’équipe se retrouve dans les mains d’une seule personne. Même si chaque spécialiste (dev, produit, design, QA) gère l’évolution de son expertise au sein de l’équipe, c’est ultimement le rôle du team lead de s’assurer que l’harmonie règne entre les membres et que son équipe est performante. Comme le team lead est aussi un développeur sénior, il doit également agir en tant que référence technique (tech lead)  pour ses développeurs. D’ailleurs, avoir la même personne attitrée à la gestion du personnel et à la direction technique de l’équipe est uniquement soutenable si les équipes de développement restent petites.

Les (lourdes) responsabilités du team lead sont alors les suivantes:

Ça prend donc quelqu’un avec de très bonnes aptitudes humaines et en gestion du personnel, en plus d’être un leader technique d’expérience. Pas facile à trouver.

Basé sur le fabuleux livre Team Topologies, on distingue 4 différentes topologies d’équipe.⁴ Cette philosophie d’organisation des équipes est principalement orientée sur l’optimisation de la productivité des équipes de développement, mais touche aussi aux notions d’autonomie, de responsabilisation et de développement personnel. On y trouve l’équipe de type focus au centre, où toutes les autres topologies existent pour la supporter.

Ce livre propose aussi un petit exercice intéressant pour évaluer la charge mentale des équipes: attribuer une cote de complexité à chaque projet entre 1 et 3, et viser à ce que chaque équipe ne cumule pas plus de 3 points de complexité en prenant en compte tous leurs projets. Pas plus compliqué que ça.

Tout ça pour dire que, chez oxio, on s’inspire beaucoup de ces topologies pour bâtir nos propres équipes. C’est une base intéressante (et éprouvée) sur laquelle on peut itérer et tranquillement adapter à notre sauce. Voici les 4 topologies principales.

Les équipes focus (malhabilement traduites de stream-aligned teams en anglais) devraient de loin être les plus nombreuses au sein d’un département de logiciel moderne. Elles travaillent sur un seul flux de travail (produit, système, etc.) et sont responsables de produire une tonne de valeur pour les clients, de façon rapide et indépendante. Ces équipes doivent être autonomes sur tous les aspects interagissants dans le cycle de vie de leur produit, comme la sécurité, l’infrastructure, l’expérience utilisateur, la commercialisation, etc. Toutes les autres topologies d’équipes servent à supporter les équipes focus pour qu’elles soient le plus productives possible.

Par exemple, notre équipe chargée de développer le système de gestion de la clientèle est une équipe focus, car elle a comme mission de développer un produit qui génère directement de la valeur pour nos consommateurs. Cette équipe est supportée par d’autres équipes dans sa mission, notamment par l’équipe qui gère le service de Notifications (type plateforme) qui met des outils à leur disposition pour faciliter leur travail.

Les équipes habilitantes servent essentiellement à coacher les équipes focus sur certains aspects et les décharger de certaines responsabilités, encore dans le but de les rendre les plus productives possible. On s’attend à ce qu’une équipe habilitante soit plus homogène que multi-disciplinaire, et qu’elle soit composée de membres très séniors qui sont d’excellents communicateurs. Ces équipes n’existent que temporairement, le temps de remplir leur mission ponctuelle de coaching.

Par exemple, une équipe habilitante peut décharger une équipe focus en faisant des preuves de concept pour elle, en l’aidant dans ses choix technologiques ou en lui produisant de la documentation. Elle peut également l’aider à parfaire ses connaissances avec du coaching sur certains domaines plus spécialisés (apprentissage machine, sécurité, blockchain, ...), pour éviter qu’elle ait à changer son focus.

Une équipe de sous-système complexe est composée de spécialistes responsables de bâtir et maintenir une partie d’un système jugée assez complexe pour vouloir éviter que les autres équipes aient à en apprendre le fonctionnement. Le but est de limiter la charge mentale des équipes focus pour qu’elles puissent utiliser et profiter de ce sous-système complexe tout en restant concentrées sur leur propre produit.

Par exemple, notre squad Internet (appréciez ici notre imagination) est une petite équipe de spécialistes et détient toute l’expertise sur l’activation et la maintenance d’une connexion Internet sur divers réseaux canadiens. Elle abstrait toute la complexité d’envoyer des requêtes et de communiquer avec ces réseaux et propose un API simple aux équipes focus qui peuvent l’utiliser sans se poser trop de questions. Cette équipe est composée uniquement de 3 développeurs et d’un spécialiste en assurance qualité.

Les équipes plateforme assistent également les équipes focus en leur offrant des services ayant un bas niveau d’abstraction qu’ils peuvent consommer au sein de leur produit. L’objectif est, encore une fois, de permettre aux équipes focus d’avoir un maximum d’outils à leurs dispositions pour être efficaces dans leur développement. Typiquement, une équipe plateforme peut développer des outils qui aident les autres équipes dans la maintenance d’infrastructure cloud, le monitoring applicatif, l’audit, la gestion de paiements, l'envoi de communications, etc. Bref, contrairement aux équipes focus, les clients des équipes plateformes sont des collègues développeurs.

Dans le cas d’oxio, nous n’avons pas d’équipe plateforme dédiée pour l’instant, principalement parce que chaque équipe focus possède des développeurs à l’interne ayant une expertise en infrastructure. Toutefois, nous avons quelques micro-services qui ont été bâtis avec comme objectif d’être utilisés comme plateforme par les autres équipes. C’est le cas de notre service de Notifications, qui permet aux autres squads d’envoyer des email et SMS de façon standardisée sans devoir se soucier du fonctionnement interne.

Optimiser simultanément pour l’autonomie et la productivité peut parfois être difficile à réconcilier. Par exemple, plusieurs équipes soucieuses de maintenir leur autonomie pourraient développer des outils similaires en parallèle sans en être conscientes, impactant négativement leur potentiel. Forcer les équipes à constamment se synchroniser et partager un maximum de code, à l’inverse, peut grandement nuire à leur autonomie.⁵ Il s’agit alors de trouver une fine balance entre la réutilisation et la liberté de choix technologiques.

En pratique, nous tenons des démonstrations techniques (enregistrées) toutes les 2 semaines où les développeurs sont invités à présenter quelque chose susceptible d’être utile aux autres équipes de développement. Lorsqu’il y a assez d’engouement pour un certain outil ou fonctionnalité, le tout est extrait dans une librairie commune réutilisable pour éviter que d’autres équipes aient à réinventer la roue. Les équipes ont le loisir de l’utiliser ou non, en fonction de leurs propres cas d’utilisations.

Au final, chaque équipe est libre de ses choix technologiques. Si une équipe veut déroger des technologies et des pratiques communes proposées par le département, elle devra toutefois bien justifier son choix, préférablement en se basant sur nos 3 métriques divines présentées précédemment.

S’il y avait une seule chose que j’aimerais partager à mes confrères qui veulent structurer un département de développement logiciel, ce serait cette implication de la Loi de Conway⁶ 🤓 :

Il est alors impératif de proposer une structure d’équipes qui va en synergie avec l’architecture logicielle souhaitée. Dans le cas contraire, la structure des équipes peut carrément freiner l’émergence d’une architecture.

Je vous rappelle que nous avons des petites équipes distribuées à travers le Canada, avec une forte cohésion, organisées par domaine d’affaire, qui ont un faible couplage avec les autres équipes, et qui optent pour une communication asynchrone lorsqu’ils doivent partager des informations en dehors de leur équipe.

Les fins connaisseurs y verront directement l’architecture sous-jacente: des microservices distribués, organisés par domaine d’affaires, basé sur une architecture événementielle de communication asynchrone. Coïncidence? Je ne pense pas.

À part le film Dune de Denis Villeneuve, il n’y a pas grand chose de parfait dans ce monde. On a identifié plusieurs défis en développant notre philosophie de structure départementale, et aussi en observant d’autres compagnies développer un modèle similaire.

D’abord, trouver les bonnes segmentations par domaines d’affaires n’est vraiment pas aussi simple qu’il puisse paraître. Une excellente connaissance du domaine et une bonne dose d’essai-erreur sont requis pour vraiment saisir les interconnexions entre les différents domaines et comprendre leurs limites. Une mauvaise segmentation et l’équipe pourra se retrouver avec trop de dépendances sur d’autres équipes et perdre de l’autonomie, ou bien avoir une portée trop grande ou ambigüe qui sera difficile à gérer.

Ensuite, pour retirer un maximum de bénéfices générés par notre modèle, on vise à embaucher uniquement des développeurs full-stack, et idéalement au moins 50% de séniors. L’embauche de développeurs est déjà un défi de taille pour la majorité des compagnies, donc combiné avec les qualificatifs “full-stack” et “sénior”, ça diminue énormément le bassin de candidats. Ceci dit, nous ne sommes pas prêts à nous compromettre sur cette contrainte pour le moment, vu notre bonne moyenne sur les embauches des dernières années, et sur les avantages notoires au niveau de la responsabilisation.

Tel que mentionné précédemment, il y a également un souci de sélectionner des langages, outils et architectures qui vont renforcer la structure d’équipes souhaitée. Par exemple, une architecture en microservices favorise la cohésion et le découplage des équipes, une techno comme Typescript permet d’utiliser un seul langage pour le frontend, le backend et l’infrastructure-as-code, favorisant l’autonomie et l’embauche des développeurs full-stack, un outil comme GraphQL Federation permettra de centraliser les APIs de chaque équipe sans qu’ils aient besoin de se coordonner, etc.

Finalement, la communication au niveau départemental est définitivement un défi. Avec une structure qui favoriserait un plus petit nombre de grosses équipes, il serait plus facile d’aligner tout le monde au niveau de la vision et de la stratégie. Dans notre cas, avec beaucoup de petites équipes autonomes qui travaillent sur leurs domaines d’affaires respectifs, il y a un besoin accru de présenter et de synchroniser tout le monde sur le big picture qui peut leur être complètement étranger.

Si un mélange de chance et de bonne exécution nous permet encore de grossir significativement notre département, certaines modifications devront se produire:

D’abord, Les squads ayant une forte cohésion et une mission similaire devront se regrouper au sein d’une tribe (spotify squads).³ Les membres de la tribe partageront des rituels en commun, comme les meetings de synchronisation et les démonstrations techniques. Ça nous sauvera tous de douloureux meetings à 40 personnes. Par exemple, les futures équipes de Billing + Debt Collection + Payment pourraient faire partie d’une tribe Revenue qui engloberait tout ce qui touche à la partie revenu du logiciel.

On devra également créer plus de meetings horizontaux pour partager efficacement les bonnes pratiques liée à une expertise (voir chapter sur l’image ci-dessous). Présentement, nous n’avons des horizontaux que pour les designer et les gestionnaire de produits, mais viendra le jour où ce sera bénéfique de faire pareille avec les différents domaines du développement (frontend, backend, infrastructure, analyse de données, blockchain, ...). Ça permettra d’assurer une certaine cohésion et un partage de connaissance plus large.

Il y a une tonne de façon d’organiser un département de développement logiciel, ses nombreuses équipes et les différents membres au sein de ces équipes. Il y a évidemment une tonne de manières de mal faire l'exercice, tant que la structure à appliquer n’est pas clairement pensée pour favoriser des comportements souhaités.

Ces comportements seront d’ailleurs portés à changer en fonction du stade de l’entreprise, ce qui nécessitera un changement au niveau de la structure du département. Dans le cas d’oxio, notre structure favorise principalement la vitesse d’exécution, et c’est un choix conscient qui nous donne un avantage compétitif évident dans l’industrie. Ceci étant dit, le fameux adage “move fast, break things” qui nous sert très bien présentement pourrait, à terme, ne plus du tout nous être favorable. Il s’agit donc de constamment s’adapter aux nouvelles réalités de l’entreprise et du marché, dans le but de toujours rester compétitif.

Tu as une opinion, une expérience ou un commentaire à partager à ce sujet? Écris-moi au olivier@oxio.ca et on va jaser !

Merci au suprême Simon Frenette pour sa dangereuse connaissance de la Loi de Conway, et pour les nombreuses heures de brainstorm passées ensemble, en Californie entre 2 parties de spikeball, à modeler une vision long terme. Un gros merci également à tous les membres du département de continuellement vouloir tester (et parfois subir) les nombreuses itérations et évolutions de cette structure.

Écrit par Olivier Falardeau, chef de l’ingénierie, en buvant un Bubly aux pêches et en écoutant Blackwater Park de Opeth.