Loading summary
Transcript80 lines
- [00:00]
Andy Zhang
At the end of the day, a user thinks about, hey, like, I just want two or three really good features, and I just want everything to work really well? How do you package this such that a user can understand very well, derive a ton of value from it, make it feel very good, and make them want to use it again?
- [00:16]
Rid
There are so many different ways that I can attack a different project or a set of problems. And even figuring out how I want to get momentum on something has become a much more nuanced evaluation process that I appreciate.
- [00:30]
Andy Zhang
Now that we have all these tools to accommodate all those different types of thinking, you no longer have to be like, how do I best fit my thinking for this one medium? But instead, the question is, which tool for thought is my favorite?
- [00:44]
Rid
Welcome to Dive Club.
- [00:46]
Unknown
My name is Rid, and this is.
- [00:48]
Rid
Where designers never stop learning.
- [00:50]
Unknown
This week's episode is with Andy Zhang, who is the design engineering lead at Windsurf. So we're going to shine a light on all of the ways that design engineers can make a big impact on their team.
- [01:01]
Rid
But before we get into all of.
- [01:03]
Unknown
That, I wanted to start at the.
- [01:05]
Rid
Beginning of Andy's journey because he had.
- [01:08]
Unknown
One of the earliest roles at Figma.
- [01:10]
Andy Zhang
The story behind the Figma internship was I was so lucky. I happened to have stumbled upon it. For the longest time, I wanted to do software engineering. I studied software engineering in college at the University of Waterloo. As a part of Waterloo, you get to do six internships. And I remember my first one, I was like, oh, like, software engineering is so much fun. The second one, I was like, oh, this is cool. And by the middle of the second, I was like, okay, you know what? I think I am ready to try something new. And at that point in time, I was thinking about getting closer to the user. I was like, okay, like, design seems very, very close to the user. You know, you're doing all the user research, trying to see, like, how to design an experience that makes users happy. I think it bring them from point A to point B in a product. You know what also would be a natural stepping stone into design? A company that works on design tools. And so as I was talking about this with some friends, I remember I was in the living room with a friend. I was like, yeah, like, I really want to get into design. And my friend asked, have you heard of Figma? And I was like, no. And this is like when it was less than 10 people at the time. It's a good friend, Great friend. We're still in touch. Then I went ahead and applied. And I remember my interviewers, I remember Sho being one of them. And it was right before I won Exchange. I think I did1@5am while I was in China and I was already in Asia at the time. And then after that went through and then I was like, oh, I'm super stoked. We'll see how the startup ride goes. And they also sent me this video of everybody saying like, hey, like, welcome to Figma. Super excited for you to join next summer. Wow.
- [02:34]
Rid
Do you still have stuff?
- [02:36]
Andy Zhang
I do. I'll send you the link.
- [02:37]
Rid
That's so cool, man. That's so cool.
- [02:47]
Andy Zhang
Oh, hi Andy. Hi, Andy. Hi, Andy. Fast forward to now. I'm just like, I already knew Figma was awesome, but now looking back, I'm like even more grateful than I already was. And for so many reasons and even.
- [03:01]
Rid
For context, for people listening, we're filming this the week after the ipo, so it's gotta be kind of crazy to look back at some of those early pictures and see how it all shook out.
- [03:10]
Andy Zhang
Seriously. Yeah. I was looking back on the photos, I'm like, wow. I was definitely very grateful for it back then, but now looking back on it, it was by far my favorite internship. And I think the reason why I look so fondly back on it was that I feel like it was probably my most formative internship, more so in the mindset aspect. And the reason why is because, I mean, first of all, the team is absolutely stellar. You got Dylan, you had like Rasmus there and a whole bunch of other folks who I really looked up to. My mentor at the time, Jessica, she was probably the best mentor I've ever had. And I think that what I really liked about my time with her was that I think as an intern you kind of walk in, you're just like, oh, you know, what am I going to work on today? What are the problems I'm going to solve? The common thinking for intern is that like, oh, you're just given some work and you have to go do it and you just have to get it done, especially at a startup. What was really fascinating about Figma was that I had a choice of pursuing my curiosity. And I think that was something that really stood out to me from Jessica as a mentor. She was basically probing, like, hey, like, what are you interested in? What do you want to work on? And at this point I was like, oh, I want to work on this. I think this is interesting. Yeah, I would love to work, get into design. And she's like, great, Good to know. I'M going to try to figure out work for you that is aligned with all that interest. And so I remember the next day or two, she came back and she's like, here's your next project and it's going to be focusing on these areas. And I'm like, whoa. Not only do I get to work on really cool stuff, but they completely align with my interests. So many of the people there were such good teachers. And what I mean by that is, like, if you are really good at unpacking a really complex concept into something that's like, super simple, then you probably understand it very well. And I think that that was really clear from some of the folks there, such as Rasmus as well as Evan, and probably more conversations that I'm forgetting now. I remember one clear memory was we were at the lunch table. There's a huge, like, bowl of cho Choc. And then we would be eating, and then like, somehow Razbes and I started talking about compilers and he somehow had like, a paper and a pen, as any designer would. I was like, okay, like, like, here we go. And he starts deconstructing how Go compilers worked. And it was like, whoa, aren't you a designer? That was like, such a cool moment, number one, Appreciating the fact that not only is he an outstanding designer, but also an incredibly knowledgeable engineer. Rasmus, what's really outstanding about him is he's able to take these complex concepts and then break it down. He really understood, understood these concepts. It was not just pure regurgitation. And lastly, he was just excited about it. Like, we went like an hour or two beyond lunchtime to talk about this while everyone was working at their desks. I really love this environment, how people are just so open and excited to teach all these cool things. I remember Evan Wallace did the same thing, the CTO at the time, where after our show and tell on a Friday, I remember the other intern, ati and I, we were hanging out with Evan, and he was basically giving us an entire walkthrough of how multiplayer worked and all of the internal dev tooling, how he was thinking about operation transforms versus, like, CRDTs at the time, which is like, I believe the algorithm for how they resolve the multiplayer and how there might be, like, race conditions and how exactly do you resolve all of that? I think it was really cool to just feel no hesitation to walk up to anybody and ask them, like, hey, like, I'd love to learn about this. In fact, people wanted to do that and talk about their work. The last thing that really stood out to me in that FIGMA internship was the amount of detail people poured into the work. And the one story that really, really stuck with me to this day was one of my projects was to solve this problem where if you were trying to delete a file, it basically was completely gone. No way to recover. You'd have to contact figmo team. You get bombarded with these requests and you're just like, oh, no, we have to recover all these files and do all this manual work. And you have to do this for almost every use. So obviously it is a problem in terms of time spent internally and also frust for an end user wanting to recover their work. So the natural idea was like, how do we create this buffer where it's kind of this trash bin? And I remember one of the conversations where we were just trying to figure out the copy of this design, and I was in the room with Rasmus, and we were talking about what was the right copy for this, and we dove down a rabbit hole of like, an hour to 2, just trying to figure out, like, whether it was better to use delete or remove, I think. And it was crazy. Like, he started talking about every, like, physical analogy related to those words. And I think my mind just, like, kind of expanded a little bit after that conversation, probably by a lot, not just by a little bit. It's just, like, so interesting to see how much detail can go into one copy change. And it made me realize that, like, early on in the days of figma, that was probably not an exception. That was probably the norm. The amount of detail that went to every thing, whether it was a pixel or whether it was the name of a button.
- [07:52]
Unknown
Real quick message, and then we can.
- [07:54]
Rid
Jump back into it.
- [07:54]
Unknown
Raycast is my portal to AI. It's a quick keyboard shortcut away, which means it's always at my fingertips. I can add attachments, build presets to streamline certain workflows, and they even support over 30 models from OpenAI to Claude to Perplexity. So your chats aren't bound to a single model. And the best part is you can try their AI and all of their extensions for free. And no subscription, no account needed. Raycast has pretty quickly become the cornerstone of how I use my computer. So if you haven't tried it yet, do yourself a favor and head to Dive Club Raycast to get started. That's R A Y C A S.
- [08:37]
Rid
T. All right, here's the thing.
- [08:39]
Unknown
You don't need another dashboard. What you need to do is to talk to customers. So I want to introduce you to Genway AI. You can think of it kind of like vibe researching to validate your ideas quickly. Just draft your questions, select an icp, and then their AI agent runs interviews on your behalf by pulling from a panel of global participants. I mean, you could literally set it up in the morning and get actionable insights by lunchtime. It's validation at your fingertips and you can try it out free for 14 days. Just head to dive club Genway to get started. That's G E N W A Y.
- [09:19]
Rid
Okay, now on to the episode. And I'm sure so many people are listening, wondering, you know, man, what is it like to get to start off a career working with some of the greats like that? You know, I mean, Erasmus is on my short list of designers I really look up to. And it's incredible that you were able to get that opportunity. And for so many people, internships are, you know, the little line item on a LinkedIn that eventually scrolls below the fold. And yet for you, it sounds like this really did impact significantly the the trajectory.
- [09:47]
Unknown
And even knowing where you ended up in more of a design engineering kind.
- [09:52]
Rid
Of hybrid generalist role, and perhaps some of that even was, you know, attributed back to how that early Figma team worked.
- [10:00]
Andy Zhang
Oh, 100%. Whenever I'm trying to figure out like, oh, like, who do I look up to? Like, what do I want to be? I think like, oh, like I want to be a really good designer. I also want to be a good engineer, like, who comes to my alt Erasmus undeniable, like such a stellar design and engineer and also even better, like human being. Really just look up to him as a person.
- [10:19]
Rid
Well, let's zoom ahead in the story a little bit because eventually you wind up at Windsurf. So put us into that moment in time where how'd you land the role and kind of where was the company at? And then maybe we could kind of drill into what design engineering looks like in practice for you.
- [10:36]
Andy Zhang
Yeah, the way that I ended up in this role was quite random, actually. This is a pivotal time in my career. This is in 2023, where out of school, I have three years of product manager experience at Uber, and then I also was a founding engineer designer at another startup where I was the only engineer and designer. I was like, trying to look at the job market. I was like, huh? Like, what would be a good role for me? And I would open one one opening six years of software engineering experience. It's like, not sure if that's quite me. I open up another posting, it's like, oh, five years of product management experience. Like, not sure if that's me. And so I was like, okay, like, clearly nothing is going to fit this weird hybrid. And so I started applying to different roles. What would be a good fit for me? And so I started applying and I would actually get quite far into the interviews. But I think that because of my unorthodox background, I would do really well in most things. But there are certain spikes that you get from a lot of expertise that I think I lacked. And so it was a little confusing for me at the time. Like, hey, like, how exactly do you navigate this? Because you don't magically get three extra years of software engineering experience, nor do you get three extra years of PM experience out of the blue when you're interview prepping. Like, that happens with work, not by studying. You know, I was kind of lost for a little bit. And design engineering was not that prominent at the time either. So I was still trying to figure out what I want to do. And in this free time, just to burn off some steam, I would play basketball in a rec league. And at some point I was like, hey, like, you might as well just exhaust your network. So I mentioned to my teammates, I'm like, hey, like, by the way, I'm looking for a job, guys. And then one of the teammates is like, oh yeah, like, what kind? I'm like, product design, engineering, all that stuff. And then I can see my friend doing some mental math. He's like, oh yeah, working for exactly that. I'm like, cool, let's chat. You got a job description or anything? He's like, no, but I'll get you one tonight. I was like, great, Love the scrappiness. Like, let's do it. And so that night he sent it to me. This is Kevin Howe, the lead of product engineering at Windsurf. An amazing basketball player for woods, for he's an absolute Hooper. Such a cool Hooper. And so we chatted and then I was about to go to Asia at the time time. Really poor timing given that I was still in the midst of a lot of interviews. I did have some offers at the time, but I was like, hey, like, I want to see this through and see like, what WinSrip was known as Codium at the time was about. And their product was a Context Aware code completion extension. So basically you can install it into your favorite editor and you basically get code autocomplete for free. And it was fast. It was Context Aware. There's also chat with your code, basically solving two use cases, allowing you to write code faster and allowing you to understand your code. Did the entire interview Friday. I did a take home interview the weekend. I was calling the founders for like two to three hours a day. And then the next week before my flight to Asia, I commuted down to Nanofee to meet the team doing on site interviews. And then they were like, yeah, let's make it happen. I'm like, cool, great. Like, I signed and I flew to Asia that same night. And then, and then after that is, I guess the rest is history. Or how many people are at the company? Oh, it was only like 20 people.
- [13:39]
Rid
Can we talk about the role a little bit? Because it sounds like they kind of just created the job for you in some ways. You didn't fit nicely into a box. Fine, we'll make a box for you. It's 20 people. I would imagine, you know, at some point, pretty quickly in this story, you start hitting some very serious scale. So what was that like in the beginning? Like, what were you working on? What was the set of roles and responsibilities that fit into this new job that was given?
- [14:06]
Andy Zhang
Initially the role was called a growth engineer, which is funny because maybe no one really coined it as design engineer at the time, but what was sold to me was, hey, we're expecting you to do some products, maybe some marketing, some engineering, some design. And I was like, great. But when it was actually came to the job, like the main asks, just to kind of get the ball rolling, was more around like front end engineering. As I would tackle tasks, it became more evident that like, there were always other problems inside of the product that people weren't as much thinking about. So at that point I was like, okay, if no one's going to think about them, then I'll start thinking about them. A lot of those problems were design. And so I initially first started thinking more about front end as well as, and then increasingly to design, all the way to engineering. So basically the scope of my role slowly expanded up to a point where I was owning larger parts of the engineering system as well as owning a lot, if not all of the product design. And so the role kind of grew into a design engineer as opposed to start off as a design engineer. In the process of seeing a lot of the problems at the company, I came to the conclusion that a design engineer was what was best for the company. In other words, someone with the skill sets of both engineering and design was what was going to take the startup to the next level and make it successful. And I think that it really took seeing a lot of the day to day problems to really identify that. And I don't think I would have been able to like land on that conclusion if I looked at it from the outside. And I think that that is also that I expect for a lot of companies out there where if you try to examine a lot of your problems, and especially in this day and age with AI, I think that design engineers is increasingly going to be a supercharger for many startups to really elevate their product experience. And I think that we saw that once we launched Windsurf not only was an incredibly built product, but it was fairly well designed too. And many people were raving about the design, saying, that's the reason why I want to use it. And the UI just felt very clean and everything feels so thoughtful. And I would love to take a lot of credit for it, but I think a lot of it was the work of the entire team because I think that we really cared about the overall experience and we knew that it's not just about how it's built, but it's also how it's designed and how exactly it feels. And so I think it was a big team effort because there's no design without engineering. There's no engineering without design.
- [16:22]
Rid
When you got to that point, when you realized that perhaps the most impact that you could make on the product was through the lens of design rather than pure engineering, what were some of those things that you were identifying? Like, is there an example of a needle that you thought you could move with design? Specifically, in the early days, I think.
- [16:40]
Andy Zhang
The two most important things that came to mind were the philosophies as well as the patterns that were established. I think that without those two, then it's very easy for everybody to be building all sorts of things. And ultimately, when you're working at a very high agency startup where everyone is empowered to build all the great features that they have in mind, then there's a good chance that you might end up with 500 different features, none of which are cohesive with each other. And so, so much of it has to do with packaging. Like at the end of the day, a user thinks about, hey, like, I just want two or three really good features and I just want everything to work really well. How do you package this such that a user can understand very well, derive a ton of value from it, make it feel very good and make them want to use it again, because ideally it's delightful and ideally they want to Feel that delight once more. So I think a lot of the philosophies is like, hey, how can you make this as easy to use? And I think that this boils down to like, hey, like, how do you think about the design of like, autocomplete? Like, where should things be positioned when you're trying to show a hint while someone is in the flow of coding, how should it look? Should it be in two spots or should it be in one? When you're trying to audit code because the agent is doing a lot of work for you, how do you first inform the user that the agent has done a bunch of work for you? How do you allow a user to really go through all the changes really quickly? That entire experience is also completely brand new in this day and age of humans closely collaborating with agents. So it's important to establish the philosophy, how do we think about the design of the product? The second thing relating to the pattern is how exactly do you establish a pattern that is easy to extend? And what I mean by that is that it's very hard to establish this initial pattern because you don't necessarily know if it's like the right pattern or not and how well it will scale. You also don't know what other teams might be adding onto it. But if you can have an opinionated pattern that scales fairly well to many other features or many other use cases, then suddenly you have a lot of engineers thinking, like, I don't even have to worry about how it's packaged. The only thing I need to think about is how to build this cool feature or this cool change. And then in terms of delivering this to the user, I don't have to think about like this pattern, but instead it's very easy for me to just extend this pattern. And so a lot of that difficult work is done.
- [18:58]
Rid
I think that's one of my favorite parts of being able to be an early stage designer is you don't have the same level of like product surface area silos where you're touching a little bit of everything. And so even more than designing any individual feature, you're really playing a role in shaping the overarching mental models that a user is forming while using the product. And that is the time to do it. And so it's interesting to hear you talk about first and foremost patterns rather than features.
- [19:28]
Andy Zhang
Even people don't want a thousand features, they just want two or three really great features. And those can come in the form of patterns. The really good thing about patterns is that you only learn them Once and everything that you do to them is the activation energy to use it is very, very low, especially as it changes. The hardest part is just establishing this pattern. You're basically trying to think, okay, what is the role of this pattern? Why does it need its own space? And this is how it relates to a lot of the engine of the product. So it's a lot of thinking up front, but once you establish that pattern, it becomes a lot easier to just extend it. One trap is thinking like, okay, you know what, maybe I don't need a pattern right now, but I'm just gonna start adding some features and then maybe I'll establish a pattern afterwards. But the problem is that then becomes pretty hard to prioritize the change of introducing the pattern. So as an example, I introduce button A, button B and button C and all three are consistent. You're kind of left with this fork where, okay, I'll remove button A, B and C into a pattern and then consolidate them, or I will add button D. The activation energy to removing all three of those and adding a pattern is way higher than just adding a button D. And so it becomes not only complex from an implementation standpoint, but it's also complex from a user standpoint because they have to unlearn three things and then learn an entirely new thing.
- [20:57]
Rid
Can you talk a little bit about this balance though, of trying to have this forward looking mindset where you're anticipating where things would go and how you can create a pattern that would be extensible. But at the same time, you know, roadmaps change and you're moving at this blistering pace, not only with the scale that you're seeing as a company, but also the industry in general. Everything is changing so fast. How did you wrestle with that tension as someone who's owning a lot of the design?
- [21:24]
Andy Zhang
Where are the degrees of freedom in your product and where are the invariants of your product? So like for example, the architecture of large language models are not going to change and the inputs and outputs are likely always going to be the same, which is tokens in tokens out. This pattern of agents where there's a series of user messages, there's also tool calls is also not going to be changing. The output or the endpoints that these tool calls do might change, but the overall structure is not. And so generally understanding what is going to change and what is not going to change is important to know as a designer so that you know how to build things or design patterns that make those assumptions. And you also know how to make things more bespoke. If something is more accustomed to a tool call. So, for example, there's one specific tool call that uses an image, and most of them don't use images. And that's probably more of a bespoke type of design. What type of tool call is it? Is there an output or not? What are some of the actions that you can do on every tool call? Whether it's like a revert action or whether it is a status read only label? There's a lot of invariance in all of these different parts of the system. And by understanding what those invariants are, it allows you to design within those constraints. That way the pattern's degrees of freedom matches the system's degrees of freedom. And then that way you generally know anything that is built within that system can match the pattern itself. And then whenever something is flexing those degrees of freedom, then you can kind of lean in and try to figure out like, okay, here's a more bespoke solution that still adheres to the pattern that was built in the first place.
- [23:05]
Unknown
Can we dig into your process for.
- [23:06]
Rid
Figuring this all out? Especially as someone who started off technically as a growth engineer, which also I kind of find hilarious, you eventually create this role for yourself, design engineer. You're straddling these two disciplines in a way. When you're thinking through all these meaty problems, what tool are you using? What's your creative process? How are you untangling all this complexity?
- [23:26]
Andy Zhang
I almost think of it almost like as an LLM where it's funny, I feel like the LLM should be thinking like me, but instead I'm thinking like them now.
- [23:33]
Rid
Dude, that resonates so much. Oh my gosh. I literally think like an LLM and so much.
- [23:39]
Andy Zhang
Yeah, seriously, I was just like, inputs in, inputs out. What do I need to make the best decision possible? And so from there I'll work backwards and be like, okay, if I'm trying to make the best decision possible, what do I need to know? How much of the engineering system do I need to know? How much of the design do I need to know about? Because I need to work around this existing design. How much should I know about the user? So, for example, do users know about these types of products? Are they brand new? Are they used to a competitor's products? And if so, like, what do competitors currently do? What do I think about them? Are they good or are they bad? What are things that I would improve? I would try to gather a lot of that context. I would also try to deeply understand what is the problem that this is solving. And then with all that in mind, the first question is, should you even work on this in the first place? If you do decide you want to work on it, the cost of building and designing is way higher than the research. Honestly, a lot of that research could be done fairly quickly, especially for a smaller future. But building it, you know, good chance it might involve other people. And then you have to do planning. You have to go through entire software development life cycle. And that's a lot of time. And so sometimes the best decision is like, hey, like, let's not work on it. There's many times where I say no. I think that's one of the things I learned as a product manager is it's so easy to want to build everything. And when you kind of boil down to, hey, we have limited amount of time, we have these priorities and we have these goals, what actually fits into that? The solution is you need to start saying no to many things. You need to start cutting down the scope of many things. How exactly do you fit that with your constraints?
- [25:13]
Rid
And it's not even just the time constraints too. Whereas now the fact is, actually the cost of creating all these things has plummeted in largely part to windsurf in many ways. So as a result, if the goal is to preserve the simplicity of the mental model and the root system, you have to say no to things. Otherwise, yeah, you can accomplish all these different goals in isolation, but at the cost of what you are building at a top level. Now, all of a sudden, the reason I'm saying no is because it's too easy to build too many things and create a product that is complex.
- [25:45]
Andy Zhang
Yeah, that's totally true, because so much of it is about incentives in my head, where, like, if it's so easy to build things, then you'll do it more. And the end consequence of that is that it could be very complex product. Going back to the idea that users don't want a thousand features, they just want one or two that are really good. When I go to McDonald's, I'm not going to memorize the entire menu. I just know my favorite order and maybe I'll think of I have 5 or 6 favorite orders. Maybe the outlier might have 10, but the menu is probably way more than 10 items. Sorry, it's lunchtime. Food analogies are hitting kind of hard right now. You have these different tensions where people are so excited to be building things, but users are really only asking for few things, but way better of those few things. So how exactly can you balance a lot of that? So the first thing is saying no a lot. Because your goal is not to advocate for your engineers. Your goal is to advocate for the users and think about what they are asking for, think about their problems, and then say no to the things that conflict with those problems that the users have. I think that's like a first part of my process, which is just figuring out like, hey, what is the minimum amount of time I need to invest to make the first decision of saying, like, should we actually look like invest in this or not? The second part of this is cool. Let's commit to this. What is the right scope for this? Like, should we make this a big deal? Or should we just kind of do a little baby launch and kind of like figure out, like, if this actually has legs or not? And that is probably more of a question that is dependent on a lot of the other projects going on. Like, let's say there's a lot of other things going on. Hey, let's just minimize this. But let's say there isn't that much going on and we really want to allocate effort into this project. Then yeah, let's, let's go for it at that point. Okay, great. Let's start getting to the design. And so from a design standpoint, you have a lot of this context that you've gathered earlier on, and you also have a better understanding of the engineering systems and like all the users, like, okay, great. With all of that in mind, the first thing is what exactly is being built? Before even going to designs, I love to just like jot down all my notes in the form of like a baby prd. And this is really good for me. Just organize my thinking in written format. Because sometimes designs are best shared in text format. They don't always have to be rectangles and circles. I think that for me, I type way faster than I draw on Figma. And while I'm very, very fast with Figma, nothing beats like, you know, a bullet point that says a button does that and then you basically have it. Like, someone can immediately grok your solution. Because at the end of the day, what you're creating is a means of communicating an idea to everybody else. And it can be visual, but can also be in the form of text. So I think that's one thing I like to do in parallel. I like to inform other folks and like, hey, I think this is the next thing that we should be working on. What needs to be done ahead of Time to get this started. So they might be starting to do some research or they might start building up any type of platform changes that need to be done to support this. So basically starting any other parallel threads that can be running so that, that way we can build this as fast as possible. So once I finish this baby prd, I'll send it out for review. And then in parallel to that, I'll also start working on designs. If I had to summarize, I think a lot of it is unblocking other people who should be working on this project so that they can get started on the work. And then on my end, I'm trying to define what the solution looks like. First, the lowest fidelity format in the form of text, and then afterwards a little more visual, whether it's as a prototype or whether it is as a figma design. That fork in itself is interesting where if I know for a fact in my head that the vision is crystal clear on how to build this, I'll just go ahead and build it myself. But if the design's a little more gnarly and it has a lot more states, then I'll try to map it all out and then grab people to do a design review and be like, hey, like, what do you think about this? Does intuition feel right? Do you feel like this is complex to build? Then you kind of like bring it all together, try to figure out like, hey, like, what's my time on what's other people's timeline, if there's other people's involved, and then just try to coordinate a lot of it. And so there is, it's not really a science in my opinion. A lot of it is really much more of an art where for every project it's got a different process to it. And I think that the only way that you can figure out what's the right process is by understanding what it takes to be in the shoes of every person involved in this process. Meaning as a designer, as a product manager, I know what it's like to write a PRD that's good. And then also coming up with designs. As an engineer, I know what it's like to do the research to figure out how long it takes to figure out how something should get built. And so with a lot of that context in mind, I think that a lot of my role is to try to orchestrate things such that not only are we able to build something that is high quality and feels very good for the user, but also how fast can we do it? Like, what is the fastest way that we can get there. Because frequently you might build the same thing, but just takes way longer. And that's because there's a lot of inefficiencies. Maybe you should have involved the engineer way earlier, but ultimately you didn't because you were very, very focused on writing a PRD or design. But how fast can you involve other people and start a lot of the parallel threads really allows you to accelerate the overall project. And I think that's like one of the superpowers of someone who's a bit.
- [31:03]
Rid
More multidisciplinary and also just the explosion of tools too. Like, I love the point on having maybe a looser grip on a defined process and having it be something that is dictated by whatever you're working on, rather than like, this is kind of how I like to work. Because there are so many different ways to do things now, especially if you are a little bit more of a generalist. And even from my own practice, you know, I do a lot of my thinking on walks, which is not. Not atypical by any means, but the nature of those walks has kind of changed for me where a lot of times I'm creating an artifact where I'm. I'm having a conversation maybe with GPT or something like that, and dumping thoughts and dumping states as I think about them, asking questions, being asked questions. And then I just say, okay, take everything that I've said and turn it into a document. So by the time I get back down my driveway, I now have a nice concise document that is share ready. And. And then maybe that's how I would start things off. Or maybe it's like, you know what? I'm going to use AI and I'll. I'll try to do a prd, something that feels a little bit more like a requirements doc.
- [32:05]
Unknown
And then I'll try, you know what? Why not?
- [32:07]
Rid
I'll just one shot that I'll just dump it into lovable, see what happens. You know, why not? Sometimes I get something really helpful and I'm like, okay, I'll share this out. Like, what if it looks something like this? Or maybe I'm more traditionally in like figjam and writing and kind of wireframing and sketching. And I think that's actually making the practice of design a lot more fun nowadays is I really feel like there are so many different ways that I can attack a different project or a set of problems. And even figuring out how I want to get momentum on something has become a much more nuanced evaluation Process that I appreciate.
- [32:41]
Andy Zhang
Yeah, I love the fact that there's just so many tools now for thought. To your point, like, previously, there's only like, one good way for people to think, but ultimately there's so many different ways of thinking, and not everyone is good in that one way. And now that we have all these tools to accommodate all those different types of thinking, you no longer have to be like, how do I best fit my thinking for this one medium? But instead the question is, which tool for thought is my favorite? And, like, which one's the best one for me? And I totally resonate on, like, the walks part. Like, it's. It's such a good way to drive creativity. I think that there are some problems that I spent months thinking about and then only to realize, like, oh, this is the right design for this. This is a scalable design system for this. And I would hold off and be like, hey guys, let's not build anything around this yet, because I'm trying to figure out what's the right solution. And after I figured it out, I was like, hey, how exactly can I compress an entire system, a UI system, into a very, very small little toolbar that was a small toolbar that is right above the input box where you just have a bunch of these different icons. And the idea behind that was, how can I display a bunch of these cool features that you can use the agent for in these different use cases, but doing in such a way that it fits into the very, very compressed area? And I was trying to figure out what was the right interaction for this, what were the different components in it? I made several prototypes of it as well, and I think so much of it is similar to you, which is like, hey, like, you just gotta go on walks and give yourself the room to think. Sometimes the best thing you can do for work is to not work a little bit and just, like, go on walk and like, allow yourself to detach from the problem, to Maybe talk to ChatGPT on voice mode and to really just think outside of the box for a little bit, because that little time away can go really far when you step back in.
- [34:35]
Rid
So when you get closer to the implementation side of things, I'm curious how much code you're writing as someone who is the design engineer. But again, you're kind of creating your own role in so many different ways within that answer too. Like, how much of it is exploratory versus production.
- [34:54]
Andy Zhang
It really varies. I think that the way I think about my role is if there is a cup A lot of the other engineers on the team are rocks, sand, et cetera. And then I think that what I try to do is just be the water inside of that cup and fill in the gaps. And sometimes the gap is engineering, where there's no design effort needed. We just need a lot more horsepower on the engineering side, at which point I jump in. And I think that a lot of how I think about my time on the engineering side is I don't like context switching. And I'm pretty sure a lot of people do not like context switching either. When I'm designing for a lot of these projects, I want to make sure that the engineers working on those projects can just completely focus on that. So a lot of my time, whenever I am context switching across a lot of these design tasks and product related tasks, is just trying to tackle a lot of these bugs because those are a lot of small atomic things inside of the cup that I could just take care of. So that way the big rocks are taken care of by the engineers. They don't have to worry about all these different gaps. That's how I think about spending a lot of my time at the moment. For one, it elevates other people because they don't have to do any context switching. And number two, it also elevates the product because that's just less bugs overall. Number three, I think it just sets up the culture where, hey, my time is obviously very valuable, but nobody is too important for bugs. I want to make sure that everybody is tackling bugs. And so I'll try to do my best to tackle bugs here and there, but obviously I'll try to distribute these as needed to make sure that we get the product at the right quality for you just to be happy with it.
- [36:30]
Unknown
I'm a big believer in the power of video to explain my thinking as a designer. So when it's time to get feedback, I'll drop a loom link and slack and another link to a Figma prototype and feedback will be scattered everywhere. And I mean, it's a mess. So I'm building the product that I've always wanted to exist, and it's called Inflight. You can kind of think of it like an async critical. It's an easy way to share a video walkthrough along with an interactive prototype or whatever you're designing, and then AI interviews the people on your team to get you the feedback that you need and organizes everything for you in a beautiful insights page. So right now I'm only giving access to dive Club listeners. So if you want to be one of the first to use inflight, head to dive, club slash inflight to claim your spot.
- [37:17]
Rid
Something I was just having a conversation about a few days ago where all of a sudden I feel much more empowered to tackle bugs. I can just hop into linear and just start cranking out some of the things that are a little bit off. And, you know, every once in a while I fail. But it works, you know, like, I.
- [37:33]
Unknown
Can bring a lot to the table.
- [37:34]
Rid
All of a sudden on front end.
- [37:35]
Unknown
Polish, but it's like a very different mindset.
- [37:39]
Rid
You're in a fundamentally different place when you're squashing little front end bugs versus taking a step back and doing more deep design, product oriented thinking. And the reality is I love squashing bugs. Like some people maybe would look at that and be like, ah, you know, that's like low level work. No, I love it. I love polishing, I love sanding down the product. And it's tempting for me to spend a ton of time where, you know, it's an early stage product. I'm like, you know, I probably should spend a little bit more time like, figuring things out at more of a conceptual level. Is that like a balance that you had to kind of find yourself weighing? Because it is two very different ways to move the needle.
- [38:17]
Andy Zhang
Oh, 100%. It's so tempting to just look at a product and it depends on what lens you're wearing. You're just like, God, this is gonna be a buggy type of day. And you just like start squashing all of them. You're just like, okay. And then you're just realizing like, oh, crap, I was supposed to work on that one really important thing for this other engineer. That's the worst case scenario where you get so deep into the bugs that you just forget the bigger picture. And so I think what the really important thing is, like, how do you time box yourself? And this is actually something I learned from Rasmus, where I was just like, I remember just studying from afar. I'm like, dude, how is he so productive all the time? How is he working on Figma in the daytime and then also designing intern the evening that I think was his side project in 2016.
- [39:01]
Rid
Heck of a side project.
- [39:03]
Andy Zhang
Crazy side project. I love intern. And I think so much of it for Rasmus was that he was so intentional about his time. And I think that monkey see, monkey do, I saw him do that. I wanted to be like him. So I'm like, okay, great. Like, I'm also just going to start blocking off my time for bugs. So I start budgeting time in my calendar being like, hey, I have a rough estimate for a lot of these bugs. I'm pretty sure I can get through like all five to ten of these bugs in the next two, three hours. Yeah, I'll block this off and I'll just like start tackling all of them. And so that way, like past the two to three hour mark, I'm like, great, I finished all these bugs. I am okay with the existence of a few bugs here and there. And so that's one way that I try to detach myself from getting too deep into it and instead make sure that I'm always pouring in a constant amount of time into bugs. Now there's days where the rate at which bugs come in is like constant. Others is just like. It kind of just like goes like crazy because maybe there was a bad release and a lot of people are complaining. And at which case it's a bit of a call to action for a lot of our team where we're just like, hey, users are going rampant about the quality of our product and we need to fix this. This entire week is going to be bug bash week. And at that point, it' like that is another solution for us to get all hands on deck to solve bugs. But in more of a steady state, I'll usually just lean on to like, blocking off some time to tackle the bugs.
- [40:27]
Rid
I want to zoom out and talk career stuff for a second because obviously Windsor's been in the news. For those that don't know that you're going to head over to Google, there's kind of this line in the sand, career wise. You've had a heck of a journey leading up to this point where you've dabbled in pure design, you've dabbled in pure engineering, you had the PM uber roles. Design engineering, like, you can kind of almost take this in any direction. So given your vantage point right now, how do you think about positioning yourself as a career? What's next? What do you want to grow into from here?
- [40:59]
Andy Zhang
All three of design Engineering PM are really, really exciting to me because I think that it's really fun switching around and feeling like you can one day be doing engineering, another day being doing design, another day doing product. But I think that what's the most exciting thing out of all of this is less so the skills, but more so like, the opportunity to work with great people. When I look back on my internships and all of my work experience, I don't think like, oh, that engineering problem was the best. Or like, oh, that design problem was so interesting and it really scaled my mind, I think back on who were the most exciting people I got the chance to work with. And I think I feel very fondly about a lot of my work experiences. And I also have a bit of disdain for the ones where they were not as good work experiences. And so knowing that that is really what sticks with me, teaches me that the thing that I should gravitate towards is to work with people that I feel very excited to work with and that can be examined from the culture of the team. And I think that I saw that within Windsurf, which is why I felt this pull and I was like, hey, look, I want to work with these people. And longer term I will also think about it the same way where depending on what kind of opportunities come up and I'll have to make decisions, my North Star is always going to be like, who am I most excited to work with?
- [42:17]
Rid
Hypothetically, your Google journey comes to an end because you're too excited not to start building and you want to work on a new startup, so you're going to create something from scratch. What about the Windsurf culture would you hope to instill in that new startup?
- [42:30]
Andy Zhang
When I was interviewing with Windsurf, I felt like culture was really, really important and the things that I really cared about were the fact that so much of the company, if not all the company, was very, very low ego. That in my opinion is just way easier to work with, to be very aware that you know a lot, but you don't know it all. To know what you don't know, the ability to, to work hard and just get things done, the ability to sit down and teach other people, knowing that like it's not just a one man journey, but it's team effort. That type of culture allows people to make a whole that is greater than the sum of the individual parts. It also allows for better collaboration, just more fun journey. Overall, I think that that's kind of what felt very special when I joined Windsurf because I didn't sense any type of ego from anybody. Every lunchtime I would just be talking to a different person. And it was really fun getting to know everybody in a team. And the more I got to know more people, the more excited I got. And I think that that is something that if in the future I were to start a company, I definitely would want to make sure everybody is super low ego before I let you go.
- [43:42]
Rid
I'm sure there are at least some people listening that maybe have more of a traditional design background, but they're fascinated by this idea of being a design engineer and kind of curious what that would even look like to grow in that direction or bring that set of skills to the table. Do you have any parting advice for that person who's listening?
- [44:02]
Andy Zhang
At first glance, code is so intimidating. But I think that the hardest part is to just try to figure out how to break it down into atomic bits. Because I think that that's what we do as designers, right? We think in terms of the atoms of the entire design system, think in terms of molecules, and I think that overall, we think in systems, and I think that engineers do the same, but just do it in a different way. And I think that when you look at a overall system, it's very complex. You look at a React app and you're like, oh, my God, what is all this gibberish? Why are there, like, greater than and less thans everywhere inside of my text file? But I think that once you're able to figure out how to. How to break it down into atomic bits and just see, like, okay, this is what this word means. This is what that word means. You get a sense of, like, okay, this is what I should be paying attention to. This is all just boilerplate that is just designed to maybe intimidate me. Once you kind of understand a bit of that, then I think that it slowly becomes more approachable, bit by bit.
- [45:03]
Rid
It.
- [45:03]
Andy Zhang
Let's say you want to build a website. There's a ton of tools out there that allow you to quickly build that website. And these tools are optimized for two things. Building things really quickly and then also helping you understand it. Building part is a bit more trivial because you just ask the agent, like, hey, build me a tic tac toe app, and then it'll go ahead and do that for you. And then all you probably have to do is just open up every individual file and just be like, hey, like, what does this line do? Hey, what does that line do? And you can just basically, instead of trying to understand the entire system as a whole, you go into the underlying parts, which is all the files that are supporting, and just ask like, hey, what does this thing do? And you can note down all these different parts of the system. I think that the goal for designers shouldn't be to understand all the engineering systems. I think it's just having understanding of some of the concepts, some of the building blocks, and some of the constraints. Ultimately, the most powerful tool for designer to have. It's not to understand engineering, but it's the ability to learn as needed and to pick up these new concepts whenever possible. And the best way to be able to pick up those concepts as fast as possible is to practice that muscle of learning a couple of these concepts. If you feel like you are learning these concepts and it's really, really hard, chances are you probably just need more practice or maybe the concept is a little too difficult. You probably shouldn't be starting off with concurrency or operating systems. Maybe start off with understanding a CSS property or how Display Flex works inside of css. Maybe understand how a React component looks like and what are the different components within it and how a state works within React. And then once you have the confidence that you can learn a lot of these concepts, then I think that that carries over into your work where you know what you don't know. You also know what you know. And you're able to figure out what it takes to understand what you don't know in order to do your best work.
- [46:50]
Rid
I love that. And even listening to you talk was kind of just sparking an idea where as designers, we're able to notice when production does not match our figma. And every designer listening has experienced that situation before.
- [47:03]
Andy Zhang
Oh yeah.
- [47:03]
Rid
And that's not something that a lot of engineers would be excited to fix. And so just using that as the ability to say, hey, Mr. And Mrs. Engineer, I'd like to try to fix this. Like, I'd like to try to rectify this. And then the chances are you could even maybe drop a screenshot of the difference and then maybe ask the agent and say, hey, what differences do you observe here? Great, let's fix those. And then explain to me, like, what did you do? What changed? Why did that make the change?
- [47:36]
Unknown
And it could be like the tiniest.
- [47:37]
Rid
Little padding thing or alignment thing. And that's such an easy way to get momentum. And I think we're operating in this.
- [47:44]
Unknown
Really fun moment in time right now.
- [47:46]
Rid
Where a lot of people can take.
- [47:47]
Unknown
Almost the inverse path of you, where.
- [47:49]
Rid
You were the, you know, engineering in a very engineering driven culture. And it's like, okay, I want to bring some of the design to the table. Whereas a lot of designers have the ability to kind of take a few steps into engineering land just based off of some of those tools. And so I'm hoping that there's at least a subset of people listening that are inspired by your journey and want to get momentum in that part of their career.
- [48:12]
Andy Zhang
Yeah, hope so. I mean, yeah, code is definitely your friend, not your enemy.
- [48:16]
Rid
Well, Andy, this has been amazing, man. Thanks for coming on and sharing a little bit about your journey. Journey and just the winding path. You know, I think a lot of people hear a story like yours and are inspired simply for the reasons that it's just not true. It's not the exact playbook. It's not the step one, step two, step three, step four. Like, you know, you just followed your interest and it worked. And now you have this very diverse, interesting set of skills that you can bring to the table. So hopefully that inspires people as well.
- [48:46]
Andy Zhang
Thank you so much for having me.
- [48:48]
Unknown
Before I let you go, I want to take just one minute to run you through my favorite products. Because I'm constantly asked what's in my stack. Framer is how I build websites. Genway is how I do research. Granola is how I take notes during crit. Jitter is how I animate my designs. Lovable is how I build my ideas in code. Mobin is how I find design inspiration. Paper is how I design like a creative. And Raycast is my shortcut every step of the way. Now, I've hand selected these companies so that I can do these episodes full time. So by far the number one way to support the show is to check them out. You can find the full list at Dive Club Partners.