Listen Now

Listen to this podcast on your favorite platform Spotify, Apple, Google, or Simplecast.

Episode Summary

There’s an exciting moment in the design lifecycle when you move from concept to reality, when the “idea” becomes the “thing.” This phase of the process is a deeply collaborative effort between several different disciplines. After leading design organizations at Palantir, Slack, and now Loom, Joshua Goldenberg has insight into how we can make building and shipping an opportunity for inclusion and a shared sense of ownership. He also reminds us that design’s responsibility doesn’t end after the handoff — we should be collaborating with cross functional teams early and often.

Episode Notes

VP of Design at Loom Joshua Goldenberg shares insights about how to make building and shipping an opportunity for inclusion and a shared sense of ownership. He also reminds us that design’s responsibility doesn’t end after the handoff — we should be collaborating with cross functional teams early and often.

• Joshua's website
• Joshua on LinkedIn
• New Loom branding launch
• Plasmic

By Design is a show about the process of designing exceptional digital experiences. In each episode, our host, Josh Brewer, dives deep into a specific stage of the design lifecycle with an industry leader. Our hope is that hearing their insight can help us shape a better future for design.

If you’re interested in improving the design process at your organization, see how Abstract can help.

Transcript

Welcome to By Design, a show about the process of designing exceptional digital experiences. I'm your host Josh Brewer. And in this series, we will look at the different stages in the lifecycle of designing digital products. Each week, we'll hear from experts with an intimate understanding of what particular stage what has, and hasn't worked for them and how we might all apply these insights in order to shape a better future for design.

In the lifecycle of design there is a moment where the energy shifts in a real and noticeable way… when you move from concept to reality, when the “idea” becomes the “thing.” And, unless you happen to be one of those rare individuals who can design, build, market, and sell your product all by yourself, you quickly find that the way you get there is a deeply collaborative effort between several different disciplines that are needed to actually bring this product to life.

Joshua Goldenberg has been a designer for over 25 years and in that time has worked on tools and products used around the world. More recently, he has been building and leading design organizations through hyper-growth at companies like Palantir, Slack, and now Loom.

Whether it's finding your Engineering soulmate at each company you work for or building an environment of high trust with the CEO, Joshua’s insights on this stage are a great reminder that as designers we have a tremendous responsibility to stay engaged throughout the entire process—that the context we hold, the enormity of the problem space that we are immersed in, is critical to the success of the whole team and ultimately the product as well.

Thankfully, it’s not all on our shoulders. This phase more than any other, is really an opportunity for inclusion, a shared sense of ownership where different disciplines bring their respective context in order to make it whole. Really successful teams are doing this earlier and earlier in the process thankfully breaking down the old misconception that design’s responsibility ends after the handoff. Instead, it’s a realization that we’re all in this together until it ships. And the trust that’s been built in that process will enable continued collaboration and iteration once the product is live.

We had a lot of fun talking about everything from offroading in the snow to design systems and what to do when things go wrong. Here we go!  

Joshua: It's great to be here. I'm psyched.

Josh: I’d love it. If you could tell our listeners a little bit about yourself.

Joshua: Sure. I've been in design for 26 years, maybe less half of that, more focused on product design, software, user experience, type jobs. Outside of work I drive a Jeep off-road into the mountains, as much as I can. I've been living in the mountains on, in a town called Grass Valley with my family for the last almost four years. So we're kind of living the mountain dream that we've always desired. Two kids, spend as much time with them as I can. Doing my best to get outside as much as I can this winter. That's been a, like a pandemic goal is just to not spend the winter hunkered down like we have been for the last year.

Josh: Any winter activities that, uh, rise to the top of the list for y'all?

Joshua: I mean, really it's actually been, you know, instead of sort of the typical skiing and stuff, we've been just taking the Jeep into as deep of snow as possible as we can. Getting stuck, like winching out. And then, you know, the kids will go run around and, and build igloos for a while and then we'll drive back out.

Josh: Amazing. That sounds like a blast. I bet the kids totally enjoy that.

Joshua: Yeah. They love it. It's been great.

Josh: That's fantastic. Do you happen to have a, a hobby or a practice outside of design that that kind of keeps you sane?

