À mesure qu'une startup se développe, ses flux de travail doivent changer. J'ai réalisé que c'était particulièrement important pour les ingénieurs. Mon rôle en tant que co-fondateur et directeur technique a considérablement changé au fil des ans. Mes responsabilités et tâches quotidiennes ont changé, et j'ai dû changer mon approche du travail plusieurs fois pour aider l'entreprise à atteindre le niveau supérieur.
Au début de l'entreprise, l'équipe se composait de trois types qui travaillaient nuit et week-end, sciant au sous-sol ce qui allait devenir plus tard Zapier. Avant le lancement, nous avons réalisé trois ou quatre versions du produit. Six ans se sont écoulés depuis, nous traitons maintenant des centaines de millions de demandes vers notre API, et notre équipe emploie 80 spécialistes du monde entier (dont plus de deux douzaines d'ingénieurs).
La croissance depuis l'époque où nous étions trois jusqu'à nos jours a été très difficile. Si vous le souhaitez, vous pouvez lire les conclusions que j'ai tirées pendant cette période. Sinon, je vous suggère de vous familiariser avec les leçons qui m'ont été données lorsque je grandissais en tant que CTO-débutant.
Arbre de développement de la gestion technique dans une startup
Avant d'aller trop loin, découvrons-le - qui diable est de toute façon un CTO? C'est la question que je me suis posée lorsque nous avons embauché les deux premiers ingénieurs de l'équipe. CTO - un dictateur éternel bienveillant qui dans le monde du logiciel fait la même chose en suivant le code? Ou est-ce une sorte de super manager ou de super hacker?
J'ai demandé conseil à de nombreuses personnes. J'ai contacté les directeurs techniques de Buffer, Unbounce et d'autres startups légèrement plus grandes que nous. Et j'ai eu la réponse: personne ne le sait vraiment. Il s'agit d'un rôle flou qui ne peut être intégré à aucun cadre. Dans le processus de communication, j'ai découvert un certain nombre de modèles de croissance communs de petites startups axées sur la technologie et formulé ce que le CTO devrait faire à chaque étape de développement.
Puisque je suis ringard et que j'aime jouer aux jeux vidéo, l'arbre de développement me semble le plus évident. Au fur et à mesure que vous acquérez de l'expérience dans le jeu, vous augmentez votre niveau et à certains moments, vous pouvez choisir différentes branches de développement.
Voici à quoi pourrait ressembler une arborescence STO dans une startup.
Hacker solitaire (1-2 ingénieurs)
C'est exactement le moment où nous travaillions au sous-sol. C'était un moment amusant et éphémère. Vous faites beaucoup de choses, il n'y a presque pas de frais de communication et de communication, car tout le monde travaille en synchronisation. Vous essayez simplement de comprendre ce qui fonctionne et ce qui ne fonctionne pas.
Petite équipe de codeurs (2-6 ingénieurs)
En tant que fondateur de startup, vous souhaitez développer votre équipe, vous commencez donc à embaucher du personnel. Habituellement, tout le monde commence par embaucher des amis. Certains disent que cela ne vaut pas la peine d'embaucher des amis, mais je pense que c'est génial à ce stade précoce. Vous savez que vous pouvez travailler avec eux, vous savez à quel point ils sont intelligents et ils s'intègrent parfaitement. La petite phase d'équipe est celle où le CTO commence à ressentir la douleur de passer du piratage à autre chose. C'est toujours assez bon car vous n'avez que quelques ingénieurs. Les frais généraux de communication sont assez faibles. Vous êtes toujours à peu près synchronisé. Vous comprenez ce qui se passe. Rien ne vous surprend.
Croissance de l'équipe (6 à 12 ingénieurs)
Ensuite, tout devient un peu étrange. Vous arrêtez de parler à chacun des membres de l'équipe. Vous devrez vous attaquer au terrible mystère du management, pour moi c'était quelque chose de fondamentalement nouveau - contrairement à une programmation qui était compréhensible et naturelle pour moi. C'est à ce stade que la surcharge de communication liée à l'écriture de code augmente considérablement. Vous devrez peut-être envisager d'embaucher des personnes qui ne sont pas vos amis. Les choses se compliquent parce que des choses commencent à arriver dont vous ignoriez l'existence. À ce stade, tout se passe très rapidement, et vous rencontrerez également la première branche de l'arbre de développement.
Organisation d'équipe (12+ ingénieurs)
Avec une équipe de cette taille, vous travaillez probablement dans différents domaines. Vous ne serez pas capable de bien gérer les gens et le code en même temps, vous devez donc faire un choix:
VP of Engineering: focus sur la gestion du
CTO: focus sur le codage et l'architecture
VP of Engineering est la personne qui met en place les processus, met en œuvre les outils, qui améliorent la productivité globale et aident les ingénieurs à se développer. Si vous restez directeur technique, vous continuerez à faire les choses liées au codage direct. C'est le CTO qui connaît l'ensemble du système de et vers, et sait également où les squelettes sont cachés dans les placards.
Devez-vous être directeur technique?
Je n'étais pas prêt pour une telle décision. Je ne savais même pas que je devrais faire un choix. Je pensais que le directeur technique serait le gestionnaire de facto. Cela semble être le cas dans plus de la moitié des startups auxquelles j'ai parlé. Quel que soit le chemin que vous empruntez (managérial ou technique), vous devrez trouver quelqu'un qui reprendra la deuxième branche.
Pour prendre une décision, il vaut la peine de se souvenir de vos origines. Où avez-vous passé le plus de temps, dans quelle mesure êtes-vous confiant et dans quoi aimeriez-vous revenir?
Au début, votre équipe n'aura qu'un ou deux ingénieurs. Tout votre temps sera consacré au codage, ce qui est génial. Lorsque votre équipe compte environ 6 personnes, tout ira bien. Environ 80% du temps sera consacré au codage et 20% à la communication. Et le flux de travail sera toujours agréable. Vous serez sûr à environ 90% de tout
Et puis les choses deviendront beaucoup plus difficiles. Vous serez engagé dans un travail direct dans la moitié du temps, car vous serez occupé à embaucher de nouveaux et de nouveaux employés. Il y aura de plus en plus d'employés qui ont besoin d'aide, et ce n'est pas si génial, car vous devrez le faire et écrire du code autant qu'avant. À ce stade, vous devez décider de ce que vous voulez faire - gestion ou développement. Comment aimez-vous ce mouvement le long de l'arbre du développement?
Vous avez juste besoin de trouver celui qui produit votre dopamine.
C'est un excellent conseil d'un fondateur de startup. Vous sentez-vous bien si vous pouvez aider quelqu'un à faire face à une tâche? Ou aimez-vous résoudre des problèmes techniques? Ce sont les réponses à ces questions qui devraient vous aider à comprendre la voie à suivre.
Quatre leçons des CTO de différentes startups
J'ai parlé avec 15 fondateurs et directeurs techniques pour essayer de décider sur quoi se concentrer. J'ai demandé à chacun d'eux ce qu'ils avaient remarqué en cours de route et les difficultés qu'ils rencontraient. Dans ces conversations, quatre sujets ont constamment fait surface:
1. Acceptez les points de basculement
J'ai interrogé tout le monde sur leur plus grande erreur - quelle expérience ils en ont tirée et ce que c'était, et comment ils l'ont corrigée. Puis je leur ai demandé comment ils essaieraient de l'empêcher. Tout le monde a réfléchi un peu avant de répondre, puis a dit quelque chose comme: «Vous savez, je ne le ferais probablement pas. Nous devons traverser des moments comme celui-ci pour vraiment comprendre ce que nous essayons de faire. Pour apprendre à bien faire les choses, vous devez vous familiariser avec l'autre camp. "
En termes CTO, considérez les points d'inflexion comme une mise à l'échelle du service. Si vous rencontrez des goulots d'étranglement, vous devrez les corriger. C'est beaucoup plus efficace car il est très difficile de prévoir leur occurrence - en particulier dans les startups.
2. No man's land
C'est ainsi que je peux appeler une équipe composée de 6 à 12 ingénieurs. Dans de telles équipes, un peu de tout se passe, et c'est très déroutant. Vous remarquerez que vous dites des phrases telles que «Pourquoi cette personne ne savait-elle pas cela? Et ne savait-il vraiment pas quoi faire? " Si vous êtes confronté à de telles questions, vous ne pourrez plus combiner les responsabilités - vous devrez faire une chose et transférer l'autre moitié des tâches à quelqu'un qui peut y faire face. Vous n'êtes pas assez génial pour gérer deux rôles à la fois, mais vous n'êtes pas assez stupide pour ignorer cet état de fait. Vous semblez être coincé au milieu.
À ce stade, la communication peut aider à construire des ponts. Si vous vous retrouvez à dire des phrases telles que «Pourquoi X a-t-il fait cela?» Alors vous devriez commencer à dire certaines choses plus souvent. Répétez jusqu'à ce que les gens roulent des yeux et disent: «Encore une fois». Ceci est important car cela vous aide à assurer un niveau égal de compréhension entre tous les employés.
3. Mimétisme structurel
Souvent, j'ai entendu des CTO dire quelque chose comme: «Eh bien, nous avons vu comment ils le font chez Spotify ou« Nous avons vu comment Amazon le fait ». Ces personnes ont adopté la structure d'autres entreprises. Si vous, en tant qu'entreprise technologique, innovez, vous ne devriez pas inventer des méthodes de gestion innovantes. Vous ne devriez même pas proposer quelque chose de nouveau dans la structure de votre entreprise. Vous devez innover grâce à votre technologie, votre code et vos produits.
Trouvez ce que vous trouvez intéressant et essayez de l'appliquer dans votre entreprise. Au fil du temps, votre entreprise deviendra unique en mélangeant des idées et des modes d'organisation que personne d'autre n'a. Vous pourrez peut-être trouver quelque chose vous-même, mais cela ne devrait pas être votre objectif. Vous devez essayer de comprendre ce que font les autres et vous efforcer de vous éviter les tracas.
4. Focus
La dernière leçon est basée sur mes erreurs personnelles. Lorsque nous avons commencé à embaucher des ingénieurs, nous pensions que plus de personnes nous permettraient de faire plus de travail. Au début, les fondateurs et la première paire d'employés engagés jonglaient littéralement. Il nous a semblé que tout le monde pouvait travailler sur deux ou trois projets - et c'était bien. Donc, quatre ingénieurs peuvent gérer huit à douze projets en même temps, non? Non, c'était une pensée terrible.
Plus il y a de projets, plus il y a de fils de communication. Il est beaucoup plus difficile de suivre tous les processus et de s'assurer que tout le monde comprend tout. Avec le recul, je pense que lorsque nous avons embauché plus de personnes, cela valait la peine de maintenir la charge de travail au même niveau, ou peut-être même de la réduire un peu.
Nous venons de choisir un projet sur lequel tout le monde s'est concentré. Nous avons clairement fait comprendre à tout le monde que c'était notre priorité absolue. Il y avait aussi des tâches secondaires, mais elles étaient secondaires, notre objectif principal était le principal.
J'espère que mon expérience aidera ceux qui essaient de naviguer dans les eaux troubles des premiers stades des startups, en particulier en tant que CTO. Ce serait formidable si je savais tout cela à l'avance, mais peut-être que je n'aurais pas toute cette expérience. Néanmoins, il est tout à fait normal de se confondre, de reporter les décisions à plus tard et de régler le problème lors de vos déplacements. Tout cela est normal, car au début, les startups ont une grande variété de besoins.
- Discussion sur HackerNews
- Chaîne de télégramme "HackerNews en russe"