EPISODE 1593

[INTRODUCTION]

[0:00:00] ANNOUNCER: One of the key challenges that teams encounter is how to smoothly collaborate on converting a design into code. For example, if a designer designs a web component, how can it be most efficiently implemented by a developer? What happens if the designer needs to adjust the design and communicate this change to the developer? These sorts of issues can often lead to inefficiencies and frustrations on a team. 

Figma recently announced Dev Mode, which aims to smooth design and developer collaboration. The idea is to tie the visual language of designers to the actual component implementation of the developer. Marcel Weekes is the VP of Product Engineering at Figma. And before that, he spent 6 years at Slack. 

Marcel joins the show today to talk about Dev Mode. How it will boost collaboration between designers and devs? And the new Figma VS Code plugin that brings design into the IDE. Marcel also talks about the concept of the new manager death spiral and how individual contributors, or ICs, can smoothly transition to management roles. 

This episode is hosted by Josh Goldberg, an independent full-time open-source developer. Josh works on projects in the TypeScript ecosystem. Most notably, TypeScript ESlint, the tooling that enables ESLint and prettier to run on TypeScript code. Josh is also the author of the O'Reilly Learning TypeScript ook, a Microsoft MVP for developer technologies and a live code streamer on Twitch. Find Josh on Bluesky, Mastodon, Twitter, Twitch, YouTube and .com as Joshua K. Goldberg. 

[INTERVIEW]

[0:01:46] JG: With me today is Marcel Weekes from Figma. Marcel, welcome to Software Engineering Daily.

[0:01:51] MW: Good morning, Josh. I'm really looking forward to our conversation today. Thank you for the warm welcome.

[0:01:54] JG: Yeah, likewise. I've been a Figma user for quite a while. I'm really excited to talk to you about all the stuff that's been happening in the next few years. It sounds like you've got a lot of cool things in the pipe there.

[0:02:03] MW: Yes. And thank you for being a user. We appreciate all our users and the great feedback that they provide us with.

[0:02:08] JG: Love it. Real quick. I do have to ask, for those who haven't used it before, what is Figma?

[0:02:14] MW: That's a great question. Figma as a company makes a set of product surfaces and tools that allow for collaborative software for teams. Basically, allow teams to build products together. And we cover the entire sort of cycle of software development. From brainstorming, to design, to actual build. And we're probably most well known for our flagship product, Figma design, which is the middle step of that visual design. 

But prior to that, in terms of flow, prior to that is our brainstorming or online whiteboard tool, which is FigJam. And this is really a fun and delightful tool that allows teams to get together, including non-designers, virtually asynchronously in person at the same time and sort of do some quick prototyping, quick ideating and get their ideas on screen. 

And then we move from that sort of brainstorming phase into the build phase with, as I said, the Figma design tool. And then lastly, we have this product surface inside of Figma design known as Dev Mode, which helps front-end developers to actually take those designs and accurately, with high-fidelity, turn those into a working product.

[0:03:20] JG: Well, that sounds like a great outline for an interview. We're going to go through each of those, especially Dev Mode. But before we cover Figma, I also want to cover a little bit on you. Who are you? 

[0:03:30] MW: Oh, thank you. Again, my name is Marcel Weekes. And I am the VP of Product Engineering here at Figma. I support the teams that work on our end-user experiences. If you are a designer who is in the product six to eight hours a day, it's our teams that are working on that. If you're a developer who drops into FigJam to help on a brainstorm, our team support that. And as we'll talk about, if you're someone who uses Dev Mode, we also support that feature.

[0:03:57] JG: And how long have you been at Figma now?

[0:03:59] MW: I've been at Figma just just over a year and a half now.

[0:04:01] JG: And how's that going? How do you like it there? 

[0:04:03] MW: It has been a pretty wild ride these last 18 months. One of the key things when anyone's looking for a job I think is sort of what they're going to learn and, perhaps most importantly, the people they're going to be around. And I have learned a ton over these last 18 months. It's been a very dynamic time here at Figma. But even though we've all been working hard, it's been great because the people have been fantastic. It's been a lot of fun to really work with this group of folks. 

[0:04:26] JG: Well, I'd love to hear that. You've been working in productivity tools for good amount of time. Breezeworks, Slack, and now Figma. Is there anything in particular that draws you to that type of product? 

[0:04:35] MW: Yeah. I'd say – as you mentioned, I worked at Slack, which several people – many people may know about as sort of a workplace productivity tool. Prior that, I've been at Breezeworks, which was a startup that was focused on productivity tools for on-site service professionals. You can think of these folks as people who typically run their business from a truck and maybe have a shoe box full of receipts in their center console of their vehicle as they run from job to job. 

And that was really for me in a moment where I – I had been working in adtech before and had done sort of the three-sided marketplace with consumers, publishers and marketers. But I wanted to do something that was a bit more direct monetization where we were building tools for people that would be willing to pay for them, frankly, and really enjoyed using them. 

I think the through line across all those products, but really that has stood out – there are two through lines I should say. The first is using technology as a high leverage point for end users who basically – a lot of end users at work don't get to pick the tooling they have. It's often times there is a distinction between the end user and the IT purchaser. And I think there's a lot of satisfaction to be had in building an amazing consumer-grade experience for enterprise users. 

Someone's got to be at work all day. They're oftentimes using tools. It'd be great if those tools were fun to use and were actually made them more productive. We all have too much work to do. I know that's the case for everyone. And being able to get through that in a more productive fashion, but also a fashion where you enjoy the tooling you're using, that for me, it's sort of a Northstar of things I could work on and things I really enjoy bringing to folks.

