Navigating Multi-Product Expansion: Leadership & Career Insights from Figma’s CTO, Kris Rasmussen #124

We're doing a special in-episode feature with our friends and sponsor, Unblocked.

A lot of tribal knowledge is actually scattered across all of these systems. And so when you connect through MCP, what you get is access, and which is not the same as context. That's like understood, reconciled, and delivered at the exact right moment.

Stay tuned for later in the episode. Denis Pilarinos, founder and CEO at Unblocked, explains why MCP's rules and skills give access to information, but not understanding, and how a context engine pre-computes what agents need to get their jobs done more efficiently.

One of the things that's helped me is just really kind of focusing on the outcome that I'm trying to create and trying to think about the most effective way to do that. All of us want to feel respected. We want to feel valued. We want to feel heard. But at the end of the day, we also want to create something that's greater than ourselves. Um, we want to work on something that kind of outlives us. And if you really want to do that, it doesn't really matter whose idea it was or who said what. All that really matters is that you come to the right solution as a group.

Hello and welcome to the Engineering Leadership Podcast, brought to you by ELC, the Engineering Leadership Community. I'm Jerry Li, founder of ELC. And I'm Patrick Gallagher, and we're your hosts. Our show shares the most critical perspectives, habits, and examples of great software engineering leaders to help evolve leadership in the tech industry. Kris, just want to say welcome to the show. Thanks so much for joining us. How are you doing? How are things? What's going on in your world?

Yeah, I'm doing great. Things are good. It's been a lot of fun at Figma the last couple months and excited to, uh, be getting some snow up here where I am right now. So all around good.

All around good. Gotta love the snow. Well, you know, speaking of things have been going well at, at Figma, I think the last time we had caught up would've been somewhere around like middle of 2021. And I know that so much has happened at Figma. So much has happened in your life. To begin our conversation, just wanted to catch up a little bit and learn more about you and your role. How have things evolved? What's been going on at Figma? Talk to us a little bit more about, you know, what been going on behind the scenes for you in your world at Figma?

Yeah, um, I guess for me personally, I guess just to kind of give you some background on how I came to Figma. So I started off as a contractor while I was taking a bit of a sabbatical. I was doing some technical advising and consulting with a variety of companies. And, uh, when I first joined Figma, I actually just came in to help them solve some engineering challenges prior to their public launch back in 2016. And I had such a good time doing it that I started to kind of reevaluate what I was looking for in my next role and ultimately concluded that joining a company like Figma, even though it was pre-revenue and, you know, wasn't at the stage that I thought I was looking for, was was really just kind of in the sweet spot of my own personal passions and interests and really just got me to realize that what I care most about at this stage of my career is joining something I really believe in, joining a team that I really want to help make successful, and being able to stick with something long term. And so I'm really happy to say that it worked out and continues to work out. I joined officially in 2017 as the Vice President of Engineering, and eventually my title switched over to CTO, um, about a little over a year ago. And so my role has actually largely been the same in terms of title. I don't, I don't think the title changed all that much. I think what changed is the growth of the company, the growth of the product, and the growth of the team. I'd say all the inflection points in my tenure have to do with having solved interesting challenges along the way or having brought in really incredible people who can do what I— some of the things I was doing better than I could and needing to kind of look for other ways to leverage my time.

There's a couple things I wanted to dive into from, from that story. First off, I didn't know that you started off as a contractor in like the pre-public phase of Figma. Can you talk a little bit more about that moment and You know, what was it like first finding that opportunity and then making that transition to, you know, full-time VP of engineering? Or I guess you were probably full-time before, but like officially the, you know, the full-time W-2 certified employee.

Yeah, so I mean, at the time I was taking a sabbatical just to go make some things and pursue some passion projects and ultimately just to take a little more time to figure out exactly what I wanted to do next and be very intentional about it. I got to work with Figma just because of a former colleague was helping them find engineers and they needed somebody who had some expertise with C++ and graphics engineering to help get the product ready for launch. And so for me, it was just like a really interesting opportunity to do something that I was already geeking out over in my free time. And I just thought it'd be a lot of fun to see how this company had actually succeeded in bringing this professional-grade design tool to the web. I'll admit I was a little skeptical at the time. I think there was just a long history at the time of web-based kind of applications not necessarily competing on the same level as their native counterparts. But after working with the company for just like a week, I was immediately blown away by what they had done. And I realized there was something really special about the team there. And so I spent the next 8 months working on various projects, some things like our original version of design systems and some performance improvements and rendering improvements. And throughout that time, I just continually was impressed by not just the aptitude of the team, but also just how intentional the team was about building a culture they were actually proud of. And for me, I think, you know, I've gone through enough different stages of companies over my career where I really just wanted to find something that I was personally excited about, that I felt like other people would be excited about, and that I felt like I could really commit myself to regardless of of the challenges we faced. And after working with the company for 8 months, I, I just kind of reset everything that I thought I was looking for and really realized that I, I just need to be a part of a team that I believe in and, and that I want to help succeed. And so I joined expecting it to do great things. Um, it's done even better than I think I could have imagined. Um, and you know, I'm very grateful to, to the team and, and everyone for that. And I feel very fortunate to still be here today.

Absolutely. A couple of the topics we wanted to talk a little bit about were just some of the career decisions and ways that you've sort of oriented taking on different responsibilities. I had one more question about this early phase. Is because I thought, I just think that transition is so interesting. What were some of the signals that validated that this could be possible? Because you'd mentioned, you know, web-based applications at the time kind of had a reputation of being really hard to execute on. Like, what were some of those signals that validated this was an opportunity that become really real and successful and a meaningful and aligned use of your time and mission and values?