Joshua: It's it's ebbed and flowed for sure. I mean the biggest, most long running one is probably, you know, writing electronic music and that's been a side project for over 20 years. It's ebbs and flowed. Like I said, sometimes it's, you know, it's involved playing live in front of audiences and other times it's just been me messing around on gear and then the pandemic project has really just been working on a Jeep, like teaching myself a totally new skill, particularly one that doesn't involve computers at all, which has been really satisfying to just like, you know, kind of mess up my hands and get dirty and, and work with something physical in the garage. And that's also, that's been a blast and a huge learning experience for me.

Josh: Yeah. I can only imagine I grew up with my dad working on cars and I never quite picked that up. And I always feel like it's actually like an incredibly complicated yet super satisfying kind of skill to have is, you know, the ability to really take something apart and put it back together and have it work. So I have a lot of respect for folks who dive into that.

Joshua: I'm not at the point where I can take apart an engine yet, but I can, I've done. I've done a lot of the other things around that and that's been the satisfying part.

Josh: That's so cool. That is so cool. Before we dive in, what motivates you to stay curious?

Joshua: The thing that probably motivates me to stay curious the most, it's actually something that I value. I want that from the people that I work with and the people that I spend a lot of time with. So it's interesting, because I don't know if it's a specific thing. It's maybe more of a discipline. I care about that. If I'm not curious about something, I probably shouldn't be doing it. I'll get frustrated more easily. I'll get bored. Maybe that's actually, it is, I'll get bored.

I know now having tried a lot of different things in it, if I'm, if I'm not curious about it, it won't last, it won't be something that I stick with. So like, you know, the characteristics of those things are, I mean, one way to describe it as like I will try to tinker with things that are complicated, whether that's a product design problem, a brand problem, or you know, or a vehicle. I think by picking things that are beyond my abilities and beyond the things I'm familiar with, it's easy to stay curious about those things.

Josh: So a couple of thoughts, one I think the older I get, the more I realize the people that I do want around me and that I find myself gravitating toward are other curious people in innately, not just like in their profession, but like as a person they're curious, they're they desire growth. They desire to learn and explore. And so I really resonate with that. And the other one is just around yeah the complexity of some of these things, you know, you were explaining whether it's a product problem, brand, an engine, right?

These are complex systems in some ways, I think you're describing the inherent draw, right? Like it is such a complex problem. And it's like, it's, you're solving problem after problem to get towards a greater answer, knowing that it's impacting a lot more than just maybe the specific thing that you're, you're touching on at that moment.

Joshua: Yeah. I mean the bigger the organization, the more complex, the problems in some sense. Um, and it's also just, it's finding interesting domains where there are puzzles to solve and hopefully the puzzles lead to greater puzzles. And that's a good way to stay curious.

Josh: Well, I'm with you on that one. Alright. So let's, uh, let's kind of jump in here and talk a little bit about the build and launch phase of design. What kind of immediately comes to mind when I say build and launch, like for you as someone who has led and also been a practicing IC designer as well, what does build and launch mean?

Joshua: On the surface, I think about the things that happen after you've written the brief, done the research, done some need-finding, figured out what people need done. Some ideation done some concepts, some prototyping and prototyping is where this, where it starts to get fuzzy. And you're ready to make the thing, whether it's the first draft of the thing, or you're ready, really ready to make the thing that you have a lot of confidence that you're going to ship and you get it into a state through heavy collaborative effort between a bunch of different disciplines to put it out there into the world, to let people know about it. It's that it's that spectrum of like, we're committing more than a little bit and that between that and the world is going to see this and we're going to figure out how the world is going to see it, that end to end space to me is what I think about when I hear build and launch.

Josh: That's awesome. I think about the exact same space. And I do think that the first thing you said was around how interdisciplinary it is. It really is, and it's just not design and engineering, but there's several other dimensions to it. And I'm wondering, what is the influence of those other stakeholders or departments have on how design moves through this process?