[0:06:12] JG: You've spoken in the past on being a manager, on being a director, that track up to VP. And part of what you just said rings true I think for a lot of people. That if you're going to spend a lot of time using a tool, it's better for you and better for the team to enjoy using that tool to not have it get in your way. Are you able to qualify and/or quantify the benefits from the management perspective of say the team is more productive or more likely to innovate when using a tool like Figma or Slack that's pleasant to use?

[0:06:38] MW: Oh, yeah. That's a great question. I think sometimes people refer to it as the tool sort of getting out of your way. And actually, I think it's slightly different than that. It's nuanced and that people don't want to be fighting the tool they're using. But you really want the tool to be an accelerant to help you do more of what you want to do and do it more effectively. 

And at some level, it comes down to this term that I wish we had another term for because it's somewhat overloaded. But it comes down to a sense of engagement. When people are using tooling and they're getting their ideas out faster, whether that's – and faster in terms of speed is really an important aspect of all of these tools. Because you want your fingers and you're pointing device to operate at the speed of thought. 

But if you can get those thoughts out quickly and be collaborating with your co-workers as quickly as possible, those ideas start to riff. Especially with collaborative tools, you get a bit more of momentum going in terms of pushing ideas forward. I think it's important for tools to not get in the way. But more than that, to really accelerate what it is you're trying to do with the tool. 

And I've seen teams just – it's really interesting. Oftentimes, once a tool or a bit of workflow is in place, teams are reluctant to change that because they start building up other – it sort of creates around it, right? You get other tooling that integrates with it. It becomes expensive to pull it out. But I'm sure you've seen this as well, but there are times where like a new tool comes along and you swap about what you have been using for this new tool. And all of a sudden, things are going faster. And it's not that the tool is necessarily faster. It's just it allows people to do more than they had been doing before. 

[0:08:10] JG: Tools like Figma I think are notorious for being the upstarts here where they're that much easier to use, so that people are still then able to move from the older tool even though you have a lot of process build-up over it.

[0:08:20] MW: Yeah. Absolutely. And I think this is somewhat well-chronicled, but I'd say the secret sauce with Figma to the extent it was secret is the collaboration aspects and being able to very quickly share what you're working on in the moment and have multiple people check out and provide feedback without having to sort of manage files, if it's a single URL for a file. And that obviously really helped up the game of collaborative design. 

And I think for a long time, there had been this stereotype, and it's true on the development side as well, of someone sort of puts on their headphones. They go into the basement and they spend six, seven hours there and they come out with this amazing design or this amazing functionality and code. And in practice, both those activities even within their disciplines are very, very collaborative. It's a team sport. 

And I'm sure we'll talk about Dev Mode. Once you start crossing those disciplines, that's also true. Even more so. I think getting these tools to be more collaborative, whether that's your source control system or, as a developer, whether it's something as integral as your design tool as a designer. Having that be collaborative really helps you do what it is you intended to do, which is to work with your collaborators.

[0:09:28] JG: Sure. I want dive into that actually. Because from a pure software standpoint, the Figma collaboration model is fascinating. Are you able to give a high-level overview without spoiling any company secrets of how that stuff actually works underneath it? 

[0:09:40] MW: Yeah. I can give a relatively high-level overview of this. I think what people maybe most identified first with Figma, and now we're starting to see other completely different products and disciplines take this into account, is what we refer to as multiplayer, which is the notion that not just that you and someone else are looking at the same file, but you can interact with the other person. 

And within Figma and within FigJam, this actually takes on like a very playful attitude at times. We have this feature that's not as – a relatively little known feature, but it's gaining in popularity of cursor chat, which allows you to actually hit a keyboard shortcut and then type in what you're thinking, which shows up right below your cursor. And it's really fun when you're actually presenting or having a conversation with a group of people and someone starts riffing on ideas right in there in the document and you can see it. 

I'd say that multiplayer is like the main aspect of what's known. But there are other pieces that underpin this as well. We certainly have a very rich commenting system in both of our tools that allow people to either communicate synchronously or asynchronously. It ties in with notification systems through email, or Slack, or other tooling as well. 

I'd say that it's really – those are sort of the two main standouts. The multiplayer, which people identify is like the circles with everyone's face in the top right and cursors moving around and being able to see what you're seeing and being able to spotlight someone. And everyone goes to what that person's looking at or following them. It helps for presentations as well as for ideation. 

[0:11:13] JG: Sure. Let's take a technical issue. Because I would love to know how Figma handles this. Let's say that I'm in the United States with, let's say, a terrible internet connection. And I enter a document. I see there's a blue square and I change into a green circle. And then a colleague of mine on the opposite side of the world with the opposite quality internet connection, let's say, somewhere in China, changes it to a red triangle at roughly the same time. What does Figma do in that case? 

[0:11:37] MW: This like an age-old problem of conflict resolution. And there's lots that we've actually written up a blog post around this, which we can include in the speaker notes below, I guess. But I'll give you the high-level premise, is last right wins. That's how we treat that. 

And one of the reasons we do that is because we can reflect back to everyone as quickly as possible what's there. It's almost the last right wins is a well-worn path on this. But what it enables you to do is sort of you can always see what the other person is seeing. If, as you said in that example, you're on a slow internet connection in the United States. Someone else is on a slow internet connection in China or in another country far away, you make your change and they'll see that eventually. But if they don't see it right away, they'll make their change and they'll see their change. But ultimately, you will then see their change as well. 

And we do track all those changes. What's interesting there is if someone doesn't undo gesture. They're not popping back to the first state. They're popping back to the intermediate state. 