Yeah, so I think, I think there are a lot of different signals that started to come together over that kind of 8-month contracting period. I've already talked about one, which is just like, I really believed in the team. I think that's so important. When you're joining an early stage company, you're really betting on the people. I know that's kind of cliché to say, but it's very true. I mean, ultimately you have to look at the people around you, look at your own skills and believe that you can be the best at something. And I could look around me and, you know, I actually had an opportunity to consult with about a dozen different companies during my sabbatical. And Figma just really stood out as a very special team that had the ability not just to do great engineering things, but was also just very intentional and thoughtful about the kind of company they were trying to build and the kind of team they wanted to be known for. And so that was the first thing that really stood out to me. The other thing was the technical challenges. I think as an engineering leader, it makes your job a lot easier if you have a diverse and broad set of technical challenges in one company that actually have some really hard problems. And for me, it felt like Figma was the kind of company that was going to succeed or fail based on the quality of the technology. And I felt like I could tell a really true and convincing story to the people we needed to join us to help us be successful about how they were going to kind of influence the trajectory of what we were going to do and be critical to our success. Um, and then on top of that, I really believed in the value of collaboration. I had come from Asana as an early engineer and one of the early engineering leaders there, and I'd seen the sort of virality and scale that comes with collaboration. But I also was aware of some of the challenges that come with just trying to sell collaboration and, and not necessarily having a great single player experience as well. And so one of the things I realized with Figma is that we weren't just trying to prove that there was this value in collaboration in this new space, but we were also trying to figure out how to build an existing professional tool in a better way and change the way people work around that tool in the process. And so it felt like it had this really interesting product-led growth opportunity, which is something that I always aspire to be a part of. I really love working for product-led growth companies, and it felt like Figma was in a really unique place to both capture that kind of single-player magic moment experience and then expand through this differentiator around the sort of workflows that a web-based product enabled and the collaboration that we could provide.

One thing stood out to me in this experience is that you get involved really early on, and I mean, the stability of the engineering executive team is— that's important to the company. So I know there are a lot of startups when they are at a certain size, they hire VPs engineering from outside, what are some of the levers you have by getting involved really early on?

One of the levers is you get to start off by building the respect of the team by doing things rather than coming in and sort of trying to figure out how to get that respect as you're already starting to direct things. And so for me, it was really beneficial to be able to come in as a contractor, to be able to work alongside the engineering team and just help to solve the most important problems. Personally, I never really worry too much about what my title is or, you know, exactly what I'm supposed to be doing. I always try to position myself in place where I feel like I can have the biggest impact given the stage of the company. So I've been very comfortable going— I should say I'm now very comfortable. I wasn't always so comfortable, even though I did it, going back and forth between these sort of management leadership positions and these IC engineering positions. I think if you think about it, right, in an early stage company, what does it even really mean to be like a VP of engineering or a CTO, right? It's just a team of maybe 10 people or something like that. You know, at best you're maybe a manager. So for me, the title wasn't ever that important. And I learned a lot by doing consulting around figuring out how to actually have leverage and have impact, even though I didn't have like designated authority to tell people what to do. I just had to figure out, you know, what is important and convince other people of that. And so that was a really valuable experience for me. I think it was a great growth opportunity for me as a leader, actually. I think a lot of us take it for granted when we become leaders because we've built up respect that we can just be a leader at another company again. And so for me, it was really nice that I got to come into Figma as an engineer first and work alongside the team.

You'd mentioned early on, Kris, and I think this is a really interesting concept that probably people need to talk about more of, is the idea that like, you know, your title doesn't change, but responsibilities shift. And I think one of the things that you've shared about Figma that stood out as well was this really conscious effort around intentionality across all aspects of the organization. And so I know that in the last year and a half or so, there's been some really intentional shifts in terms of where you focus your time and your areas of responsibilities. And how that intentionally aligns with the important areas for where the company is at. And so I was wondering if you could talk to us a little bit about, you know, what have been some of those big milestone shifts in the company over the last year or so and how has your responsibility shifted? You know, how and why did those transitions in areas of focus shift?

