Give Good Feedback!

December 05, 2019

We’ve talked about how important feedback is in the past, but how do you give good feedback? Joshua and Kel talk about how to give feedback people will appreciate and value.

Be sure to check out our new Slack community to meet others who are facing the same things you are and share your journeys!

• 00:00 Joshua

  Hey folks, welcome to Getting Apps Done. A mostly non-technical podcast about building software. I'm your host Joshua.

• 00:12 Kel

  And I'm Kel.

• 00:12 Joshua

  And on the show, instead of talking about technical things like syntax and frameworks, we like to talk about the other aspects of software development. And today we wanted to, we've talked quite a few times about receiving feedback and what feedback is and why it's so important. We wanted to talk a little bit about how to give feedback, because that's very important as well.

• 00:35 Kel

  And this came up real life for us recently of how do you give a feedback to someone who, what was it, they had had a website designed and it was not the best. It kind of like how do you give feedback to that, that you should probably talk to your developer about these issues or, and how do you know, how do you move on from that?

• 00:54 Joshua

  Yeah, so in this particular case, someone local to me had been talking about how great their new website was. They were very excited about it and they were sending links out to people to take a look at it. And I did. And um, it was a bit shocking. Uh, I won't say it was bad. It was okay, and I can certainly see why they were happy with it, but there were a lot of technical flaws. There were a lot of things that I knew were going to cause them dings on Google because they weren't dealing with certain things the way they should be. It was going to cause them issues when people were browsing it with mobiles because it didn't look right. It just looked unprofessional. And we're talking about somebody who's trying to run a business. It needs to look professional, otherwise people are going to look at that. I don't want to go with this person. So I wanted to give them some feedback, particularly because I like to support local businesses, but also because I think it's just good if you've got the ability to help somebody like that. Technical things are scary as hell to people who are non-technical. So if you can make that a little bit easier for them, I think you should.

• 01:51 Kel

  And like the problems you're describing are some things that even a junior developer just like straight out of boot camp, it has probably actually seen of, you know, what do these things look like on mobile devices, how is accessibility? Like these are a lot of the things you go through and like you're pretty early training so you can start giving this type of feedback and being able to help people really early on in your career. But it's also how do you again tell somebody that, Oh, that's not so great and I know you're excited but, and everyone always hates the but there.

• 02:20 Joshua

  Yeah, absolutely. And that is one big part of it. And I know for me in particular, and uh, Kel mentioned this, but I was actually going to do this anyway. I'm brutal when it comes to feedback. I like to have real feedback. I don't want somebody to just tell me it looks nice or just to give me platitudes that make me feel good about it. I want actual feedback. I want them to tell me if something is absolutely horrible, I want to know, so what I, what can I do to make this better because I'm trying to make something good. Not everybody wants that and I'm very well aware that not everybody wants the sort of feedback I want to give and I'm not going to be one of those people who would just tell you, yeah that looks nice. Unless that's really what you want. And I'll say, yeah that looks nice and then I'll walk away. But there's not much in between. I'm either going to give you feedback or I'm not so, what Kel said and what I usually do. Makes a lot of sense. You need to ask them first and that's exactly what I do. I flat out tell them I have some feedback for you. I am going to be brutally honest. Do you want me to be brutally honest?

• 03:26 Kel

  I love this, because this combines two of my favorite things in terms of like how we interact with each other. I'm a, I'm a big proponent of consent and all things like you need consent to tell them a bad thing. Like you should ask them first and that might, they might say no, they might not want to hear your feedback and you kind of have to get over that. Um, and also combining it with the, the politeness thing of that in a lot of scenarios we use politeness to kind of smooth over those types of back and forths of you know, I don't want you to do this or I do want you to do this, we kind of hide that. But if you just kind of put it all out there at once of I am a very brutal feedback person. Do you want to hear this? It kind of covers both bases. You, you get to be unfiltered, which is always great because then you get the actual advice that you want to give and the, the useful information out of somebody, you know, they can use more words and it's safe to do so. And you have their permission? So yeah, like combining these two things, it's great.

• 04:20 Joshua

  And that is exactly why I do it because I don't want to give crappy feedback. It's just not who I am. It's not something I like to get, so I don't like to give it and I just, I'm not going to compromise in that way by doing it this way. I don't have to compromise. I can just be completely honest with these people and they know what they're getting into. If they then say yes, I want to hear it, they know they're going to get it. And it's actually, it becomes kind of a joke with people who know me when they're getting ready to do something and it's really, really important and they got to get it right and they say, I gotta go talk to Josh, he'll tell me how crap this is.

