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, or maybe you have an us versus them sentiment 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 Irizarry. Aaron is the director of UX at NASDAQ. So we're going to be introducing Aaron shortly. My name is Jonathan Cottrell. 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 out, you're not going to be a great developer. 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. And this is the second interview. I'm going to get out of the way so we can talk to Aaron Irizarry. I'm here at Squares with Aaron Irizarry, the Director of UX at NASDAQ. And I'm really excited to talk to Aaron. Aaron has been kind of an iconic face around the conference this year. He's been front and center at pretty much every talk. And I'm really excited to talk to you, Aaron. Thank you. Thank you so much, man. Thanks for having me. Can you talk a little bit about the talk you gave here at Squares? Yeah. It kind of came from just experience at work, right? And I think some of those talks like that resonate. So it really came from working on a few projects that really went sideways and did not go as they should. So the title of the talk, what was it? Oh, yeah, yeah, yeah. Hold Fast, Managing Design Teams When Projects Go Sideways, right? Sure. And so... That happens. All the time. And we pretend it doesn't, right? We're on Twitter and social networks talking about how great everything is. And we often don't talk about some of the frustrations we face. Yeah, sure. 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, exactly. And so that's kind of how that talk came. We had a project that went really terrible. And I just started taking notes. 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. So what are two or three ways that a design team can go sideways? Or maybe four or five. I don't know. Yeah, I mean, when we get in the middle of projects, you know, people, I think one of the worst things that happens. 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 what happens is we have communication breakdowns and not, people are not having the shared understanding of what they're trying to do. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. designers put on a beret and a scarf and get really mad when people give them feedback on their work right like that also starts to become a problem because they think they know everything and they're not listening to uh 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 that everyone 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 a 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 uh yeah a bunch of developers uh sitting around you know bashing on designers but oh yeah for sure certainly the same thing can happen with developers developers think they know everything and and uh they end up causing problems because you know not only are we assuming very poorly yeah uh we're also you know approaching something from the perspective that everyone else needs to listen to me yeah yeah like i i'm 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 um because really like my context is design and that's just because that's what i do right yeah um i think this goes beyond uh whatever your skill set is it really comes down to how people work together to achieve a goal yeah and and what do you do when that starts to to fall apart yeah and so you can do that with a lot of different things right and uh 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 um i 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 to accomplish something and so we 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 kind of bridge that gap and like realize that we're 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 gonna use a yeah a good illustration uh it's the the concept that the you know there's good and bad things about titles uh we this has been a hot topic recently we talked about it here at this conference but you know when the title creates a wall um within a team when it creates difficulty within a team um then step back and see what things are like if you remove the title yeah at least give that a chance right yeah well you know i and in 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 my thought i mean i definitely don't think on its face that everyone is a designer and i understand at its core um and i think that's a really good point and i think that's a really good point because i think that's a really good point because i think that's a really good point there is some value there where at least what i'm thinking what i'm hoping is that they're pushing for inclusion right in the process sure 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 yeah like your skill set is different for me and that's good right because if if not we become an echo chamber right it's all of us saying the same things and there's no diversity there's no the value of diversity is it provides different angles and lenses to the things you're trying to do and so that's where I think, yeah, I get saying everyone 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. Or by their title. The title doesn't matter. And that's, again, that's, that really is the, the, the key phrases, uh, inclusion and title are not, uh, are not, you know, coincidental. Right. Right. Um, and also, you know, that discussion is also largely, I think it was about the, 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, uh, you know, uh, the fact that, uh, I mean, we hear this all the time. Right. And I'm not, I'm not even going to make a comment on, on what I think it is because it really isn't super valuable to, to pontificate for hours and on. Yeah. That'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 team. Yeah. 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. Like you may. And, and, 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 at a company doing UX and I was the web master web project manager. Right. Nothing to do with the work I did, but that's how the organization classified what I did. And it was 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. It's not bad. And there's work on the table. And so the, the, it's the classification problem, right? We have this fallacy believing that if we classify something that somehow it becomes stronger, right? If we, 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 then, you know, we have all these fights about whether parallel is better than hierarchical. And, and it doesn't, it doesn't really, really we're just trying to explain how we work rather than, you know, 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. Yeah. I think I've always kind of thought, and I don't, I don't know if this is entirely, it's just like, 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 and not fully understanding something. Right. And so we have to define it. Yeah. 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, that's human nature, but I just, I'm not, I don't really need to control this. I just need to do it. You know, like 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, 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. 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. They care about the work. They're like, okay, cool. Did you fix my computer? Yeah. No, cause I don't do that. I'm a designer. Right. Like it doesn't matter. You know, did you fulfill your, your role for the day? I don't, I don't know. Maybe. Totally. So I want to kind of hyper focus in on one word that you said that I think is so important is assumption, right? Yep. This concept of assumption. And I'll, I'll lay out an idea and we can, you know, 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, the hardest, the hardest jobs that we have because you know, when I say useful assumption, uh, this is, this is what I'm talking about as we're talking here, we're using a shared language, right? Yep. We've never sat down and had an interview before. Right. Um, 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, yeah. Um, we can, we can communicate back and forth and come away with a reasonable expectation that we were sharing the same ideas. Yep. Yep. Um, and that reasonable expectation is really an assumption. It's, it's a strong assumption because our language is defined outside of the two of us. And, 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, in a, in a organization, especially in a project. Yeah. Um, when you say, uh, application for example, or when you say, uh, um, even some of the words of technology, like some of the, the definitions of technology that you're going to use JavaScript, that means a whole different thing to another person than it means to you. So, uh, 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, 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, um, 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. Yeah. Um, 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. 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. Cause that's how 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, 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, cause 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, you're going to get to a point where you're like, we are not on the same page. Yeah. 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. It can go really bad. And I think it's, it's, it's like a design thing, right? Like, like you said, a positive assumption is I think this is what the user wants to do. Right. So what do 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 applies 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 does it in a non, uh, really rate this non, almost like a self-deprecating way. She's like, you know, she always says, I know when it's coming, she'll be like, I may be dense here, but is this what that means? Yeah. I'm like, 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. Yep. 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? Uh, you know, because again, we are different roles. Yep. Like I said, the talk were different people with different roles and experiences and context tasked with building something. And so it's, it's, it's, it's a little silly to think that instantly everything, everything works the way it does for me. Right. Yeah, exactly. That's, that's where, that's where just talking about it and trying to set some defined things about key ideas, principles, and terminology at the outset of a project can really prevent frustration down the line. We're going to pick up on our conversation with Aaron about communication and setting expectations, uh, and different techniques that you can use when communicating with your team in just a few minutes. But first I 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 rerecord. 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 developers to use for their applications. The result is clearer dialogue in your applications. It is multi-channel. So a surround sound in your iOS applications, go and check it out. Spec.fm slash Dolby iOS. Uh, 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 T. If anybody has gone through relational, uh, um, therapy, like if you go to see a therapist, one of the things that a therapist may tell you to do, and this works extremely well outside of, you know, uh, you know, significant other relationship is what they'll tell you to do is when someone is explaining to you, uh, you know, in, in that context, it'd be what they feel, but in, in this context is explaining what they think, you know, this module does whatever, uh, or what they think this particular project is intended to do. Uh, a useful, uh, operation for you as like the responding listening party is to repeat what they said in your own words. Right. Yeah. And so now you've, you've explained to them that you've heard them and you've given a translation. So you've given them a translation, which means that you're, you're now adding a secondary identical, hopefully identical definition. Yep. So there's more, just statistically speaking, there's more reliability between the two because it's a, it's a message sent message received. If you think about the way we do, uh, uh, you know, a browser receives a message that also responds with, with a, with a response code, right? And it gives you an, okay, everything is good. Yep. And so you read both sides of that, of that relationship. Yeah. In our, uh, in the book, uh, Adam Connor and I wrote discussing design. We have a section on that called active listening. Yeah. And it's, it, it is that it's, it's basically same back them. So if I understand you correctly, you're saying if we build a stored procedure this way, we could run into this problem, right? Or if, if we are, you know, if it's, if there's too many calls on this page, like whether it's JavaScript or whatever, like it's going to slow things down and 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. So it's really important to do that. Yeah. I love it. My wife and I just, uh, went to Portland. And, uh, 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, in the same conversation. Yeah. And that little bit of extra, the two little letters behind Oregon, uh, or I'm sorry, behind Portland could put you, uh, on two different sides of the country. Yeah. Yeah. Yeah. Uh, extremely important that, that that happens. And, um, so that clarify 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, and you add more detail through prototyping. You have more detail through, uh, through design, iteration through all of these, you know, technical specification, acceptance criteria. If you want to use that term, there'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, uh, very strangely, a simple coffee meeting with someone to understand some of their, their cultural background can help the success of a project. Totally. Totally. Yeah. Like, you know, that's, that's like, it's, it is, it's like research, but inward, right. And I think that's so important to, 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. Yeah. Yeah. But it saves you down the road. Right. And that's kind of, it's, it's, it's insurance. 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. Um, 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, I give them a little more understanding. I, I listen a little better. Um, you know, they get much more benefit of the doubt because I know who they are as a human. Yeah. And that, absolutely. And I know like they're not, you know, they're, there's more than likely not malintent of something's going wrong. Right. Right. Yeah. And so you can understand how to help each other's weaknesses and also maximize each other's strengths. Yeah. Yeah. Um, this is something that we focus on on whiteboard as well. It's, uh, we use the term togetherness, right? There's a minimum togetherness that you have to have for a project to have the correct, uh, chemistry for it to have the correct, uh, level of, of, uh, intentionality from all parties and buy-in and all of these things. You can't manufacture that. There's, there's some level of this that, uh, is really just time spent together. And it's whether, even if you have a remote team, you can, you can still accomplish these things, you know? Uh, so absolutely essential. We found that it, it makes perhaps the biggest impact on, on the collaboration that we have. Definitely. I can imagine it does. Yeah, that's absolutely correct. So, uh, as a UX director, um, what are some of the things that you think developers can do, um, to help this design? Like, obviously we all have our different domains and, and what are some of the, kind of practical things that a developer can do, um, to communicate better, particularly with UX design. Yeah. Uh, so that some of the assumption is, is cut and we can get, 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 even 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, um, I try to include as I can, it doesn't always work cause we have a distributed development team, but, um, 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. Yeah. And, um, I, I constantly tell and talk to teams like, cool. When you start generating ideas, get development involved as soon as you can. And because one, I'm not, I don't think that design holds, the standard for good ideas. Yeah. I believe good ideas can come from anywhere. Right. Sure. 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. Um, 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, um, you know, and I'm, I'm jealous of, of, of folks who have onshore, like in house development sometimes, cause I'm like, oh, we could collaborate so much more. Yeah. Um, but that, 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. Yeah. And, and I, I mean, again, my, the other side of that for me is designers, you know, invite, right? Like, welcome, 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? Yeah. And developers who are listening to this right now, if, if you were, um, uh, as a team lead, I, I know some people in my past, I have created those silos. I've been responsible for the walls, uh, or at least partially responsible. So, uh, have your, have your, have your, uh, superior, whoever that would be, listen to this and, and, and have a conversation about this, about this, you know, breaking down on walls because, uh, it, you may feel like you don't have the permission right now. And, um, that's, you know, that can be a really tough, a tough spot to be in. Yeah. 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, um, is, is going to, to yield much better product. Yeah. I, it's, I, I do think it is human nature to, like we were talking about earlier, like define one another's roles because we try to understand each other better. But really like, that classification process, like we don't, we don't like, there's not two quarters. Right. A quarter has heads and tails. Yeah. Like I, 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 artifact. Yeah. 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 my, I've, I've bought myself some license there. You're allowed to do that. Yeah. Yeah. Um, so it's like, I do, I, I am an idealist and I, to an extent that I would love to see that like integration where, um, the, the design and development teams are interwoven a little more. Yeah. A little bit smoother in between. Yeah. Yeah. Like I don't have this ability now just because of the way we're structured in Aztec, which isn't a bad thing. But when I think about like, how would I structure things? Like if I like in an ideal world, how would you build your own thing? Yeah. In a world where design and dev work together? No, like I, 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. Yeah. Working on projects. Right. And that would be interchangeable, you know, so give me some desks with wheels. Mm-hmm. And we'll, 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, we'll swap them out and sit with other people so that they can be almost like side by side. Like what are you, okay, I got this, you got that. Like, like co, like one of those co-pilots, right? Uh-huh. Uh-huh. Like the copilot doesn't sit in the back of the plane. Right. Waiting for his instructions from the pilot. Like, okay, I took us off. You land us. You know, like, but it doesn't work like that. No, So I, I would love to see that integration happen more. You know, I'm, so I'm, I'm anticipating my, my audience's response to what you're saying right now. There's, there's two, two main responses to what you're saying. One is the people who've already done this. Yeah. And, and they've experienced what it feels like to work on a, a multidisciplinary team. Yep. 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, when you get the chance. Yeah. 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 the 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, or interrupt me at all. Yeah. And it's easy to get to that place because you feel a sense of, of, uh, flow, a sense of zone. Uh, 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. It's going to be exactly what we're talking about. It's going to lack any context. 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. Well, I think, I definitely think you can still have that, right? Like, yeah. You know, if, if there's a, a little pod of like three, four desks together and someone needs that heads down time, put on the headphones, throw a red sticky 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 till you get to the next level. You get that done unless you really, unless there's something really pressing. 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 head sound time and designers need that too. You know, like, sure. 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. And so that's okay. 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. Like exactly. So it can work. I understand that need though. I definitely understand that need. Yeah. And I, 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 not extreme programming. I'm not going to talk about that today, but that, that extreme version of, of folks. Yeah. But yeah, I think it's important to stay dynamic. It's important that we do break down those walls and, 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, 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 it was recently. They were talking about walking up a mountain. And, you see your job on this project, to walk. Walk up the mountain. And one of the first things they do when they evaluate, you know, when they coming in to help someone with, with a project, secondary person coming in to help the primary developer 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. Are you, are you, you know, stuck on the middle or are you 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, is incredibly important. Yeah. I didn't know one of the things too, when, when a project, if you think the project's starting to go sideways, a really great first step is to ask if it is. Yeah. Right. I know that sounds super basic. Wow. That's really good. But it's like, Hey guys, I think this is going a little off track. Am I like wrong in this assumption? Right? Yeah. Like again, it's validating an assumption and, right. And then you say, okay, cool. Because you need everybody on board with the same. Right. 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, we want to avoid that defensive nature. Because as soon as someone thinks something's going wrong, they're going to get like, well, it's not me. Right. Yeah. Well, we know, we know, calm down. It's okay. So, so that's why you let them share what they think might be going wrong first. And then like compare notes, right? Yeah. You can 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, I love like, um, divergent 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. Because I don't want to be informed by if you put it up on the whiteboard. Right. Yeah. And then I instantly start when it comes to my turn. I, my context is now in everything you've just written. Right. Yeah. And so that, that, that doesn't give me that, you know, I'm, I have a different lens now. Yeah. Yeah. Absolutely. Pump it out there. So it's a very, very, uh, a common cycle. Psychological issue is, uh, 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, uh, then typically you're going to have a lot more, uh, conformity either to one spot on the survey or to one of two spots on the survey, right? That, that dissection, but that's good. Yeah. Great. This has been a fantastic interview. I mean, we're, uh, we're running, running close on our time here, but, uh, I do want to ask you two questions. I ask everybody who comes, who comes on the show. Uh, the first question, uh, is what do you wish more people would ask you about? It can be anything. It doesn't have to be related to this barbecue. I love to cook. So that's like my favorite thing. So we had a great answer on the panel. It was a coffee coffee. Very simple. Yeah. Yeah. Uh, some people give, some of the answers are like barbecue. Yeah. So have you been to here in here in Dallas? There's a place called hard eight barbecue. I was actually gonna try to go there for lunch today. It's a, you should go. Yeah. I'm going to go. I, we try to make it every time we come in there. Unfortunately, we're not gonna be able to go. Yeah. It's like a praise hand emoji place. I heard. Yeah. That's incredible. Uh, uh, just your eyes will be bigger than your stomach unless you want to expand your stomach. Um, lots and lots of meat, not certainly not a good place for, uh, for the vegan population, but very good. Very good. I'm sure there's enough cardboard, for them to eat. They'll be fine. Uh, so, so, so barbecue. So if you see Aaron, uh, 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. It's great. Uh, and the second question that I like to ask everyone who comes on the show, um, if you had 30 seconds, uh, to give every developer, regardless of their experience level, just a little bit of advice, which, what would you say? Um, I think it's to that thing I said earlier about participate. Yeah. Um, and then lead your participation by listening so that you can learn and participate more effectively. Yeah. And I would give that advice. Doesn't matter what your skillset is. Right. Um, but I think that becomes really helpful in bridging our self-imposed divides between design and development and all of that. Right. You know, listen and participate and, and be willing to be wrong. Yeah. I like, I don't like that answer a lot actually on this show. Yeah. Like I don't like being wrong, but I like being wrong because then I learned something. Yeah. Um, so I like being wrong, like in hindsight. Yeah. Yeah. I don't like it in the moment at all, but after the fact, when I learned something, it's, it's good. It's so, I think that's where listening and participating really come together. I think there, they have to be joined together. Yeah. Cause 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. Oh man. Thank you for having me. It's great. Thank you again for listening to today's episode of developer tee. Thank you to Aaron, Arizona 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. Dot 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 tee 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. Dot FM slash developer. That's spec. Dot 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 and 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.