Yeah, that's a, that's a great question. Like I said, I think a lot of it aligns with sort of the stage of the company, the stage of growth, the stage of the team, more so than like whatever title you're given, right? I think that the best way to kind of navigate your career is always try to think about like what What is the unique value you can bring and what are the most important problems to solve? And if you don't have agreement with people about what the most important problems are to solve, share your thoughts and, you know, try to build a shared headspace with them. Um, so in the case of Figma, I think in the early days, uh, we were trying to figure out some level of product market fit. I think in some sense we were kind of right place, right time. We're at this really interesting moment when the web started to adopt these lower level APIs and interfaces that enabled us to kind of work around some of the traditional constraints of browser technologies. Um, so that certainly helped us find a great opportunity and get product market fit. But ultimately, like, building a professional-grade design tool, product design tool in the browser, is a really hard thing to do. And most of the hard work is just executing and implementation. And fortunately for me, a lot of that stuff had actually been done even before I joined, well before I joined, um, by a lot of other great people. And so at the stage I joined, we were trying to evaluate what level of product market fit we actually had. We're trying to figure out how to turn this, like, initial launch into a real business. And so in the early days, a lot of our time was just continuing to kind of play catch-up with with other product design tools at the time, like Sketch, and, you know, just trying to kind of pay off the backlog of the long tail of features that we didn't have at launch that were important to get entire teams to switch over. And so I focused a lot of my time on just making sure that we had a shared sense of the priority of those things and making sure that we were unblocking the team and executing as quickly as possible. So a lot of my focus was on execution. Once we started to monetize the product and we had revenue, then it was becoming a real business. We had real customers. We really needed to make sure that we were keeping up with their growth. And so we refocused a bit of our time on really understanding the needs of the people who are scaling most quickly with our product. So I did a lot more, you know, customer conversations. Our engineering team would meet with customers to understand like unique challenges of big customers like Microsoft. But I also started to shift a lot of my focus over to recruiting. And I think, you know, everyone who's been an engineering manager eventually realizes a big portion of your job is recruiting. Um, as like the, the person who's responsible for all of engineering, it's like most of your job for most of your time at a company. And so I'd say for many years, my focus was just on making sure that we were bringing in the right people. We were scaling teams quickly enough so that people weren't burning out and making sure that I was empowering people to do the things that I otherwise would have been doing in the past so I could go focus on other things in the future. And so I think like one thing that was really helpful for me is given that this is maybe my third-ish, third or fourth time kind of doing this sort of thing, I've learned to just kind of give up any sense of ego around like I have to be the one rolling out these processes or I have to show that I know how to do these things. And I was much more willing this time to just actually identify people who could do it as well or better than me and enabling them to do that. And I think that's a really key thing that you have to be willing to let go of as a leader. You have to worry less about what people think you should be doing and more about what needs to be getting done and the best way to do that. Later on, there was another transition around finally having this like really great, amazing product design tool that I think really does have incredible product market fit and incredible growth and feeling like that we'd built up the capabilities of the company and the team sufficiently that we could now start to divert some of our attention towards newer audiences in the same kind of product development lifecycle. And so a big shift for me and I think for the entire company was figuring out how to go from a one-product company to a two-product company and starting to learn about all the challenges that that entails. I think the first transition is always really difficult because your organization is not structured in such a way that you can kind of just spin up this new initiative and not disrupt any other initiative. You really have to kind of adjust everyone's roadmap and get everyone to kind of change their priorities for a while to bootstrap the new initiative and get those get this new product off the ground and then eventually carve out dedicated teams to support them and, and that sort of thing. Um, that was another kind of big learning opportunity and shift in my focus is just figuring out how to help make all of that happen and how to reorganize the teams, um, in order to deliver on this new product and make sure it was also successful. And I'd say where we're at now is we now have two products and we want to continue to expand our capabilities as a company. We don't want to have to thrash everyone in the process every time we do this. And so I'm spending a lot more of my time now on thinking about these sort of adjacent audiences that we can deliver more value to and thinking about how to structure the teams and the technology to make it more seamless and easier to do that on a go-forward basis without thrashing people and introducing a lot of complexity or new bugs and things.

Tell us about the process to identify those most important problems. As you were talking about all of those different shifts, like, was it a, a conscious moment where you and the executive team would come together and be like, okay, here are our most important problems we need to solve? Was it you and the engineering organization identifying those? Like, what did that look like and how could somebody maybe introduce that into their role?

Yeah, that's a, that's a great question. I don't know that I have like a silver bullet for that, but I can tell you some of the things that I look at and pay attention to and the people I work with to figure out that answer. The first thing is like, I'm a very detail-oriented person. This is actually something I really respect about Dylan too. It's something that drew me to Figma. I think Dylan is, is a great strategic thinker and he's great at prioritizing and figuring out what are the important problems. But he also takes the time to go read customer feedback, to pay attention to what users are saying and to read like every bit of feedback that the team provides upwards to the company. And so I try to sort of mimic that same thing. I think naturally I'm a very like obsessive type of personality. And so it's very easy for me to kind of unwind by trying to catch up on every Slack channel that I think contains relevant information, by reading engagement surveys, by reading support forums, by checking Twitter occasionally, things like that. So I just try to like digest as much information as I can. And I don't worry too much about getting into the weeds sometimes because I think it really helps me develop a stronger intuition for what's really going on, be it in the culture of the company or in the experience of our users. And so that, that helps me feel more confident when I do start to develop a perspective. It also gives me some evidence and insights to draw on if I need to kind of run that perspective by other people to build consensus that it's actually the right thing to focus on. So I'd say like my advice to anyone is like, don't be afraid to look at the details. I know it's like tempting to always try to abstract yourself away, and I think it is important to figure out how to do that. But you also need to kind of dive deep sometimes just to stay grounded and be real. And then from there, you know, I think that you have to kind of weigh everything, right? There's all these different priorities that you have when you're building a company. You want to be proud of the culture you're building. You want to be proud of the quality of the product you're building, and you want to make sure that you're hitting the business metrics that are important to keep up the momentum and the growth and deliver on the promise that you made to every employee who joined you. So you have to really take like a very broad perspective, I think, as a leader, regardless of what your title is, and try to like understand not just what your priority should be, but what the company's priority should be. And then from there, I think there's a question of what do you have the unique ability to change? Are there other people who can solve these other problems? Maybe you don't actually need to solve them yourself. Maybe you just need to convince someone that they are a problem or have them convince you that they're not a problem. So I tend to try to focus my time on the things that I think I'm best suited for. And in many cases, I also then focus my team's time on the thing that they're best suited for. But I'm also looking for things that maybe, you know, sometimes like the biggest problems bubble up outside of your function. It could be like a product strategy problem or a support problem or something like that. And I think it's important to recognize that even though we all sort of identify with a particular function, we're still trying to build a company. Like we're trying to create this outcome together and we have to be willing to kind of cross-role boundaries from time to time. And so I I try to be very willing to do that and I like kind of lose my ego when I'm doing things that don't feel like they're necessarily like consistent with my title or my role or whatever else. Because at the end of the day, like when you're trying to build something, the end goal is to make that thing exist, not to like validate your own insecurities or something like that.

