Les Erreurs que J'ai Commises en tant que Nouveau CTO

Les choses commencent généralement pour une raison, c'est ainsi que j'ai lancé Madison Technologies. Trop souvent, nous oublions qu'il y a des raisons pour lesquelles nous faisons les choses. J'aime apprendre par l'échec. Pour échouer, il faut être un idéaliste pour choisir le chemin que l'on veut suivre. J'ai choisi ce chemin à cause des leçons que j'ai apprises en tant que CTO fondateur de GOJEK (maintenant appelé GoTo et coté publiquement à la Bourse indonésienne.)

J'ai rejoint GOJEK en décembre 2014. J'étais le nouveau CTO et je suis arrivé juste avant le lancement de l'application mobile. Nous étions une équipe joyeuse de 3 ingénieurs principaux, et j'étais le nouvel ajout. Le travail difficile pour construire l'application avait déjà été fait, et j'étais prêt à prendre les rênes lorsque nous avons lancé. En regardant en arrière, il y avait de l'excitation, mais j'étais alors dépassé. Il semblait y avoir tant à faire et pas de temps ou de main-d'œuvre pour le faire. Quoi qu'il en soit, je me suis mis au travail et j'ai divisé mon temps du mieux que j'ai pu pour finalement lancer.

Un de nos premiers événements de lancement impliquait de rassembler un petit groupe de journalistes dans un restaurant à SCBD, Jakarta. Nadiem, notre PDG, a fait une présentation, après quoi nous avons invité les journalistes à télécharger l'application et à expérimenter la réservation de Gojeks de première main. Cependant, pendant ce temps, nous avons rencontré un bug gênant: le service qui affichait la carte avec tous les conducteurs plantait, provoquant la disparition de tous les conducteurs de la carte. Cela signifiait aussi que personne ne pouvait réserver un trajet, et nous devions redémarrer le service.

Et puis, 5 minutes avant que Nadiem termine sa présentation, j'ai jeté un coup d'œil à mon téléphone et j'ai vu que la carte des conducteurs était vide. J'ai couru vers mon ordinateur portable aussi vite que mes jambes tremblantes pouvaient me porter, priant pour que la connexion 3G de mon téléphone me permette au moins de faire SSH sur le serveur pour redémarrer le service. La chance était de mon côté ce jour-là, et j'ai réussi à redémarrer le service juste à temps et je me suis assis là en hyperventilant alors que les journalistes s'excitaient de pouvoir réserver leur conducteur. Voici une photo de nous à la fin de l'événement de lancement.

De gauche à droite: Sam, Kevin, moi, Nadiem, Mikey et Rio

Il y avait beaucoup d'histoires comme celle ci-dessus. L'application était notre objectif principal, et à l'époque, nous avions beaucoup de feux à éteindre. Alors que nos utilisateurs grandissaient, nous avons rencontré des erreurs et des bugs que nous n'avions jamais vus auparavant.