[0:12:37] JG: Let's say it's me then you, and then I undo, which state am I undoing then?

[0:12:44] [] MW: If there is an initial state, let's call that A, then I make a change that's B, and then you make a change that's C. If you undo your change, you will see B.

[0:12:53] JG: That's fascinating.

[0:12:55] MW: Yeah. We're actually like logging all of the changes and keeping them in there, which is what we would do if these were taking place over a longer period of time as well. It's just the interaction is where that's really nuanced and making sure that you see it as quickly as possible. 

[0:13:08] JG: Mm-hmm. The scaling then must be incredibly difficult for a company that's had as many successful user adoption stories as Figma. Have you had to do anything in particular harry or otherwise over the last couple years for that? 

[0:13:19] MW: We spent a lot of time over the last 18 months working on scaling. And say some of the major initiatives we really focused on have been around scaling and quality. I'd say it's less sort of like harry out there things. We have written a lot of custom functionality to make sure that we can actually scale. 

Some of these would be fairly standard things that you get to once you have this inflection point of usage. And we're doing some horizontal sharting at the database layer. But we also have our own custom craft QL-like system in order to access data in a timely manner. 

And it's interesting because we don't want to do anything too harry. We want to keep this as simple as possible. Because a simple architecture is one that stands up over time. But it's also something that you can bring – as we scale our own company, you can bring in engineers and they can ramp up quickly. 

But there are times where we have to sort of make pragmatic choices and we try and hide as much complexity or encapsulate as much complexity as possible. But overall, the system architecture is meant to be really straightforward. 

[0:14:19] JG: Let's shift gears a little bit then. Because that system architecture has managed to underpin now three, give or take, products. You've got traditional Figma, as you said. FigJam and Dev mode. Could you walk us a little bit through that story of how the company came to decide on that as the trajectory for what the products are? 

[0:14:36] MW: Yeah. This is really interesting. And it was one of the things I was most interested in when I first started talking to Figma. Because FigJam at that time had just come out and I think was exiting its beta period. I spent a lot of time asking about this as well. And Figma originally launched the Figma product, the Figma design product but had always known that designers, while our core audience and it's the people we intend to super serve, they are collaborators. 

And in order for them to have the best experience, we always knew we would have to work out across the adjacencies to their collaborating partners. Whether that's product management or development. Everyone in the traditional sort of PDE-plus cross-functional group. 

While the initial core product was meant to allow designers to come up with amazing designs and share them quickly, we always knew we would have to move both to the upstream portion of that into brainstorming, and downstream, into building. And that's sort of the motivation for what you've seen over the last year and a half. 

I'd say the first step there was clearly the brainstorming part with FigJam. And it's amazing how much FigJam has taken off not just from a design standpoint, but now we've got lots of people who aren't designers using FigJam. I think that speaks somewhat to the general-purpose nature of an online whiteboard. But we really believe that FigJam is the best tool for doing online brainstorming in the context of design. While you could use it for lots of other things, whether that is planning – it's the full PDE life cycle. Whether it's Gantt charts for planning, whether it's personas, whether it's working with your cross-functional partners to come up with priorities and drag them around and actually highlight them. 

We think that being able to pull in designs into FigJam is really cool. Because people can leave quick comments there and ideate there. But then, also, you can interrupt the other direction as well and bring something that you sketched out in FigJam into design and then make that high-fidelity. 

[0:16:30] JG: That's kind of the visual language. Going from Figma to FigJam. But now you've got Dev Mode, which is somewhat of another direction. Yeah?

[0:16:37] MW: Yeah. What we've really focused on there is designers spend a lot of time putting together their designs. As someone who builds tools for designers, we know that they are very opinionated and they are very sensitive to every pixel on the screen. They want their designs to be built as designed. They want to get as close to that as possible. 

And historically, this is sort of the anti-pattern we've seen across the industry for years. Design will do this work sometimes in a high-fidelity tool. And then they hand it over to engineering or development. And they don't actually know what's going on there. There's no communication. It gets handed over. Developers get it. And they take their best pass at this. They may spend a lot of time reinventing the wheel because there may already be a component that does what they're looking for. Or it may actually get to the point where there's some miscommunication and they build something that's not quite what was designed. And Dev Mode's really meant to address this. 

Dev Mode is meant to move us from a single point of handoff where there's no communication to what I think happens in practice on the highest-performing product teams of actually having this be a phase of communication. And design and development are working together to turn those ideas that we've seen in design into reality in product. 

And that process is one of information exchange back and forth. But it's also one where inefficiencies can really add up. Inefficiencies certainly will lead to slowdown in time to development. But perhaps more importantly, they can also lead to miscommunications and then they're just – you end up building something different than what was intended. 

And that can be – depending on what it is you're building, that can be relatively expensive. An example of something like that is – and I know that this is a trope that gets pulled out over time. But you've heard this phrase that developers are appropriately lazy. And I don't think it's that they're lazy. It's that they're efficient. But they do not want to repeat themselves. 

And one of the things I think developers find very frustrating is when they get a design and they aren't able to tie any of the design to existing components. They either go spelunking through their code base or they end up rewriting a component from scratch. And it may be the case if you're rewriting a component. You missed something that was in the original implementation or the more perfected implementation of the component. And something that might get lost there is something like accessibility. 

People spend a lot of time making sure that their components are accessible. And if you write a component that's not quite accessible and you use it, now we've got problems because it can't be used in the actual product, especially if you're selling into certain organizations. 