I love the give up your ego. Okay, so the last question related to this problem solving one. Currently right now, when like identifying the highest leverage points right now in your role, what did that look like and how did you come to the determination of like here are kind of your core areas of focus? Process right now? What did that look like?

There's definitely a very collaborative process around company planning. So I'd say like, first off, we do like this sort of biannual big kind of company planning process. And the way we kind of think about planning is that it's sort of this nice delicate art and balance between top-down alignment and bottom-up strategy. So we know that as leaders, like, we have to make sure that, you know, the team is marching in a shared direction. But at the same time, we recognize that we don't understand all the details. And oftentimes we're not the ones best suited to solve the problem because we're lacking a lot of context. And so Every kind of year, twice a year, we do sort of a more kind of rigorous top-down alignment exercise where we work with our leaders and the wider executive team to realign on the kind of top outcomes that we're driving towards as a company. And that creates a sort of shared mental model for what success looks like and helps to inform the teams around, in addition to all the basic kind of keeping the lights on, scaling sort of things, what are the additional strategic levers that they should be trying to push that help us all move in a single direction as a company. And so I'll look at those outcomes and I'll figure out like, which ones is engineering really going to be driving, which ones are other functions probably better suited to drive or able to drive right now? And then I'll figure out which ones do I need to pay the most attention to in order to ensure that they're successful or in order to kind of ensure that the team's converging on a single solution versus diverging in different directions. Oftentimes those relate to engineering-specific things like they could be issues around reliability or scale. So by default, I'll just assume that those are the ones I need to be on top of. But sometimes there's new product initiatives there's like a lot of different product initiatives and we might not be at a stage as a company yet where we have all the right people in place to kind of shepherd those. And so I'll look for opportunities to kind of get involved in those areas as well and help shape the strategy and build alignment there too.

Fantastic. And I think it's a great transition to the product conversation. Jerry, I know you've been dying to ask this question, so jump on in. What are the early kind of aha moments when you start building the second product and what that informs the org structure and processes later on after you get that experience and can optimize for a lot of things?

Yeah, so I mean, just to kind of start with some history. So generally my philosophy on org structures is when you're really small, you don't have enough people to do everything you want. And while it is tempting to give everyone these like really kind of clear swim lanes and well-defined ownership areas, you want to be careful not to make those too permanent because you need to be shifting your priorities across these different things constantly. You don't have like enough people to just dedicate people into these specific areas. And then I think as a company matures and you start to figure out what's most important and have more people to enable them to focus for longer periods of time in specific areas. I tend to structure teams in a more vertical way, so I don't think you necessarily want to immediately split into platform and product teams and all this sort of stuff. I think you want to try to minimize communication barriers and really empower people to work up and down stacks so that they can solve the problem as is best for the user without worrying too much about team boundaries. That's largely the mode we were in up until our second product. I mean, we'd evolved a little bit beyond that, but conceptually that's where we are at. The reason we decided to build a second product was twofold. One was, I mean, we'd always sort of envisioned imagined that one of our strengths as a company from a technology perspective is building this kind of real-time, modern visual collaboration infrastructure. And we thought of product design as sort of a beachhead into the, the wider space of collaboration for companies. And we always imagined building some sort of like really awesome collaborative diagramming tool or whiteboarding tool from the early days of Figma. We just didn't feel like it was the right time. We didn't have enough people to divert our focus yet. The team got larger, the core design product got more mature, still, still growing very quickly even today. But what we realized that like we were in a better position, we felt like we could kind of take of the core needs there and continue to innovate while diverting some focus to a new effort. And then ultimately the pandemic happened and remote work became like this real thing rather than a speculative thing. And everyone was looking for better ways to collaborate and align. And so we just felt like it was the right place and the right time to now go and try to start our second product. And so that's ultimately what happened. And then what we learned was that it did create a lot of disruption and a lot of thrash. You know, every company has this ideal planning process. For us, it's like biannual top-down alignment and then quarterly adjustments and bottom-up alignment. and so, uh, we sort of had to throw a lot of those plans out the window. And I don't think we even realized it at first, but we, we sort of set this date, like we need to get this product out by our next user conference at Config. And as soon as you set a hard date like that, if you don't have the thing sufficiently staffed or sufficiently figured out, it's always going to trump other priorities. So that's, that's a key lesson I think I've learned time and time again at Figma is that when there's date-driven things and non-date-driven things, date-driven things always win. And so, uh, it did thrash a lot of teams. I think we're all really excited and happy we did it. It's worked out really well and it's an awesome product. Um, but we learned a lot in the And so some of the changes we've made since then is we've really kind of reevaluated our organization structure and we've started to think about it less just as these kind of vertical pillars and more as this kind of sandwich construction where you have these two vertical product pillars, um, Figma Design and, uh, FigJam. And then you have this sort of like shared horizontal product platform layer. And then you have the lower level, you know, systems and infrastructure layer. That's something that we were starting to do before the second product, but we certainly hadn't done fully yet. So we had to kind of patch over a lot of those rough edges. And now that we do have two products. and we're looking to just be able to spin up new investments faster in the future. We're really leaning into that. And I think one of the benefits of eventually evolving into that type of org structure is you start to create space for these longer running platform initiatives that don't necessarily need to or should be quite as date-driven, right? Because it's kind of a never-ending project such that your date-driven initiatives or your marketing-driven initiatives don't always subsume other roadmaps. And so this has enabled us to make more progress than we historically had been able to on some of the core technology problems that were not just important for our own productivity, but also important for our end users' productivity. So things like really, you know, diving a lot deeper into some of the performance challenges that we'd been trying to solve over the years but hadn't quite finished. And also thinking about the architecture of our system as a whole and how to make it possible to build new product experiences with less risk to existing product experiences and existing infrastructure.

