On a beaucoup écrit sur l'importance du développement personnel du fondateur dans les startups à croissance rapide. En règle générale, les textes sur ces sujets sont consacrés au rôle du PDG. Des conseils de leadership généraux peuvent également être utiles pour d'autres rôles, mais je n'ai pas été en mesure de trouver de matériel pour aider les fondateurs de technologie. Après avoir lu un tas de formulaires S-1, il est devenu clair qu'il est très difficile de trouver des CTO à partir de zéro qui sont passés de MVP à IPO (alors que la situation avec les fondateurs-PDG est exactement le contraire). Ce fait m'a paru intriguant - j'ai décidé de creuser plus profondément. Je voulais aller au fond des choses et des raisons de cet état de fait. Cela m'énerve aussi un peu: et si je n'arrive pas à grandir rapidement? Je devrais le découvrir avant que de vrais problèmes ne surviennent! Je veux être le CTO qui fait de RevenueCat une entreprise publique! (une)
Est-il plus difficile pour les fondateurs non PDG de croître rapidement? Se pourrait-il que le PDG bénéficie généralement d'un soutien important? Quoi qu'il en soit, tout a ses propres raisons. Peut-être ai-je simplement posé la mauvaise question. Après avoir discuté avec de nombreux fondateurs de CTO, il est devenu clair qu'il n'y avait pas de définition standard d'un CTO. Les responsabilités d'une personne occupant ce poste peuvent changer complètement en fonction de l'entreprise et de son stade de développement. Le CTO apportera probablement beaucoup de contributions personnelles au début, mais cela pourrait bientôt changer. L'expérience de différentes personnes peut être très différente. Malheureusement, je n'ai pas de réponse pour les fondateurs non PDG. Peut-être que je n'ai pas de réponses pour ceux qui sont devenus CTO pour la première fois non plus. Quoi qu'il en soit, j'ai pensé qu'il serait utile de réfléchir à ce que j'ai appriset comment mes responsabilités ont évolué en 3 ans chez RevenueCat.
Dilemme: CTO vs vice-président de l'ingénierie
En termes simples, le rôle de CTO est plus proche de l'architecture et du code, tandis que le VPE sera en charge du processus et de la gestion. Une analogie serait de comparer le parcours d'un ingénieur senior / à plein temps et d'un directeur de l'ingénierie.
Dès le début, vous avez besoin d'un CTO qui peut rassembler et organiser les artistes qui créent le MVP. A ce stade, le fondateur peut être très utile car il est nécessaire de définir la vision produit et la culture des processus techniques. Idéalement, un CTO devrait comprendre le problème que sa startup résoudra.
Et si le produit réussit? Et si le produit prend sa place sur le marché? Dans ce cas, vous devrez engager plus d'ingénieurs pour répondre à la demande des consommateurs. C'est un défi formidable. Vous avez peut-être de la chance et vous trouverez des financements, ou vous générez peut-être déjà des bénéfices. Mais plus votre personnel est nombreux, plus les exigences en matière d'excellence des processus sont élevées. Le moment viendra inévitablement où quelqu'un devra devenir vice-président de l'ingénierie. Le début de ce moment deviendra évident dès que les processus existants (ou manquants) cesseront de fonctionner. Dans une telle situation, vous avez plusieurs options. Le directeur technique peut reprendre le poste de vice-président de l'ingénierie ou l'entreprise peut embaucher des employés supplémentaires. Cette décision est probablement une question de préférence personnelle et d'expérience de gestion.Relever ces types de défis nécessite un ensemble de compétences complètement différent, et il peut être difficile d'acquérir ces compétences dans un environnement où vous devez vous développer très rapidement. C'est pourquoi le CTO est généralement externalisé.
Le fondateur peut être flexible. Il peut avoir le pouvoir de déterminer le chemin que prendra l'entreprise. Peut-être détestez-vous gérer les gens et souhaitez-vous continuer vos compétences et vos connaissances afin de travailler directement avec la technologie. Ou peut-être souhaitez-vous améliorer vos compétences en gestion. Le premier type est généralement plus indulgent pour les défauts de gestion des fondateurs. Ils ont rejoint l'équipe parce qu'ils faisaient confiance aux fondateurs, croyaient en leurs idées et étaient convaincus d'avoir de bonnes intentions. Au début, ils préfèrent peut-être travailler directement avec vous plutôt qu'avec une personne extérieure. Dans tous les cas, à l'avenir, l'entreprise aura plusieurs niveaux de gestion, donc si vous voulez emprunter cette voie et que vous n'avez aucune expérience, alors vous devriez apprendre et apprendre rapidement.
Brian Helmig, co-fondateur et directeur technique de Zapier dit que vous devez trouver ce que la dopamine vous donne. Personnellement, il a toujours été plus facile pour moi de communiquer avec les ordinateurs qu'avec les gens. Je n'étais pas sûr du choix de la voie de développement, mais j'ai préféré faire des choses liées à l'informatique. J'ai toujours aimé travailler avec eux et je peux dire que je suis plus efficace en tant qu'ingénieur qu'en tant que manager. Après avoir intégré la nouvelle fonctionnalité, je me sens plus énergique qu'après une rencontre en personne.
Cependant, en tant que fondateur, je reçois de fortes doses de dopamine lorsque l'entreprise se porte bien. Lorsque les acheteurs recommandent notre produit. Lorsque nous atteignons nos objectifs de revenu. Lorsque nous embauchons des ingénieurs mieux que moi. Lorsque ces ingénieurs sont satisfaits de tout et résolvent avec succès des tâches ambitieuses. Lorsque la révision du code est fatigante, mais qu'elle se déroule dans une atmosphère de collaboration, pas de colère.
Donc, au final, j'ai décidé non seulement de suivre mes préférences, mais de faire ce qui est le plus efficace pour l'entreprise à différentes étapes de son développement. Après tout, je peux résoudre des problèmes. C'est ainsi que j'ai parlé de mon rôle. Mes qualités de fondateur sont plus importantes que ma position de CTO. Dans une perspective à long terme, en tant qu'actionnaire majeur, je dois faire ce qui est le mieux pour l'entreprise.
En règle générale, une fracture se produit lorsque votre équipe compte 8 à 12 ingénieurs. Cependant, cela peut survenir à un autre moment, tout dépend du produit et de l'environnement. En tant qu'entreprise entièrement distribuée, nous avons été confrontés à plusieurs points de basculement lorsque nous avons intégré de nouveaux fuseaux horaires dans nos flux de travail. À cette époque, bon nombre d'entre eux devaient assumer les fonctions de directeur technique et de vice-président de l'ingénierie en même temps. J'ai essayé d'accepter un travail pour lequel d'autres manquaient de ressources (je l'ai fait temporairement et pas très bien). Cela m'a aidé à trouver les points faibles, à établir des processus et à embaucher quelqu'un qui peut assumer ces tâches.
Lorsque j'ai appris comment les autres fondateurs géraient leur temps à différentes étapes du travail, j'ai pu mieux gérer mon rôle. Depuis la création même de l'entreprise, j'ai tenu un journal. Sur la base de ces notes, je parlerai des tâches sur lesquelles je me suis concentré et de l'évolution de mon rôle.
2018: YC, MVP et premiers employés
Quand nous sommes arrivés à YCombinator, il n'y avait que Jacob et moi. Jacob a travaillé sur le SDK et le frontend, et j'ai travaillé sur le backend. Après YC, nous avons embauché les deux premiers ingénieurs pour reprendre les responsabilités de Jacob et travailler à plein temps. Nous vivions tous à San Francisco et nous connaissions déjà ces personnes. Nous avions des contrôles simples (et presque complets). Il n'y avait pas de frais généraux, nous avions des sprints hebdomadaires et nous nous sommes déplacés très rapidement.
Ces journées ont été intenses mais très amusantes. Nous avons jeté les bases d'une culture d'ingénierie et avons vu les clients entrer les uns après les autres. J'ai passé la plupart du temps à développer les premières versions des fonctionnalités dont les clients parlaient. Nous avons répondu à leurs demandes le plus rapidement possible. La plupart des demandes ont été traitées le même jour.
Ce dont je doutais le plus à l'époque, c'était que nous étions en train de créer un produit dont les gens avaient vraiment besoin et qu'il pourrait pousser et justifier notre ronde de semences de 1,5 million de dollars.
Les principales conclusions: il y en a trop, il est trop difficile de généraliser. Nous avons beaucoup appris en passant par YCombinator. Il vaut probablement la peine de souligner la communication avec les clients, la capacité à créer ce qui les rend heureux et à répondre à leurs besoins. Ceci et une livraison très rapide sont devenus nos valeurs fondamentales.
2019: Nous suivons le rythme des clients et développons des technologies
Il semble que nous ayons pris notre niche sur le marché. Des clients sont venus nous voir, les demandes d'assistance ont commencé à s'accumuler et les performances de notre API ont augmenté chaque jour. Le premier ingénieur à distance de Taiwan a rejoint l'équipe. Dans un premier temps, la différence de fuseaux horaires causait certaines difficultés, il était nécessaire d'adapter les processus de travail. Cependant, tout a fonctionné. Nous avons fait du bon travail avec les demandes et le suivi des clients.
L'adaptation était un processus simple et ponctuel. J'ai fait des rencontres en personne (pas très souvent, environ une fois par mois), mais la gestion était assez facile. La plupart des conversations étaient encore techniques. Je contribuais toujours en tant qu'artiste ordinaire. J'ai également assisté à plusieurs conférences.
A cette époque, j'avais surtout des soucis techniques. J'ai surtout pensé à l'évolutivité de nos systèmes. Tous nos ingénieurs avaient de l'expérience avec le produit et nous avions des points de défaillance évidents. Je pensais constamment à ne rien casser. La balance était constamment hors de ma zone de confort. Nous avons fait face à l'optimisation des scénarios les plus courants, à la migration des infrastructures et aux points critiques évités. Nous avons également remboursé la dette technique accumulée au cours de l'année écoulée.
En fait, jusqu'au quatrième trimestre, j'étais ingénieur d'appel. Je ne voulais pas déranger les autres membres de l’équipe en dehors des heures de bureau et j’ai estimé qu’il était de ma responsabilité en tant que fondateur du département technique d’assurer une fiabilité maximale. J'ai transporté mon ordinateur portable partout avec moi. En fin de compte, nous avons assuré la rotation. Avec le recul, je comprends que cela aurait dû être fait plus tôt.
Points clés à retenir: ne vous attardez pas sur l'évolutivité, mais n'oubliez pas la surveillance. Surveillez les goulots d'étranglement potentiels et les points de défaillance. Ces problèmes sont stressants, mais y faire face n'est pas si grave. Embaucher et former des ingénieurs d'appel dès que possible, documenter les solutions pour les incidents connus. Fiez-vous à votre équipe. Il n'y a rien de mal avec la dette technologique si vous l'abordez de manière responsable et essayez de trouver le produit qui sera en demande sur le marché.
2020: Délégation et planification de la future organisation
En 2020, notre équipe a encore doublé. Nous avons embauché des ingénieurs d'Europe et d'Amérique latine. A la fin de l'année, nous avions plusieurs collaborateurs dans chacune des équipes (SDK, frontend, frontend, ...). Nous avons réussi à travailler sur plusieurs projets et, finalement, nous avons pris des tâches plus ambitieuses. Cependant, nous devions améliorer la coordination. À ce stade, le travail sur la structure de gouvernance n'a pu être évité.
Au cours des premier et deuxième trimestres, j'ai passé la plupart de mon temps à faire des révisions de code, à fournir des directives architecturales et à écrire un peu de code à côté. J'étais toujours la personne qui comprend nos systèmes. Au milieu de l'année, il est devenu évident que j'étais le goulot d'étranglement pour la sortie de nouvelles fonctionnalités. J'ai également tenu des réunions individuelles, participé à des discussions de brainstorming et n'avais plus le temps d'écrire du code et de le mettre en œuvre à temps.
J'ai complètement arrêté la programmation. Au lieu de cela, j'ai confié mes tâches à d'autres ingénieurs et j'ai commencé à passer plus de temps à transférer des connaissances. Au début, cela semblait prendre du temps, mais la délégation a lancé de nombreux projets et a donné à de nombreux ingénieurs un fort sentiment d'appartenance. C'était très étrange de ne pas écrire le code au début. J'avais l'impression que je ne faisais pas mon travail (ou que je travaillais de manière improductive). C'est une sensation tout à fait naturelle. J'ai vite réalisé que je m'étais libéré de la programmation, et maintenant je peux voir la situation dans son ensemble. J'ai pu penser à l'avenir de la structure d'ingénierie.
En termes de gestion, j'ai commencé à passer plus de temps à parler d'avancement professionnel et à travailler avec des ingénieurs pour grandir et me développer. Du côté du produit, nous manquions de ressources pour prioriser, planifier et coordonner correctement les sprints. J'ai fait de mon mieux pour libérer les gens et établir la communication.
Nous sommes également passés par la ronde de financement A et avons commencé à tenir des réunions du conseil. J'ai également commencé à consacrer beaucoup de temps au recrutement.
Points clés à retenir: la mise en œuvre de nouveaux fuseaux horaires est devenue plus facile lorsqu'ils se chevauchent. La diminution du facteur de bus est très importante pour faire évoluer l'équipe d'ingénierie. Une fois que vous avez vérifié vos flux de travail et qu'ils fonctionnent, automatisez-les autant que possible. Si vous ne voyez pas la forêt pour les arbres, quittez la programmation et déléguez.
Avenir
L'année prochaine, nous prévoyons de doubler à nouveau notre équipe. Il semble que passer de 20 à 40 employés soit plus difficile que de passer de 10 à 20. D'ici la fin de 2021, l'entreprise va changer de manière significative.
Je pense que je vais me concentrer sur l'évolutivité de l'équipe. Ne vous méprenez pas, nous serons bien sûr confrontés à de graves problèmes techniques et nous avons de nombreuses tâches très ambitieuses dans nos plans. Au cours des dernières années, nous avons beaucoup appris sur nos clients, nos problèmes et la pile technique qui sous-tend notre solution. Travailler avec des ingénieurs talentueux qui ont les compétences et l'enthousiasme pour résoudre les problèmes est une grande partie pour moi.
Je veux continuer à embaucher les meilleurs talents et maintenir une culture d'ingénierie saine. Ce ne sera pas facile. Je devrai travailler en étroite collaboration avec le responsable des ressources humaines pour rationaliser et automatiser les processus de sourcing, de recrutement, d'intégration et de communication. Les références ont contribué à accélérer le développement de l'équipe, mais il est temps de se concentrer sur la diversité au sein des équipes. Je pense que nous aurons des opportunités d'embauche de juniors, je voudrais les aider à atteindre leur plein potentiel.
Nous devrons améliorer notre gestion de l'ingénierie pour rendre les ingénieurs heureux et les responsabiliser. De plus, si nous voulons nous attaquer à des tâches ambitieuses, nous devrons investir dans des processus de planification. développement et lancement de produits.
Je suis très enthousiasmé par ce qui va se passer l'année prochaine. Bien sûr, en plus des problèmes existants, de nouveaux viendront. Mais cela n'arrive jamais autrement. Ce ne sera pas plus facile!
J'espère que ce texte était intéressant et utile. J'ai l'intention de revenir sur ce billet et de le compléter avec de nouvelles connaissances. Si c'est votre première fois en tant que CTO, je serai heureux de vous aider de toutes les manières possibles. N'hésitez pas à me tweeter ou m'envoyer un e-mail.
Un merci spécial à Alex Plugar, Calvin French-Owen, Xavi Santana, Adam Houghton, Sam Lown, Saul Diez et Will Larson pour leurs conseils et avoir pris le temps de partager leurs expériences. Et, bien sûr, à toute l'équipe d'ingénierie de RevenueCat pour m'avoir permis de les expérimenter, pour avoir accepté mes lacunes et leurs commentaires francs.
(1) Au fil du temps, j'ai appris que l'anxiété et la peur sont principalement causées par le syndrome de l'imposteur et qu'elles ne sont pas fondées. Si l'entreprise vous dépasse, ce n'est pas nécessairement une mauvaise chose. En fait, c'est un problème sérieux! Le fondateur devrait y faire face. Concentrez-vous sur l'embauche de personnes meilleures que vous, qui vous aideront à grandir et à améliorer votre entreprise. Je veux toujours aider RevenueCat à devenir public, et si cela réussit, mes responsabilités et mon poste seront moins importants.
- Discussion sur HackerNews
- Chaîne de télégramme "HackerNews en russe"