Now you've got to go back and retrofit or pull something out. And now you find the actual component, but it's not quite doing what you had intended. These become inefficiencies and frustrations all around. Dev Mode's really meant to tie the visual design system language that your designer is using to the actual component and design system implementation language that developers are using. So that we can have a one-to-one correspondence there and developers have high-confidence that they know what component they should be pulling from their library or know what they should be building if they're building it from scratch.

[0:19:45] JG: Let's say that I'm on a web platform team. I'm managing the design system for a company. And we've newly started using Dev Mode. We're all very excited about it. Thank you for this. And someone has decided that there will be a new variant of button. Let's say it's a new call to action button. What happens next using Dev Mode?

[0:20:03] MW: When you say someone's coming up with this new variant, the designers come up with this new variant and they now want to use it in the implementation. What will happen is they can actually link that component. Or there's probably already a link from the button to the implementation. And they can update that link with additional information. And it's pointing oftentimes to a component in your GitHub repo. They point out here's how we want that actual component to work. 

And full disclosure, we're working on addition functionality here so that that implementation is described in the product. We're introducing a higher level of annotations so that designers can actually describe the different states or what's actually changed about that variant. And then we can link that through documentation to the actual implementation in GitHub. 

Of course, someone on the engineering side will need to build that new variant now. But when they build it, it's linked via that link. And that actually means that the next person coming in has access to it straight away. 

[0:20:57] JG: What does link mean in this context though? 

[0:21:01] MW: That's a documentation link. And one of the things we allow in Dev Mode is that you can take a component in Figma, which represents in Dev Mode, and link that out to another component elsewhere. It's just a URL link out to a component in your repo or potentially into something. Like you may have an external design system maybe in Storybook or something and you can link directly to that. 

[0:21:24] JG: If I were to, let's say, rename the file or move it or some – is it smart enough to figure out or to be told that I need to update the link?

[0:21:32] MW: We have not yet got that going. But that is something we're paying attention to. 

[0:21:36] JG: Great. Thanks.

[0:21:37] MW: I've been on teams that have, and this is an incomplete list of shenanigans, forked the design system, forked individual components in the design system. Copy and pasted. Just used a new design system. It's nice to hear about linking to help prevent that type of shenaniganery.

[0:21:52] MW: Yeah. As we've had Dev Mode in the beta, we have learned a lot about the real-world use cases that people run into with their design systems. And we've incorporated some of that into the product already, but also have thought plans on how we're going to incorporate those going forward. 

[0:22:08] JG: One problem that comes up a lot is the inevitable discrepancy between the two mediums. We have the code medium. Whatever UI library you have, et cetera. And then the Figma medium. Inevitably, each side wants to optimize for how their own medium works. How do you resolve that discrepancy?

[0:22:23] MW: Yeah. I think this is actually one of the key points that what you identified in terms of – there's almost two different systems that need to be bridged. And at that point, it's almost as if people are speaking two different languages. Your designer is speaking the language of Figma. Developers are speaking the language of, oftentimes, the React component. But perhaps it's a SwiftUI component or an Android jetpack component. 

And our goal here in bridging that is to provide as much information in context so that you can actually see that together. Part of this is we address this with CodeGen. If there's a component that someone has in Figma, designers put forth in Figma, you can actually tap into that component and see what code would be required in order to generate that. And that code can be expressed in CSS, React. As I said, Swift UI or Jetpack Compose and also the legacy versions of those mobile platforms as well. 

And by having that additional context, it allows the developer to go back and forth and know that we're actually getting the right information to sort of cross that language barrier if you will.

[0:23:26] JG: Yeah. It's funny. There are small things in products that just exponentially improve my – or one's usage of them. With Figma classic, as we may call it, it's the ability to directly copy a CSS block or SVG from existing elements. It's incredible how much nicer the development flow is when you're going from Figma to code for those little nuances, you know? 

[0:23:49] MW: Yeah. This is one of the things about – getting back to your earlier question about working on productivity tools. That's sort of the magic moment for us as builders is when we identify something like that and build that out and people actually use it. It's oftentimes not some big feature splash. It's the efficiency you find in the workflow that makes it just easier to use. 

Again, that gets back to sort of this notion of not just the tool getting out of your way, but actually helping you move more quickly. And those – you're right. It's those key flows. They're really hard to find. But when you do find them, they're great. 

[0:24:21] JG: Now I'm curious. CodeGen for something like CSS with a bunch of SVG shapes, it's not an overly complicated thing. I'm sure there are developers who would be offended that I just called their six-month of work not complicated. But, conceptually, it's straightforward. But if you're outputting Jetpack, SwiftUI, React Plus, of course, TypeScript, what does that look like for code generation? How does that system get structured? 

[0:24:43] MW: One of the things that's interesting is, first of all, as you said, everyone who's writing this from scratch knows that it's difficult at some level. But one of the things that's interesting is we learned from developers that, for the most part, they aren't necessarily copying and pasting all of that content in. What we try and provide to them is the actual structure of what they're seeing visually. And that allows them to map to either something they already have or to provide a starting point for them.

We ended up generating the code – really, we're trying to link to standard processes and design systems that actually render these components for them. And we know that in some cases they will actually copy that and drop it right in. But in cases maybe – and that is probably true if you're working with a greenfield and you're trying to get going really quickly greenfield codebase. But if you've got an existing design system that you're working with, what you kind of want is to get the general structure in your mind and know where to look in your design system to find a similar component. And that's what we are trying to reflect by showing the CodeGen there. 

[0:25:48] JG: I'm not setting up an automation to sync Figma to my repository via an automated pull request? 

[0:25:55] MW: You know, we do have some people who are interested in that. And they're looking at working on a plugin to actually do that. We've got a couple people who are working on plugins to do that right now. I would say that's more in the nascent stage. I would not say that that's complete and finished at this point. 