Can you provide more details about the how? You mentioned the semi-arch structure. What are the layers today and what are some of the vertical product-related arch structures as as well.

I won't bore you with like all of the pillars because there's, there's a lot more now, but I'll just give you a couple examples to make that a little easier to understand. So I already mentioned that there's sort of these vertical product pillars like FigJam and Figma Design. There's also this sort of horizontal layer on teamwork and collaboration and communication and all that sort of stuff. Um, so there's a pillar for that as well. And then on the lower, like lower end of that sandwich construction, you have these like systems kind of infrastructure focused teams. And so for us, examples of this would be like a more, um, traditional infrastructure org that focuses on core storage systems, developer velocity, those sorts of things. And then what's unique about us is we use C++ and WebGL and, and all these sort of like native concepts in the browser. So we also have sort of like a game engine pillar, if you will, um, which we call Creation Engine. So it's kind of like the equivalent of a traditional web infrastructure, um, group, but it's focused more on the, the rich client abstractions and the things that make Figma unique.

Our team actually have been using Figma since 4 or 5 years ago, and we pivoted from Mira to FigJam after finding out that's available and it's very easy to collaborate with the team because we're already on, on Figma. So I think as any user, we're really happy about having the, the second product available.

That's awesome. That's great to hear. I'm glad you like it.

We are taking a quick break for a special feature, breaking down the role of context in the shift toward AI-driven development with our friends and sponsor Unbloq. Dennis Pilarinos, founder and CEO at Unblocked, explains why MCPs, rules, and skills give access to information but not understanding, and how precomputing context helps agents get their jobs done more efficiently.

When an agent queries an MCP server, it can actually get 3 results. It stops at the first plausible answer. It doesn't know which source is necessarily authoritative or what might contradict each other. What it'll end up doing is something called satisfaction of search. I get a part of the answer or something that looks like it's the answer, and I go away taking that snippet or that fragment and try to come up with a solution, but it isn't the actual end-to-end solution. And so that is one of the biggest things that we see is that a lot of tribal knowledge is actually scattered across all of these systems. And so when you connect through MCP, what you get is access, and which is not the same as context that's like understood, reconciled, and delivered at the exact right moment. And so as you add more and more connectors, you're actually contributing to that problem. It will basically find something that looks like the right answer and be like, okay, let's go explore that path. Doesn't come to the right conclusion, goes all the way back up, tries the next one. There's no reconciliation or conflict resolution. Skills and rules file have that same kind of ceiling, right? They encode what you already know. They can't capture, you know, a PR change that changed the convention or, um, decisions that weren't documented or the constraint that exists like in a thread that's like 6 months Unblocked isn't another source to query. It basically pre-computes all the context that you might actually need. It's able to look end-to-end across all these different data sources such that you get the right answer that has been deconflicted and that the agent can move on with its next step without having to like go down these rabbit holes. You know, as a developer, what you get is the benefit of not having to spoon-feed these agents all this information. It is able to pull together information from Slack and Confluence and Jira and Datadog and Sentry in an efficient way so that the agent doesn't spend time burning a bunch of tokens, burning a bunch of wall clock time in order to get to the solution faster. We run this experiment. We see our customers do this all the time. They ask the agent to do it using unblocked and they ask the agent to do it without using unblocked. Almost every single time, depending on the complexity of the task, the unblocked result is far more efficient in terms of literally wall clock time.

Give your coding agents the context your best engineers have. Your agents can read code, but they don't know how your team works. Rules and MCPs give access to information, but not understanding. That's why you still have to tell them where to look and what to look for. Unblocked gives your agents the history, conventions, and decisions behind your code so they can generate mergeable output without the back and forth. It automatically surfaces the right context for every task, so agents stay on track without the setup tax or the correction loop. Ship faster with AI outputs that actually reflect how your system works. To get started, go to getunblocked.com/elc. That's getunblocked.com/elc. I wanted to follow up about the kind of the multi-product moment. The thing that I am always really impressed by with Figma is like the mission and like sort of central to what you all are after is essentially making creativity concrete and to like make these other abstract concepts like collaboration seamless. That just is like an incredibly difficult thing to do when you think about what all goes into a creative process or what all goes into the invisible work that goes into a collaboration process. I was wondering if you could talk about some of the, the challenges maybe that you encountered when getting to this multi-product moment and how you address some of those challenges and how you made decisions over which, you know, feature will help enable creativity or collaboration better. Like, how do you think about those things and what are some of the challenges that you found?

