What do you do when your teammates are not communicating well and things seem to be going off the rails? Things are going poorly. You have conflict on your teams where maybe you have an us versus them symptom between the designers and the developers and the project managers and the client even. That's exactly what we're going to be talking about with today's guest, Aaron Irzari. Aaron is the director of UX at NASDAQ. So we're going to be introducing Aaron shortly. My name is Jonathan Cutrell. You are listening to Developer Tea. My goal on the show is to provide you with coaching, the inspiration, the insights, information, and generally the conversations with people like Aaron that will help you become the great developer that you want to be. I know you want to be a great developer because that's why you're listening to the show. And if you don't count yourself in that group, then you probably don't want to listen to this to the show. This is all about becoming better. This is not a show where you're only going to leave entertained. I want you to leave feeling challenged but also optimistic. I want you to feel empowered to become a better developer and to deal with the kinds of problems that Aaron and I are going to be discussing. Of course, this interview was done in person at Squares. This is the second interview that we're putting out from Squares. So you'll hear some background noise. But I had a fantastic time at Squares. I highly recommend that you check out Squares next year. I will most likely be there so we can talk. We can sit down and hang out. And I always love meeting those of you who are working in this industry. I'm going to get out of the way so we can talk to Aaron Erazar. I'm here at Squares with Aaron Erazar, the director of UX at NASDAQ. And I'm really excited to talk to Aaron. Aaron has been an iconic face around the conference this year. He's been front and center at pretty much every talk. I'm really excited to talk to Aaron. Thank you so much. Thanks for having me. Can you talk a little bit about what the talk you gave here at Squares? Yeah. It kind of came from just experience at work. And I think some of those talks that like that resonate, so it really came from working on a few projects that really went sideways and did not go as they should. And so the title of the talk was? Oh, yeah, yeah. Hold fast. You know, managing design teams when projects go sideways, right? Sure. And so that happens all the time. We pretend it doesn't, right? We are on Twitter and social networks talking about how great everything is and that we often don't talk about some of the frustrations we face. Yeah. And that's that's a, that's, I so I think it's good to talk through that stuff because I feel like it resonates because we've kind of all been there. And so yeah, I have this odd rule that if I'm going to go through something that I don't like, I'm going to get something out of it. Yeah. And usually it's like what lesson can I learn from this? From this difficult thing. Yeah, yeah, exactly. And so that's kind of how that talk came. We just, we had a project that went really terrible. And I just started taking notes, like what I thought maybe we could do better next time or what did I mess up and I thought, you know, man, this could actually be a good talk. I said, what are two or three ways that a design team can go sideways? What is, or maybe four or five? I don't know. Yeah. I mean, when, when we get in the middle of projects, you know, people, I think one of the, the worst things that happens is because we know our work pretty well for the most part, we tend to make a lot of assumptions. Sure. And what happens is that leads to, and those assumptions may be absolutely correct. It's just that the idea of when we make assumptions, we're not communicating. Like I don't have to talk about this because I already know. And when happens is we have communication breakdowns and sure, not, people are not having the shared understanding of what they're trying to do. So it ends up that people will go in different directions or they, they think they're delivering one thing and they're doing another or they, they don't understand what the expectation and the goal is in a way that everyone else does. So you end up just like someone comes up short, someone doesn't deliver on time. You know, designers put on a barai and a scarf and get really mad when people give them feedback on their work. Like that also starts to become a problem because they think they know everything and they're not listening to, you know, the product managers or the developers or people who may even be like subject matter experts, right? The product folks often know the industry really well, the, everything the folks are designing for. But just because they're not a designer, right? Yeah. Designers, I've done it like you tend to kind of take their feedback, their thoughts of the little bit of a grain of salt, which really kind of messes things up sometimes. Sure. And this, so to, to be very clear, this was a talk given to designers, not a bunch of developers sitting around, you know, bashing on designers, but oh, yeah, for sure. Certainly the same thing can happen with developers, Developer Think they know everything and they end up causing problems because, you know, not only are we assuming very poorly, we're also, you know, approaching something from the perspective that everyone else needs to listen to me. Yeah. Yeah. Like I am the expert. And you know, what's interesting about this talk is I've given it at a project management conference, I've given it here, I've given it to developers because really like my context is design and that's just because that's what I do. Yeah. Yeah. I think this goes beyond whatever your skill set is. It really comes down to how people work together to achieve a goal. Yeah. And what do you do when that starts to fall apart? Yeah. And so you can apply it to whatever context, right? Sure. And I think that's, I think it's important. And I think actually it would do designers really well to think in that mode. I try to get my team to not think of like us and them. Yeah. As much as it's just like us. Right. Like we are, I tell everyone we are, we are a product development team. Yeah. And yes, we have varying roles based on our skill set, but we are working together and those skills need to augment one another and accomplish something. And so we, we definitely try to keep it away. I try as hard as I can to like, and I'm not always that great at myself, but like keep it, you know, like it's not us and them. It's not low designers over here and developers over there. You know, we really try to bridge that gap and like realize that we're different sides of the same thing. You know what I mean? Like this is really, you know, this is titled tyranny. I'm going to use a good evaluation. Yeah. It's the concept that the, you know, there's good and bad things about titles. You know, this has been a hot topic recently. We talked about it here at this conference. And you know, when the title creates a wall within a team, when it creates difficulty within a team, then step back and see what things are like if you remove the title. Yeah. Well, at least give that a chance, right? Yeah. Well, I know that, like there was a lot of Twitter conversations about like everyone's a designer and all these different things and there was a lot of backlash. And I thought, I mean, I definitely don't think on its face that everyone is a designer. And I understand at its core, there is some value there where, at least what I'm thinking what I'm hoping is that they're pushing for inclusion, right? And the process. My thought process is though that I don't have to change who I am nor do you have to change who you are to be included in my process. Yeah. Like your skill set is different for me and that's good, right? Because if not, we become an echo chamber, right? It's all of the same, the same things. And there's no diversity. So the value of diversity is it provides different angles and lenses to the things you're trying to do. And so, you know, that's where I think, yeah, I get saying everyone's designer makes, you know, makes people feel included in the process. But I can still include them. And I don't have to, I can call them by their name, right? Right. Right. I have to call it a title. Yeah. And that's, again, that's, that really is the key phrases. Yeah. Inclusion and title or not, you know, coincidental or not. Right. And also, you know, that discussion is also largely, I think, it was about the definition of design, which, you know, is a very common topic. How many conference talks have you seen about the definition of design? What it is, what it isn't, you know, the fact that, I mean, we hit, we hit all the time, right? And I'm not even going to make a comment on what I think it is because it really isn't super valuable to, to pontificate for hours and on end. Well, yeah, you know, it's my thought, man, it's like, why are we talking about this with each other? Yeah. This conversation is most valuable, probably within our, within our organization and our teams. And that's where we talk about it most likely the least. Right. Yeah. Except, you know, we open Twitter and argue with each other about what to call each other and what those roles need to be. But that's really weird to me because like we're trying to apply this like label to everything, but yet we all work in different contexts. Yeah. So that may not apply, right? You may, and honestly, like most of the titles we have were given to us by the organizations we work for. Yeah. Like for the longest time, I worked in a company doing UX and I was the webmaster, web project manager, right? That's nothing to do with the work I did, but that's how the organization classified what I did. And it's like, cool, I don't care. You can call me whatever you want. Exactly. One, you pay me and two, I'm still employed. We're fine. Right. Yeah. It's not bad. And there's work on the table. And so it's the classification problem, right? We have this fallacy believing that if we classify something that somehow it becomes stronger, right? If we give it a structure, a mental structure that seems to make sense because we have a hard time understanding a picture that we can't tell a story about. Right? And so we create this mental map of where people are in the organization. And we have all these fights about whether parallel is better than hierarchy. And it doesn't really, really we're just trying to explain how we work. Rather than create a structure to inform how we work. And it's much more difficult to explain something that's as organic as the average organization. Right? Yeah. I think I've always kind of thought, and I don't know if this is entirely accurate. It's just like what bounces around in my head sometimes is like, when we don't understand something, we're not satisfied with that. Yeah. We're not okay in not fully understanding something. Right. And so we have to define it. And a lot of times we feel like if we define something, we're in control of it. Which that makes sense. I mean, that's human nature. But I just, I don't really need to control this. I just need to do it. Yeah. I'm not as worried about that. So I understand how it happens. I know we can get caught up in that stuff. And I have in the past got caught up in labels and who does what? And sometimes labels are really effective because they help explain what you do. Like, yeah, thankfully, every time I go to Thanksgiving with my family and I have to try to fix somebody's computer and I have to tell them what I do. My label works for that. Right. Yeah. And you know what? My family does not instantly hop on Twitter and start debating me about it. Yeah. They're just like, okay, cool. Because they care about the work. You're like, okay, cool. Did you fix my computer? Yeah. No, because I don't do that. I'm a designer. Right. Like, it doesn't matter. You know, did you fulfill your role for the day? I don't know. Maybe. Totally. So I'm going to kind of hyper focus in on one word that you said that I think is so important as an assumption, right? This concept of assumption. And I'll lay out an idea and we can pass this back and forth. But, you know, there's, there is useful assumption and then there's harmful assumption and drawing the line between the two is perhaps one of the hardest jobs that we have because, you know, when I say useful assumption, this is what I'm talking about. Because we're talking here, we're using a shared language, right? We've never sat down and had an interview before. But because we have this cultural, a shared cultural thing, because we have a common language and a protocol, if you want to call it that, we can communicate back and forth and come away with a reasonable expectation that we were sharing the same ideas. Yep. Yep. And that reasonable expectation is really an assumption. I'd say strong assumption because our language is defined outside of the two of us. But the reality is some of the words that I'm saying have slightly different meaning to you than they do to me. And so this happens in a organization, especially in a project, when you say application, for example, or when you say even some of the words of technology, like some of the definitions of technology that you're going to use JavaScript, that means a whole different way. It's a different thing to another person than it means to you. So I say all that to say, how can you, what are some of the ways that you would find to kind of disambiguate things that could be ambiguous? Yeah. I call it the Princess Bride Theory. Like that thing you're saying, I don't think it means what you think it means. Right? And so what I do is early on in a project, we set some principles, some ideas, how we want to approach things and try to establish one, a shared understanding. You can call it what you want. I really don't care so long as we mean the same thing. And so we try to do that. You know, we try to, so when we kick off a project, I'll say we're going to do X Y Z. And as a team, to us, X Y Z means this. Right. And someone, and I say, you know, does that make sense? And they, someone from the business side may challenge that assumption and say like, well, actually, it might work this way if we call it this better because that's how it, I'm like, oh, cool. Then let's redefine that. Right? Yeah. And so it's really trying to, and we don't define every word we say to each other. Sure. But some of the core things we're trying to do, we, we try to put a little bit of definition around them just so, because we know that it will, in the future of the project, more than likely it will prevent communication breakdown. It will, it will prevent those hurdles that come from like you're saying, like having a different understanding of the same thing. And that's where an assumption can go really bad because if you both assume you know what you're talking about, but you aren't talking about the same thing and you just keep going. Yeah. You're going to get to a point where you're like, we are not on the same page. The further along you go on in a project where you are not on the same page, the more trouble you find yourself in, right? Yeah. Yeah. And it can go really bad. And I think it's, it's like a design thing, right? Like, like, say, a positive assumption is, I think this is what the user wants to do. Right. We validate that assumption either by using research or by doing some usability testing or getting it in front of some folks and seeing how they respond to it. And so that's applied inwardly to how we talk with one another and just making sure that we know, like, I have a really good product manager I work with and she does that really well. And she doesn't in a non, really rate this non, almost like a self-deparating way. She's like, you know, she always says, I know when that's coming, she'll be like, I may be dense here, but this one that means, yeah. But you're not dense, stop. Yes. It means that or no, it doesn't. Here's what it is and she's like, oh, cool. But we just have established that practice of like, yeah, anytime there's a little bit of doubt about what we mean. We have the license to talk to one another about it. Yeah. Grab her and chat and be like, hey, on the call you said this, is that what that means? Yeah. Yeah. Yeah. Yeah. Because again, we are different roles. Yeah. Like I said in the talk, we're different people with different roles and experiences and context tasked with building something. Mm-hmm. So it's a little silly to think that instantly everything works the way it does for me. Right. Yeah. Exactly. And so that's where we're just talking about it and trying to set some defined things about key ideas, principles, and terminology at the outset of a project. It can really prevent frustration down the line. We're going to pick up on our conversation with Aaron about communication and setting expectations and different techniques that you can use when communicating with your team in just a few minutes. But first of all, we want to talk about today's fantastic sponsor Dolby. Users want better audio. Users want good experience across the board, but a lot of times we forget about audio because it's easy to think that audio, really good audio, is left to the people who are doing audio products like Spotify. But it's not just for Spotify. It's also for those of you who are making, for example, iOS games. And you can get better audio by simply using a better codec. A lot of the time you don't need to re-record your audio, the source files are usually pretty good. The codec you use can make a ton of difference in the quality of the audio, especially the quality that the user hears. Dolby provides a free online tool for Developer To use for their applications. The result is clear dialogue. In your applications, it is multi-channel, so surround sound in your iOS applications. Go and check it out. Spec.fm slash Dolby iOS. You don't have anything to lose here. This is totally free for you as a developer to implement. Spec.fm slash Dolby iOS. Thank you again to Dolby for sponsoring today's episode of Developer Tea. Anybody has gone through relational therapy, like if you go to the therapist. One of the things that a therapist may tell you to do, and this works extremely well outside of, you know, significant other relationship, is what they'll tell you to do is when someone is explaining to you, you know, in that context it'd be what they feel, but in this context it's explaining what they think, you know, this module does, or what they think this particular project is intended to do. A useful operation for you as the responding, listening party is to repeat what they said in your own words, right? Yeah. So now you've explained to them that you've heard them, and you've given a translation, which means that you're now adding a secondary, hopefully identical definition. So there's more, just statistically speaking, there's more liability between the two, because it's a message-scent message received. If you think about the way we do, you know, a browser receives a message, also responds with a response code, right? Yep. And it gives you, okay, everything is good. And so you read both sides of that relationship. Yeah. In our, in the book, Adam Conner and I wrote Discussing Design, we have a section on that called Active Listening. Yeah. And it is that it's basically a same-backed them. So if I understand you correctly, you are saying, if we build a stored procedure this way, we could run into this problem, right? Yeah. Or if we are, you know, if there's too many calls on this page, like whether it's JavaScript or whatever, like it's going to slow things down, you're like, yes, that's what I mean. Or you give them the opportunity to say, well, no, like here's what I really mean. And it's almost like you're helping, one, you're helping your own understanding, but you're also helping them communicate better and more effectively, right? Yeah. It's important to do that. Yeah. I love it. My wife and I just went to Portland. And if I were to tell you, we went to Portland, there are, as a significant portion of the population that would think we went to Maine and another portion that would think we went to Oregon. And so to actually disambiguate, you have to add more information, right? And so whenever anything, even if something doesn't seem ambiguous, there could be more information behind the veil, like in a, in a, in the same conversation. Yeah. And so a little bit of extra, the two little letters behind Oregon, or I'm sorry, behind Portland, could put you on two different sizes of country. Yeah. So extremely important that that happens. And so that clarification process and detail process, you know, knowing when to stop is important, but also understanding that you can get a lot by just simply having a face-to-face conversation, right? And you add more detail through prototyping. You have more detail through design iteration, through all of these, you know, technical specification, acceptance criteria, if you want to use that term, it's all these things that you can do. But ultimately, starting out with that, that initial conversation and communicating back and forth with another person, creating a shared language, spending time with them, very strangely, a simple coffee meeting with someone to understand some of their, their cultural background, can help the success of a project. Totally. Yeah, like, you know, that's like, it is, it's like research, but inward, right? And I think that's so important to realize. Some of this stuff seems like, wow, trying to define terminology. That seems like a lot to do with the beginning of a project. And it might be, it might be, there might be some heavy lifting there, or it might be like, kind of like a time suck, right? But it saves you down the road, right? And that's kind of, it's, it's, it's interesting. There's a, yeah, there's a level of preventative care that's happening right there, for the project. And so I think that's really important. I have found that when I take time to understand the people I work with in a non-project context, I give them a little more grace during the project. I give them a little more understanding. I, I listen a little better. You know, they get much more benefit of the doubt because I know who they are as a human. Yeah. Absolutely. And I know like, they're not, you know, there's more than likely not, malintentive something's going wrong. Right. Right. And so you can understand how to help with each other's weaknesses and also maximise each other's strengths. Yeah. Yeah. This is something that we focus on on my board as well. It's, yeah. We use the term togetherness, right? There's a minimum togetherness that you have to have for a project to have the correct, yeah, chemistry for it to have the correct level of, of intentionality from all parties and buy in and all of these things. You can't manufacture that. Yeah. There's some level of this that is really just time spent together. And it's whether, even if you have a remote team, you can, you can still accomplish things. Absolutely. Yeah. You know, so absolutely essential. We found that it makes perhaps the biggest impact on, on the collaboration that we have. Definitely not. I can imagine it does. Yeah. That's absolutely correct. So as a UX director, what are some of the things that you think developers can do to help this design, like, obviously we all have our different domains and what are some of the kind of practical things that a developer can do to communicate better, particularly with UX design. So that some of the assumption is cut and we can get to the core of the meaning, the real value in a project. I think, if I were to like give it like a one word thing, I would say participate. And I think what happens is, whether we say we're agile or whatever our process is, I still think we remain slightly siloed and you are design, you are dev. And I try to include, as I can, it doesn't always work because we have a distributed development team, but I try to include a lot of, you know, non-designers in the collaboration process. Sure. And that just helps them understand our wacky world a little more. And I constantly tell and talk to the team like, cool, when you start generating ideas, get development of all the students you can. Because one, I don't think that design holds the standard for good ideas. Yeah, I believe good ideas can come from anywhere, right? And I think that we benefit from various lenses and approaches to things. So in my experience, a lot of developers can tend to be very pragmatic and analytical. And that's a really valuable approach to bring to the process, right? Yeah. I also think that when you just collaborate with someone, you build a shared ownership. And so that's why I would love to see, you know, and I'm jealous of folks who have onshore, like in-house development sometimes, because I'm like, oh, we could collaborate so much more. Yeah. But that would be a participate, be a part of the process just because you don't design, doesn't mean you have to stay out of the process until it's time for you to build it. Right. And again, the other side of that for me is designers invite, right? Like welcome. Yeah. Get out there and let invite, you know, non-designers into your process to collaborate and be a part of that, especially developers, you know? And developers who are listening to this right now, if you were as a team leader, I know some people, in my past, I have created those silos. I've been responsible for walls, or at least partially responsible. So have your superior whoever that would be, listen to this and have a conversation about this, you know, breaking down the walls because you may feel like you don't have the permission right now. And that's, you know, that can be a really tough spot to be in. But for those of you who are managing teams, understand that breaking down those walls is a huge part of your job, actually creating the connections rather than creating the walls is going to yield much better product. Yeah. I do think it is human nature to, like we were talking about, define one another's roles because we try to understand each other better, but really like that classification process. Like we don't, like, there's not two quarters. Right. Quarter has heads and tails. Yeah. I don't pay for something with the head side sometimes and the tail side other times, right? Like it's two sides of the same argument. And that's what design and development really are. And they should be a little more interwoven. Sure. And my idea, I mean, I know that's probably sounds naive, but I'm old. So I've got myself, I've bought myself some lights there. You're allowed to do that. Yeah. So it's like, I do, I, I have an idealist and I, to an extent that I would love to see that, like integration where the design and development teams are interwoven a little more, yeah, a little smoother in between. Yeah. Yeah. And I think that's the ability now, just because of the way we're structured in Hasdeck, which isn't a bad thing. But when I think about like, how would I structure things like if I were like, in an ideal world, how would you build your own thing in a world where design and dev or together, you know, like what I do is I would like, you know, little pods of people sitting, you know, like where people sit, not just in the organization, but like in the office. Yeah. Mm-hmm. Would be together working on projects. Right. And that would be interchangeable, you know, so give me some desks with wheels. And we'll get designers and developers and product folks together and sitting in the same space. Yeah. And then as they don't work on those projects anymore, we'll swap them out and send them to people so that they can be almost like side by side like, what are you? Okay, I got this. You got that like, like, like, like, like, one of those co-pilots, right? Uh-huh. Like, like, the co-pilot doesn't sit in the back of the plane. Right. Waiting for his instructions from the pilot. Okay. I took us off. You land us. But it doesn't work like that. No. I think that integration happened more. You know, I'm anticipating my audience's response to what you're saying right now. There's two main responses to what you're saying. One is the people who've already done this. Yeah. And they've experienced what it feels like to work on a multi-disciplinary team. And they're all shaking their heads. And they're wishing other people could experience because it feels like, you know, magic almost when you get the chance. But then there's the other group of people. The other group of people are the developers like I used to be where I would like to close a door. I would like to put my headphones on. Yep. I'd like to turn the lights off. And I don't want you to ever knock on the door or interrupt me at all. Yeah. And it's easy to get to that place because you feel a sense of flow, of the sense of zone. Uh-huh. And there are times where that flow is important and where that isolation and focus is important. Absolutely. But on the flip side, if you're always isolated, then your work is going to show that isolation. Yeah. And it's going to be exactly what we're talking about in just any connection. It's going to last any connection. Yeah. Yeah. Yeah. You will have to make assumptions. Yep. You will have to, you know, have that cold interaction with people. You'll never get that personal interaction. Yeah. I think, I definitely think you can still have that, right? Yeah. You know, if, if there's a, a little pod of like three, four desks together and someone needs that heads downtime, put on the headphones, throw a red sticking note on the top of your monitor and go to town. Right. And I know that when that comes down, unless, you know, I leave you alone to get that done unless you really, unless there's something really pressing. Mm-hmm. But even then, it's like, I'm going to send you a message and wait to respond. I'm still not going to lean over and interrupt your process, right? Right. So I still think you're going to have that heads downtime. And designers need that too, you know, like, like, like, thinking through a design and tackling it or, you know, just banging out screens sometimes, you know, it's like, you need to get in that groove and make progress. Yeah. So that's okay. Mm-hmm. Or, you know, get up and go to another if you have the opportunity, go sit in another part of the office for a little bit to get that momentum. And then when you feel like you've made some progress, then come back to your desk and then they know you're available, right? Yeah. Exactly. So it can work. And I understand that need though. I definitely understand that need. Yeah. And I don't want people to think that we're saying, you know, throw that out, right? Right. Exactly. Because there are benefits to that extreme focus and the extreme version of, I'm not extreme programming. I'm not going to talk about that today. But that extreme version of focus. Yeah. But yeah, I think it's important to stay dynamic. It's important that we do break down those walls and it's the only way to remove that assumption. Yeah. And to help the, to avoid going sideways in the first place. Yep. Right. Exactly. Totally. And when you see that happening, going sideways, you know, one of the first things you can do is fix the things that you didn't do right in the first place. Yep. Right. Go ahead and walk through that clarification process. Yeah. Figure out, where are we? You know, I was talking to another person I can't remember who was recently. They were talking about walking up a mountain and each of your job on this project to walk up the mountain. And one of the first things they do when they evaluate, you know, when they're coming in to help someone with the project, the secondary person coming in to help the primary developers or something. The first thing they ask is, is where are you? Where are you on the mountain? Yeah. Did you just now start? Do you have blinders on? Are you like walking up a different mountain all the way? Right. Yeah. On the middle or near the top? Are you potentially almost done? You just need that last little push. Yep. Understanding that, positioning and really getting a clear picture of where things are in a project is incredibly important. Yeah. One of the things too, when a project, if you think the project is starting to go sideways, a really great first step is to ask if it is. Yeah. Right? I know that sounds super basic. That's really good. But it's like, hey, guys, I think this is going a little off. Am I any like wrong in this assumption, right? Yeah, like again, it's validating an assumption. Right. And then you say, okay, cool. Because you need everybody on board with the same thing, right? They do. And you're not, definitely not at that point. You're not like pointing fingers. We're saying like, something feels off. Am I correct? Yes, no. Obviously, no, fine. We're good. Yes. Cool. How do we fix it? I have some ideas I'd like to hear yours first. Yeah. Yeah. Because we want to avoid that defensive nature. Because as soon as someone thinks something's going wrong, they're going to get like, whoa, it's not me. Right. We know, we know, go down. It's okay. So that's why you let them share what they think might be going wrong first and then like compare notes, right? Yeah. Yeah. Like even write it up on a board and then, you know, you could, or what I like to do is I don't like to, there's this love like, um, diversion thinking where if we're both going to try to figure out what's wrong, I write down what I think is wrong. You write down what you think is wrong. And then we share those ideas. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Absolutely. Don't put it out there. It's a very, very common psychological issue is conformity, right? If you were to take two surveys and the first one, everybody sees the results as they come in and the second one, everybody doesn't, then typically you're going to have a lot more conformity, either to one spot on the survey or to one of two spots on the survey, right? That, that, that, that section, but that's good. Yeah. Great. This has been a fantastic interview. Yeah. We're running, we're running close on our time here, but I do want to ask you two questions. I ask everybody who comes, a whole, who comes on the show. The first question is, what do you wish more people would ask you about? It can be anything. Doesn't have to be related to this. Barbecue. Barbecue. I love to cook. So that's like my favorite things. We had a great answer on the panel. It was a coffee. Coffee. Yeah. Just a little bit. Very simple. Yeah. Yeah. Some people give answers like barbecue. Yeah. Yeah. So have you been to here in Dallas? There's a place called Hard 8. I was actually going to try to go there for lunch today. It's a, you should go. I've been there. We try to make it every time we come and then I'm fortunate that we're not going to be able to go. Yeah. I'm like a praise hand emoji place. I heard. Yeah. That's incredible. Just your eyes will be bigger than your stomach unless you want to expand your stomach. Lots and lots of meat. Not certainly not a good place for the vegan population, but very good. I'm sure there's enough cardboard for them to eat. They'll be fine. So barbecue. So if you see Aaron instead of walking up to him and asking him what it's like to work at NASDAQ, ask him about barbecue. Yeah. I much rather, much rather talk about barbecue than work any time of the day. Anytime. That's great. In the second question that I like to ask everyone who comes on the show, if you had 30 seconds to give every developer regardless of their experience level, just a little bit of advice, what would you say? I think it's to that thing I said earlier about participate. And then lead your participation by listening so that you can learn and participate more effectively. And I would give that advice, doesn't matter what your skill set is, right? And I think that becomes really helpful in bridging our self-imposed divides between design and development and all of that, right? Listen and participate and be willing to be wrong. I don't like that answer a lot actually on this show. Yeah, I don't like being wrong, but I like being wrong because then I learned something. So I like being wrong in hindsight. Yeah. I don't like it in the moment at all. But after the fact, when I learned something, it's good. So I think that's where listening and participating really come together. I think they have to be joined together. Yeah. Because if you're not willing to listen while you're participating, you're not going to participate as effectively as you could. Yeah, absolutely. Fantastic advice. Thank you so much, Aaron. Thank you, Robin. It's great. Thank you again for listening to today's episode of Developer Tea. Thank you to Aaron Erzari for joining me on today's episode and for discussing all of these critical things that are very often so difficult to solve and to talk about. Thank you again to Aaron. If you haven't checked out Dolby's offerings for iOS, I highly recommend you go and check it out, spec out of them. Slash Dolby iOS. That's D-O-L-B-Y-I-O-S. I always want to hear more from the listeners of the show. I want to know more about who you are, what you're going through. You can always email me at Developer Tea at gmail.com. But I also just launched a survey. It's just a simple Google form. It's totally anonymous. And I would greatly appreciate if you go and check it out. You can go directly to the survey by going to spec.fm slash developer. That's spec.fm slash developer. Thank you so much for listening. If you don't want to miss out on future episodes, open up your phone or your computer or whatever you're using to listen to today's episode and click subscribe. This is a function that all of your devices should have and it helps you be notified whenever a new episode comes out. A little pro tip. You may want to go into the settings and reduce the number of episodes that you keep downloaded on a given basis. It's good that you automatically download episodes so that when you don't have good service, you aren't streaming using data. Typically you can download it directly using Wi-Fi. But if you end up downloading and keeping every episode, then your phone runs out of space. It makes it very slow and frustrating. So I recommend going and checking on those settings. That's a little pro tip for you podcast listeners today. Thank you so much for listening and until next time, enjoy your tea.