[0:26:11] JG: What other projects? I'd love to know. Are there any upcoming Dev Mode or other Figma features you're particularly excited about?

[0:26:17] MW: Yeah. I mentioned earlier the annotations feature, which I'm very excited about. This will allow – again, it speaks directly to the collaboration between designers and developers. Allowing designers to provide even more rich information. 

One of the things about Dev Mode is that prior to us having launched this at Config earlier this year, the experience for developers landing in a Figma file was not ideal I'd say. Oftentimes, it was the case. Many developers I talk to, they say, "The first time I ever used Figma, my designer sent me a link. I clicked on it and I landed in this amazing design that I did not want to break. And I was afraid to touch anything. And I started to pan and zoom. And I got scared." And we recognized that, while the information was there for developers, the experience wasn't what we were looking for. 

Dev Mode was the first of many steps to actually allow us to really create a more developer-specific experience as they land into Dev Mode. So now when someone clicks through on a link, they get something that's a bit more developer-friendly. They can actually see frame-by-frame navigation of the file. And we're building upon this. 

As I mentioned, we're adding annotations so that more of that information that designers meant to convey appears directly for developers as they're consuming these designs. But we've also added and are enhancing a diffing feature. Comparing the changes between versions of elements or even just two – by versions, I mean, actually through version history or even two instances of an element. 

And this helps with one of the main pain points that developers have, which is identifying what's actually changed in the design. I know that the designer rift on it. I had a plan for what I was building. But I don't know what's actually changed. So I don't know where I need to go back and tweak. And having the compare changes functionality is really nice there as well. 

And while we recognize that Dev Mode is a huge accelerant in this case, we also know that developers spend most of their in their IDE. And, specifically, for front-end developers, a lot of their time in VS Code. We have a plugin for Figma that goes into VS Code. You can think of that as us meeting developers where they are. And that'll actually help them with their autocomplete of code generation and looking at the actual designs in their editor. 

We're bridging the gap of being both in VS Code and also having a better experience for developers in Figma. And very excited about some of these features that are coming out towards the end of this year.

[0:28:39] JG: Well, now I'm excited too. We talked about Figma's journey. Where it was? Where it is? And where it's coming over the next one to two years. But you've, as we've discussed, been in productivity tools for quite a while. Do you have in your personal mind a five to 10-year vision for where Figma & Co. might go?

[0:28:54] MW: Yeah. I really wish I had a crystal ball so I can actually see what the 10-year horizon looked like. But what I would say is incredibly excited about some of the changes that are coming industrywide and how they could apply specifically to productivity tools and to Figma. 

I think the most obvious that people are spending a lot of time thinking about now, but we're in the very early innings here, is AI and what that could be doing. And we spent a lot of time looking at this in Figma. We've not announced too much yet. But what I can say is we got some really interesting things coming here. 

I'd say our approach has really been what can we do to help remove sort of the rote drudgery work and automate that away for our designers. And we thought that would be like an initial one or two things. But there's actually a host of things that designers do repeatedly. And a lot of it has to do with generating data, generating sort of an initial start to their designs. 

But there's more that is coming on the horizon here. I think there's a lot that could happen with design systems both in terms of automatically extracting that from an existing set of designs or tweaking, making lots of changes across a design system very quickly and efficiently. I think this is again in the vein of how can we make our users more productive? AI is going to be a big part of that.
 
Now, I think sort of stepping away from – stepping up a level from that sort of very specific use case, Figma exists in the ecosystem of product development. And how will product development be changing over the next two to five years? I think that's a really interesting question. And 10 years at the limit I think is sort of – maybe our best guesses fall apart after that because there'll be yet another platform shift of some major in nature over that time frame. But I would suggest that we're probably looking at teams that become more effective. And the knock-on effects from that are really interesting. Do you end up with smaller teams doing more work? Do you end up with many groups of smaller teams that need to interact more to get something done but that actually work in sort of smaller groups of four or five as opposed to 12 to 15 as we've seen in some cases? And I think that's going to be one aspect. 

Another one is because developers have more tooling, do we end up seeing developers moving more towards full stack across the board in terms of their skill set? Do they end up doing front-end but also jumping into back-end and doing more there? I'm really interested to see how this plays out. 

I think there are a couple different scenarios I could paint. But it would be a fool's errand for me to predict the future here. What I would say is that I think AI is going to play a very effective role here. And I think developers and product teams will become more efficient in what they do. So that it'll be really interesting to see if you have – I just think you're going to end up with smaller teams that are more effective.

[0:31:43] JG: Do you think there's an alternative where, instead of having smaller teams, we've reduced the friction of many people communicating so that we could have bigger and bigger teams that are still able to be effective? 

[0:31:55] MW: I think those will be organized around smaller teams. It'll be groups of teams. but because the cost of communication is going down, at least in terms of tooling, there's always like just the innate cost of communication. But the cost of communication in terms of tooling is going down. That allows different teams to work on different components. And that means that we'll end up with more modularized solutions. But I still think we'll actually end up with smaller individual teams doing things because these modular components will be available off the shelf in many cases. And each of those engineers will be more effective than they have been. 

There are these stats about how much more productive. And these are, at some level, take them with a grain of salt. But how much more effective people who are using various AI assistants or co-pilots are? Whatever their job is. Whether that's writing code, or doing tax preparation, or legal analysis. But if you just look across the product development life cycle, it could be really a multiple of leverage that we're getting for product managers, designers and engineers. 