Yeah, I'd first like to admit that we're very fortunate in that we're solving our own problems, right? So we're definitely users of our own software. And a lot of our roadmap is sort of a combination of listening to customers and really trying to understand what are they experiencing, what are they doing with our tools, what are the core problems that we need to keep solving in order to show them that we understand their needs, but also trying to imagine where is this all going? What do we ourselves need? What's the longer-term vision we're driving towards and where do we think everything's going to go? So we're always trying to kind of balance that future vision and innovation with meeting people where they are right And I think this is really important and it's like a key ingredient to our success. So just to kind of give you an example, I think in the, in the early days of Figma, there was a lot of speculation around whether or not design tools, product design tools in particular, were eventually going to be displaced by these new, like, kind of hybrid design engineering tools, right? Was there going to be this convergence of how designers and engineers work? We were also wondering the same thing, right? We were trying to figure this stuff out in the early days too. And we eventually came to this realization that there is a reason for these two processes to be separate, right? There's like something different about the design phase of a project and the productionization phase of a project. So in the design phase, you're very much focused on how do I explore a solution space in the most efficient way possible to bring a lot of other stakeholders along and build consensus around where in that space I want to be. And so in order to do that efficiently, you don't really want to have to go through all these layers of abstraction and reason about all these edge cases and all these details that you can kind of assume that other people already understand. So to put this more concretely, like when you're designing, even though tools like Figma allow you to position things, you know, using auto layout and constraints and all this sort of stuff, you're not always going to do that at first, right? Um, for a lot of people, that's sort of a level of indirection that slows down the pace of thought and expression. And so oftentimes you just want to figure out how to make a tool such that it can be directly manipulated to keep up with your thought. And you're expressing something just enough to make sure that other people get what you're trying to show and feel the same conviction you do that you've explored that solution space. On the other side, when you go to production, now Now you have to reason about how to make this thing reusable, how to make this thing maintainable, how to make it composable. All these, these concepts become even more important as you go to production. And so trying to kind of do all of this stuff in one process really slows down the design process and potentially introduces risks into the productionization process. And so for us at Figma, we, we had these debates internally. We were trying to figure this stuff out for ourselves and we came to this conclusion and, and we continued to kind of lean into the strategy and the product experience we had already built as a result, but we also We also recognize that there are opportunities to kind of streamline the transition from design to production. And so we're thinking about that too and thinking about how to build better experiences for developers as well. When we think about all this, like what's implicit in this is that we're not, we're trying to not just design for product designers, we're trying to design for entire product teams, right? We really want to improve the entire product development process. And so that's where all the collaboration comes in and we have our own grievances and issues for a long time. Like we weren't happy with our own comments implementation and finally got that into a better state. But that's also kind of helping to inform the strategy. And the roadmap. And then we're also, like I said, listening to customers, understanding like, what do they need right now? Like, you know, it's, it's possible that this future that we're envisioning is not ready, or like the world's not ready for it yet. How do we make sure that everything we're doing right now is benefiting people too? It's always just trying to kind of evaluate whether or not we're striking the right balance between innovation and, and also just listening to customers and making sure that we meet, meet everyone where they're at.

I think it's incredible that you can make explicit the sort of implicit or subconscious decisions that somebody makes in the design process as like what you're looking at to remove the friction of that experience. I think just As you were, you're walking through that whole process, like, to be able to make those ideas explicit, I think, is incredible. Also, I think it's really interesting that you deprioritized a feature that really was annoying to your team in the, you know, while you're working on other stuff that maybe were higher priority for other folks. Um, so I imagine that must have been like annoying for a long time until you finally were able to resolve that. Says a lot to be able to deprioritize something that really pisses you off.

So yeah, sometimes you do have to do that, and it's sad, but yeah, we all wish we could do everything at once, but we do have to prioritize. I think another lesson and just for what it's worth, is like, I really believe in more wood behind fewer arrows. I think there's this temptation, especially when you're in an early-stage startup and you don't have enough people, to try to just have every person work on their own project and do as many things as you possibly can at once. But that rarely actually optimizes for overall throughput, and it also hurts your culture, hurts collaboration, hurts information sharing and documentation. So we've been very intentional about trying to make sure that we are actually, actually prioritizing.

I'd love to get more of a sense of your thoughts on exploring solutions, R&D and prototyping, and determining investment. How do you determine when an idea is validated enough to justify staffing something up? So like you're in an experimental area, you're trying to determine what's the right solution. Share a little bit about your thought process there and what that's looked like at Figma.

I think one of the things we've learned over the years is that oftentimes the projects that have been kind of the most challenging or potentially like sometimes the most demoralizing are projects that we staffed a little prematurely because we didn't really recognize that there was a sort of exploration phase that needed to happen before an execution phase. And I think this actually happens with engineering architecture and tech debt as well. When you're trying to kind of do a lot with a small team, you have to be very thoughtful about whether or not something's actually ready to put everyone on it, or if you're still figuring things out and maybe it won't be ready for some time. And so one of the things we do is we try to be very intentional now on a go-forward basis around identifying first and foremost, you got to line on the problem. So we land on the problem. But once you have the problem, there's a question of like, do we actually know the solution yet? And sometimes we don't. Like sometimes you think you do. It like sounds good in theory, but you haven't really adequately vetted the idea. You haven't mocked it up. You haven't built prototypes to see how real it feels, see if there's anything that you didn't anticipate feeling funky. And so we're trying to be much more intentional around like delineating between exploration phase projects and execution phase projects. And this is not to say that we want to be like Waterfall. It's quite the opposite. I think in the exploration phase you can still work in a very cross-functional, iterative manner, but you might just want one engineer rather than 10 engineers staffed on it, right? Because it can be really demoralizing with 10 different people trying to contribute to a project if the project's hung up on some fundamental design decision, right? That's not fun. Not everyone can contribute to that at all times. One of the things we've learned is just to be a lot more intentional around staffing exploration phase projects with smaller teams and really setting the context that this thing may or may not actually get to the execution phase depending upon how much conviction you help us feel in the solutions that we're exploring.