Pendant cette phase, j'ai assumé un rôle tactique, travaillant directement avec le code et essayant de déboguer les problèmes qui surgissaient. Une fois, je faisais un profilage mémoire du même service de conducteurs parce qu'il semblait que le ramasse-miettes faisait planter tout le service (déjà à 98% d'utilisation CPU). Cela a pris si longtemps que j'ai décidé d'abandonner et de réécrire l'API de Java vers Go, je l'ai remplacée derrière notre équilibreur de charge, et j'ai regardé avec étonnement alors que l'utilisation CPU descendait à 3% pour ce serveur. C'était génial, mais ce n'était pas ce que je devais faire.

J'avais besoin de plus de personnes, et je les voulais rapidement. J'aurais dû prêter plus d'attention à tant d'autres domaines de l'entreprise qui avaient besoin d'aide. Par exemple, notre tableau de bord opérationnel, où nous suivions l'intégration et la gestion des conducteurs, avait désespérément besoin d'une refonte. Croiriez-vous que nous avons utilisé des Post-Its pour suivre certains de nos champs de base de données? Vraiment:

Et puis il y avait nos analyses pour suivre comment nos dépenses publicitaires se portaient. Nous avons utilisé de nombreux SDK, mais voici un aperçu d'un échange que j'ai eu avec l'équipe AppsFlyer à l'époque:

Tant d'autres domaines qui avaient besoin de mon attention ne l'obtenaient pas. J'étais coincé dans cette sécheresse d'embauche et dans un état d'esprit qui ne m'aurait pas fait dépenser notre argent déjà rare.

Tout d'abord, j'aurais passé beaucoup plus de temps à développer un réseau d'individus intelligents de l'espace technologique. Des individus avec qui je pourrais échanger des idées ou demander de l'aide en cas de besoin. J'imaginais que je devais garder de près toute ma propriété intellectuelle secrète et ne parler à personne. Pire encore, je suis introverti, et les conversations ne viennent pas naturellement. En conséquence, je pourrais être meilleur pour maintenir le contact et cultiver les relations. Si j'avais travaillé là-dessus à travers mon réseau, il aurait été beaucoup plus facile d'obtenir de l'aide ou des recommandations sur les embauches.

Ensuite, j'aurais parallélisé davantage. J'étais dans une frénésie d'embauche, mais il arrive un moment où l'embauche atteint un point où vous avez un tas d'entretiens et de candidats potentiels, mais le progrès stagne. J'étais assez prudent et hésitant à investir dans une équipe externalisée pour travailler sur des projets simultanément. Mon objectif était uniquement de remplir les postes internes, ce qui, rétrospectivement, s'est avéré être une erreur. Si j'avais changé mon état d'esprit, j'aurais temporairement doté mes équipes d'opérations et de marketing d'une équipe d'ingénierie externalisée et j'aurais permis à ces flux de travail de se déplacer en parallèle pendant que je travaillais sur des problèmes plus difficiles.

En regardant en arrière, l'impact le plus significatif de mes erreurs était une perte de temps. Ce n'est pas quelque chose que vous pouvez jamais récupérer; pour une startup, le temps est souvent une ressource rare lorsqu'on essaie de rivaliser avec d'autres dans l'espace. Nous aurions pu avancer plus vite si j'avais exécuté les flux de travail pour les opérations, le marketing et les RH en parallèle en embauchant une équipe externalisée. Nous aurions également eu plus de données à intégrer dans notre développement d'applications. Enfin, nous aurions pu être encore plus attractifs pour les VC en récupérant ce temps et nous aurions levé des fonds plus tôt. Bien que j'aie fait partie de quelques levées de fonds, aucune ne se passe aussi facilement ou aussi rapidement qu'on s'y attend.

Bien que cela puisse sembler simple, c'est l'une des leçons les plus importantes que j'ai apprises. La tech n'est pas seulement votre produit principal. L'application de la technologie s'étend au-delà de l'ingénierie et dans divers autres départements tels que les Opérations, le Marketing, les RH et les Finances. Les CTO plus récents peuvent parfois négliger cette réalité et ne pas fournir le soutien nécessaire à ces fonctions aussi rapidement que requis. Je l'étais sûrement, et rétrospectivement, ma première étape serait d'élargir mon focus au-delà du produit.

Un autre mouvement de débutant de ma part était de prendre la propriété exclusive de toutes les choses tech. En essayant de livrer la tech aux autres équipes moi-même, j'ai ralenti tout le monde, y compris moi-même. Si j'avais placé une équipe temporaire ou externalisée avec un bon tech lead dans ces fonctions, j'aurais pu permettre aux propriétaires de fonctions de prendre le contrôle et de développer des solutions selon leurs exigences. Leur dépendance à mon égard aurait été limitée à des questions importantes telles que l'architecture et la cohésion globale. J'ai réalisé qu'en essayant de tout contrôler, j'utilisais un état d'esprit 2x et non 10x. Alors, abandonnez le contrôle, donnez à vos co-leaders les ressources et sortez de leur chemin.

Cela nous ramène directement à la raison pour laquelle j'ai créé Madison Technologies. Nous sommes là pour vous aider à faire avancer les choses plus rapidement. Nous sommes là pour combler les lacunes pendant que vous embauchez votre équipe de rêve. Nous avons été là avant, et nous allons traverser cela ensemble.

N'hésitez pas à me contacter via mon LinkedIn pour une conversation plus approfondie. Connectons-nous!

Sheran Gunasekera est chercheur en sécurité et développeur de logiciels. Il est co-fondateur et Directeur de la Recherche de Madison Technologies, une entreprise de développement de logiciels à Singapour, où il conseille l'équipe d'ingénierie interne à la fois en sécurité des ordinateurs personnels et des appareils mobiles. L'incursion de Sheran dans la sécurité mobile a commencé en 2009 lorsqu'il a commencé avec la recherche en sécurité BlackBerry. Depuis lors, il a occupé des rôles de leadership à la fois en ingénierie et en sécurité dans plusieurs startups en Asie, y compris GOJEK, l'application multi-services à la demande qui est maintenant cotée publiquement.