And I think that is something that the main constraint here, the limiting factor, will be less about communication or team size. And it'll be what people can actually hold in their head because there'll be so much information that they'll be available to them at their fingertips. 

[0:33:14] JG: Sure. And there'll be so much less craft in that information. Fewer things that you just have to memorize because the tool can't do it for you.

[0:33:22] MW: Yeah. They'll be like this sort of the boilerplate that developers deal with that I think is going away hopefully. That's my hope for the next generation of developers, is that you don't see a bunch of boilerplate that they are writing themselves or that even that they're reading themselves. I think as we spend more time reading code than writing it and getting through the boilerplate is – that should all just go off into the distance. Recede into the background.

[0:33:46] JG: Yeah. I would love to see a study of some sort on the boilerplate or repeated theoretically unnecessary tasks that specifically front-end and/or visual teams do. My horror stories of folks duplicating components, well, in theory, AI can help with that. It can let you know if this already exists. Or, okay, here's how to code the thing and then let other people know about it.

[0:34:08] MW: Yeah. And I think that first point you mentioned of just sort of like detection of components so you're not duplicating effort. There's so much lost effort and miscommunication that goes into not knowing that something already exists. And I think maybe more than the duplication of effort is the frustration when someone finds out that something did exist and that they've spent time something similar but not quite that. If we could get to a point where we are able to identify that for people through AI or other heuristics, that's going to be hugely beneficial.

[0:34:37] JG: Yeah. Before we move on to other topics, I do want to give you a congratulations, and myself, both of us, for lasting a world record year 2023, more than 30 minutes without mentioning AI in a tech podcast. I think we win, you know? That's truly unheard of.

[0:34:53] MW: Yeah. Maybe this is the inflection point where people will start to – we peeked at AI. And now we're may be getting into actually using it. 

[0:35:03] JG: The trough of disillusionment next per the Gartner hype cycle. And I cannot wait for the plateau of productivity. Well, I'd love it. I want to shift a little bit. Because we've been talking about processes. And you I think would also be a fascinating person to talk about processes and management. Could you define for us the term new manager death spiral that I found on your previous podcast interviews? 

[0:35:24] MW: This is a term that I learned from my former manager, Michael Leube, that he used as he was describing to me what happens when people make the transition from IC into EM. And one of the things I had observed is that, as an industry, we don't necessarily do a good job of supporting people doing this. It's often the equivalent of a battlefield promotion where a team has reached a size and scale where everyone recognizes they need a layer of management. 

And what we do is oftentimes pluck the most productive person off of that team and ask them to stop writing code and now become a manager. Oftentimes, the reason we're doing this is because we've noticed some points of friction and stress across the team where productivity is starting to dip. And we think management will help with that. 

But now that you've removed maybe one of the more productive members of that team from doing that, the productivity takes a bit of a dip. And the newly minted manager feels like the team should be doing more and they feel like they're under pressure to help the team. And the first thing they reach for is the tool they know best, which is jumping back into the code and helping out with that to help unblock the team. 

And while that's like the intuition and maps well to their existing skill set, it's actually not what the team needed. The team needed a manager to be dealing with in the interrupts that were inbound, or doing some strategic planning, or actually resource reallocation. 

And because we don't actually do those things and we slip back into doing development, now the team's back in the same hole it was in before with sort of not a full contributing developer and not a full contributing manager. And now you've got this manager in what is termed the death spiral. They try and work harder and longer hours and they see fewer and fewer results as a result of that. 

And that can be incredibly frustrating for them. And I actually think, unfortunately, this is one of the main reasons we see such a high attrition rate where people make this transition to engineering management. They do it for a period of time and then they say, "You know what? That's not for me." And they get out of it thinking that that experience they had was representative of engineering management as a whole. 

And I think as an industry, we could do a much better job of supporting people as they make that transition and letting them know both in terms of having mentors and other managers to lean on. But also, letting them know that it's okay that your job now is not actually just writing code. It's doing these other things that are going to be leveraged by the entire team. 

Because, ultimately, engineering management, it's like a service industry. And you are operating in service of people on your team. Writing more code is not necessarily the only way to support that team and certainly not the best way.

[0:38:07] JG: What would be the preferred alternative or alternatives to the behavior that results in that death spiral? 

[0:38:12] MW: This is one of the hardest things. Because you kind of have to take your – the analogy here is maybe taking your hand off the wheel a little bit as someone who's moved into this engineering management role. And rather than being focused on what's happening over the next week or two weeks and what the team is dealing with, they kind of need to take a bit more of a long-term approach. And that's scary because you can see the team is dealing with issues today. And while you can address some of that, the real focus of what you're trying to do is to pave the path for them forward and start thinking about, "Okay, how's next month going to be better? What are the things we need to do to make next quarter better?" And help with the workload the team has or provide clear direction to the team. And a lot of that is going to be – instead of looking internally to the team, it's working externally with cross-functional partners. Whether that's product management or leadership to get a sense of what should the team be doing, clarifying priorities and then making sure they have the resources they need to execute against those.

[0:39:08] JG: You successfully executed the switch from software engineer or engineering lead over to management and director of engineering a few years ago. How do you think you specifically or you personally managed to do this well? Were there particular resources or folks that made it possible? Were you just naturally always an engineering manager at heart?

[0:39:25] MW: Oh, I should be super clear. I tried this and failed the first time. And the most – I've probably gone back and forth about three or four times in my career now. And certainly, the first time, it was exactly what I just described. I thought I could code my way out of the problem. And that didn't work. 