Is there an example maybe, or a story from Figma where you were encountering like a particularly challenging R&D R&D project. And can you share maybe what it was like navigating, identifying the right solution for that, and then determining that conviction moment in the staff investment?

Yeah, so we've had, we've had a number of these for what it's worth. One little anecdote I'll share is that I've definitely always been very curious, or I guess like I care a lot about the perception of the team around how we deal with tech debt. I take great pride in like the quality of our engineering and our code. I know nothing can ever be perfect, but I always want to make sure we're striking the right balance and making sure that we're proud of what we're doing. And there was a time when, when the team was telling me that like they were worried that we weren't staffing enough people on these hard tech debt problems. But from my perspective, we were. They just weren't successful. And I think the reason they weren't successful is we were trying to do too many things at once, right? We weren't putting more wood behind fewer arrows. We were just kind of letting people pick off whatever problems they thought were most important at the time and oftentimes not getting enough people to help them. And in some cases, we were picking off problems before we actually knew the solution or before we really realized how hard it was to deliver the full solution. Solution. And so we got better over the years. I think we're still learning like everyone, but an example of a project that I think worked out really well was this project that we called FullView internally. Basically, just some, some background context is that we have historically had two separate implementations of our kind of core rendering technology and scene graph technology for the Figma file format. One that was optimized for mobile and one that was optimized for desktop computers because when Figma got started, a lot of these newer lower-level browser APIs weren't readily available or adequately supported on mobile devices. And so we had to sort of take different technology path and use more traditional JavaScript versus like WebAssembly and ASM.js and stuff like that. And so this meant that we had to maintain these two different codebases for many years. It meant that every time we tried to bring richer application prototyping experiences to mobile phones, there was always this like challenge around like, well, we can't actually compute this thing on the phone because the phone can't do the things that the desktop can do. And so we always knew that we needed to reconcile these things. And we saw that mobile devices are getting more powerful, that the APIs and browser standards are getting better there. What we did to ensure this worked out well was we first made sure that we took on smaller projects to de-risk the technical limitations. An engineer on the team, Susan, took the initiative on her own to basically take a simplified file viewer, which doesn't support interaction and stuff like that, it's just like view a Figma file, and try to see if she could like re-implement that using the shared WASM C++ codebase. And she rolled it out and she ran into some potential bottlenecks, but she kept working through those, right? And we kind of made sure that she was able to work through those and got her some support from other people on the team to de-risk the bigger bigger project first. And at a certain point, we got to the point where we really understood what the gaps were to kind of make this an acceptable experience and make it a great experience. And in parallel, we started to staff another project to go evaluate what is it going to take to actually eliminate the code duplication here, and what level of elimination can we kind of scope this down to ensure, to ensure that we can make forward progress and celebrate a milestone. And so we were sort of de-risking the last part of this in parallel with trying to better scope out like what the actual cost of the migration was going to be. And once we had enough conviction on both sides, like we could kind of understand and convince ourselves that we saw a solution that would work, then we brought in more people and we made sure that the team had sufficient kind of horsepower to get through the messy refactors and the long tail of random bugs that you didn't anticipate up front to guarantee that the project was successful. And so I was super, super excited to see that the team broke it down into milestones and actually delivered it ahead of schedule. This is like, I think one one of the first big success stories in terms of delivering such a complex project on time at Figma. Um, and so we're trying to kind of repeat that process when we go tackle other hard challenges in the future.

I really appreciate laying out the process. I was noting sort of the high-level areas around like small projects to de-risk the tech challenge, understand the gaps, and then the staffing in parallel element to ensure that you'll be able to like make forward progress on some of those challenges so that they're appropriately scoped and not overwhelming. I think that's great. You know, at this point in time, we've talked a little bit about shifting responsibilities and a lot of like the scaling lessons from building different products, I know that you've spent a lot of time considering and thinking about the release and how that impacts the type of stakeholders that you'll work with at Figma, where there's tons of collaborators and different people with different functional expertise. And so there's this sort of like complex stakeholder relationship. And so I was wondering if you could talk to us a little bit about some of the lessons you've learned around releasing products or around this type where it's, it's heavy collaboration, heavy creativity, and some of the lessons you've learned from working with those types of challenges?