• 04:52 Kel

  Exactly. And like, and, and that's a great example of like, people kind of get used to this too. Like once you, you've kind of set up this routine, like there's the, you set the expectation, which we've, we've talked about expectation setting before. It's a very important step and once they're prepared for it, then it's a lot easier to want those things and to ask for them and then actually be able to act on them without, you know, kind of panicking of Oh no, what did I do? And also kind of sets up an opportunity of just general networking. I mean we were kinda talking about how you can start doing this really early in your career of actually being able to give useful feedback to nontechnical folks and that's a great way of being useful to them of being able to give them useful advice right out the gate. They know that they can come to you for information on something they don't know.

• 05:35 Joshua

  Absolutely. And that's something we've talked about in the past and I am absolutely against this whole LinkedIn connection building thing. I think people should be establishing real connections and that's a great way to do it. Giving people feedback, particularly if you're a technical person and they're not, is a really great way to provide value to them and build a real relationship with them. That could turn into anything the road, it could be a job, it could be an opportunity for a new business with them. It could just be that you become friends or it could be anything in between. So it's well worth doing it.

• 06:07 Kel

  Exactly. But there is that large "but", you have to ask first. You have to make sure that they want to hear it. They You got to have consent in these types of things. Like a lot of times it's just more stress like, and at the case I believe that this particular website, like they didn't have a budget to make any changes really. So it was kind of like it doesn't matter. And so you don't want to push the stress onto somebody when there's nothing they can do about it and it doesn't, you know, it might not even matter to them. Maybe that's not what the purpose of this was. Like maybe it never needs to work on mobile because it's an internal site for their family. Like sometimes these things aren't that important to the business person that are really, really important from a technical standpoint and just kind of have to accept that like it doesn't really matter why they don't want to hear it. You just kind of have to take it.

• 06:54 Joshua

  And then to very valid point. In this case I asked the question and the feedback that came back to me was basically, no, I don't want to because I can't do anything about it and it's just going to scare me. I left it out. I didn't really bother. I gave some light feedback, things that I thought that they could just be aware of so they knew and if they make any changes later they can deal with it, but not enough that is going to scare them for the rest of eternity until they can afford to.

• 07:21 Kel

  Exactly. It's like you do it. You do have that balance. There is like, I guess that's a very good example of being polite and you weren't too brutal there. But yeah, they, they gave back feedback on what they kind of things they were interested in hearing and not hearing and that's a useful thing and you gotta, you have to accept whatever they tell you on that. And hopefully though they will accept like your full feedback and then it can hopefully move into you know, career things.

• 07:44 Joshua

  Yeah, absolutely. I and I have had a lot of people who come back so I can guess please tell me everything. And then about halfway through everything they say is there more, there always is more welcome to technology and you know, they're thinking what did I get myself into? But at least they said yes and they know and they have accepted that.

• 08:07 Kel

  Yeah. It's actually really surprising and you'll find when you ask those types of questions like upfront like can I do X? You know, you get consent from somebody. Most people are way more forgiving about the types of situations they run into. Like that's not what they expected. But they deal with it anyway because they kind of took on responsibility for, you know, they said this is what they wanted and you'll find that actually helps a lot, kind of smoothing over a lot of, a lot of disagreements and problems of those types.

• 08:33 Joshua

  I agreed and they can always say, stop please. I said, no, I don't want to know anymore. And you need to stop.

• 08:40 Kel

  Exactly. Consent can always be withdrawn. Like this is a very important concept. Um, but also the things that we do all the time, like when somebody says, you know, that's, that's enough feedback you stop giving, that's a, that's also feedback, feedback about your feedback.

• 08:56 Joshua

  So assuming they have agreed to the tirade of information, I'm going to give them, um, how to give that to them is very important because we've, again, we've talked about this before, but you need to make sure that the feedback you're giving them is in a language that they can understand. Because particularly in this case we're talking about giving nontechnical people advice about technical things. If it's the website or their app or something like that that you're trying to help them with, you need to make sure that they understand what you're saying in the first place. Otherwise it's no good at all. Or they're in a position that they can take that feedback and give it directly to somebody who will understand it.