I realized afterwards, I was one of those people. Like, "I'm done. I don't want to do this again." I was fortunate that I got another shot to do it. But also, that I had mentorship and was in an environment where I had the sport structure needed to make that possible. Because the second time that opportunity came around, I was like, "Ah, I learned my lesson the first time. No way. Fool me once." 

And I was fortunate I had a mentor who's like, "Tell me what happened the first time." And I explained it. And they said, "You didn't really have a support structure. We have that now and we can help." And I was fortunate that second time. I do not chalk this up to some sort of like, "Oh, I got it right the first time. And I know how it works." It was I had the same lessons that we as an industry have had. And I just got fortunate that I was in an environment the second time around with support structure. 

[0:40:25] JG: I think it's very poignant. One of the points you that folks go into their comfort zone. You're a skilled programmer. You, Marcel, program. You're in an EM situation. The comfort zone is programming. And I think people do that with tools also. 

I remember, I resisted switching to Figma for years. Because I was proficient in Photoshop back when I used to put my friends' faces on animals in high school. There's this bizarre moment when that pain of existence is greater than the perceived pain of switching over. And that can be very difficult to execute on without a support network. 

[0:40:56] MW: Yeah. Definitely. And I think it's true. It's really interesting the way you pointed out in tooling. Because that's very true across the board. Think of the last time you switched your favorite editor for coding. Yeah. Right? Something major needs to happen to precipitate that. The activation energy on something like that is just huge. 

But it's true also of people in their careers, whether it's going from – making any sort of transition. I transitioned from being an EM to a director, and from a director to a VP. And at each transition, I caught myself sort of slipping back into what was my comfort zone from my prior role and leaning into that when things got tough. 

And I think that's just human nature. I think this is part of maybe what's oftentimes described as having a growth mindset. And I think, personally, it's been challenging for me in those situations to sort of say, "Okay, I know what makes me comfortable here. But I also know that what's going to get me to the next level is not what I had been doing, but it's doing something different." And being open to that. 

I had another manager who described it really well to me. He said, "You need to become comfortable being uncomfortable. And that's your path to sort of trying out new things." And it's funny, I've shared that line with my kids when it comes to eating different foods. But I think it applies to just sort of like a lot in life. The more we're willing to take on and try different things, whether that's new tooling, or new approaches, the more doors that opens up for us. 

[0:42:19] JG: Real quick. Would you be willing to define growth mindset for us? 

[0:42:24] MW: I will take my pass at the definition here. I'm sure there are multiple if we were to Google it. But for me, the growth mindset, as I've heard it and as I've internalized, is really people being comfortable with sort of first-off recognizing there are things they do not know. Being guided towards those things and looking at them not as necessarily failures or challenges that can't be overcome, but actually saying, "All right. I don't know how to do this yet. And I'm going to learn." And learning is a positive thing here. And leaning into that. 

And I think it's in contrast to maybe there's a set of things I know how to do particularly well. And I'm going to stay in that zone. Because I don't want to make any mistakes and I don't want to do something that I haven't done before. And I think that's – the growth mindset allows you to be – I actually chalk this up to being the impact of that I think is that you're more resilient. Because you try things out. You're okay knowing that not all of them are going to succeed. And when you fail, you bounce back because you've actually come into this with the approach of I'm going to learn how to do this and get better. That's how I've internalized the growth mindset. I've certainly heard different versions, but I think that one's the most effective one or most applicable to me.

[0:43:34] JG: Yeah. T think there are at least three skills there that you just touched on. There's the skill of getting yourself psyched up ability to get that activation energy to try the new thing. Second, there's the skill of trying the new thing. And third, there's the skill of failing at the thing and yet still bouncing back. Those are three separate skills that are super valuable to practice but can be very difficult to get yourself in the position to. Unless you go through a lot of effort.

[0:43:56] MW: Absolutely. I mean, just that third one about sort of failing and bouncing back. I don't know how many times people want to practice that. It's kind of like learning to snowboard or something, right? You're only going to find the limits when you fall. But you want – and it hurts to fall. You want to actually get better at it by trying.

[0:44:13] JG: We've already brought up a lot of really good – I hate to coin them as buzzwords or buzz phrases, but they are very good. I want to bring in one more for now, which is barrier to entry. The things that are preventing one from doing an activity. Trying a new product and so on. And you've t talked about how Dev Mode and Figma and other parts of Figma try to reduce that barrier to entry. Like, say a developer opens a Figma for the first time and is paranoid that they're going to destroy it all the moment they click something. Are there any particular things that you're also doing in Figma, especially in Dev Mode or the core product that try to reduce that barrier to entry for folks to give them the comfort?

[0:44:47] MW: Yeah. This is a big area for us. because you can imagine the tension that we face, is we have power users who not just use every tool that's available to them in Figma, but ask for more. And we are trying to satisfy that cohort of user. At the same time, we've got aspiring designers or people who are relatively new to design. Opening up Figma as an end user, as a designer. 

And one of the things we observed is having that blank canvas is actually a little bit intimidating. What do you do next, right? You start clicking around in the toolbars. And one of the things we want to do is make that just much more simple for people coming in. Basically, providing them with the set of starting points. Whether that's a well-known design system. You can think of something like iOS and their human-computer guidelines. Or the equivalent Android with material design. Or all of Google with material design. And giving them sort of that library and a panel that they can just drag out and start using things and assemble from pre-existing Lego parts if you will. 

That's something that there's a tension there. Because our more advanced power users, they prefer having that sort of blank slate and just fire firing off because they know exactly what they're trying to build quickly. And I think for people who are maybe new to design, having something to iterate from is actually really key. We're trying to balance that and deliver both of those experiences. I will say that this is probably an area where you'll see Figma do a bit more with AI and being able to actually generate an initial starting point for people. 

