Cette semaine, le bulletin est parrainé par Faros.

La plupart des équipes d'ingénieurs ont adopté l'IA. Moins de peut dire ce qu'il produit. La consommation de jetons est en train d'exploser.

Les dirigeants de l'ingénierie doivent savoir si les dépenses sont consacrées à des travaux productifs ou à des boucles d'agents sur des tâches insignifiantes. Le flux est passé du jeton au résultat expédié.

FarosS Engineering World Model relie vos équipes, outils, repos et workflows.

• Il observe où chaque jeton est allé et ce qui a expédié

• Il diagnostique la cause profonde derrière chaque fuite d'efficacité

• Il optimise par des modèles de routage, des compétences et un contexte éprouvés sur votre propre code

En savoir plus

Merci à Faros pour avoir sponsorisé cette newsletter. Revenez à la pensée de cette semaine !

Introduction

Fait intéressant, presque toutes les entreprises à qui je parle de nos jours ont une structure d'ingénierie et d'équipe différente.

Il y a 2 ans, la structure org était assez normalisée, avec des équipes interfonctionnelles de 2 pizzas et un gestionnaire d'ingénierie qui dirigeait l'équipe. Ensuite, un directeur gère 2-4 gestionnaires d'ingénierie et relève d'un vice-président, qui relève du CTO.

De nos jours, tout le monde s'en rend compte au fur et à mesure qu'ils vont, en procédant à des ajustements et en voyant ce qui peut fonctionner ou non.

Cette année, j'ai vu à la fois des structures très traditionnelles et des structures d'ingénierie extrêmement uniques.

Dans l'article d'aujourd'hui, je partage les différences entre Anthropic, OpenAI, Shutterstock, et aussi des mentions honorables supplémentaires (certaines sont des configurations très uniques).

Commençons !

Comment OpenAI construit des équipes d'ingénierie native de l'IA

J'ai parlé à Thibault Sottiaux, qui dirige à la fois ChatGPT et Codex, au début de l'année, sur la façon dont ils construisent des équipes d'ingénierie d'IA-native.

Fait intéressant, ils recrutent surtout des ingénieurs logiciels, qui peuvent construire des projets de bout en bout, et possèdent aussi des projets d'une idée jusqu'au moment où le projet est lancé puis maintenu.

Les équipes sont séparées sur la base de projets spécifiques, et se composent principalement de 2 à 4 ingénieurs. Le rapport entre le gestionnaire et l'ingénieur est très semblable à celui du PM, qui est d'environ 1 h 30.

Thibault a également mentionné que dans le département du Codex, il y a même un ratio 1 : 40 PM-moteur.

Les ingénieurs sont censés porter de nombreux chapeaux différents, et ils travaillent avec un PM ou un concepteur quand il ya un besoin pour elle. Chaque projet a également une IRM (personne directement responsable), qui possède le projet. Fondamentalement, étant le Responsable technique prendre des décisions sur le projet et faire des communications avec les intervenants.

De plus, les équipes ont le moins de réunions possible, elles ne se rencontrent que lorsqu'elles doivent s'aligner sur une certaine chose. Pas de Scrum, Kanban, ou des réunions quotidiennes, juste des équipes se concentrant sur l'exécution de leur projet et collaborant sur celui-ci.

C'est aussi la raison pour laquelle beaucoup d'entre eux préfèrent travailler sur place, car ils travaillent sur ce projet de la même façon qu'un hackathon-style, au lieu de cela, ce n'est pas une version "throwaway", c'est un produit réel sur lequel ils travaillent.

Pour en savoir plus sur la façon dont OpenAI construit les équipes d'ingénierie de l'IA-native, lisez l'article complet:

Laissez aller à la prochaine.

Comment anthropique construit les équipes d'ingénierie native de l'IA

J'ai eu récemment le plaisir de parler avec Katelyn Lesse, Chef de l'ingénierie plate-forme à Anthropic, et il a été très intéressant d'apprendre comment ils construisent des équipes d'ingénierie native de l'IA.

Ce qui est particulièrement intéressant est qu'ils ont un état d'esprit complètement différent quand il s'agit de construire des équipes d'ingénierie que OpenAI.

OpenAI travaille avec de petites équipes de 2-4 ingénieurs, tandis qu'Anthropic est toujours en faveur d'une équipe cross-fonctionnelle traditionnelle de 2-pizzas avec 5-8 ingénieurs, un PM, un Product Designer dans le cadre de l'équipe, et un gestionnaire d'ingénierie à la tête de l'équipe.

La principale différence entre une équipe traditionnelle et l'équipe Anthropique AI-native est qu'il n'y a pas d'ingénieur QA dédié. Le travail d'AQ devrait être fait par quiconque au sein de l'équipe.