• 09:31 Kel

  Exactly. And so like as a, as a technical person, you'll, your, your first instinct will be to tell them exactly what needs to be fixed. But that's usually the wrong instinct because from their point of view, they don't know what any of that means. They don't know what the attributes on an image mean. They're looking at it, okay, what is this? Give me, what problem does this solve? This how they're looking at it. So you kind of start at the end and go, Oh, well your, your, your site does this on mobile. It doesn't look right on mobile. Um, or it's hard to read for folks with, um, like a colorblindness or like you started the problem and then you can kind of lead them towards the solutions and the technical, you know, the technical things that are happening. But you, especially when talking to business folks who don't even care, like that's not their career, that's not their bat. That's why they hired somebody to do it for them. Um, it's, it's better to start off with the problems or at least the, some cases the solution, but you don't really want to get down into the technical nitty-gritty until they ask for it or have a use for it.

• 10:26 Joshua

  Yeah. I usually try to start very high level and I will just flat out tell them your side has some issues with mobile phones. Mobile phones are important. Google's going to ding you for that. People who are using your mobile is, are going to ding you for that. It's important to sort those out. Do you want to know more information about that? Again, you can ask them if they want to know more.

• 10:46 Kel

  It's amazing how much you can get just by asking.

• 10:49 Joshua

  It's the same with things like access, accessibility. That's something that a lot of people don't really understand. So you can tell them that there are issues with accessibility and you can explain to them why that's important, what that means to them. Because when it comes down to it, they care about them. Um, you can share how it affects other people, but when it comes down to it, they really need to know how it affects them. And in that case you can just tell them you don't do goals grading you based on these things. Other people are grading you based on these things and it will affect your business. Therefore it's something that you really should sort out. You can give some extra context in there. You can say, you know your struggling with this at the moment, but actually there are a few things that you could do that are really easy and quick and your developer can probably do it in an hour. It's giving them in some information, adding some context in there that helps them from a business standpoint, understand why is this important? What is it that I need to be focusing on and what's the effect or the impact of that on me.

• 11:43 Kel

  I feel like we need to give a warning on the estimate of time there just because it's like, well it might be an hour maybe depending on a whole lot of things that went into your website and what it looks like and how it's built and how it's designed. But at the same time though, that probably will be the very first question is how long would this take you to do that? And so you want to kind of make sure you don't put another poor developer. Yeah, set some expectations. Exactly. Set those expectations but also like think of the other poor developer that you might be throwing under the bus because this will happen to you eventually that their smart friend will tell them that everything is broken and they will come to you with this list of stuff that their friend told them will only take an hour. And then you get to spend at least that long explaining to them why it's going to take way longer than that because of reasons. And there are always, always reasons that take forever. So yeah, like do keep that in mind. They want an estimate. Try to be helpful about that. Also, don't throw your poor friend developers under the bus.

• 12:49 Joshua

  of course. You can add artificial intelligence in less than a day. No problem. I could do that in a day.

• 12:55 Kel

  What's it going to do? Who knows? It probably won't be interesting. I'll give you that your day long AI will probably not do anything smart or useful.

• 13:09 Joshua

  Well, it might, it just might not be in the right context or useful to you at all.

• 13:14 Kel

  Yeah. AI tends to be about as smart as about a puppy. Like if a puppy can do it, your AI can probably do it, but that's also the level of mistakes it's going to make just to like set those... Anyway. Another topic for another day.

• 13:29 Joshua

  Yeah, I equate it to my toddler. You know, the one who walks into things randomly, he has to do it three or four times before he realizes. No, you shouldn't walk into doors. You should open them. Yeah. Yeah. It's kind of the same.

• 13:39 Kel

  Yeah. The puppies don't ever, some don't always learn that like that's why I like to use the dog. Like toddlers will eventually grow into that, but some dogs don't.

• 13:48 Joshua

  Anyway. Anyway, so feedback. So they've given you consent. You have given them some broad terms in a language that they understand. You've added some context in there. Now a lot of the time what they're going to ask next is for advice. Yes, and again, some of this again is about making sure that the advice you give them is not based purely on what you can do or what you know, but the situation they're in. And that's a lot of this and it comes back to setting these expectations because you need to understand, if you're going to give advice, you need to understand a little bit about their situation. Who is the developer? What is love, experience they have? What are they capable of, what's the normal sort of stuff that they're doing? And that might mean that you have to do some research and that is one thing that you need to be aware of. If you're going to give feedback, you need to be willing to put in some effort.

