What are your users doing? Like, who are the people who are using your product? What are they doing their day-to-day lives? Not how do they interact with their website? But are they grabbing a cup of coffee and then thinking about sending money internationally? Or whatever it is, you know, actually tying back to real people and real interactions? Because again, so often, and this even happens to me from time to time in my daily life at work, is you can get so separated from the people you're trying to solve problems for. And so I think books like that or reading techniques and stuff try to really challenge myself to think, how does this relate back to the end user from a real person standpoint? I found really refreshing. Hey, everyone. Welcome back to Developer Tea and part two of my interview with Joshua Aziz. And that's who you just heard talking a moment ago. Thank you so much for listening to today's episode. Developer Tea is intended to help you as a developer uncover your career purpose. That's my entire goal here on the show. And really, the goal that I have set out in all of the endeavors that I participate in. And so I hope that this show helps you do exactly that. That's what I drive at with all of the guests that come on the show. And that's really who this show is for. People who care to dig a little bit deeper, do a little bit harder work. The work that requires you to look at yourself, to evaluate yourself, understand yourself enough to be able to change your opinions, change your behaviors, change the patterns that you participate in. So that's the stuff we're talking about on this show three times a week. So I hope you subscribe if you fit that description. I'm going to get out of the way and we're going to talk to Joshua Aziz. This is part two. Make sure you listen to part one. If you don't want to be a little bit confused, thanks again to Joshua for joining me on the show. We as developers and product managers and, you know, agile coaches and all of those roles that we fulfill, we very often forget that the first role that matters is the customer. And if we forget to actually put ourselves in their shoes and walk through that whole experience, not just the subsection that we have some control over, but the whole thing, you know, we can't assume, for example, that people have a clear perspective of the product that we have created, just because we understand where everything is, or just because we know what, for example, what transfer wise does, doesn't mean all of our users do. Even people who actively engage, even people who actively use the application, people who listen to this show may not even totally understand, even though I've reiterated it, some people may not totally understand why this show exists. They may not understand, you know, why are most of the episodes short, for example, right? And, you know, establishing that user journey, the long frame user journey and understanding it as a person who is implementing and working on behalf of that user, that's essential, in my opinion, I think in yours too, Josh, that's essential to succeeding on behalf of the customer. Yeah, that's right. I mean, if you, most, I'd like to think that most engineers and product managers and other roles, purposes at the end of the day are to ultimately better serve customers, that's why we like building things, that's why we love to make things better. And I think you're exactly right, the best way to get closer to that is to really, really understand the users from one side to another, walk in their shoes, take away that bias of knowledge that you have every day because you know the ins and outs of your product, but maybe you don't understand the context that someone's going through or how their day's going and how that impacts how they use your product. And yeah, I think that's great advice. And when this comes to actually implementing, we discussed before the show this idea of volumes of voices. And I love for you to kind of speak for a moment or we can kind of open up an open discussion on this topic. But the idea that when you're working on a team that's trying to understand and serve customers, first of all, you mentioned that the person who's closest to the customer needs to be the one that's solving the problem. Can you kind of expand on that idea? Yeah, so usually when someone goes to solve a problem, make a decision the way it classically works in an organization or in a team is the bigger the decision is, the higher up the ladder it goes, right? So if two engineers are trying to decide an approach to something, they to agree on that approach they talk to their engineering lead and that engineering lead, okay, is it? Or about what priority we should work on next? Maybe that goes to the engineering lead or the product manager, or if it's a big enough priority, maybe it goes to that person's lead. And well, you notice is a lot of these problems that you're trying to solve, the person making that decision is potentially several steps away from the actual customer, the people who are talking to them day to day, the people who are building the product that impacts them day to day. So the way we handle that at least are transfer wise is by flipping it on its head and saying, if the engineer is the closest person to the problem that a customer's facing, they should be the one solving it. Or if someone in customer support is talking to users every single day, we should be letting customer support help figure out what our priority should be, right? If you have someone in an office who's never talked to a customer before trying to help make decisions and trying to solve problems, they're never gonna do it as effectively as the person who's that much closer. So I think it's just a good personal mantra to take on, even if you're the company you work for or the team you're set up with, doesn't have that luxury of passing all decisions down. Just think of that within your own team amongst each other, right? Who's closer to this problem? Is there someone who could help be even closer to the user to solve this problem? Yeah, and I love the reality that's presented there that as problems become bigger or more important or more waiting as it relates to the money that's involved in that particular decision, that they go up the chain. As of somehow, that management structure gives you a better decision power. And while there's something to be said for experience levels, right? And experience with making decisions that are effective and strategically effective, I guess, is the best word for that. Being close to the problem is at least equally important. Would you agree with that? So I guess that's more of a question. How do you treat experience of that particular individual? Because generally, experience typically follows that same line of going up the chain, right? The longer you've been doing this, the higher up the chain you go. So, of course, experience, well, I guess not, of course, but arguably experience allows you the opportunity to learn from mistakes. And so those who are less experienced, they may not have had that chance. So how do you balance those two things? Do you allow those experience voices to come in and provide direction? How does that work best? The way I've found it works best in terms of getting your team closer to their purpose of their mission and at the same time helping people to grow is, if you're someone who's experienced, so myself, I have a lot of experience in data insights and talking to users and kind of trying to extract, what are the real problems they're facing day to day? There may be a newer team member on my team, an engineer who hasn't really talked with users that much, or someone in customer support who hasn't really learned how to pull data or write SQL or something like that. Now, I could use my experience and say, guys, I got this, I'll make all those decisions, I can solve those problems. But when I take a step back, I see, if I can teach and help this person in customer support grow and learn how to pull data and get data insights, they're going to be able to do their job 10 times more effectively. And on the flip side, I'm not going to have to spend as much time on that stuff or make those decisions I no longer become a bottleneck. So I just 10x the impact I can have on the company or on the engineer's perspective, right? The engineer is further away from the user instead of always having them rely on someone more experienced, show them the way and help them grow. And I feel like at the end of the day, that helps me reach my personal purpose and mission at work even more so. And it helps someone grow and feel great about working at the company they're working at. Yeah, this is such a great perspective because really what this means is empowerment first, right? That's kind of the heuristic is if there is a way to give this opportunity to someone who can learn and execute simultaneously, rather than someone who is only going to be executing because they're experienced or whatever, giving the opportunity to someone and saying, hey, you know what, if you fall, if you can't accomplish what you're trying to accomplish, I'm here to help. That's my role right here. It's to support you as you learn and support you as you execute on something that's relatively new to you. But if you never give them that opportunity, if they never have that moment where they're kind of pushed beyond their comfortable limit, then they're not going to get stretched any further and you're not going to let go of those keys and that will be the bottleneck, that will be the cab in your team or in your organization. Yeah, exactly. I think it's also important to set those expectations as well, you know, when we're all learning to ride a bike, when we're a kid and our parents, you know, push us on our bike without the training wheels, they help set the expectation that like, look, if you fall, we got the band-aids, you'll get that up on the bike, you're going to be fine. And it's fine, we're not going to take the bike away. And I think it's the same thing with your team, you know, yes, give them the opportunity to fail, but also have blameless approach to that sort of thing, you know, I think a lot of people when they're approaching something, they're worried, I'm going to screw this up and then they get really stressed out. But if you help us at that expectation that like, we're here to help, you can make mistakes, we build fast and learn and we fail. That's the best way to grow and get more experience. Right, yeah. And so that idea is well supported by research as well that learning happens best in low-stake environments. In other words, if you fail, you know that the consequences are not threatening. We have to take away that sense of extreme threat for people to feel the sense of experimentation that's needed for learning. And so if you say, hey, you know what, you have a support system here. It may hurt a little bit, it may feel a little bit frustrating. You may actually go through, you know, you may lose a little bit of productivity and you may have to spend an extra hour at work that day or whatever the thing is, right? There may be a consequence, but it's going to be small. This is not, your job is not online here. If you fail this little task that I'm intentionally giving you because it's outside of your normal limit. And so the research is actually pretty clear on that. There's some research on learning, there's some research that's been done on experimentation and actually more specifically on loss of version. And if you encourage someone by removing that or at least giving the bias kind of a kick in the other direction and saying, hey, you know what, the potential gains far outweigh the potential losses here if you end up learning from this. You know, that kind of reverses that issue of the loss of version. And again, you know, the research on learning says that that low stakes environment is the most conducive position to be in for learning. So, and what ends up happening is, if you don't have that environment, if you don't have that set up, people will fall to the things that they have, the most control and predictability with. And very often that means learning very little. Most of us learned and failed when we were trying to figure out how to get a job, right? A lot of what we did, especially as developers, we would do side projects and we'd have to try, try, try, try, try, we do a freelance projects that was at the edge of our limits because there's nothing to lose. We didn't have a job, we didn't have security, we didn't have a salary, we don't have a lot, you know, at stake. And so that environment is actually low stakes, even though the consequences are similar to a high stakes environment, ultimately it is low stakes because we just don't have, we haven't gained a lot at that point in our careers. But once you get a job, once somebody has secured a job, now that protective mode is going to kick in, and it's going to be very hard to encourage them to learn in a high stakes environment. You can also remove some of that loss or kind of lower the stakes in terms of helping other people grow as well. I think something that can relate a lot to engineers is the concept of a post-mortem. You know, something goes wrong and something goes wrong at every company, right, or in every project. And depending on the environment, or in people are afraid to share. But I think when things go wrong like that, when it's to the point where you probably should be emailing the entire engineering team, or just your own team and kind of fessing up, hey, you know, something went wrong. If you can set a low stakes environment there, you're going to help so many people learn. So at TransferWise specifically, and I think this is something other people can take into their own companies and projects, we have blameless post-mortems. Everyone's encouraged you right on, and you see sometimes multiple a week depending on the teams, and what they were building. And I think it helps everyone at the company, even non-engineers, to learn even more, and have clarity, and it helps those other engineers, like maybe the ones who cause those issues to happen and having to write that, to maybe feel a little bit better about, yes, sure, something went wrong, but by highlighting this thing, and highlighting how we could tackle a better next time, it's going to make me feel more confident. And I'm going to teach hundreds of people, potentially, how they can grow from this environment, and that also encourages those people to kind of think that blameless thing happening in the future as well. So I totally see your point that, if you can have a lot of impact with low stakes, or at least set up the environment for low stakes, that goes a long way. Today's episode is sponsored by Linode. Linode provides hosting. You've seen plenty of companies that provide similar services, similar technology, perhaps inferior products overall, but mostly similar. There's other companies there in the space, so why would you choose Linode? Well, first of all, Linode has proven that they care about developers. They're one of the longest running sponsors of Developer Tea, but it's not just that they care about developers. They actually have quite a few developers who are working on their products. Developers who are creating new products, like for example, block storage. This is something that's in a public beta right now. You can go and join it on Linode if you already have an account, but they also have things like a CLI. Command line interface for managing your servers. And this CLI is actually open source. It's available on GitHub. There's tons of evidence of Linode caring about you as the developer. And on top of all of that, they make their products incredibly affordable. So you can get spun up on a one gigabyte of RAM server for $5 a month. This is honestly cheaper than most fast food meals these days. $5 a month, less than a price of a hamburger and a coke, essentially is what we're talking about here. Can get you an excellent server that you can start running experiments. You can run your personal site. You could do your own private Git server. Anything you can do on Linux, you can do on Linode. Now here's what's really cool about that. If you go ahead and get set up on Linode and you develop your own procedures, your own scripts, your own wrapping scripts with their CLI, and if you develop a relationship, for example, with the community that's already using Linode, then if and when you need to scale up, you have the support of that community. It's a really interesting prospect because it's not just the cold computing box that's sitting somewhere in a server farm. It's also the people, the community that surrounds Linode that makes it the product that it is. So I encourage you to go and check it out. Spectre.fm slash Linode, you can use the code Developer Tea 2017 to check out. Linode's gonna add some icing to the cake. They are going to give you $20 worth of credit just for being a Developer Tealistener. This will pay by the way for four months of that one gigabyte of RAM server. Or anything else that you choose to put it towards. Thank you so much again to Linode for sponsoring today's episode of Developer Tea. I love post mortems and this is something that happens, you know, if you do like, I don't know if you guys, I don't know what you framework or whatever methodology transfer wise follows, but this is something that you can do in agile, you can do it really in any kind of environment because it's very simple ceremony, right? You gather people together, you look at what happens, you know, one really effective thing to use is the five wise, which is, it was actually developed by Toyota. And the idea is to find the root cause for a failure. So you ask why until you get to that root cause for the failure, if you, you know, you may find for example that you ask why enough times and the developer says, oh well, I rushed on that. And a lot of people stop there. They say, okay, well, you know, don't rush, don't rush anymore, but they haven't really uncovered the real problem. They haven't uncovered, okay, you rushed. Why did you rush? Right? This is a question that is very often missed by management. We try to correct the behavior rather than understanding the reason for the behavior. And, you know, if you were to ask why did you rush, well, because my kid's birthday party was that night. Well, that's, that's a really good reason, right? Maybe we could have handed that to someone else. Maybe there was a good handoff moment. Maybe we could have, you know, worked on that a little bit earlier or delayed by one day and avoided this failure altogether. Yeah, definitely. I think that's really important. I think it also helps to uncover the five wise can help to uncover maybe some of the issues in your company or your team's culture. I think that stuff doesn't come out. Oh, yeah. You know, you do your, your end of your sprint retro when people talk about their ups and downs. But a lot of times it doesn't get to that root issue, which is something that might actually be much bigger that you can have a lot more impact fixing. Just like you said, you know, maybe, maybe things didn't need to be so deadline driven, but there's been this culture that's been created in the team where engineers feel like, if I don't get it done tomorrow, I'm screwed. I'm going to be in so much trouble. I'm not going to feel great about what I'm doing. And, and that culture is there in the background and it's hard to see. But if you had asked those five wise, you might have uncovered that and you can, you can help separate expectations and make people work a lot better together. Yeah, it's very interesting. You know, if you continue asking, if you ask six or seven wise, you might get to somebody saying, because I want to feed my family, right? There's some really some deep things that can happen when you go down that chain. And for a company, you know, you may hear things like, because I don't trust my teammates, that may be the end point. And you realize, hey, this deep, deep rooted issue is that we have developed a culture that breeds mistrust. It's not that we have people who are rushing and they shouldn't rush. They're rushing because X, Y, and Z, right? Because they don't trust each other and they don't believe that their teammates are going to deliver on time. Or, you know, they don't trust each other to give them the thing that they need on time, right? And there's a myriad of these deeper cultural issues like you mentioned, the deadline issue, well, I don't feel safe. I don't feel like my job is secure because I don't really know what happens if I'm late on a deadline. Nobody's ever told me what the real consequences are. Well, okay, now as a manager, or as a team architect, if you want to call it that, I can say, hey, this is what happens when we're late. This is what happens to us as a business and this is how that affects you as an individual worker in that business. I love the point you made about trust. I think it's surprising to see how many issues within a company or within a team or within a side project ultimately come down to, people just not trusting each other. We spend all this time and energy and money like hiring people into companies and then people don't trust each other. So I think you can solve a lot of problems by just empowering each other and trusting each other. We say at Transurizer, we say we hire smart people and we trust them, right? Back to the point of empowering people on the team. The engineers on my team are really smart people and I trust them with my life. Why not trust them to make some of these decisions and have an impact on customers and do the right thing. But if that's not a part of your culture is not a core part of your culture, it can lead to a lot of frustration and maybe not the best effectiveness. So I think question yourself in your day-to-day work. Do you trust other people on your team and if you don't, why not? And how can you help to shift that culture? Yeah, absolutely. And there's so many answers to that question. We're obviously not gonna get to all of that in this episode, but starting by being inquisitive and curious and genuinely caring about the answers that you get. Don't stop asking those questions if you just for the reason of feeling a little bit uncomfortable. This stuff is not easy to deal with. It's like kind of, it's kind of like exercise. It's not gonna be comfortable, but ultimately it is the thing that will be good for you in the end. And not just good for you in a holistic sense, but good for the people around you, good for your efforts. Your efforts are going to be much more effective if you actually go through these processes. And a dealing with humans is not something to be optimized. It's not something to be shoved away into a corner and minimized as small as possible. That's not the point of the optimization stuff that we do as developers is not to abstract away the humanity in the work that we do. Instead, the optimization should be creating space for the humanity in the work that we do. And if it's not doing that, then we're gonna go off track. We're gonna end up with people who don't trust each other because they see themselves as being optimized. They see themselves as modules in a system, for example. So Joshua, I have two questions that I like to ask every guest that comes on the show. And the first one is pretty simple, what do you wish more people would ask you about? That's a great question. What do I think more people would ask me about? I think something that I wish more people asked me about was, which is a question I try to ask a lot of people, is how can I help you do your job better? How can I help you have a bigger impact in what you're trying to do? And the reason why I wish people ask this more is a lot of people wait around till their yearly feedback session or they're going through the cogs of official HR feedback and finding out ways they can improve. And I think if everybody asks each other, how can I help you do your job better? It can highlight things that maybe they weren't aware of or ways they could work better together. And I think it just can open up a conversation that's really helpful between two people that doesn't always happen. And it's hard if you're the only one initiating that or it always feels like it's coming from one side. And so I think that's a way people can grow more. And that's something I love to do is help people grow more. And so more people ask me that, I might be able to help them grow. Yeah, that's really good. I actually have these kinds of conversations with Taylor, the CEO of Whiteboard on regular basis. And one of the questions that I asked him that's very much in line with us kind of thinking of kind of stirring up the thinking by your job. I asked him, hey, tell me one thing I should do more of and one thing that I should stop doing all together, that I'm doing today that I should stop doing all together in more specifically for managers out there who are watching on to this idea and taking notes. I was asking him for something that I was doing intentionally, not like a behavioral issue or anything like that, but rather something that I was putting energy into on purpose that he feels like I should stop putting energy there and put it in this other place. And it's actually an amazing kind of eye opening experience to hear somebody articulate to you what they see and you doing, right? Yeah, it's uncomfortable, but it's also extremely effective in opening your eyes to your own strengths and your own kind of effective work that you do or ineffective work that you do. One of the things that he told me to do is stop trying to sell anything. You're not going to do well selling and that's okay. Like it's your role here and the things you're going to do well here, it's not going to be about selling. And so it's kind of flipping it on the head, hey, how can I do my job better? Very similar kind of question though. Yeah, definitely. I think that stuff's important because it can uncover stuff that feels uncomfortable, but how else would we learn if we're not uncomfortable? Yeah, I mean, it's basically saying, hey, tell me what's in your head. Yeah, right. Yeah. So the second question I'd like to ask Joshua and this is kind of a summary question. If you had 30 seconds to give advice to all developers, developers of all backgrounds, all experience levels, what would you tell them? If I were to give advice to any developer out there, I would say, do you know your purpose and what you're working on? And if you don't, figure out what that purpose is. Empower the people you're around with to help you reach that purpose but also reach their own personal purpose. And make sure everyone in the room has an equal voice. Don't worry about titles. Don't worry about who has experience or who doesn't. If you can make that all equal, you're gonna make an even better product at the end of the day. Joshua, that's excellent advice. And I hope that the people who are listening to show that they're inspired and they're challenged by what you've shared with us. Is there anything else that you'd like to kind of share with developers in any place they can find you, follow your work online, anything like that? Definitely check out the Transferwise blog where we have a bunch of posts on Medium that are similar content to this that I think people can take and apply to their own jobs and companies or if you're starting up your own company, there's some great lessons in there. So you can check out ideas by Transferwise on Medium or on our blog. And yeah. Awesome, thank you so much, Joshua. Thanks so much for having me. And thank you for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Linode. You can get started on Linode in just a few minutes and you'll get $20 worth of credit when you sign up today, Spectat FM slash Linode, use the code Developer Tea2017 and check out. If you don't wanna miss out on future episodes of Developer Tea, including all of 2018, we've got a lot of awesome content planning that is happening right now for the new year. Really excited to move into the new year with everyone who's listening to this show. And if you don't wanna miss out on any of that, then make sure you subscribe in whatever podcasting app you prefer. And do that real quick before you move on to the next thing. That's gonna help you not forget and miss a bunch of episodes. You'll get behind, which is really easy to do. We release three episodes a week and a lot of people end up getting behind because they forget to subscribe. So, encourage you to subscribe. Thanks so much for listening. And until next time, enjoy your tea. Bye.