Joshua: That's a great question. As a designer and as a member of a product design and engineering or R&D groups, every business unit in the rest of the company has a stake in. In that whole process and the, and the way they play into it each with their own expertise that, you know, there's an example for pretty much everyone, finance is interested in how we're going to price and package the thing that we're launching and how that impacts the plans. If you're a SAS business, which is, you know, lots of, lots of your listeners will identify with that. We're collaborating with marketing to figure out how we're going to market. How's it gonna appear on the website, if it's part of the pricing and packaging. Like w where is it? How do we talk about it?

The folks who do writing both from a product and brand perspective, have to think about how we cast it, what it's named, what's its voice and tone like, salespeople are going to have to figure out how to sell it. What they're going to have to understand it. End to end.

They're gonna have to understand why it exists. Who cares about it, how to talk about that from SMB to enterprise. That just goes on and on through kind of every single business unit in the company. As you get closer to launch, everyone's going to have to be armed with the right information to get their jobs done as you progress toward putting it out in the world.

Josh: So what immediately comes to mind for me, and in, in that description is designers are still doing design work. There, but they're also over here connecting with and collaborating with, I think you listed a handful of different departments within the company. How much should design be involved in those areas?

You know, naming, for example, should design be a part of that? Should design be in the, should they weigh in on how we're going to sell it? I'm kind of curious if you have an opinion on that.

Joshua: I think the design should be involved. There there's lots of points in the process. I just described where I think in terms of who is directly responsible, if it's, you know, DRI or RACI, um, where we become like supporting cast members even more maybe than we are usually.

And, and what that means to me is. We have so much of the problem space in our heads, because we've done everything from participating or driving the research, perhaps all the way through ideation, up to the prototyping process and helping prepare to get it into the collaborative loop that we have with engineering when build really starts. And so all that context for sure should get shared from a first person perspective to all those other business units should design own naming? It depends, you know, if there's a phenomenal writer on someone's team who is just wonderful at doing that, design can play a huge support. And can support that person in, in doing their job really well.

If I have to collaborate with, uh, with the marketing department to figure out like how we're going to go to market and what that means from a visual perspective and from a language perspective, I can support that. I'm not necessarily going to drive that because that's, it's their job to drive it, but they want the context that I have and how I've thought about it so far. If we have a high functioning partnership, we can support sales by making sure they have really well-designed materials that resonate, you know, with a through line from the work that we've done, the feature that we've designed to get it out into the world from a sales perspective, that makes sense. And that they're like selling it correctly. So yeah, I actually think there's a role potentially to play in all of that, even if it's just context setting and making sure that we're sharing the knowledge.

Josh: That's incredible and really powerful, the way that you just described that. I heard you say support several times in there, which to me is such an important piece of it.

I think design does, whether we're driving or not, we are often bringing others into a process or we're adding to your point, adding context to someone else's, you know, mission or objective. And the other thing that strikes me about this is, the opportunity that design really has to tell the story of the product to the rest of the organization. And I've always, I've always seen this from like a visual standpoint. One of the powers that we have as designers is we can show you a future that doesn't exist yet. And what you just said kind of takes that to the next level for me, which is, it's not just the picture, it's all of the context and thinking that got us to the place where we could put that picture in front of you and confidently say, “we believe that this is the future we should go build.” A that's extremely powerful, but B that is a huge responsibility. How do you think design is doing and managing that?

Joshua: I think we're doing all right, but I also don't think it's it. I don't think it's as scary as it sounds when you think about the team around you, that you have to do it with. It's not exclusively design's responsibility to do all those things. The PM and the designer and the person who drives engineering really can do that together.

My hope is always that there is a really collaborative tightly woven team that does this stuff together. So if a feature team or a product leadership team even is, is bonded really well and works fluidly together as a team, often, the things I described can happen together. And then each member of that discipline brings their context to the table for the other business units in my previous example.

So it's, it's the cool thing is it's actually not all on our shoulders. The part that is on our shoulders is visualizing it in the way that you just, you described, which is exactly how I think of it. And then making sure that everyone is able to add their context on top of that. If that makes sense.

