 and assumption about you all. That you all care about your work. After all, you're at a conference to learn how to be better at your work in some way. I imagine that most of you want or need to work with other people. You design and build software, products and services and hope that someone else will use them. If however you work in a vacuum and never need to share your work with anybody else, this next 30 minutes is a good time to switch off, read Twitter, read a book, bask on your peaceful, deserted island. For those of us whose product or process involves interacting with other people, we have some work to do. Whether you feel awkward asking for feedback, sometimes sound too harsh in the feedback you offer, or unsure how to respond to negative feedback, I hope we'll cover something in this talk that you can take back to your work. Something that improves your work, your productivity and your happiness at work. When you're making a new piece of work and you reach a solid pause, you're happy with how this part looks. You're not totally sure about that part, but overall you think it's probably fine. You stand back and you feel relieved to have finally reached a stage where you're happy with how this thing looks. You feel quite proud of what you've accomplished so far, and you might say to yourself, I made that. I'm awesome. Around this pause you'll start to feel like curiosity. Oh, I wonder what everyone else will think of it. Perhaps you'll share it now with a safe confidant, your partner or a parent, and they might offer you some tips on things you could tweak to improve it, but they love you and they'll tell you, you made that. Aren't you awesome? Perhaps you'll share what you made with a group of your peers in your field or your workplace now. You put your work out there, that thing you've poured your blood, sweat, maybe just keystrokes into, and you wait. You feel a sense of anticipation as you put this new creation out into the big bad world and you wait to see how people will respond. And it turns out they don't like this, they don't like that. They might ask you all sorts of weird questions about it, some things you think aren't even relevant, not right now. Why? Someone might say, you made that. That's terrible. You might cry a little bit, and then someone else might say, I like what you've made so far. Have you thought about changing that part? That would make it awesome. You'll feel a little bit deflated, but also uplifted, that at least you know what to work on next, you know how to improve it. And you might wonder sometimes, why do I put myself through this gauntlet? Why can't I just make work in peace? And essentially, we put ourselves through that gauntlet because we know our work only improves through feedback. If you don't ask for that feedback, it's not only less likely you'll receive it, but you won't have any control over the process and then just won't benefit the most from it. Way before working in tech, I mostly learned about feedback at college, where I studied sculpture of all things. When I started my degree at Glasgow School of Art, I was 18, fresh from high school, fresh from a place where if you did the work and for me in art, if it was aesthetically pleasing, you got good grades. There wasn't that much to discuss. In my first term at art school, I got a terrible shock. The most valued skill was not a technical or creative skill like drawing or carving. The most valuable skill was how we discussed our work. Critical discourse was actually written into the curriculum at art school. In the first year, the curriculum aimed to just get students to critically engage with their own work and the work of their peers. And by the fourth year, students were expected to critically articulate their ideas about their work on a professional level, to be able to stand up professionally with gallery owners or media and talk about their work. To succeed, it wasn't enough that you could make pretty things. To be successful, you had to be able to give and receive feedback well. And we worked on those skills every single week through group discussions about our work. These group critiques or they're called crits at art school were a time on our tradition. We'd each have to stand up and present our work, typically a work in progress and explain our ideas, our process, the decisions we'd made together. And then everyone in the group and the members of staff present would ask us questions. Why had we chosen that material? What did we think worked well? What would we like to change? What would we improve it with next? At first, I found this process terrifying. It really felt like I was being grilled. But I gradually learned partly to prepare better for group techniques or group critiques. Sorry. I learned how to not take the critique personally and absorb the feedback into my work. I learned that really my work would be terrible without that continual feedback. So let's talk about how to ask for feedback. Sometimes that gets overlooked. There are three particularly useful elements to consider when asking for feedback. What, when and who. Be explicit about what you want feedback on. You won't get the best feedback if you just put your work out there with a general request for any thoughts. Think about what you actually want feedback on. Maybe you want just a quick pair of eyes on some code. Maybe you want to debate the whole technical approach. Maybe you want to critique on some design. Here are some examples from my workplace of people asking for feedback. Actually, this is an example of someone asking for zero feedback. This person has changed over 30 files and doesn't tell the group anything about those changes. Doesn't ask for any feedback. This man is an island. Here is one of our lawyers actually just asking for a pair of eyes. Has he missed anything? Just a simple request for feedback. And here's a great example of someone on a pull request at GitHub who gives a summary, explains the impact and asks some specific questions. I'll just zoom in on the questions. And he has some really specific questions that are areas that he wants feedback on. He wants to know about the API design. He wants to know about performance. And then I like that he leaves an open ended. Is there anything else? Be explicit about when you want feedback. When reviewing code or design, it's good to keep in mind whether you're close to the beginning or the end of the project. There's different concerns depending on how finished you are. If you have an early work in progress, just be explicit about that. Here's an example of someone saying, I'm working on this thing. And he uses the phrase, it's half baked. At that early stage, let your peers know that this is a check on the general approach on the direction of the project. For a review of work at that early stage, it's suitable to discuss if the project seems feasible. If it's headed in the right direction or if anyone has any concerns, it would prevent you from pursuing it further. It's not so suitable to discuss polish when something's at an early stage. It's great to ask for a work in progress review early on and get that feedback. It can save you a whole heap of time and energy. You can still adapt and change direction at a really low cost. If your work is nearly done, you should also make that clear. Let your peers know that this work is almost ready for production. At this stage, you expect you want your peers to go over your work with a fine tooth comb. You want people to help you polish up any rough edges before they affect your users. Here's a good example of someone who wants people to follow his work in progress but to hold off offering feedback until a certain point. And I like that because it's given people setting those expectations is helpful to everyone and honest. And he's in control of that process of asking for feedback. Whether you're at the start or near the end of completion of development, given and receiving feedback at the wrong level is frustrating. So it helps everybody to just be clear about what stage you're at. Be explicit about who you'd like feedback from. Think about, do you want feedback from someone who sees the big picture or just a specialist area? Do you want someone who sees things differently to you or just a sympathetic ear? All of these things can be beneficial at different times, but just know yourself what you would like and go get it. You can ask individuals you specifically want to hear from, call them out by name or bring in a specific team. Here's an example of someone asking different things of different teams. And you can imagine if you're on one of those teams, how that expliciteness would be really helpful. You know exactly what the person would like feedback on. And I also advise when you're asking for feedback, don't shoot yourself in the foot. I'm from Ireland and I live and work in the States now. And I've definitely noticed some cultural differences to how we talk about our work. In Ireland and the UK, our tendency is to be quite self-deprecating and underplay our own efforts. We might say, I made this thing, I don't know if it's any good, if it's not too much trouble, maybe you could have a look at it. And in the States, I've noticed people tend to be a little bit more, I have this great idea. I would advise, choose language that is authentic for you and honest for sure, but just don't set yourself back from the start. Here's a few examples I've noticed of that in our workplace. This is someone introducing their work by saying, it's fine if you want to destroy it. This is a guy who's excited about the changes he's proposing. But he's also excited to get feedback on it. So some quick tips on asking for feedback. Think about what you actually want feedback on and ask for that explicitly. Be aware of what stage of completion about that and talk about that when giving your reviewer's context. Think about what individuals or type of person you want feedback from and seek them out. People are generally pleased when you seek them out for feedback. It's a compliment and use authentic, but assertive language when you're presenting your own work. There's been a lot of research in the aviation industry demonstrating that some plane crashes have happened because of miscommunication. Whether that's been cultural, ranking, or subordination factor, as to the reason why, there've been many cases where co-pilots have so unsuccessfully offered feedback to the captain that their concerns have just gone unheard and planes have crashed as a result. Here's some chat from a black box recording between the first officer and captain in one cockpit. The first officer is concerned about ice on the wings. And he says, you see all those icicles on the wings back there? And he says, it's like a losing battle trying to de-ice those things. It gives you a false sense of security. And he tries again, let's check those wingtops again, shall we? And you can see the captain just says, I think we get to go here in a minute. Later, that plane crashed because of problems coming up. And he says, you see all those icicles on the wings back there? You can see the co-pilot hints three times about the possible dangers, but the captain just ignores his comments. Like perhaps if the co-pilot had more strongly advocated his concerns, and of course, if the captain had been open to hearing the feedback, that incident could have been avoided. In the medical world, often harm is actually caused to patients from similar problems. There have been many studies showing a correlation between teamwork skills and error rates caused to patients in operating theatres. If you've had the misfortune to undergo surgery recently, as I have, you might remember that surgeons often don't have the best communication skills. They're quite an intimidating figure in the room. And obviously, we want surgeons to have the best cutting skills, so that's kind of okay. But you can imagine, if you're a nurse in the operating theatre and you think you see the surgeon do something wrong, how difficult it would be to offer that feedback. So the medical industry learned from the aviation industry and developed methods to, first of all, measure those communication skills. Here's a screenshot of a test used to measure a surgeon's non-trial and non-technical skills. You can measure things like the surgeon's openness to opinion from other team members. In hospitals, when they gave coaching in these non-technical skills, what they found is that the actual technical performance increased. The team was better at communicating with each other. So their technical performance increased and the rates of harm caused to patients decreased. In our work world, giving feedback doesn't usually affect life or death situations, but how we give feedback still has a huge effect on how our team works together, how people in the group feel about each other, and ultimately, how successful the product is. So here's some skills we can work on to improve how we give feedback. First of all, we can practice our empathy skills. When we give feedback, we really don't want anyone to feel ashamed of their less than perfect work. We certainly don't want them to feel afraid of us or of making more change. Our end goal in giving feedback should be to improve the product that we're making together and we can mitigate against anyone on our team feeling that shame or fear by improving our empathy skills. Brynay Brine, a social researcher, if you haven't seen her TED talk on vulnerability, by the way, you should look that up. She's amazing. Brynay Brine asserts that empathy and shame are on opposite ends of a continuum. Shame results in fear, blame of ourselves or others, and disconnection. Empathy is cultivated by courage, compassion, and connection, and is the antidote to that shame. Rather than judgment, which exacerbates shame, empathy conveys a simple acknowledgement. You're not alone. I've been there. One of the things we can do to improve those skills is simply listen. Really digest what the other person has said. Listen the whole way until they finish before you even start forming your response. Slow down. Pause to think about why they are putting forward this idea. Consider their experience and what might have led them to this view. Ask follow-up questions to better understand. To better understand their intention and how the person feels before you respond with your opinions. How I communicate about my work or the work of my peers is a reflection of who I am right now. And so much can shape that, including my ambition, ideas, needs, memories, goals, prejudices, distractions, and fears. These things shape my life and my communication is affected by them, obviously. Everyone I'm working with will have different goals, distractions, fears, if I can work on being more aware of what those things are in other people and consider where they're coming from, I'll be better equipped to understand them. I'm better equipped to respond. Working on your empathy skills is an investment. You need to make a conscious decision to listen, to understand. It is time-consuming for sure, but the return of a happier, more productive team will be worth it. Some quick tips on that. Familiarize yourself with the context of the work itself and the people who made it. Give it a few minutes before responding, especially if you disagree. As a general principal, the opposite to the principal in programming, ask, don't tell. You can say, what do you think about trying? One of the lessons they drummed into us at art school was that as a group, we're there to further our fellow artists, or in this case, programmers' understanding of the work. Our job is to support that person to progress the work. It doesn't actually matter whether we like it or even respect it. That's our job as a group. We can also explicitly work on our critique skills. We can make a conscious effort to practice critique. As opposed to criticism. Let's consider the difference. Criticism tries to shut something down. Critique tries to further it. Criticism looks for what's lacking. Critique finds what's working. Criticism is negative, whereas critique is positive. Criticism is vague and general, and critique is concrete and specific. Criticism looks for flaws in the creator as well as the creation, whereas critique addresses only what's on the page. In our tech world, criticism might look like, never do that, it's super slow. Whereas critique might look like, are there performance implications with that approach? What do you think the trade-offs are? We can practice giving critique, not criticism, by just observing what we're about to say. Pause for a moment before offering feedback and consider if it seems like a criticism or a critique. See if you can adjust the thought to be firmly on the side of a critique. Most of us don't like criticism, but we're good with critique. Some quick tips on that. Avoid using derogatory terms, like stupid, when referring to the work someone has produced. Avoid hyperbole, like never do. Just be humble, say, I'm not sure, let's try. Explain the reasons why something should be changed. Maybe there's a style guide that you think isn't being observed. Maybe it's just personal preference, but be honest about that. Offer ways to simplify or improve the work. Think how you want the person to feel when they receive this feedback, and think about what you want them to do after they receive this feedback. We can also practice making group critique a regular part of our work. If someone says, to me, I'd like to talk to you about the work you just made, I don't know about you, but I immediately regress to feeling like a 10-year-old child that's just been called to the headmaster's office. I'm not sure what exactly I've done wrong, but I'm pretty sure I'm in trouble, and now my stomach feels a bit sick. We want to avoid that feeling of being told off, of not being treated like an equal. Criticism and blame makes people retreat or retaliate. It's that fight or flight response. Whereas if my team is in a regular pattern about talking about our work, say once a week having a group discussion, then it just becomes normal. It's a welcome routine. You've got to get used to it. And you will get better at it. There was a story in a UK newspaper, The Independent, a few weeks ago, where a female author was trying to get a book published. She contacted some 50 agents and heard back from two. She contacted them using her real name, of course. And when she got such a negative response, she tried a different thing. She pretended to be a man, and she sent the exact same letter to the exact same agents. And as a man, she got massively more positive feedback. He is eight and a half times better than me at writing the same book, she said. The same features were described with positive language in the man's work, were criticized in the woman's. While his main characters were called exciting and clever, her and the woman's work, her characters were criticized for being a bit too feisty. In our work world too, women often receive different feedback to men. Feedback given to women may contain small subtle slights, perhaps excessive nitpicks on minor details, or patronizing comments on their work. Talk to women in a tech company, and you'll hear experiences of these frequent, like, paper cuts of feedback. Or of having the feedback they offer be overlooked in favor of the next male commenter. Usually that behavior is accidental, but it is damaging. There are some simple actions you can take to try and prevent it. Take an unconscious bias test. They're available online. Find out where your own prejudices might lie. Be aware if they are seeping into how you give feedback and who you give it to. Some other quick tips. Studies have shown that in written communication, neutral language is often perceived as negative. So see if you can really positively use positive language as opposed to neutral. You can use emoji to clarify tone in written language. Consider the difference between just the written word and the written word backed up with some emoji. At GitHub, we use emoji extensively to the point that often comment threads have new words anymore. You can practice giving yourself feedback. When you've reached a solid pause in your own work, you can try thinking of three words to describe your work. And then think of three words to describe how you would like it to be. And often we already know ourselves what could be improved. Recently I was making a big change to our code base at GitHub. I wanted to use a system that another team had engineered and I started researching and exploring how to do that. And then had to present the solution to my team and this other team. The work had become fairly complex and the changes in code were really quite difficult to grasp for anyone not directly involved. And this was all discussed through the written word as we do. And some of the comments became like short essays. But we really needed feedback from this other team. And that team was interested to offer feedback. But yeah, when we asked for it, they said things like, I don't really understand or I can't wrap my head around what you're doing. And at first I wondered, geez, you're the experts. How can you not get it? But even with subject matter experts, expecting them to read a whole amount of code and just get what you're going for is too much to expect. There was too much to digest. So I realized that that response didn't necessarily mean that the approach or the code was wrong. When they said, I don't really understand, I heard, oh my God, there's so much information here. Do I really have to wade through all this? And that was good feedback to hear. It told me maybe how I was presenting the information was just too complex. So I took a step back and drew a diagram of the changes with simple boxes and arrows to indicate the flow and the structure. Changing the presentation like that immediately turned the conversation around. This is the first response I got. So that wider angle view, let other people in and let them understand. It takes practice to not be so emotionally connected to your work that you can't take a step back. Empathizing with the people giving you feedback helps with that. And this was a good reminder. Can you respond in such a way to feedback that lets other people in, that opens up a dialogue? And of course the same guidelines on practicing our empathy and critique skills apply when we're responding to feedback. If you experience people leaving blunt or harsh feedback on your work, you can try and raise the entire game. Practice your empathy skills. You can think, why might this person be speaking like this? I wonder what their fears are or their goals. You can practice your language of critique. If someone bluntly says, I don't like it, engage with them, practice those critique skills, you might say, that's interesting. Can you explain why? What would you like to see changed that would improve it? Keep the dialogue about the work, not the people making the work. And that way you let the whole team see what kind of vocabulary can open up that dialogue. What approach could help prevent judgment and shame? These are good principles to work by when you're working with your peers towards a common goal. Hopefully you are working with people who are invested in you and want you to improve. If you receive negative feedback from people you don't know, or people trying to undermine you or attack your work for some irrational reason, it's probably best just to ignore them. Their aim is not to help improve your work. Anne Friedman wrote a great post about this. She has what she calls a disapproval matrix to help you identify whether feedback is rational or irrational. So I'd suggest you look that up, handy reference. I'd also suggest don't put up with aggressive or disrespectful behavior if you're in the workplace. If that's something you experience and it's definitely difficult to resolve yourself, get support from your peers and your manager. So some tips on responding to feedback. Always try and lead with an expression of appreciation, especially when the feedback has been mixed. Ask for clarification if you don't understand. You can simply say, I don't understand. Can you clarify? Step away from the written word if there's growing debate or confusion. You can try and talk in real time, have a video chat if you're a distributed team. If there was a written dialogue beforehand, they would just post a follow-up and let anyone else follow in along. See what you resolved. Always try and keep the goals of the product or project in mind. This isn't about you, it's about the work. Our work improves through continual feedback and we might improve as a happy side effect, but we are not our work. We practice our technical and creative skills. We set goals to learn new languages and new pieces of software. I propose that we consciously decide to practice our feedback skills, that they will reap the greatest reward on the quality of our work, on our productivity and our happiness at work. Try it out. Write yourself a checklist of things that you'd like to improve in your own process. And just check in with yourself next time you're asking for or giving or receiving feedback. You might ask yourself, am I setting myself and my work up to receive the best feedback? Have I paused to empathize with the person asking for or giving me this feedback? What do I want them to do after I give this feedback? And how do I want them to feel? Am I offering critique, not criticism? Am I stepping back from my own work to really hear the feedback I've been given? Am I letting my peers know that I value the feedback they're giving me? Perhaps you have a personal checklist of the things you want to ensure you do or don't do. Practice these skills as you would your technical and creative skills. I wish you the grace to support your peers, to listen to why they made their thing and to offer ways they could make it even better. I wish you the courage to talk about what you've made, why you made it, and to ask your peers, how can I make this even better? Thank you.