• 14:44 Kel

  That is very, very important. Yes, like a lot of systems you'll run into, especially even websites they might be by you know, a large, uh, content management system that makes it really difficult to do some things that are really easy to do if you just hack it straight into the front end. And so like you need to know how that system works to be able to give useful advice. Um, and that's a really common thing that you do need to understand all of it to be able to give like useful, detailed advice. And that's important.

• 15:15 Joshua

  And I think it's important to get into some of that detail when you're providing the feedback in the first place. But just saying, you know, you need to deal with these accessibility things is one thing, but actually understanding what the impact of that is on their particular site in the situation that they're using with whatever hosting they have, whatever CMS they're using more. If they're not using a CMS, whatever package they're using, the developer that they're using may or may not have any awareness of this. So getting some of that knowledge in the beginning will help you advise them more accurately. We'll also help you figure out what the priorities should be.

• 15:48 Kel

  You'll, you'll notice there's a large overlap of what we're talking about here and some of the other things we've talked about of getting to know your client and things that you should help them and learning about the project and... It's pretty much the same thing. It's the same structure of advice and trying to figure out what their problems are and figuring out the solution to that. In this case, the problems are kind of obvious and that's why you're coming to them to give them feedback. Um, but the solutions again require research and estimation and yeah, effort.

• 16:15 Joshua

  And that's actually a really good way to look at it. We've mentioned this about clients in the past and how you need to work with clients and how you get to know them. Effectively, when you're giving feedback to somebody, they are your client, you are a consultant for them. They may not be paying you. It might be your neighbor, it might be your best friend, it might be your cousin, but effectively they are your client and you need to treat it much the same. You need to do that research. You need to put in that effort because again, we've talked about accepting responsibility on their end when they say yes, I want that feedback. You are accepting responsibility for giving that feedback and doing a good job of it and not, you know, as we said earlier, throwing another developer under the bus or giving them bad advice that might cause them to go the wrong way because they're seeing you as an expert and when it comes down to it, even if you are a junior developer, they still see you as an expert because you, there's a very big gap between zero and magic and the amount of effort you have to do to get there is actually very little. But the knowledge gap is huge.

• 17:17 Kel

  Yeah, that's, that's still a really difficult one to explain I think to a lot of people until you've actually, you've spent a few months learning to code, building neat things and then like dip your toes into a few projects and then you talk to the first person who's never done any programming whatsoever and everything you do is magic.

• 17:33 Joshua

  Yeah, absolutely. I mean within months you can have so much more knowledge about programming in general, how software works, how development works and how the web works and everything else that it's scary almost.

• 17:47 Kel

  There is a reason why people about doing this in school a lot. If you're a totally non developer listening to our podcasts, which seems unlikely but possible. Um, this is why a lot of people recommend learning programming and like development skills so early is because it's such a fundamental concept and you can learn it so quickly and get kind of like the large scale highlights so quickly and that is why like a lot of push like this is worth learning. This really is, it will help you solve problems in new and interesting ways.

• 18:14 Joshua

  Absolutely. The approach to development, the patterns, all those things apply to so many different things in life. The infrastructure involved that you need to understand to be able to develop software for it in the first place. Just learning those things changes the way you look at computers. It changes the way you look at how we use computers and software and it's well worth doing even if you aren't interested in becoming a developer full time. But it's very worth keeping that in mind when you're volunteering yourself to give this advice. That they see you very differently than you see yourself. You might see yourself as a junior developer who's just giving them a little bit of advice so they can go talk to somebody more senior who can actually help them, but they see you as the expert and you need to keep that in mind. Even if you are an expert, you might not be an expert in everything that's involved. So you need to against that some expectations and tell them, I'm not an expert in these things, but this is the way I see it. You should get better advice.

• 19:10 Kel

  Yeah, that was a, I remember learning that lesson that I, even though I was not an expert. I was not an expert in all things. And that was an interesting lesson.

• 19:20 Joshua

  To this day, I mean, I've been developing software for 20 years, but new things come up. A lot of it isn't even software related. GDPR is huge here. And of course, because we're building software, we're building web apps and things like that. Everybody wants to know about GDPR, what do I need to do with this? And you know, because I have to deal with these things on a regular basis. I've learned a lot about GDPR. I'm not a lawyer. I'm not even sure the lawyers have any clue. Most of them when I talked to them, they just say, uh, I don't know. We'll just cover all our bases and then cross our fingers.