Josh: Yeah. No, it definitely does. That's really powerful. I'm thinking back to one of my favorite moments in my career happened towards the end of the end of my time at Twitter, 2013, things had gotten into a pretty act, pretty decent groove and. I was super proud. Every new project that we kicked off started with research, design, product, and engineering, those four people in a room. And it was this, this shift towards we together. Are going to be responsible for this, instead of it being one person's thing, whether they, you know, it got put on them, which often happened, or they purposely wanted it to be theirs, which also happens. There's just this cultural shift that I think is what you're describing in those really high functioning collaborative relationships is where it's a shared sense of ownership.

And I think what you said was each of us bringing our context to that thing, which will make it a whole. And I think that's the opportunity for inclusion. That's the opportunity for differing opinions and perspectives. And I think that I'm finding more and more, the teams that I see are really successful are doing that earlier and earlier in the process. Alright. So what do you think some of the common misconceptions are about this phase of the design lifecycle.

Joshua: I mean, one easy one is that that design sort of drops off after they've handed something off and their job is to just sort of maybe consult in a couple of key points throughout the build process, but it's really almost in a sense that it's changed hands.

Whether that's precisely waterfall or not, I don't think that that gets the best outcomes. The best outcomes and outcomes can mean, how we feel about the design quality of the thing, how it performs, how it's received by the market. What it creates for future possibilities and the product does are all potential outcomes.

I think the outcomes are generally better when the level of collaboration stays high throughout that whole process, where, you know, whether it's virtual over Zoom or in person in an office or asynchronous, that design and engineering are still shoulder to shoulder throughout that process and iterating in small loops rather than big, long loops.

I think that's a common misconception. I also think it's something that we, that as an industry, we are getting better at. Our tools get better, right? Like, I mean, even the thing that you're working on right now is designed to afford us to be able to do this better. And so, like, I see it trending up, which is good.

Josh: Yeah, I don't disagree at all. It's especially if you look just even the last 10 years, it's actually it's noticeable the trajectory. And I think we're, we're just gaining steam. And I think it also says a lot about engineering, you know, really being open and inviting design into that part of the process.

Some of the most, I think enjoyable and successful things that I've worked on have been tightly uh, partnered with engineering all the way through to the moment that somebody presses the, you know, that deploy goes through. We're we're in it together, making sure that it gets out. And that usually has a lot to do, I think, with the, the level of care that the people are operating with that also kind of stands out to me as one of the key ingredients in this being really successful.

Joshua: Something you just said, I think is important there too. You want all of that to happen? And one of the ways you'll know it happens is if you have that shoulder to shoulder relationship with engineering and on the day that the flip, the switch gets flipped. The designers they're in the, in the war room or in the launch room. And they've been with it the entire time. And that team, that team is all present for the moment that thing goes live. That's a good sign that all the things we said before that have happened.

Josh: Yeah. It's funny that you say that we have a value at Abstract, which is when we ship, we ship together.

And one of the things that we, that kind of came out of that initial conversation around it was all right, well, not everybody ships code, right. And, and it became this moment to talk about no, but we're all shipping, all the time. Anything that goes and eventually touches the customer. It doesn't matter what part you played in it, you're part of shipping and I don't know, there's some really cool, I think for us internally that like locked into, I don't have to be an engineer to ship.

I might, you know, I might be adjacently affecting this thing, but I helped ship this product too, and I hope to see more and more of that evolving in the way that we're operating. So tell me a little bit about one of the times when this has gone really well for you. What about it kind of led to it being a really successful build and launch phase?

Joshua: One of the best examples is probably from super recent history actually. It was a Loom project. We did a rebrand. So started on the identity system. We built that up into a stable set of tools that we kind of knew we were going to use on the brand side, and then immediately took that and implemented it all the way through the entire product, every operating system, every surface area of the product.

Oh, all in about two and a half to three month timeframe and then launched it. That came to fruition, I think, mid October of last year or so. And that that's, that's my sort of near term example of one that went really, really well.

Josh: Anything in particular about it that lent itself to going as well as it did when you look back on it?

Joshua: Yeah, we've, we've done some, some good introspection, just kind of asking ourselves why we love the process and why it went well. And there's a couple of things that stood out. I think on the brand and identity system side, we had enough time and enough space to work on that piece.