En outre, la plus grande différence est que tout ingénieur logiciel peut être un chef de file technologique, alors que dans une équipe traditionnelle, vous avez la plupart du temps 1 chef de file technologique.

C'est ainsi qu'ils peuvent exécuter jusqu'à 5 projets simultanément dans l'équipe, au lieu de 1 ou 2 projets traditionnels, car le Tech Lead n'a pas la capacité de diriger plusieurs projets simultanément.

En outre, ils sont de grands défenseurs pour les gestionnaires de produits, en particulier les TPM, les gestionnaires de produits qui comprennent vraiment la technologie sous-jacente ainsi. Leur raisonnement est qu'avec de nombreux projets se déroulant simultanément dans l'équipe, il ya un besoin plus grand de PM.

Et ils pensent même avoir plus de 13 heures dans chaque équipe interfonctionnelle. C'est un état d'esprit complètement différent de celui d'OpenAI, où ils ont 13h pour environ 30 ingénieurs, tandis qu'Anthropic a 13h pour environ 5-8 ingénieurs et potentiellement le rapport de plus en plus bas.

Ils ont également un rôle spécifique au sein de leur entreprise appelée Prod Ops (exploitation de produits), avec le rôle de rendre les systèmes, les processus et les outils plus efficaces afin que les PM et les équipes puissent prendre de meilleures décisions plus rapidement et obtenir de meilleurs résultats.

Une autre chose intéressante est que TOUS leurs codes sont générés par l'IA. Au lieu de modifier manuellement la sortie du code généré par l'IA en fonction de l'invite, ils fournissent une rétroaction et guident l'agent d'IA vers le résultat correct (norme requise).

Ils voient cela comme un meilleur flux de travail que le changement continu du code eux-mêmes manuellement. C'est aussi la raison pour laquelle Katelyn croit que la révision du travail généré par l'IA est devenue l'une des compétences d'ingénierie les plus précieuses.

Pour en savoir plus sur la façon dont Anthropic construit les équipes d'ingénierie de l'IA-native, lire l'article complet:

Comment Shutterstock construit des équipes d'ingénierie native de l'IA

J'ai parlé à Jefferson Frazer, Directeur des métadonnées et de la livraison d'IA, Shutterstock, très récemment, et il a partagé beaucoup d'informations intéressantes sur la façon dont Shutterstock fonctionne et construit des équipes d'ingénierie d'IA-native.

Je partagerai beaucoup plus d'informations à ce sujet dans un futur article, mais aujourd'hui, je partage certains des points importants, surtout par rapport à la façon dont OpenAI et Anthropic construisent leurs équipes.

Leur structure d'équipe d'ingénierie native de l'IA est beaucoup plus semblable à Anthropic. Ils travaillent également dans une équipe de 2-pizzas avec 5-8 ingénieurs dans le cadre de l'équipe, et un gestionnaire d'ingénierie à la tête de l'équipe.

La grande différence est qu'ils ont environ 1 PM pour toutes les 2 équipes, donc le rapport est d'environ 1 PM pour 10-15 ingénieurs. De plus, la conception de produit ne fait pas partie de l'équipe interfonctionnelle, et elle est utilisée lorsqu'il y a un besoin pour elle dans une partie des projets sur lesquels les équipes travaillent.

Une autre grande différence est qu'ils ont 1 Tech Lead dédié à l'intérieur de l'équipe, qui est responsable de tout ce qui est technique concernant les projets, mais il peut également y avoir des propriétaires supplémentaires de certains projets à l'intérieur de l'équipe, mais principalement, une personne est la principale direction technique de l'équipe.

Un élément important que Jefferson a également mentionné est que leurs équipes de produits travaillent dans les sprints de 2 semaines et utilisent Scrum comme mode de travail, ce qui est le même que les équipes traditionnelles.

Ainsi, ils ont toutes les réunions en tant qu'équipes traditionnelles : réunions quotidiennes, planification, rétrospective, etc. Et il y a aussi une réunion de démonstration de sprint à la fin de chaque sprint.

De plus, chez Shutterstock, ils ont aussi des équipes d'ingénierie ML dédiées, et ils travaillent beaucoup plus différemment que les équipes de produits.

Ces équipes travaillent dans un délai de 6 semaines, où elles se concentrent sur la réalisation d'un certain objectif dans les 6 semaines. Pas de Scrum ou Kanban.

La raison pour un flux de travail tout à fait différent que pour les équipes de produits est que le travail ML est beaucoup plus imprévisible, et vous ne pouvez vraiment pas promettre certains résultats en X quantité de temps. Vous voyez ce qui peut être possible en fonction des recherches que vous faites.