• 19:51 Kel

  I've spent a lot of time with accountants and lawyers on electronic signatures and similar scenarios of, I don't know if anybody's an expert on any of this stuff. Um, but yeah, I'm learning lots, I know a lot more. And you'll find this as a pretty common, it's like whatever industry you end up with and you'll, you'll end up learning a whole heck of a lot about that industry trying to design automated systems for them. You know, trying to build tools that they can use. You have to learn a lot about them to be able to be useful to them. And you know, again, feedback. If you're going to give feedback, you probably should learn enough about them to be useful to them too. Um, but yeah, you learn a lot.

• 20:26 Joshua

  In that particular case. When people do ask me about GDPR, I will, I'll give them advice. I take on that responsibility. But I set some caveats straight up front and I say, you know, I have learned a lot about this. I probably know a little bit more than you do, but I'm not an expert. You really should consult your lawyer. And it just sets that expectation.

• 20:44 Kel

  Unfortunately.

• 20:45 Joshua

  Unfortunately. And not all lawyers are that bad. It's okay.

• 20:48 Kel

  It's not the lawyer, it's the, you have to talk to your lawyer to implement a basic feature to create a website. That's, that's the unfortunate part. We, we would like all of these things to be intuitive and obvious and straightforward, but they're not. Laws. Anyway.

• 21:03 Joshua

  But in doing so, I've set the expectations. They know that I'm not an expert. They can't just go do exactly what I said and feel comfortable that everything's going to be okay. But it also gives them a ballpark. They have some idea of the sort of things I need to be looking at. And for a lot of people that's enough. That's what they need to know. That's what they can then go to their lawyer about and save a lot of time because they say, you know, I'm doing these five things. What do I need to do to be safe? Instead of going in and saying, uh, I have no clue what I'm doing. Help.

• 21:34 Kel

  Yeah. It's always nice to have a starting point. Yeah. A starting point, a vague idea of what you're trying to accomplish and what you're trying to build and those are the types of things that you can give to people pretty early on in your career. And definitely more and more as you keep growing as a developer.

• 21:49 Joshua

  All right, so giving feedback, get consent, give good feedback,

• 21:58 Kel

  Do your research, do your research. Be honest.

• 22:00 Joshua

  You need to be well aware of what you're giving feedback on and you also need to set expectations. Particularly if you're going to be giving any advice, make sure that they're aware of what that advice means because like you say, they are not in the same place as you are, so we need to try to help them set it up so that they have the right context.

• 22:19 Kel

  Taking responsibility for what you're telling them is probably the the correct mindset you want to be in there. Like, this is something I'm telling them, I'm responsible for the information I tell them even if, you know, especially if it's even wrong. So keeping that kind of thing in mind will help you give better feedback.

• 22:35 Joshua

  Alright. I will put some transcripts up at gettingappsddone.com. Please be sure to check out my website at joshuagraham.info and Kel's website at piffner.com.

• 22:46 Joshua

  Obviously this is all about feedback, so we would love to get your feedback. If you would like to give us some or practice. And you can be completely and brutally honest with us. We're okay with that. We're giving you consent right now. Pop onto gettingappsdone.com/slack and tell us all about it. We'll uh, listen and cringe and thank you in the end. Well, no matter what you say.

• 23:09 Kel

  We might cry a little. It's okay.

• 23:10 Joshua

  We might, but that's okay. We told you it's okay. So we're taking that responsibility anyway. We post every week except last week because it was Thanksgiving and we might have a Christmas break in here coming soon. It's coming very quickly. I am shocked. I think it's what, three weeks away now? I was pretty sure...

• 23:27 Kel

  You are asking the wrong person about what day holidays actually fall on.

• 23:31 Joshua

  I have kids that are excited. Yeah, taking breaks is good. Maybe we should do an episode about taking breaks at some stage because it's good to get rest.

• 23:41 Kel

  We could do an episode recording us eating pizza, like watching cartoons or something. It's like, this is us resting. See, this is great.

• 23:49 Joshua

  This thing is good. That's when your brain recovers. All right. Uh, we'll be back next week on Thursday. Thanks for listening.

• 23:57 Kel

  Cheers.