Turning Feedback into Future Success - A Guide for Developers

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are Continuing Up Season where we're talking about the developer journey and we're sort of continuing from last episode. This time we're going to talk about once you've won your first project, once you've completed your first project or honestly any project, how do we get feedback? What do we do? How do we take that and spin it into more work, into the next project that we win? But before we carry on, I want to introduce myself. My name is Rob Broadhead. I'm one of the founders of Develop-N-Or, also known as Building Better Developers. It has its own story, how we got there, and a founder of RB Consulting where we do software development, custom and also integration stuff. So we simplify, integrate, automate, make your life easier, get rid of technology sprawl and all of the things that happen that are not positive when you've got like 40 different applications that you're trying to deal with. On the other side is just one application you have to deal with and his name is Mike, but he's going to introduce himself. Hey everyone, I'm Michael Milosz, founder of InVision QA and co-founder of Develop-N-Or. We're at InVision QA. We help businesses analyze, understand their current technology stacks, help build custom software, and we also help write integration tests and testing tools to help make sure that their software development is clear and that you release quality software without bugs. Well, we're going to release a quality podcast with two bugs talking for the next however long we go on it. What I really want to talk about is finding a way to get something out of it. There are obvious things where you can say, hey, at the end of a project or maybe at the beginning of a project, you say, hey, I want a reference. So at the end of the project, you're like, hey, I need a reference. But references are generic in a sense. That's sort of a big open, like what's a reference? It could be as simple as like, hey, Mike's a great guy, check him out. OK, that's not very helpful. What is actually helpful? I thought about this, one, because Mike asked me not too long ago, but like, hey, how do you do this? How do you go about this? That got me thinking because I really, through my career, have not used references. I don't lead with them. That's probably on me. That's probably not a good thing. So this is something I've done that is a don't do like I do because I don't think it helps me as much. I've usually waited for a reference when somebody has asked for it or requested it. The thing is, those references have always been very good. Those have always helped. Those have like dragged me across the finish line many, many times. And so that's why I probably should have led with those more. Now, one of the things I do when I'm proposing, when I put project proposals out now on a regular basis, and part of it is because it's very easy now, Upwork allows you to easily post in feedback from prior projects. So I can go back and look through stuff and grab some. So that's like a, it's like a quote that you're going to see on a website where it's like, hey, check out this guy's work or gal's work. And here's five people that said this and this and this and this and this about them. And that was actually something I did in a recent retooling, redoing of the RV consulting site is I put a couple of little quotes down there, not quite quotes, but it's stuff people have said us have things people have said about us. And then they're not full quotes because that's where I'm going to go back and reach out to some people and say, hey, is it okay if I put this on a site? I have left it, you know, generic right now, but it's good stuff. And that's the key to it is what is good stuff? The whole process of winning a project starts with you, basically somebody's out there, they need a question, they need a problem solved, they have questions they need answered. They come to you and some either directly or through a site or something like that. It's like, hey, I have this problem to be solved. So what do you do? You're answering their questions. Basically, you're saying, hey, you can do this, you can do this, or here's a solution for your problem. Ideally, when you get done, the reference should continue that story. So it should be along the lines of I needed problem A solved, I went to Mike, Mike said this, Mike provided this kind of solution, it worked great, it was awesome, I love working with them, blah, blah, blah. And then you have something that is valuable. Now the keys to this is you need to make sure that the problem or either the problem that part of that reference or the question or questions you answered are part of that, because that's what's going to really resonate with the reader. If you say, if you've got a reference that says, Rob did a great job helping Mr. Musk build a rocket ship, and you're like, I'm trying to build a CRM, doesn't really help, does it? You're going to look at it and you're like, I don't care. I don't care what he built. It doesn't help me in this. And this is where niches become part of you or that you need to be aware of them, at least, is things like, hey, and this way, it also needs to have a couple of details to make sure that it is relatable. If you just say, Rob built some cool software for us and he did it on time and it was on budget and we love working with them. Yeah, that's awesome, but it really doesn't resonate because if I'm coming to you and saying, I need you to build a timecard entry program for me, and the reference doesn't mention timecard entry, doesn't mention a technology stack, doesn't mention anything that helps me, that relates to me, then it's a useless reference. So when you're doing a reference, one, make sure that it has those kinds of details where it talks about the questions that are answered or the problems that are solved. And ideally, if you can do that in a way where there are multiple details, because almost never is there going to be a project where you're just solving one problem and you just did it and that's it. There's usually multiple problems. There's multiple facets to it. So it may be, for example, instead of Michael built a really cool CRM for us, it would be something more in the lines of we were struggling. We were using a custom CRM that had gotten out of date. Michael helped us figure out what we had, helped us migrate our data, helped us design a new one. And now we use this for our company of 200 people. We do this on a daily basis. It was easy to maintain and was done on time, on budget. There's a lot of details in there that can resonate with the reader. So that's what you want. You want it to be, you don't need like, you don't want a book because they're not going to read a book. But if you can have some bullet points like that, that's key. And maybe even what you do is you have, maybe you look at a reference and you've got 10 bullet point items that you could pull out of them in any given response or email, whether it's responding to an email or maybe it's a proposal or something like that. Maybe only use three or four of those bullet points because those are going to sing to whoever the person is on the other side. That's going to really resonate to them. They're going to say, oh, that's exactly what I'm looking for. And that's why we've talked in the past about having, for example, multiple types of resumes where you take all your stuff you've done and you use it in a language that really communicates more to that specific audience. If you're trying to build a custom application, you should have some wording and some references that are and things that are built based on that. If it's enhancing the existing one, you're going to have slightly different. It could be from the same project, but you're going to emphasize things differently. So when you're looking for that reference, and yes, see, I did come back around to the point. I did get totally lost. When you're asking for that reference, you can start with it. That's how you start with it. You can say, hey, I really enjoyed the work. Could you give me a little bit of feedback on this? Now that helps, but if you maybe give them five questions along the lines of, and you can look at any rating system and take something like this. So it's like, how did it go overall? Ideally, what you get is what was the high point? What was the low point? What do you think we did great? And where do you think we can improve? If you ask those, one, you're going to get honest answers. And within that, you're probably going to get some two things. You're going to get the really valuable one. You're going to get probably some good reference material. And the other side, you're going to get some good, where do you need to improve material? Those things combined are how you're really going to leverage project one into project two and three and four beyond that. So thoughts on that? I know once again, I sort of dove right in, but last time it worked so well, I'm going to let you follow up and see where you go with this. All right. So you've kind of explained the whole process and why we want feedback. And you kind of walk through the different types of things that we should be asking for feedback from our customers. So I'm going to take this a slightly different direction. I'm going to take it more of a deeper dive into that process. So I literally just went through this with a project I was on. As I went through the whole experience of the Statement of Worth, the actual doing the assessment, walking through completing the assessment, the final meeting, and then requesting feedback, before I went out and did something like SurveyMonkey or Google Forms or Typeform, where I actually built a nice online questionnaire to get feedback from, I walked through the whole process of what it was that we did with the customer. Because if you're going to be asking for feedback, like Rob said, you need to ask questions, especially if you want testimonials, you want to ask them in such a way that if they do give you a testimonial, it is reusable or it's helpful for that next project, for that next niche or that next customer that you're reaching out for. Interestingly enough, as I went through this process, especially for me, it actually helped me look at what it was that we did overall. And it kind of helped me identify areas that were niche-e, where I could say, hey, this is something that would be really good for a future project if someone needs x, y, or z. So I walked through and I essentially came up with 10 questions. I know Rob said a handful of questions, but you have your generic ones, like how did the project go? I asked, how was communication? Was there any questions or problems that were found during the process of the project? What could be done better? Those types of questions. But then I took it further. I started asking questions more along the lines of the assessment. What was the problem that we were trying to solve? So I asked them, going into this, did you have a clear understanding of your problem? Their response clearly was no, because they had a problem. But as by the time we got done with the assessment, we came up with the issue where they had 42 and we actually needed the question, what is the answer to Life, the Universe and everything? 42, well, what is the question? So we ultimately, through the process, came up with what their problem was. We actually defined the problem for them, or at least explained to them a way to define the problem. That actually became a good question on the survey for a testimonial. Would you refer this customer to help you understand your business or understand your problem? Are they a good problem solver? It was kind of an interesting way that came out of the assessment. And it wasn't even a survey question I was thinking about at the start of the project. Some other things to think about as you're going through the process, like if you're building an application. So if you're building a web application from a customer's perspective, not all customers are technical, how can you ask them a question in such a way that they will give you a testimonial or a response that is understandable of what the work that you did or the work that you could provide for someone else. So it's a way of unpacking this terminology, this technology, these things behind the scenes that we do that the customer doesn't see, but we need to get the feedback for what it is that we provided. So you have to make sure that you unpack those questions in a way that is user friendly, reusable and potentially can have metrics to it. Because the other nice thing at the end, as you start building these projects, you can actually put a nice little graph on the bottom of your site that says, these are the categories that we do metrics on. Here's where we stand. So like 100% customer support. Well, what does that mean? So you would have to then break down what is customer support? Is that working via the phone, working in person, solving problems? You know, you kind of have to break it down more than a high level metrics. Like Rob said, if you just give them a blanket survey, you're not going to get good feedback unless you ask more direct questions. It's like, well, how do we do? Well, you completed the project you did. I mean, if you ask that open ended like that, you're not going to get a great answer. You could get, you did great. You did lousy. You know, this is where you could improve. So you have to kind of unpack these a little bit more from yes or no and get them into more very deeply defined open ended questions. It's almost like from an interview. If you're interviewing someone, you don't want to simply ask them a yes or no question. You want to ask them, you know, how did you complete this task on X project? You want more details. The trick is how do you get these details from a questionnaire or a survey to get the feedback from the customer in a way that makes sense to you and makes sense to actually feedback so that you can make improvements on the project. Also in addition to that, as we went through the feedback process, also at the end of the came up with additional questions and concerns for the next project or for the potential next statement of work that we were to do, which led me to additional questions, which weren't even on the survey, but can be future questions for potential marketing, potential customer survey feedback to just put out in groups like on LinkedIn. Hey, are you guys having a problem with X or what are your issues? So is another way to kind of go mine your customers or your potential customers and get better feedback as to what is the problem? What is it that people need? And can your solution do that? So this kind of puts you into that niche area where, hey, I have this solution. How do I get to people? How do I find out if people actually need this solution? And that, and this is kind of how you go about and find that information, start talking to people and get that feedback. And that is really the, this is where you really start getting into like market research level of stuff. Now you're going to have customers that are more than talking to them that they're, they're more than happy to walk through things. And there'll be some that they just want to be like, you know what, we're done. I'm busy. I'm not going to give you so much, too much information. And while that's not ideal, that's okay. Is what you, what you want is you want the customers that are much more, you know, that are happy to give the feedback that are conversant about it. And if you can do it much like Michael did where it's part of a step in the process, because like, for example, it's part of your presentation at the end, you're saying, Hey, here's the assessment that we put out that feedback that you are getting the question that you get on what you produced is going to be some of the things that you can maybe utilize, whether it's asking them and getting some feedback from them about how you handled it or for the next person to say, Hey, are these some things that you're struggling with? Are these some questions that have kept you up at night? Then those are going to help you draw people in the next time around. Now I do want to, I want to, before we get, you know, wrap this one up as talk about longer term kinds of projects. If you've got something that's, that's easily to do, you know, you do it in three, six months, something like that button up, boom. It's a nice, you know, project in a box. Awesome. If it's something where it's ongoing, which for example, I've had customers that I'm, we didn't really, the project didn't end for literally like 10 years. You just sort of like a little here, a little here, a little here, a little here. Don't be afraid to periodically go back and, you know, just maybe every six months, like how are we doing? What's going to do a customer survey of some sort, just send it out. Maybe send it to all your customers that are active and just say, Hey, how are we doing? We want to get some feedback. What do you think? Because that's, there could be a gold mine of information in there. That could be very useful for you. Now, another thing, if you're struggling with the, like, how do I have applicable questions? One of the easiest ways to do it is when you first started out, you effectively set up some sort of a statement of work or project goals or requirements or something along those lines of like, here's the problem. We're going to solve. Here's how we're going to solve it. Use that at the end to say, okay, how did we do? We said, this is what we're going to solve. We said, this is how we're going to solve it. How did we do? Did we solve it? Did we solve it the way we wanted to? What, if it changed, how did we handle those changes? If it didn't change, how did, you know, how did you appreciate the, uh, the process to make sure that we got all of the details? Also, like Michael, you know, suggests a lot of times there's, there's going to be new stuff. So how did we help you learn more about that problem? How did we educate you? You know, it's there's a lot of stuff around that that can start with. At some point, we said, here's where we're at, and this is where we're going to take you. So at the end, look back and say, how was that journey? How was your ride? What is it that we did that we did right? What did we do wrong? How did we help you over the hurdles? Because those are the things that are going to be the, we'll call them interview questions at the next project. Those are going to be the things like, Hey, have you ever done this before? And you say, yes, I did. And this is the experience that I had. And it doesn't have to be sunshine and roses. You can talk about stuff and say, you know what? We had this thing, it went wrong. It went off the rails, but this is how we brought it back on the rails. And in that we learned how to avoid going off the rails in the future, but we also adapted and we made sure that it worked so that it was a, it worked for our customers and it didn't cause a whole project to sink. Final thoughts on this one? Yeah, actually through that last piece you were talking about, it triggered one additional thought. We this season are talking about the developer journey. Now this is not just about side hustles, starting your business. This is also your journey through your career, through you becoming a better developer. Some of the points Rob just mentioned can also be applied to a job, a corporate job. A lot of companies do quarterly reviews with their employees. However, some companies don't. So as you're going through and working on your daily job, these are questions and surveys you could even do with your boss, with their boss, with the project to figure out how things are going in your day to day job to progress. Because if you don't get feedback, you don't know if what you're doing is right or not. And it applies to your job that applies to your side hustle and that applies to life. So take the time to ask for feedback when it makes sense. And if you're struggling because you don't know where you're going, if you kind of have lost your way or you know, you're in that dark tunnel and you can't see the light at the end, start asking questions, try to get that feedback. And this is just an example of how you can go about and do that. Yeah. Don't be afraid to just, you know, it was the funniest thing is that when I got Michael's first question was like, how do you get feedback? And I was like, ask. I mean, it's a little bit of a smart ass answer, but that's basically going to be your starting point is you ask for feedback. You should, that's going to be how we don't get better in a vacuum. We don't get better unless we know what we've done right, what we've done wrong, what we can do better. And so that's where we've got to, we've got to elicit some feedback and don't get too, it's funny because this sort of makes me think as I've got a customer right now that we've just gone through some stuff and we sit down and they just, you could say they're like picking stuff apart, but it's really not it is they're looking at the details and they're saying, Oh, this needs to change that needs to change. And some of it's, it's a learning experience because some of it's questions that didn't get asked quite the right way or things that they didn't think about or things that I didn't think about or, or a lot of it is just differences in language and experience with, you know, there's whatever that day to day is for your customer is probably not the day to day for you. And so it's finding the, you know, the connections between those. And they apologize at one point. They're like, Hey, we're, you know, we don't want you to feel like we're saying you're a bad developer or anything. And I was like, no, no, no. I, we love feedback, feedback helps because we don't get better without it. And it, it doesn't mean we're necessarily going to take every little bit of feedback that we get and then, you know, focus on it. And then go knock that thing out. It's how do we take that and incorporate that into becoming better? Where can we take a piece of that? And it's something that, you know, helps us the next time around. One of the best things and sort of closing on this one is I love how agile with sprints does it. When you get to the end on a retrospective, is you're going to have a long list of stuff, probably. What did we do wrong or what can we do better? You don't in the next sprint, turn around and try to address everything. You pick like one or two, make it bite-sized chunks again. You're not going to become perfect. You're not going to become, you're not going to address all of your better bullet points in the next two weeks or the next month or something like that. So, you know, pick one or pick two and focus on that and get better there. And then when you're, you're comfortable that you've gotten better there, then you can pick up some more. It's, don't get yourself overwhelmed with all of the ways you need to become better. Pick a couple. And this is again, this goes back to some of the stuff we talked about is like when you've got a roadmap, it's like, how do I develop? How do I grow? Where is it that I want to focus so that I have a path and that I have goals. I have goals and I know that, you know, six months from now, a year from now, here's the things I'm working on. And I have hopefully, you know, Michael used the M word metrics. I have some way that I can measure that I did get better because that's how we're going to be able to help ourselves. And that does go back to that whole reference thing is that we, you know, we have a 90% success rate or a hundred percent satisfaction, but it's what does that mean? Not just random stats, but actually something that's valuable. And we don't see you as random people out there on the internet. We see you as people we love to get feedback from. So this is that perfect opportunity where we're going to ask for feedback from you because the next person we, and we may use that on our site or on a, on YouTube or out on the podcast or something like that. Those reviews, those are the kinds of things that feedback is the stuff that may draw somebody else to this very podcast or YouTube channel. And it may help them just hopefully as your way of paying back, paying forward, whatever it is that you've gotten, that you can help that next person do the same. So leave us, leave us comments about the developer nor.com. Leave us, you know, there's a feedback form there. You can throw comments on any of the blogs stuff there. You can check out school.developer.com and sign up there and give us some feedback there. As I say, info at developer.com on email. Developer nor is our at developer on X also known as Twitter, which someday we're eventually be able to just say out on X. We have a Facebook page. We have a LinkedIn place, you name it. We're probably there. And if you don't find us there, let us know. And we'll be there just to, just to make sure that we're there as well to, you know, service, whatever that community is. That being said, go out there and have yourself a great day, a great week. And we will talk to you next time. Thank you for listening to building better developers to develop a new podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.