And yet. We didn't give ourselves years to do it. It was constrained enough that it had the right amount of time to launch it. And yet like enough time to kind of be creative and figure stuff out. And there were both of those conditions plus the fact that it's working with our CEO and the decision making loop with the person who ultimately owns and is responsible for the brand was just really easy and fluid and high communication and also high trust.

And that, that added a lot to that whole part of the process. And then when it came time to implement it all, we decomposed it into reasonable chunks and there were areas where we were able to get started on that effort first. And that was really like starting with the design system. Because we also were in a good position by having an existing design system that was fairly well-populated throughout the code base, we were able to identify like, where are the gaps in the design system, where we don't have as good a coverage and work on those first. And so that was a relatively low lift engineering effort, meaning it didn't involve the whole engineering team. It was a few people being able to sort of scoop up the gaps and where the design system was implemented.

Then, building on top of that, once we had an even enough distribution of that, it became more and more of kind of a whole team effort until we reached the last, you know, three weeks. In which a huge chunk of R&D was just all working on it at the same time, then there were a few other, probably smaller things.

I mean, in engineering, they were kind of constantly tuning how we were going to deploy and how we were going to launch. And we kind of got better and better even at those, at those moments, how we were testing, how we were deploying that, improved the process from that perspective as well.

Josh: Do you think that without the design system in place, how much longer do you think that potentially could have extended this?

Joshua: We would still be working on it for sure.

Josh: Wow. Okay. What, what took arguably three months? If I'm, if I heard you correct, could have mindlessly extended. Yeah. Six, nine? Is that fair to say?

Joshua: Yeah. Yeah. Possibly. And I mean that, I would say that that number probably multiplies, it's not even an additive, it's probably a multiplicative, depending on how much, you know, if you're a bigger product in a bigger company with bigger surface area and that much bigger of a code base.

Yeah. It's, I mean, you've been there it's it'll spiral out of control and I think that's actually why it's strange to think that when I got to the company. I was sort of like, wow, this is really early stage to have a design system that sort of already exists and a full-time person working on it.

There's no question that it paid compounding returns when it comes to being able to even approach a problem like this, um, where it was so much easier than it could have been. If we didn't have that.

Josh: That's really, really huge. I was hoping that we might find our way to design systems in this conversation. I feel like I have to ask, are there any less than successful times that you can think of?

Joshua: Without getting too specific, there have definitely been times where we collectively have launched things that have missed the mark on metrics, or for example, you know, we've put something out there that we thought was really great that but didn't perform or had a negative impact on something. Those moments can be tough because it's, you know, designers are asking themselves, Hey, I had a lot of trust. I had a lot of latitude to try to figure this out. And I, you know, I turned a metric the wrong way. And that kind of thing has definitely happened.

If I was going to offer advice for one who is experiencing that for the first time or, or who has to deal with it in general. One thing I've I think I've learned from them as moments is don't panic. You don't actually have to fix it like that moment, that second. And sometimes what you discover is that there's a longer tail where you've actually impacted something negatively because it's a change and things go your way over a slightly longer period of time. And if you just, if you relax for a moment, you may find out that it's not nearly as bad and maybe better than you thought it was.

Josh: Yeah. And there's so many examples popping into my mind, just around metrics that you could see them and instantly know, oh, we actually missed something. There are things where it's a fundamental — somehow we all became banner blind to whatever this thing was. But more often than not, I have seen what you're describing end up being more of the case, which is you need to let that thing smooth out, change is hard for anybody. And so if it's introducing something new, if you moved things around or if you're asking users to do something that they aren't already kind of primed to do in the product, some of that's time. Right. And so it's more that if it's a steady decline. And, you know, I don't know, there might be cases where actually a number going down is not actually the worst thing in the world. If something else that has a higher priority is going up. And in those cases, it's really understanding the business trade offs, you know?

But it can be terrifying as a designer to be staring at that. And if the company's focused on it, I remember the new, new Twitter redesign in 2011, the whole company had a set of metrics by which we were measuring, whether the success it was successful or not. And design had a huge role to play in that redesign the release, everything.