I'd say that for Dev Mode in particular, one of the things we're trying to do is really understand and map to the developer workflow. This is one of the reasons Dev Mode is a completely sort of – it's a very different experience and perspective on the same design that designers have been iterating on. Because developers are – designers are in the tool six to eight hours a day. They know where everything is. They know where all the tools are and they're trying a bit after they've worked on it for a while. And they're trying to build very quickly. 

Developers tend to come in at a different cadence. They may be in the file for a couple days a week and then not again 'till the next week. And when they come in, they're looking for information that's in the file that previously had been latent and sort of hidden in the file. And we're trying to surface that up proactively to them. 

So as soon as they land, they can look at the inspect panel and say, "Okay, here's the dimensions that I'm looking for. Here's a link to the repo that has this information. Here's the variables that represent those colors so that I'm not guessing at the colors, but I actually know exactly what I'm supposed to be pulling. Providing that information up front without being overwhelming is really what we're trying to do for developers.

[0:47:27] JG: Yeah, it's not that developers are lazy. It's that we are rushed. We have a million different things there's always more on the plate. So whatever you can do to reduce that barrier to entry, to give us the ability to quickly do the right thing so we don't have to go through a painful process. I appreciate it.

[0:47:45] MW: And as you pointed out, those friction points or barriers to entry can be as simple as having to find something or click through to something that might require even just the least bit of a context switch or bit of like, "Hold on. What am I looking for?" If we can present that information at the right time, that actually will make people much more efficient.

[0:48:03] JG: We've got four minutes left. And I'd like to spend it asking you some wacky, random questions. Are you ready for the miscellaneous portion?

[0:48:11] MW: Oh, awesome. Is this is a bit of a speed round? I'm happy to do it. This sounds great.

[0:48:15] JG: It doesn't have to be too speedy. What is Code2040? 

[0:48:19] MW: Oh. So, Code2040 is an organization I've been involved with for a few years for a while now. And Code2040 is focused on increasing representation of black and LatinX engineers across the industry. And our goal by 2040 is to actually have this at a level that's representative of sort of the rest of the communities in which we operate. 

And it's been really exciting. I was an early mentor in this group. And I remember the first cohort that I was involved with was a group of six interns. And that was the better part of 15 years ago now. And I recently saw that one of those interns in my mind, they're always these interns, was a CEO of a company that they had founded. And I was so excited to see this and just sort of follow along on his trajectory and journey. 

And it's been really impressive to see this group grow. And I actually just had a chance to go to dinner with one of the former executive directors of the group and just catch up on this. And it's just such a heartwarming moment sort of be involved in that organization.

[0:49:24] JG: That's lovely. I think one of the big mistakes that a lot of perspective or first-time managers, myself included, make is we feel that every success on the people we're managing, our reports part, is their success. And every failure is our failure. And it's hard to take that emotional jump and see that to success. Given that you are a lot many times now successful manager, it must feel really nice to see a former intern now be a CEO and such. 

[0:49:48] MW: That's incredible. I think you're right. And it is sort of their success, for sure. But like just even having a part of that. I'd say some of the most rewarding moments are just when – this happened to me a couple of months ago and it sort of stuck with me as you referenced this. I had a former report who is now a manager tell me that something I had said to them like five years ago, they repeated to someone else recently in a one-on-one and found it helpful. And that was like a very full circle moment for me.

[0:50:19] JG: Do you know what that advice was off the top of your head? 

[0:50:22] MW: The bit of context here that I can share is that the person they were talking to, the manager was talking to, their report had been aiming for a promotion and had not gotten it. And they were very upset about that. And they wanted to express their displeasure with their manager. Not towards their manager, but with the lack of promotion with their manager.

And their manager reminded them that careers are not always linear straight lines. And it's not that you get promoted every 18 months. But that you do want to be growing every 18 months. You want to be growing every day. And sort of focus your career less on, certainly, a scoreboard of progress, titles and promotions. But really more on the impact they're having on those people around them. 

It was interesting. When I had shared this with the person several years ago, it took a while for them I think to actually like feel comfortable with that. They sort of took it as manager speak at first. And then came back a few weeks later and they're like, "Well, how can I have more impact? You said I should – what are examples of this?" And it started a conversation that was productive. And I asked this person like, "How did this land when you shared it this time?" And they said, "It was pretty similar. They thought I was just giving the manager speak. But I think it's going to come around." I'm excited to see this play out.

[0:51:34] JG: That's one of the worst things in the world. When something that seems like managers speak is actually sound and excellent advice. 

[0:51:41] MW: Yeah. That's true. It is a funny situation when that happens.

[0:51:46] JG: well, lovely. That's all the time we have. But, Marcel, this was an absolutely joyous conversation for me. Is there anything else you want to share with the world while we have you? 

[0:51:54] MW: I would just want to make one more plug for Dev Mode. I think a third of our users of Figma are developers. And while we know historically, we've been focused on designers, and that is our core product offering, we continue to do more and more on the adjacencies around that. I think our product managers are going to be excited by what we're delivering upstream of design. And I think developers – I would like them to know that Dev Mode, as we've presented it at Config and then again later this year, is just the first of many steps. We're going to continue on this. And they can expect to see more and more improvements coming through Dev Mode over the coming years. That would be the plug I would make.

[0:52:34] JG: Well, excellent. Well, in that case, shout out Figma, Dev Mode and Code2040. This has been a pleasure. Marcel, thanks for joining Software Engineering Daily.

[0:52:43] MW: Thank you, Josh. I really appreciate it. It's been great chatting with you.

[END]