I don't want to overly generalize here, but I think like to your point, there is something unique about building professional tools, especially tools that your core users are actually writing to 8 hours a day, you know, 5 to 7 days a week. When you introduce new features, they oftentimes come with new data types, right? And so A/B testing or doing multivariate testing on these, these new types of features is a little more tricky because you can't just like roll it back if it doesn't work out because that can create the perception of data loss or just really break the flow that someone has developed with that new feature over time. And so at Figma, for that reason, and also because we value helping to tell a story about why we're doing anything and helping to bring the community along with how we're thinking about the problem, we don't always do incremental rollouts. Um, we actually do value wholesale feature rollouts and releases. We want everyone to be able to use a feature at the same time. We don't want to take it away after it's been released, and we want people to get excited about it and talk about it all together. Um, so that does introduce some constraints around kind of reliability and developer velocity and all these sorts of things. Um, with that said, we also recognize there's a lot a lot of things we can experiment with, right? If it's just a visual treatment thing, if we're thoughtful, we're not thrashing people, we can actually experiment with some of those things in a more traditional manner and roll them out incrementally. We have to kind of figure out how to, how to ship rapidly, um, but also continue to ship carefully and be really intentional about not breaking things in the process. Breaking something in Figma is really bad, right? You're disrupting someone's professional work. Um, you're preventing them in many cases from doing their job. So we take quality super seriously. And so we have all these sort of compensating measures that we've introduced over the years to try to mitigate the risk of any sort of problem, creating massive disruption to end users. That's not to say we don't have them. We still make mistakes and we try to fix them quickly, but we've gotten better at this. And so some of the examples of stuff we do outside of more traditional kind of incremental rollouts and staged rollouts is we do like a pretty rigorous internal bug bash for each new feature. In addition to, you know, automated testing, interaction tests, unit tests, all these sorts of things, we also just make sure that we ourselves are using the features, really trying to kind of stretch the features to their edge cases, anticipate how they may or may not scale with more data. We also oftentimes work with key customers and partners to do private beta launches. So we give them an opportunity to provide us with feedback, sometimes in like a totally separate environment, but oftentimes alongside their own work. And we just make sure that they're comfortable with the idea that this might change a lot or they might actually not be able to keep their data. So we can get that sort of feedback early, detect more problems that way. And then when we do go to roll things out, we make sure that we've tested them internally with our own team, that we've gone through kind of a traditional dogfooding process, that we've all had a chance to kind of really use it rather than just bug bash it. And then ultimately We roll it out incrementally but quickly, usually in a single day. We'll do sort of a canary deploy to a subcluster of our infrastructure. We'll check that metrics look good, that we aren't, you know, breaking anything that we can't easily fix or that would cause massive disruption. And then we continue to move it forward from there. And so that's kind of like what our release process looks like for these things that we can't just incrementally roll out or A/B test. But there's a lot of things that we can, and so we have a more kind of traditional release process for those sorts of things too.

Awesome. Kris, to sort of synthesize what we've talked about so far, I think what's been interesting is we, we've talked a little bit about career transitions as in like how your responsibilities have shifted in relation to the evolving priorities and the expanding opportunities within Figma. And we've talked a little bit about the different like product strategy and scaling lessons that have come along the way. And one of the things you mentioned at the beginning was like in this space where change is going to happen, things will expand and you'll have to reprioritize a lot to figure out what's most important and high leverage. You mentioned you have to let go of your ego and what's been burning in the back of my my head is if you haven't experienced having to do this before, how would you help encourage somebody to let go of their ego and to be able to give responsibility to other people and, and not have that type of ownership? What's your secret with letting go of the ego?

I mean, I don't know that I have the secret. I think it's a learning process for all of us, and I'm not gonna lie, sometimes my ego gets hurt too. But I think that one of the things that's helped me is just really kind of focusing on the outcome that I'm trying to create and trying to think about the most effective way to do that. All of us want to feel respected, we want to feel valued, we want to feel heard, hard, but at the end of the day, we also want to create something that's greater than ourselves. Um, we want to work on something that kind of outlives us, and if you really want to do that, it doesn't really matter whose idea it was or who said what. All that really matters is that you come to the right solution as a group. And so I think trying to kind of just focus yourself on the, the longer-term outcome rather than the shorter-term insecurities is like a key way to kind of let go of some of those things and, and really do what you think is most important for the group and, and the company as a whole.

Awesome. Kris, I know, um, we're, we're at sort of the end of our time. We've got a couple rapid-fire questions.

All right, let's do it.

Okay. What are you reading or listening to right now?

I am reading on writing well, because I haven't written a paper since high school, so I figured, uh, it's good to refresh my memory, make sure I still know what I'm doing.

I love it. What's a tool or methodology that's had a big impact on you?

Um, I don't know if this exactly fits the mold of the question, but one of the things that I learned while working at Asana is this idea of like not assigning tasks. Um, we're very task-centric at Asana, and I think it's actually really helpful if you create shared task lists for teams rather than assuming that each person has a specific task that they're supposed to do. It just makes it feel like it's a shared project, and it gives people the ability to kind of learn new things and kind of fill in gaps when needed. So that's something that's been really helpful for me.

I love it. What's a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet?

I've just been really fascinated to watch the evolution of client-server architectures for web applications. I think there's a companies for years that have been building these richer, more declarative abstractions to make it easier to build web applications. But it hasn't really caught on in the open source community. And now you're starting to see some of this and it's really exciting to see it outside of these companies. So GraphQL is an example of like a more declarative, composable way of connecting services. But I think there's a lot more to it in terms of building APIs that are automatically batch efficient on your servers, that are real time by default, that support optimistic updates and really bring that kind of native level experience to web applications. Publications.

Last question to close us off. Is there a quote or mantra that you live by or a quote that's been resonating with you right now?

I don't know if this is a quote or just something that I believe in, but I think like one thing that is really important for me to keep in mind is I think if you want someone to listen to you, you have to first make them feel heard.

A powerful way to close us off, Kris, in the spirit of removing your ego and making team members feel valued and heard. Thank you for an incredible conversation and for helping share about your journey and the lessons you've learned along the way. We really appreciate it.

Thanks for having me, Patrick and Jerry.

If you enjoyed the episode, make sure that you click subscribe if you're listening on Apple Podcasts or follow if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community. To stay up to date and learn more about all of our upcoming events, our peer groups, and other programs that are going on, head to sfelc.com. That's sfelc.com. See you next time on the Engineering Leadership Podcast.