And there was a hot minute there. I think, where everybody was holding their breath and things kind of do to do. And all of a sudden it, it stabilized and started going up and we were able to learn really quickly that there were some things we could improve in really short order that had quick gains and other things that were new things we had to study. Now we have new behaviors and new metrics that we're having to add into the existing set of things that we're making decisions with.

Joshua: I think that's a really good point. Sometimes when you redesign something, whether it's a feature or the whole system, at whatever level of, of sort of scope, we're talking about, it's useful to keep in mind, especially if you're at a smaller company that doesn't have the kind of testing infrastructure and testing playbook that a much bigger company could avoid a lot of these pitfalls by just, you know, sort of dark launching and AB testing things at will. When you don't have that, it is useful to keep in mind that sometimes the thing that you put out there is sort of a new sort of is a new baseline and you shouldn't necessarily lose faith in it on day one, when, what you've set up for yourself, it's just a new thing to start improving and getting it kind of over that initial hump and into a more successful space. And, and it's, it's, I think it's easy to forget in the moment when you're, when you sort of feel that sense of panic when things didn't immediately go your way, that it isn't just that you're going to sit back and hope that it turns around, but you have, now you have a new set of iterations in front of you with which to improve.

What is hopefully a good baseline to work from? Sometimes we actually just did make a mistake and we have to undo it, but more often than not, it's like, okay, we're building off of this and how do we get it further and further, you know, into a successful state, even if it isn't that on day one.

Josh: Yeah, that's awesome. And I hope folks that are listening here, hear the encouragement in that, right? Like keep at it. We are working together to improve these things and I'll tell you, it feels like there's a lot of almost mythology out there that everything just is. You know, the most successful companies that just magically up into the right the whole way.

And I think you and I can both attest to, you know, if you got close enough to that line, you realize it's a really bumpy, bumpy line, but from far enough away, sure. It looks roughly straight. Um, and so it's all data, you know, at the end of the day, you launched that thing. And now you have data with which to make new and better decisions that you did not have before.

And in some cases, there was no way you could have had. And so I love that reframing even something that doesn't work well, it's still data and it's still an opportunity to learn and improve. So let's do some futurecasting. So imagine it's five years from now. You and I are chatting again and we're looking back. What do you imagine has changed about this stage of the design life cycle specifically?

Joshua: I would say I really hope that some of the things we talked about a few minutes ago around this, the shorter iteration loops and the closeness of a cross-functional team and the way that design and engineering work together becomes increasingly fluid.

So I think you want both things that I'm about to say to happen at the same time, which is that, you know, the ownership and the sort of the things that he discipline is responsible for to remain clear, but how do you do that? And also continue to sort of build tooling and process that brings us closer together and continue to make that iterative loop shorter and shorter and shorter.

The way that I imagined that manifesting is that the market is now flooded with prototyping tools. And we've seen a huge rise in prototyping, which is an important part of the build process, right. And where that prototyping begins and ends in the boundary between design and engineering. Hopefully it's actually getting fuzzier.

And I think the fuzzier, it gets the cheaper it gets to do. It is the thing that I'm hoping for, right? You, if you, if you zoom out, design prototyping tends to be cheaper and engineering prototyping tends to be more expensive. And I think you want to move the needle somewhere in the middle, where you can produce things that are potentially shippable in that gray area and also not as expensive to throw out and start over. That's a big thing that I'm kind of hoping for is that. Whatever fills that void is something that both design and eng can participate in equally, produce shippable things out of it and blue and, and increase the amount of collaboration that happens between those disciplines. I think that's possible. I think that's, I think we'll see more of that next five years.

Josh: I agree with you on that one and, uh, yeah. For anyone listening, if you want to go build our dream scenario, it's that basically a design system out of the box that works in whatever drawing tool you need, but it also has mapped some how and call me, I have ideas on how, but, somehow magically mapped to the components and code so that if a designer designs something, the code components are ready to go and you can compose it and effectively allow anyone to start getting to that higher fidelity prototyping. Most of what we do is actually really decomposable into a base set of forms, elements, card types, you know, just, there's not that many. It's really in the nuance of how it's assembled and what the interaction flows are that I think we probably spend more time trying to get right. And so the faster we can do that at a higher fidelity, I think the faster a company can move with confidence.

