Bruno:
10 years ago, coding was a craft. Today, it's a conversation. Between people, between tools, and between AI. And in that conversation, Figma might be one of the loudest voices in the room. But how do you scale a team when the Canva never stops growing? How do you keep the pace of delivery when collaboration itself becomes the product? And how do you build for designers, developers, and everyone in between, without losing your mind? To answer these questions of rhythm, culture, and scale, Je ne parlerai pas à Da Vinci, mais il sait bien comment faire la ligne entre design et l'engineering. Marcel, bienvenue.
Marcel:
Merci, merci beaucoup.
Bruno:
Marcel, pouvez-vous vous présenter pour les personnes qui ne connaissent pas vous ?
Marcel:
Oui, je m'appelle Marcel Weeks et je suis le VP de l'engineering à Figma. Je suis très heureux de vous présenter aujourd'hui.
Bruno:
Je suis très heureux de vous présenter. C'est le premier épisode que je vais faire en anglais. Pour l'audience, il va être un peu difficile d'avoir un épisode en anglais aujourd'hui. Mais je suis sûr que tout va passer comme toujours. Ma première question serait qu'est-ce que ça signifie de être VP d'enjeuner dans une société comme Figma ?
Marcel:
C'est un rôle très excitant. C'est beaucoup de plaisir. Chaque jour, je travaille avec certaines des gens plus smarts. Nous travaillons sur des choses que nous trouvons vraiment compétences. Ils sont difficiles, mais nous sommes excités par les choses. Et nos clients sont attendus pour nous les réunir rapidement. C'est un environnement de l'énergie de la grande énergie.
Bruno:
Qu'est-ce qui est le groupe aujourd'hui ?
Marcel:
Notre équipe de l'enginérateur a environ 700 personnes, including la science et la sécurité. La l'enginérateur de l'enginérateur est environ 225 personnes.
Bruno:
C'est une équipe massive.
Marcel:
Une équipe de équipes.
Bruno:
Oui, je pense qu'il y a des équipes. Comment vous assurez-vous que tout va bien fonctionner dans ce genre d'environnement ? que personne n'est pas de pied sur quelqu'un et qu'il faut diviser le travail en un plus efficace.
Marcel:
Oui, je pense qu'il y a un petit peu d'advantage en que nous construisons collaboration software. Donc, nous tendons... Les gens qui viennent de Figma tendent à être collaborateur. Donc, c'est pas que nous essayons d'éviter les gens de se faire sur les pieds. Nous avons des gens qui nous permettent d'être un peu, intentionally. Part of this is actually our tech stack, we have an interesting tech stack. All of our developers are full stack developers. And our tech stack, if you are building out a feature, you're certainly going to touch something on the front end in React. You might be doing something in the API layer in Ruby. Vous êtes probablement à faire quelque chose dans le canvas, qui est dans C++, qui est complète dans WebAssemblée, qui est en cours. Il y a juste une interesting stack, et il y a plus de langues, depending sur la quantité vous allez ou où vous allez. Et c'est rare que les développeurs connaissent toutes ces choses quand ils commencent. Donc, c'est un environnement où nous sommes très cher pour soutenir les autres. Les gens tendent à spécifier dans ces zones, et, en ce qui est, ils sont devenus l'expert, et ils se font avec les autres personnes, but they also have questions about other parts of the codebase.
Bruno:
It's a massive full-stack scope. Because you are talking about Ruby, C++, on the front-end you React. I'm guessing, yeah, also a lot of technologies are about that. Usually when we talk about full-stack software developers, we are meaning like React and PHP, or maybe React and something more classical. It's a smaller range of technologies, but what you are talking about is quite huge. Est-ce que c'est que c'est que être un développe de full stack en 2025 est plus difficile que ce que c'était en 1980 en 1990 il y avait, moins de technologie et tout était plus simple que ce que c'était aujourd'hui par exemple en 1990 les développeurs étaient assez facile parce que HTML et JavaScript étaient presque non-existent. Il n'y avait rien de compliqué à faire. Aujourd'hui, ce sont des jobs très compliqués. Et vous avez dit que dans le Figma, les développeurs ont un grand nombre de technologies. Comment est-ce possible en 2025?
Marcel:
Le key est de soutenir les niveaux d'abstraction. OK. Donc, nous avons des développeurs en C++ pour l'example, nous avons les niveaux de abstraction, parce que C++, qui est famous pour avoir, comment dire, « foot guns » où vous pouvez vous en tirer en la tête très facilement. Nous voulons faire de l'abstraction pour que les développeurs ne pas avoir à pas de problème de la mémoire management, comme l'example. Nous avons également une équipe d'internel design system. Avec Figma, nous sommes beaucoup plus sur le système de design. Et les gens qui travaillent dans notre front-end sont utilisés ces composants. Donc ils ont un pied sur ça. Et même si il y a plus de langues, il y a plus d'abstractions, il y a plus d'abstractions à proposer de l'abstractions. Il y a plus d'abstractions. C'est toujours beaucoup, mais c'est juste que quand on a fait notre job bien, un développeur ne doit pas aller à l'abstractions. Il y a un product engineer ne doit pas aller à l'abstractions. Ils peuvent travailler à l'abstractions et construire des features rapidement.
Bruno:
C'est-à-dire que vous avez aussi des teams dans Figma qui sont spécialisés dans le C++ ou en React pour construire ces types de tools ? C'est-à-dire que même si ils ne travaillent pas sur Figma, ils sont toujours dans ce spirit de collaboration parce qu'ils ont construit des tools, donc tout le monde peut construire des tools sur lesquels.
Marcel:
Absolument. Our engineering org is being sort of a triangle, with product engineering being the top of the triangle in terms of being the smaller piece, but leveraging all the work that is done by teams in the base of the triangle or the pyramid. So we have a team that focuses on our runtime and a team that basically at the core of Figma is a game engine effectively. And they focus on building that out so that other teams can build on top of that quickly.
Bruno:
Ce que j'ai trouvé intéressant sur votre résumé, c'est que vous êtes venu de Slack, vous avez passé beaucoup de ans sur Slack, ce qui est aussi un outil collaboratif. Nous avons vu que Slack a transformé la façon dont nous travaillons et comment nous collaborons avec tout le monde dans nos équipes. Figma est le même entre développeurs et designers. Est-ce que c'est quelque chose qui est un traitement de collaboration, cette notion de collaboration ?
Marcel:
Je pense que c'est... Je dirais que c'est... Je dirais que c'est probablement... Je pense que c'est juste que c'est une collaboration. Je pense qu'il y a un certain niveau, il y a un certain niveau.
Bruno:
Il y a un certain niveau.
Marcel:
Je pense que c'est difficile pour moi de travailler dans un endroit qui n'était pas un collaboratif. Donc, je pense que c'est un software qui peut aider à faire plus de productivité, pour aider les gens à faire plus. Mais je ne pense pas qu'on peut faire ça sans collaboration. Collaborative software est la base et puis, productivité tools, c'est ce que je suis drawn à.
Bruno:
Quand j'ai commencé cette job en début de 2000, et peut-être même avant, il y a eu l'idée que les développeurs de software étaient assez lonely. C'était une carrière lourde, vous êtes alone, facez votre computer et vous n'avez pas parlé à personne. Et en tant que années, j'ai découvert que c'est un travail très collaboratif. Nous ne pouvons pas faire des choses par nous-mêmes. Nous devons faire ça ensemble. Est-ce qu'il est plus facile à avoir ces équipes de collaborateurs quand vous travaillez sur des équipes de collaborateurs comme FIMA ou comme Slack?
Marcel:
Je pense que c'est. Nous utilisons Figma tous les jours. Nous utilisons FIGJAM. Nous utilisons tous nos meetings sur FIGJAM. Nous utilisons notre product de slides, ainsi que nos clients utilisent. Donc, nous sommes toujours en utilisant les collaborateurs. Et je pense que ça a l'air à nous servir de vraiment, de mieux comprendre les tools, mais aussi d'avoir une empathe pour nos clients et de ce qu'ils vont passer. Quand on utilise un tool et qu'on trouve un gros edge, ou quelque chose qu'on ne l'a pas, on sait que nos clients ont déjà runné à travers ça. Donc, on veut que nous voulons s'assurer que ça s'assure et que ça s'assure.
Bruno:
OK. Avant Slack, avez-vous rencontré des entreprises que vous avez travaillé qui n'étaient pas assez collaboratifs que vous avez expérience aujourd'hui avec Figma ou Slack ? Et ça a été un pain pour vous ?
Marcel:
Oui, j'ai eu hâte de long et storie de careers, donc j'ai eu hâte de l'opportunité à travailler à des entreprises qui sont collaboratifs, moins collaboratifs. Oui, c'est... Ça peut être lourdement. Je pense que, comme vous l'avez dit, développement n'est pas nécessairement une personne dans la maison avec ses headphones en, dans un quartier. Je pense que, en pratique, quand vous voyez développement vraiment working, c'est des personnes qui travaillent ensemble. Oui. Les gens qui sont en train de regarder ou à la whiteboard, mais c'est un très collaboratif. Donc, je pense que c'est un sport de software qui est un sport. C'est un activité qui est best joué ensemble. Ça ne veut pas dire... Je veux dire, il y a un temps où on a besoin d'un temps où on a besoin de focus. Mais le fun part de ça, c'est quand vous êtes engagé avec d'autres personnes. Je pense que c'est la raison que les gens se font en product engineering, c'est parce qu'ils veulent avoir construit un peu de feedback, de avoir construit quelque chose, d'un autrement à quelqu'un, souvent comme un client, et puis avoir le feedback. Les gens vraiment jouent ça. Et je pense que c'est ce qui fait un peu de ce que vous voyez avec continuous deployment. Il y a des bénéfices à ça, mais les gens veulent que la dopamine de l'honneur. C'est pourquoi ils font ça. Et je pense que si vous regardez ça, c'est ce que les gens font aussi. Ils font ça. Ils font ça. Qu'est-ce que vous pensez ? Je dis que c'est pas tellement que les gens sont looking for validation external. Je pense qu'ils sont en train de faire des feedbacks. Comment peut-on améliorer ça ? Comment peut-on améliorer ça ? Comment peut-on améliorer ça ? Je pense que c'est comme un sport de team.
Bruno:
C'est intéressant l'analogie que vous faites avec le sport de team, parce qu'en VP de l'engineering, vous êtes le coach de la team, vous avez bien sûr le rôle de l'équipe technique pour faire des décisions bonnes décisions, et je serai heureux de parler de ça en quelques moments, mais avant, en tant que coach, vous avez aussi besoin d'assurer que la team travaille ensemble. So you are saying it's easier because you are within Figma since you are building collaborative tools, people are in this collaborative kind of mindset but how do you make sure as VP Engineering that the collaboration is actually working, that the information is coming through everyone and that everything is working smoothly?
Marcel:
I'll answer this in two fronts one I think at a company level and two I think more at a team level C'est quelque chose que j'ai trouvé Figma très soutenir. Nous sommes une organisation collaborative, même en dehors de l'enginie, juste en dehors de l'enginie. Nous avons tous les deux semaines à la FIG Nation, et les gens obtiennent beaucoup d'informations de l'enginie. Ils sont en train de poser des questions en advance, et ils ont été répondu à l'enginie. Et c'est un environnement très collaboratif. Ça fait le tone pour les équipes de faire le même. Donc, à l'équipe niveau, nous avons notre propre enginie à l'enginie. We'll also make sure that teams participate or come to each other's all-hands. We certainly have a bias towards using public channels within Slack so that people can be kept aware of what's going on there. We do some ceremonies that I would say they're more for culture building than information sharing, but they have the side effect of information sharing. Donc, nous faisons des tests sur Thursdays, où quelqu'un va présenter quelque chose. Je pense que ça a commencé un peu plus comme, ici, c'est quelque chose que j'ai appris, et maintenant c'est quelque chose que nous avons fait, et les gens viennent à ce que nous faisons. Nous sommes très open avec les specs, et nous faisons une création de l'enginine. Nous avons une création de l'enginine pour la revue des designs, mais nous faisons la même pour l'enginine. Et c'est quelque chose que tout le monde dans l'enginine org est invité. People will opt-in if they have feedback, but because we use FigJam, people can participate asynchronously and provide information there as well. So I'd say the tone has been set from the top down, that it's very open and collaborative. Il y a aussi l'expectation que si vous allez dans une autre domaine, si vous voulez, que vous allez pouvoir les faire de la code ou même parler de l'approche que vous allez prendre avant que vous arrivez. Donc, vous avez eu le chance de rencontrer avec quelqu'un. Quand vous faites de la travail, vous allez vous aider, vous n'êtes pas en leur dosage. Ils connaissent ce que vous êtes en train de faire. Vous avez parlé de l'approche. Parce que ce que vous n'avez pas, c'est un code base qui est en un direction et quelqu'un et qui fait un changement qui va l'opposite direction. Ça devient difficile à reconcilier. Mais vous avez besoin d'alignement avant de changer le code.
Bruno:
Donc c'est beaucoup de feedback, et tout le monde est capable de voice leur opinion ?
Marcel:
Oui, absolument. Nous solicitons les feedbacks.
Bruno:
Ok. Et vous avez besoin d'entraîner certains de les gens à accepter ce type de feedback, ou donner le droit de la façon dont c'est aussi un deux-way street, comme je disais.
Marcel:
Oui, je pense que c'est vrai partout où je travaille, et pour moi personnellement. Je pense que c'est facile early dans une personne de travail à prendre la capacité de feedback en un état de critiquer. En un état de façon à l'étonnant. Et je pense que, quand vous vous faites un niveau de confiance avec quelqu'un, c'est que ça devient un gift. Comme le phrase « c'est un gift de feedback ». Quand vous avez un niveau de confiance avec quelqu'un et ils vous permettent de vous donner, vous savez que c'est dans votre best interest, ou dans votre best interest. Et le feedback que nous avons offert, comme une code review ou une technique de feedback, C'est juste pour faire le produit que nous avons mis en place de travail. Donc, personne ne voit ça. Ce n'est pas le cas que les gens voient que ça. C'est une critique de ce que je faisais ou de ce que je suis. Instead, c'est plus, c'est nous qui faisons le produit mieux.
Bruno:
OK. Vous avez parlé d'une plateforme, si quelqu'un fait une décision, c'est pas quelque chose que vous voulez voir dans l'organisation. So it's always the choice of doing the best thing or the right thing, in a way. Did you have sometimes, let's say, the opportunity to kill the best choice because it was not the right choice within the organization?
Marcel:
So we've definitely had situations where what was a pragmatic choice that we could have done quickly is no longer the right choice for us. Et nous voulons faire un changement grand. Nous ne faisons pas ces légumes parce qu'ils sont des investissements surtout les investissements dans le stack. C'est-à-dire qu'il y a beaucoup de dépendances. Nous sommes très careful avec ces. Nous tendons... Take a very deliberate approach, solicit feedback, especially from consumers of these changes, and then we are careful in rollout. So we'll typically do a small portion rollout to make sure that, or we'll do a dark rollout where we're doing dark reads and writes and then comparing the results to make sure that things are still going to be as we want them to. Because generally in those cases, it's some sort of a remodel where you want the end result to be the same, but the implementation is something you're doing differently. So, as long as we can maintain that level of things are still good and working and we are improving the internal system, then we're fine with that.
Bruno:
And how do you maintain… let's move to another question that is more maybe related. Because you are talking about those kind of changes you need to do on the stack to improve, de moderniser ou des choses comme ça. J'ai travaillé principalement dans les petites équipes et dans les petites entreprises. Le sujet de la débat technique est toujours quelque chose dont nous nous déroulons, même si nous sommes juste quelques-uns de développeurs. Vous étiez parlé de l'équipe de 250 développeurs et de l'équipe de 700 développeurs. Comment vous gestionez la tech depte sur cette scale ? Est-ce que vous devez juste tout drop tout régulier et tout redire ? Comment vous pouvez-vous faire ça ?
Marcel:
First off, je dirais que c'est mon propre disclaimer, mais je ne pense pas que toute la tech depte est mal.
Bruno:
Oui, bien sûr.
Marcel:
Je pense qu'il y a des moments pour nous, Comme la personnelle, vous pouvez acheter des choses pour acheter une maison ou une maison. Mais vous avez besoin d'intentional sur la dette. Et nous faisons une approche de travailler à l'entreprise. C'est quelque chose que nous faisons toujours. C'est une des règles d'une chose de trouver quelque chose de mieux que vous avez trouvé. Si vous avez des changes et que vous avez des choses, vous avez des choses qui peuvent être addressed. C'est l'expectation. Our competitive advantage is speed and our ability to iterate, and you can't iterate on a debt-filled codebase. It's very slow to do so. So in order for us to have that competitive advantage, we've constantly got to be addressing our technical debt. And that doesn't mean we're perfect at it. There's certainly times where, you know, we get to an area like, wow, this hasn't been touched in a while. What's going on? Et on ne pas, mais on ne veut pas le monde et le débat, et on ne veut pas le débat, comme un peu d'antipattern. Nous ne voulons pas à faire ça. Nous voulons juste faire ça constamment. C'est-ce qui veut dire que, à une une fois une étape, ça peut prendre plus longtemps que nous voulons. Donc, si on a quelque chose de prendre trois jours, on peut prendre trois et demi. Mais en général, nous allons plus vite, parce que maintenant, c'est plus vite, et la prochaine personne qui est en train de faire ça en deux jours, instead de trois jours. Donc, nous sommes constamment payant cette dette.
Bruno:
C'est intéressant, parce que le concept de la dette peut aussi venir du fait que vous avez un code legacy qui fonctionne, mais les normes que vous tendez à imprimer dans les entreprises sont révoluées. Donc, la façon dont vous codez aujourd'hui n'est pas alignée avec la façon dont vous codez un peu plus ans. et donc quand vous ouvrez le code, ça fonctionne. C'était standard de ce que vous avez expecté quelques années, mais pas comme ce que c'est aujourd'hui. Donc, dans ce sens, ne vous essayez pas de changer le mode que vous pouvez trop souvent, donc vous n'avez pas...
Marcel:
Oui, je sais ce que vous êtes dit. Nous ne pouvons pas, Le fait de la matter est que les choses changent très vite et les assumptions changent très vite. C'est souvent des assumptions de productes qui sont changées qui influencent le code et le changement. Et nous voulons que les choses comme des product engineers est de garder avec ces changements. Donc, nous n'avons pas d'y aller à la fin parce que ça a cause de faire un refactor. Sinon, nous disons que c'est là où nous allons maintenant. C'est là-bas, c'est là-bas maintenant. Et c'est certaine, je pense qu'il t'existe un niveau de flexibilité en l'engineering, pour pouvoir dire que c'était ce qui s'est passé et qu'est-ce que nous allons faire quelque chose de différent. Parce que je pense que avec des ingénieurs, vous ne devriez pas être marrié à la code. Vous allez changer et vous allez changer, vous allez changer, les gens d'assumptions ou les requirements changent, et vous devez avoir à la fin de ce que c'est. I think the further down in the stack you go where you've got like deep infrastructure, That's even more costly to make changes there and that's that I think is an area where people, Some of my best friends are our infrastructure engineers, but they tend to be very wed to the code yeah, they want to make sure that this is gonna last forever and they would not be as open to refactors in order to address, non-necessary changes.
Bruno:
Oui, c'est aussi parce que le plus profondément le plus impact on peut avoir.
Marcel:
Oui, le plus grand radius est plus large. Donc, je pense que en tant qu'en product engineering optimise pour speed et sur une structure stable, on est confortable en faisant ces changes.
Bruno:
Ok. Vous essayez de prendre un peu plus longtemps pour que vous pensez à ces changes to make sure you are not making, not necessarily another mistake but you are taking another path that will need to be changed in a few months or maybe a few years yeah.
Marcel:
Every time we're looking at making changes we're I wouldn't say we're future proofing things but what we want to do is give ourselves optionality going forward what can we change, what can we allow ourselves to do going forward, we don't want to, constrain ourselves to a change now just that we're gonna have to come back and revisit but we want to be future aware we're not going to be future proof we're not going to pretend to know the future but future aware there okay.
Bruno:
In in the the small teams have been working on or working with there was a lot of let's say debate around the relationship between product and developers you are building a tool pour des développeurs et des designers. Donc, en un moment, vous êtes un autre interlocuteur dans cette conversation. Comment vous construisez un tool pour aider ces gens à travailler ensemble ? Et est-ce qu'ils travaillent mieux ensemble dans Figma, parce que vous êtes en train de construire un tool pour faire les gens travailler ensemble ?
Marcel:
Je pense que c'est notre intention, C'est à faire que ça va significantly mieux. Je pense que... Je dirais que nous avons beaucoup d'amélioré le designer-to-front-end-developer relationship. Je pense que product est quelque chose que nous avons addressed et probablement a better job de product-to-designer. Mais nous viewons tous ces roles comme un plus adjoint product, design et développement. et que le travail entre eux, tout le monde a quelque chose à contribuer à la construction de la construction. Et en un cas, nous sommes tous les makers. Si vous avez un terme pour l'unbrella pour l'unbrel, vous vous appelez les créateurs ou les makers. Nous voulons tous les pouvoirs participer à la construction. Ça ne veut pas que tout le monde a la même vue, mais il veut que tout le monde a l'input. Et je pense que, historiquement, il y a eu l'impression que vous avez eu l'impression que vous êtes alluding à cette tension, entre product and engineering. I actually think some of this tension is good in that you might want your product manager to come in and say, hey, I need you to build me the universe by Friday, and have engineering come back and say, okay, I'm going to give you Earth by Wednesday. That's like getting us to the right spot. Design plays a big role in that, obviously, as well. I think it's okay to have that tension as long as people are respectful about it and understanding of it when it becomes si ça devient personnelle, c'est un problème, pas un problème. Et puis on a sort de lost le plot. Mais je pense que avant de ça, si nous pouvons très bien, avec les gens collaborer, la tension est bien.
Bruno:
Oui, je comprends. Un an à l'heure, nous avons eu l'occasion de faire un épisode avec Lucie de Figma. Nous avons parlé de la mode dev dans Figma. C'est intéressant parce que quand j'ai commencé le développement dans le premier siècle, Il y a eu un tool sur la page de Microsoft, qui a construit des pages HTML pour nous. Il y a eu beaucoup de tools depuis l'époque. Il y a toujours le même discours dans la population des développeurs, qui dit que ces tools sont construisent des mauvais codes, qu'ils ne sont pas au niveau de ce que nous pouvons faire, etc. Je pense que c'est intéressant, un point que j'aimerais parler avec vous, c'est comment, avec un groupe de développeurs, vous construisez un outil qui va générer code pour aider les développeurs dans le mode de dev mode, et pour assurer que les développeurs sont heureux, avec le code qui a été généré. Donc, comment vous approchez cette création de ces outils ?
Marcel:
Le premier truc que vous avez dit, c'est la critique que vous avez mentionné, où les développeurs se regardent à la code que l'on a génére et disent, « je ne voudrais pas avoir fait ça, c'est clairement pas que ça. Les développeurs vont dire que c'est pas que ça, que c'est pas un autre développeur qui a written. Donc, c'est à dire, nous avons nos préférons. Je dirais que, en dev mode, nous avons un peu d'advantagement ici, What we're doing with design systems in Figma means that developers want to be writing using those design system components, and they want to be leveraging that. So with DevMode, we provide them either access to their, like a shortcut to be able to find their component or the code of the component itself. And that way it's what they would have wanted. It's a constrained problem. Je pense que votre question applies quand il y a un LLM générique de code. C'est pas assez constrainé de problème. Et je pense que nous avons déjà vu ce que les développeurs. Ils pensent que je n'aurais pas écrit ce code. Il y a une critique de ça.
Bruno:
D'ailleurs, vous arrivez à Figma. Est-ce qu'il y a une certaine product que vous êtes très heureux de voir le team ?
Marcel:
Oh.
Bruno:
Brought out?
Marcel:
That's like asking me if I have a favorite child.
Bruno:
Yeah, well, maybe.
Marcel:
I'm not sure I can answer that question. They're all my favorite.
Bruno:
Okay, I see.
Marcel:
For different reasons.
Bruno:
So you arrived in Figma one year and a half or two years ago?
Marcel:
Three and a half years ago.
Bruno:
Three and a half.
Marcel:
Yeah, three and a half.
Bruno:
I've seen an interview you had when you talked about the new manager death spiral.
Marcel:
Yes.
Bruno:
C'est un concept que je n'ai jamais entendu d'abord et que je trouve assez intéressant. Tu peux juste donner un petit summary de ce que c'est ?
Marcel:
Oui, et full credit à un ancien manager qui a introduit ce concept à moi, Michael Lopp. Le nouveau manager Death Spiral est quelque chose où, je pense qu'on a une industrie, nous ne sommes pas très bons à soutenir nos engineers de l'économie à l'économie. Et je pense que nous n'avons pas très bien pour cela. C'est souvent happening under duress. C'est pas le meilleur setup. Et ce que vous aurez souvent, c'est que une équipe qui était small et efficace, a qui s'éclat, et maintenant a besoin de management. Vous pouvez voir que une 4-person équipe devient 9 ou 10-person équipe. Quand il y a 4, il y a un chef qui est en train de conduire. Maintenant, c'est 9 ou 10, il y a une personne qui a un full-time job qui est sort de interfacing avec les autres parts de l'organisation, helping support career development, helping guide technical decisions. And now what we do is we take oftentimes the strongest technical contributor to that team and put them in a different role. It's basically taking them off the team as a contributor and now having them take on a new role that they haven't had before, oftentimes without any training, and we say, good luck, you did that well, you'll probably do this well. A shrug of the shoulders. Et puis, le team, parce que c'est déjà devenu rapidement, mais aussi maintenant, il y a un qui a un major contributor. Si ils ont un problème, la première chose que le manager que l'on peut faire, c'est comme ça, « Ok, je peux le faire. Je sais que je peux le faire. Mais si vous n'êtes pas à la gestion du management, qui est probablement déjà underservé, c'est pourquoi ils ont été mis en ça, vous n'êtes pas à faire ça. Et le nouveau manager death spiral est-ce qu'ils vont faire et commencer à être en train d'être un manager à la même temps. Maintenant, vous êtes en train de faire deux jobs. Et le chances de faire un autre de ces deux, alors que les deux de ces deux, les deux de ces deux, vont bien très bien. Et vous endz avec des gens qui travaillent 14 jours. Ils se sont burnés. Ils se sont frustrés avec leurs co-workers. Et vous vous êtes dans cette death spiral. Et ce que j'ai vu, et beaucoup d'autres ont observé, c'est que vous avez des gens qui ont dit leur toe dans le management, et puis ils viennent et disent « je n'ai pas de faire ça encore ». Donc il y a beaucoup d'entre eux, j'ai rencontré et j'ai rencontré, « oui, je n'ai pas fait ça, je n'ai pas fait ça encore ». Et ce que j'ai déjà dit, c'est probablement indiqué de leur expérience. C'est un expérience où vous êtes dans une organisation qui peut soutenir la transition et qui peut aider à vous en faire et faire que vous avez les ressources que vous avez, ainsi que vous avez une équipe, donc vous ne vous sentez pas de neveux d'être dans le domaine. Et je pense que vous avez un autre résultat en termes de gens qui sont en train de changer. Parce que management n'est pas une promotion, c'est un mouvement lateral. C'est un autre travail, un autre travail. Donc c'est comme si tu as pris ton meilleur developer de l'équipe et qu'on a fait un designer, tu as prévu qu'ils vont faire un bon travail si tu donnes leur entraînement ? Ou si tu as prévu qu'ils vont faire un bon travail si tu n'as pas leur soutien ? C'est un autre traînement et c'est quelque chose que tu as besoin de soutien.
Bruno:
Donc dans Figma, tu as une certaine traînement et traînement pour ce genre de career path ?
Marcel:
We do. So we have management-specific training for all new managers, whether they're coming from an engineering background or just in other parts of the org. And I'm proud to say one of the things about Figma is that we made a big investment in our learning and development. This is aligned with one of our cultural values, which is to grow as you go. So we're always evolving and taking on new things. et je pense que c'est la sorte de, en plus de la walkie en plus de la talkie en plus de la transition en plus de la transition.
Bruno:
Ok, awesome. Donc, nous avons parlé de beaucoup de choses, il y a beaucoup de choses que je voudrais parler. Nous avons parlé de la génération de code, la capacité des développeurs à liker code written par quelqu'un d'autre. Il y a beaucoup de changements dans notre job en tant que développeurs. Dans les derniers dernières années, nous tendons que ça va plus vite et plus vite. Je parle, bien sûr, de l'AI. Est-ce que vous utilisez une code génération dans Figma pour construire l'actuale tool à chaque niveau? Ou comment vous approchez le code et les autres types de tools?
Marcel:
Oui, nous avons été très open pour expérimenter avec différents tools et nous avons commencé à utiliser various code generation tools, co-pilots de différents sorts. Nous n'avons pas restricté developers à une. Nous nous donnons beaucoup de gens, donc les gens sont utilisés à l'écart de l'écart de l'écart. C'est quelque chose que je dirais, nous sommes probablement à l'expectation que les gens utilisent.
Bruno:
Mais est-ce que vous limitez tous à utiliser juste un ? Ou peut-être qu'un autre développeur ?
Marcel:
Oui, un développeur peut utiliser un, deux, trois. OK. Nous avons une diversité de ces tools et nous nous laisse les gens utiliser. People tend to gravitate towards one because once you've built up the proficiency in it, especially if it's one where you can choose which model you want to use, they can use different models for different tasks. But we let developers use it, and what we tell developers is you still own the code. It may be generated, but you've got to review it yourself. You've got to make sure you're comfortable with it. You will be the one who responds if something goes wrong with it. Donc, les gens prennent cela seriously, mais ils utilisent ces tools comme un booste efficacement. Et nous voyons que ça ait une vraie impact.
Bruno:
Et qu'est-ce que, de votre perspective, est-ce qu'il y a une bonne idée ? Ou comment vous managez une successful integration de l'AI dans le développement de la software ?
Marcel:
Je pense qu'il y a quelques ways que nous judgeons ça. On est, nous ne faisons pas de la question de nombre de PRs ou de code, mais nous avons des choses que sont peut-être une ordre à removerre, en termes de commenter le nouveau engineers rampant sur le code base. Ceci est quelque chose que je pense n'était pas l'initial expectation, parce que les gens ont commencé à venir et ils ont un d'un buddy ou mentor et ils ont demandé des questions de commenter mais les choses sont-ils mais les gens sont-ils invariables sont-ils à-dire à-dire à-dire la seconde, la seconde, la seconde, la question in un jour. Mais vous avez maintenant un agent qui connaît la code base très bien et vous pouvez demander à-dire les questions que vous voulez. Nous avons des gens rampent très rapidement et ce résultat. Et ce n'est pas juste initial new hires, c'est des gens qui ont on move around the organization. We support internal mobility, we want to keep people at Figma and learning new things, keep fresh ideas moving around. And people will jump into new sections of the codebase and quickly ramp up by engaging with agents. So that is something I think that's been a success metric for us. We also look at the quality of the code. Are we catching more edge cases before they go out? And that's something that you have to be very careful about how you're prompting to make sure you do those. But I'd say that probably the one sort of easiest metric for us to measure is code coverage. Because I'd say the area that took off the most once we got these agents in house was people writing additional tests. C'est facile à faire des tests maintenant et les gens font tout ça pour tout, c'est génial, nous voulons plus tests. Mais ils sont en train de faire des tests, des tests, des tests et des tests, et ils font beaucoup plus de tests.
Bruno:
Donc Figma a commencé, je ne sais pas si on a la date précise, mais Figma Make, où vous pouvez générer des éléments en utilisant AI. Est-ce que tu utilises la même approche que tu avais quand tu as commencé à construire le mode dev, c'est-à-dire que les développeurs construirent un tool qui va générer code, parce que c'est quelque chose que tu fais comme développeurs, c'est à lire et lire code. Est-ce que tu as la même approche, puisqu'on est maintenant utilisé LLM pour générer des choses, quand vous êtes construit un LLM qui peut aider les autres à générer un nouveau tool ? Je ne sais pas si ma question est clear.
Marcel:
C'est un différent approach. Je dirais que l'on de la clé distinctions est que... Figma Make, je vais vous remercier pour un second. Figma Make est notre prompt-to-app service. Vous pouvez donner un langage prompt. Figma Make will generate pour vous que ce design. Et vous pouvez switcher à la code-based vue de ce design. Donc, vous pouvez voir le code qui est en train de l'écouter. Ou vous pouvez choisir de l'écouter de l'écouter dans le Figma Design pour que vous puissiez directement manipuler le filtre, aussi. Donc, plutôt qu'à avoir à utiliser le prompt pour changer la couleur, vous pouvez utiliser la couleur picker ou la couleur. Ou une de nos directe manipulations tools dans le Figma Design. Et ce que je dirais, c'est que la grande différence ici, c'est que vous êtes generating code pour quelqu'un de consomme. C'est comme DevMode, mais ce qui est différent ici, c'est que le problème n'est pas comme constrain. Nous ne savons pas ce qu'ils ont demandé ce qu'ils ont demandé. Ils ont demandé ce qu'ils ont demandé. Ils ont demandé ce qu'ils ont demandé. Et ce qu'ils ont été créés par le lever pour les gens qui travaillent avec des LLM générations, c'est ce qu'il y a l'eval. Et avoir des evalues pour que nous puissions, les efficaces de ce et comment ça performera. Mais aussi, si le modèle est plus utile, est-ce que le modèle est plus ou plus, ou qu'est-ce que nous devons changer dans le prompt, dans le système prompt, pour permettre de faire ça. Donc, je pense que les evalues sont la grande change. Nous n'avons pas de faire ça avec Dev Mode. C'était clair que nous avons généré, l'évale est venu de l'end-user. Maintenant, les evals sont presque le spectre pour ce que nous produisons en termes de l'LLM. Et c'est quelque chose qui est très différent.
Bruno:
Ok. Vous voyez aussi, parce qu'on parle de la part de code-generation, l'implementation de la fin de la fin de la fin de la fin, mais l'AI a changé la façon dont nous construisons les features dans un plus broad spectrôme, parce que nous tendons à mettre des AI et des LLMs dans beaucoup de choses aujourd'hui comme développeurs. Est-ce que vous voyez une, des changements dans la façon dont nous construisons aujourd'hui comme développeurs ou est-ce que c'est juste un autre tool que nous pouvons utiliser qui n'est pas tellement différent de la façon dont nous avons ?
Marcel:
Je pense que c'est un changement step-function. Je pense que c'est un changement substantially différent. Je pense que c'est différent en tant qu'axes. Pour moi, je pense que avant, comme développeurs, et évaluer le solution set le mieux que nous pouvons choisir un path et aller dans le nous prototipons et voir si cela est correct et aller dans le, et maintenant avec l'AI vous pouvez explorer le problème space beaucoup plus vous pouvez trouver trois ou quatre solutions vous pouvez trouver un que vous comme et vous pouvez demander pour cinq variations de ça et vous pouvez et vous pouvez aussi construire un très haut-fidelity que les gens vont interact avec, comme un prototype, en un jour, plutôt que plusieurs jours ou jours. Et puis, vous pouvez faire des changes et faire des changes. Je pense que c'est shortant la distance de l'ideation à l'automne à l'automne, qui fait le tout le path de production. Ça fait que ça. Et je pense que, en tant que façon, ça change la façon que les développeurs travaillent. Also, I just think that we are moving from... We've stepped up an order in terms of... It's a higher order interface to the code. Before, we were writing the code directly. And before this, people were setting up punch cards directly, too. This is part of a progression, disruptive in many ways to people now and somewhat anxiety-inducing until they become familiar with it. But this is part of a progression. Nous avons eu l'intention de punch-cards à declarative, language is imperative, et nous sommes mouillés dans le stack. Mais maintenant, je pense que le rôle de l'entreprise est plus à expressing system concepts, et describing ce qu'ils veulent, plutôt que de translating ça à un langage, à un langage de programmation, et de hopiner que l'entendez à l'Assemblée est exactement ce que vous voulez. Maintenant, Et vous devez que ces machines sont probabilistes, ils ne sont pas deterministes, mais avec une compétence vous pouvez exprimer ce desire que vous aimez en langage naturel et vous obtenez le résultat. Donc maintenant, vous avez beaucoup moins de temps writing individual lines de code, beaucoup plus de temps en lire individual lines de code, qui est très important, mais vraiment en pensant à la niveau des systèmes plutôt que des fonctions.
Bruno:
C'est intéressant de revenir à la punch-en-cord. I've seen a conference A long time ago that I've talked about A lot of times in various episodes In this podcast I think it was by David Bretz Or something like that, I'm not sure, And he was talking about the time When C++ Came out, Where assembler developers Considered that C++ was too high level Of a language And so C++ developers Were not actually developers parce que c'est trop haut niveau. Et vous aussi mentionnez-moi en l'épisode que vous considérez que développer, designers et product sont en même brûl de makers ou builders. Je ne sais pas si vous avez dit.
Marcel:
Both.
Bruno:
Do vous considérez que avec l'arrivée de l'AI, LLM et such, que le concept de builders est en train de changer complètement et que notre job de développeurs aujourd'hui, ce n'est pas que ça va disparaître mais que ça va changer drastiquement.
Marcel:
Je pense que c'est comment on a definié ce job. Ce qu'on a definié ce job. Si on a definié ce job, c'est qu'on a defini ce job. C'est qu'on a defini ce job. Si on a defini ce job, c'est qu'on a créé excellent solutions à des problèmes. C'est qu'on a defini ce job. Si on définit ça en un langage que peu de gens, relativement à la population, ça peut être plus qu'un autre job. Ça peut être différent, mais je vais vous remercier, je pense que le lire ça va être vraiment important. Je pense que le notion et le concept de l'entrée de programmation avec les données structures et les algorithmes, ce sont toujours très important. Et je pense qu'on n'est pas évoquant de ça d'une fois plus tard.
Bruno:
Merci beaucoup Marcel pour cette discussion. Je dois dernières questions pour vous qui sont des questions dans le podcast. La première est, si vous avez une culturelle contenue que vous voulez dire à tous?
Marcel:
Vous savez, c'est un peu d'amorté mais la série Atlanta est une de mes favorites et c'est top-of-mind pour moi parce que l'un des seasons est en Paris, est set in Paris, et en Paris cette semaine, ça me reminded de ça. Donc je dirais que c'est mon recommandation.
Bruno:
Je vais mettre un lien dans la description, pour que vous puissiez le trouver. Et la dernière question, la plus importante de l'épisode, est-ce que vous êtes un tab person ou un space person?
Marcel:
Je suis tab. Je l'ai fait comme tab.
Bruno:
Merci beaucoup Marcel. Merci à tous d'avoir écouté cet épisode un peu particulier parce que c'était donc le premier en anglais. N'hésitez pas à nous mettre en commentaire si vous souhaitez en avoir d'autres, si vous souhaitez avoir une traduction en français pour ceux qui ne le savent pas. Vous avez un transcript qui est disponible sur le site du podcast pour l'avoir en anglais et je pense qu'on mettra aussi la version écrite en français si vous le souhaitez. Je vous remercie comme toujours de partager ce podcast autour de vous, n'hésitez pas à aller checker le Tipeee si vous souhaitez participer et aider ce podcast à grandir je vous remercie beaucoup, je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.