Comme mentionné ci-dessus, restez à l'écoute de l'article complet sur la façon dont ils construisent des équipes d'ingénierie de l'IA-native, qui sera publié dans un futur article de newsletter.

Autres mentions honorables

Laissons aussi passer certaines des structures d'autres entreprises.

Clé de port

J'ai parlé avec Vrushank Vyas, Chef de GTM et CS, Portkey, plus tôt cette année. Fait intéressant, ils ont environ 24 ingénieurs, qui sont tous des ingénieurs de produits et aucun gestionnaire de produits.

Chaque ingénieur doit porter plusieurs chapeaux, y compris être un Ingénieur déployé avancé, Service à la clientèle, Gestionnaire de produits et, bien sûr, Tech Lead.

Leur structure d'équipe est beaucoup plus proche de ce qu'OpenAI fait, et leur attente est que chaque ingénieur puisse posséder un projet de bout en bout.

Et aussi, très similaire à ce qu'OpenAI fait en matière d'embauche, ils aiment embaucher des généralistes forts qui peuvent construire à travers de nombreuses piles technologiques différentes, ou des spécialistes extrêmes qui sont vraiment bons dans une technologie spécifique.

Pour en savoir plus sur le fonctionnement de PortKey, lisez l'article complet :

Poids

J'ai parlé avec Andrew Churchill, Cofondateur et CTO, et Adam Cohen, Co-fondateur & PDG, quand j'ai visité leurs bureaux à San Francisco.

Ils ont une équipe d'environ 10-15 ingénieurs, et tous sont considérés comme des ingénieurs de produits qui peuvent porter de nombreux chapeaux différents et leurs propres projets de bout en bout.

Ainsi, à l'instar de PortKey, le focus natif d'IA de Weaves ressemble à ce qu'OpenAI fait.

Pour en savoir plus sur le fonctionnement de Weave, lisez l'article complet :

Après-Hog

Fonctionne au sein d'équipes de 1-3 ingénieurs, avec un chef d'équipe assigné pour chaque équipe. Le chef d'équipe relève également directement du vice-président du génie, aucun gestionnaire intermédiaire entre les deux.

Télnyx

L'agence d'ingénierie de Telnyx est composée de 200 ingénieurs, 0 gestionnaires d'ingénierie et 1 vice-président d'ingénierie. Ils ont pris le mot "flatter org" à l'extrême.

Malheureusement, je n'ai pas les informations sur la façon dont leurs équipes sont structurées, mais il est intéressant de noter à quel point leur configuration est unique. 1 200 IC par rapport aux gestionnaires.

Dernier mot

Les entreprises semblent avoir des structures et des équipes d'ingénierie très différentes de nos jours, et on dirait que chaque entreprise à laquelle je parle fait quelque chose de différent.

La principale solution est qu'il n'y a pas de structure d'ingénierie parfaite pour le moment. Tout dépend de ce qui fonctionne pour une organisation et une équipe spécifiques.

Donc, c'est aussi mon conseil, regardez toujours ce qui est le mieux pour votre équipe et votre organisation, n'essayez pas simplement de copier un autre org aveuglément.

Et faire de petits changements est la façon d'aller à mon avis. Faites un petit changement et voyez comment ça va, et si c'est pour le mieux, gardez-le, sinon, retournez-le.

C'est bon !

Vous avez aimé cet article ? Assurez-vous de cliquer sur le bouton comme.

Rétroaction ou ajout? Assurez-vous de commenter.

Tu connais quelqu'un qui trouverait ça utile ? Assurez-vous de partager ce post.

Chaque fois que vous êtes prêts, voici comment je peux vous aider davantage

• Vous souhaitez parrainer ce bulletin? Vérifiez les options de parrainage ici.

• Découvrez mon livre -Le Multiplier Mindset--qui sort plus tard cette année, ici.

• Jetez un coup d'oeil au swag cool dans le magasin de leadership d'ingénierie ici.

• Tu veux travailler avec moi ? Vous pouvez voir toutes les options ici.

Contactez-nous

Vous pouvez me trouver sur LinkedIn, X, YouTube, Bleu ciel, Instagram ou Fils.

Si vous souhaitez faire une demande sur un sujet particulier que vous souhaitez lire, vous pouvez m'envoyer un email à info@gregorojstersek.com.

Ce bulletin est financé par des abonnements payants de lecteurs comme vous.

Si vous n'êtes pas déjà, envisagez de devenir un abonné payant pour recevoir l'expérience complète!

Vérifiez les prestations du régime payé

Vous êtes plus que les bienvenus pour trouver quels sont vos intérêts ici et l'essayer dans votre cas particulier. Faites-moi savoir comment ça s'est passé ! Les sujets portent normalement sur l'ingénierie, le leadership, la gestion, le développement de produits évolutifs, les équipes de construction, etc.