So, like I said, dream scenario, but man, I've been, I've been thinking about that one for a while that would genuinely multiply the rate of iteration that you're talking about. And I think collapsed down that design and engineering wall even further.

Joshua: Yeah, how great would it be if designers could contribute shippable components like directly then themselves that are, that are sort of already, already designed and engineering in a sense like front end engineering moves up a level and is thinking about, you know, more difficult and perhaps more interesting engineering problems of how to wire them together, you know, how to, how to make the system work as a whole.

And I have a lot of confidence that designers would love to be able to have their hands directly on those things. And see them go directly into the design system without engineering effort. Like the designers, the design system would grow faster if it was able to work that way.

Josh: I think that could be incredibly powerful. I do know there's, um, there's a company called Plasmic that is actually trying to do this right now and I'm doing some really, really cool stuff. It  gives me a lot of hope, you know, if there's smart, hungry excited people out there that really want to see this space in particular, move forward, putting their energy into it, man. I'm ready to back those folks. Big time. Alright. Last but not least, if you could impart one bit of wisdom to our listeners, what would you like to share?

Joshua: To do the build phase really well, so sticking to the topic at hand, as an IC designer, one of the things I always did when I joined a new company was to find my engineer.

It could be more than one, but I really, I would take the time to try to seek out like, who is the engineer that I should be best friends with. That is going to, you gotta be able to sit next to for days and days on end and nail the details. And this isn't a person who's just going to execute what I tell them to execute. They're going to be hopefully brilliant and have a great understanding of how the system is built. And they're going to give me a lot of feedback on how I'm thinking about it incorrectly and what I should change.

And if we can, if we can do that together, and that begins with identifying those folks who are going to be your sort of design allies in engineering, that's a great, that's a great setup for having a good build experience and one that that will produce the good outcomes that I described and work that you will be really proud of it. Yeah.

Josh: Couldn't agree more. I couldn't agree more if there was anything you were going to share that isn't constrained to just this phase of the life cycle that you'd want to share, please, by all means.

Joshua: The other one is probably don't panic. And we talked about this a little bit, but there are so many moments during build and launch when you're going to have doubts and, and everyone's going to have doubts. Even if you have a lot of confidence, you may find yourself in a room full of people who are, who are not sure.

My advice to you in those moments is don't panic. It's hard not to do that. Sometimes you do not. You don't have to have to possess an iron belief in the thing that you've made. But you can bring that curiosity to the room that we talked about in the beginning and investigate where the hesitancy and where the doubt is coming from and turn that into something that you can also iterate on.

Sometimes the way that I think about this, it's like you can take the design process for how to make things that you've learned throughout your career and apply it to any scenario at work, whether it's people management problem, or even like a people management problem, as it presents itself in a cross functional group in the room, when you're thinking about whether or not to launch, you know, you can go back to first principles and sort of investigate.

Where does the hesitancy come from? Why are people nervous about it? And rather than sort of letting the freakout just play out. You can help build confidence in the room by just asking lots of questions and being really curious and helping to surface where, where those things come from and, and turning that, turning that into a plan of action to then go iterate it.

Josh: I love that. I absolutely love that. I was out for a walk earlier today and actually had a thought very similar to this, which was, you know, in those moments where you do have that little, that panic, that just like, shoots in, how do you get enough distance from it to get a tiny bit of objectivity and to be able to just ask, why am I feeling this way right now?

I don't even need to solve it to your point. I just wanna create the space to hold that curiosity. And whether it's a breath, whether it's standing up and moving, you know, whatever it is that gets you to break that little connection and allow yourself to ask why, right? That curiosity it is. I'm so excited that that's kind of been central in this conversation today because it really, I think for so much of what we do, in every aspect of what we do, the curiosity continues to be probably the most central thing that I'm finding and good news. It also, like you said, it applies to the rest of our lives as well. So more designing with more curiosity. I'm pretty excited about that.

Joshua: Me too.

Josh: Alright. Thank you so much. Really appreciate the time. Take it easy.

Joshua: It was great to be here. Appreciate you having me.