Frameworks for Feedback
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 71 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31513 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 201671 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
Product (business)QuicksortSoftware developerData managementSelf-organizationInformation technology consultingSoftwareColor managementCodeMedical imagingMultiplication signBit rateBuildingComputer animation
01:11
CodeTelecommunicationServer (computing)Execution unitSoftware developerDifferent (Kate Ryan album)Social classType theoryError messageObservational studyComputer animation
01:59
Formal languageSoftware frameworkBitGoodness of fitData conversionData structureSensitivity analysisComputer animation
02:35
Data structureRegular graphMetric systemPoint (geometry)Lattice (order)Data managementRevision controlProjective planeVideo gameArchaeological field surveyQuicksort1 (number)ResultantLine (geometry)AreaBitMultiplication signDependent and independent variablesGoodness of fitArithmetic progressionGradientPattern languageVapor barrierControl flowTerm (mathematics)Type theoryGroup actionMathematicsSet (mathematics)Focus (optics)Mathematical analysisStandard deviationPerformance appraisalArithmetic meanState observerSurfaceRight anglePeer-to-peerFunctional (mathematics)Data storage deviceModemComputer animation
06:31
WritingSoftware frameworkBitWebsiteQuicksortProduct (business)Group actionSoftware developerMultiplication signMathematicsInformation technology consultingProjective planeData conversionContext awarenessResultantSoftware bugDifferent (Kate Ryan album)Level (video gaming)Connected spaceInterior (topology)Data miningObservational studyMereologyGoodness of fitElectronic mailing listCodePlastikkarteStatement (computer science)Validity (statistics)Combinational logicClient (computing)Digital mediaLibrary (computing)Right angleParameter (computer programming)Bit rateSound effectMassVector spaceCommunications protocolData managementDependent and independent variablesComputer animation
13:34
View (database)Point (geometry)Software developerConnected spaceMessage passingMultiplication signMereologyComputer animation
14:29
Group actionLogicMetropolitan area networkResultantComputer animation
14:54
Basis <Mathematik>QuicksortRegular graphDisk read-and-write headMultiplication signSpeech synthesisWordGradientScaling (geometry)Right angleEuler anglesPattern languageComputer animation
17:09
CodeMereology2 (number)Multiplication signLattice (order)QuicksortGoodness of fitBitClient (computing)Group actionProduct (business)ResultantValidity (statistics)Decision theoryKey (cryptography)Connected spaceMetropolitan area networkComputer fontInheritance (object-oriented programming)Latent heatVideo game consoleScaling (geometry)WordEvent horizonComputer animation
20:39
NP-hardDependent and independent variablesPower (physics)Level (video gaming)WordBoss CorporationDistribution (mathematics)Dynamical systemInequality (mathematics)Real numberComputer animation
21:47
Multiplication signDynamical systemPower (physics)Pattern languageInclusion mapMereologyGroup actionMoment (mathematics)QuicksortGraph coloringSystem callData conversionWordVariety (linguistics)Network topologyFrequencyLink (knot theory)Linear regressionRadiusLattice (order)Computer animation
25:00
Variety (linguistics)Group actionRight angleInformationComputer animation
25:42
Table (information)WordType theoryKeyboard shortcutRevision controlQuicksortTelecommunicationArithmetic progressionData conversionState of matterSoftware frameworkCategory of beingInformation and communications technologyRight angleLevel (video gaming)Social classArithmetic meanWater vaporComputer animation
27:46
Data conversionGroup actionVideo gameQuicksortMultiplication signSheaf (mathematics)Computer animation
28:21
Software frameworkComputer animation
Transcript: English(auto-generated)
00:16
I'm Rebecca Miller-Webster, I'm the CTO of a small consulting company in Chicago called
00:21
Polymathic, and we're hiring standard comment. I'm also the founder and organizer of WriteSpeakCode, which is focused on increasing the visibility and leadership of women coders. Our conference is coming up June 15th through 18th, so tell everybody you know. And I've been building software professionally for like a dozen years now.
00:46
I've worked as a developer where I'm the only developer, so I'm doing sysop, sysadmin, devops, all the things to customer support. I've been on big teams, I've worked in product and consulting and nonprofits, I've been an engineering manager in various ways, so sort of spanned the gamut of opportunities
01:04
for developers. And I've really come to believe that what we do as developers and technologists is that we communicate. And this is communication between servers, obviously, and our code and servers and different classes, but it's also what we communicate to users, what we communicate
01:23
to the other developers on our team, to future developers, and to other business units. And I'm really interested in feedback, which I think of as the type of communication that tells us how we're doing. Are we successful at what we want to be successful at? And if you think about it, most modern software development practices, Agile, Lean,
01:44
TDD, are really focused on getting more and better feedback, and we know that feedback works. So studies have shown that by far the best way to detect errors in your code is to have a human person look at it and review it. But I think that we need to think about and optimize for all kinds of feedback, especially
02:04
interpersonal feedback, because everything is feedback. It's not just what's said, it's what's not said. It's body language, it's who speaks up, who's interrupted, who stays quiet. So let's talk about feedback. So I'm going to talk about how and why I think it's important to create structures
02:22
around feedback, frameworks for giving, requesting, and receiving feedback, how to give good feedback, and then we'll talk a little bit about feedback around sensitive and difficult conversations. So I think it's really important to create structures around feedback so that it's happening regularly.
02:43
So this basically kind of means more meetings, but I think it's really important because giving negative feedback, especially effective negative feedback, is difficult for everyone. Giving positive feedback is super important and often doesn't happen enough, because as people, we're actually more motivated by progress than we are by an actual
03:01
accomplishment, and positive feedback is what tells us that we're making that progress. And I think regular feedback builds trust and safety on a team, and people might give you silly feedback, and that's okay, because you're sort of showing them that you're trustworthy and you can listen to what they say. And ideally, we have a culture that has ad hoc feedback all the time, but the
03:23
problem with only having ad hoc feedback is that it burdens the person who has a problem. So they have an issue, they have to get up the courage to talk to you about the issue, but then they also have to get up the courage to schedule a meeting and, like, have a vague subject line and then set the precedent for the meeting.
03:40
So reducing that barrier to getting that feedback is helpful. In terms of structures around feedback, I think the ones we think of often are one-on-ones, which are usually manager to employee. I think we miss the boat a little bit in giving feedback to our teammates and peers, whether that's during a pairing session or otherwise in your day.
04:04
One-on-one feedback is really great because there's a sense of safety in you just talking to one person, right? That said, depending on the relationship you have with that person, it can actually feel easier to give feedback in a group setting because you might know that there's other
04:21
people that would back you up. So retro stand-ups, course mortems, we kind of do this already. And the other type of feedback is indirect feedback. So I worked at a startup where every month we had a survey and they asked us questions about, like, how happy you were at the company. And we reviewed the results of those surveys along with business metrics every month.
04:45
And then there's obviously written reviews, but there's also observation. So if I see you talking to someone else, I'm going to assume that the way that you respond to that person is similar to the way that you'll respond to me if I say something like that. So we can't always control for observation, but creating regular structure and regular
05:04
meetings around feedback allows us to sort of even out that data point and have more data points so we average out a little better. In terms of feedback timing, a lot of the practices we use focus on feedback during and after a project.
05:20
So stand-ups, retros, post-mortems, all of those things are great. I think we miss the boat a little bit in giving feedback before we start a project. So I'm a chronically late person. I was a late for first grade and so on and so on, and, you know, not that it's a good thing, but it's something I'm working on and will probably work on for the
05:42
rest of my life. But if I work with someone who is really focused on punctuality and that's really important to them, then we might be set up for conflict or failure in a lot of ways. But if we could talk about that ahead of time and I could understand the areas where it's really important to them and they can maybe give me a break on some of the
06:01
other things, we're more likely to be successful and to collaborate successfully. And the other feedback that I think that we don't do great is cumulative feedback. So usually you have performance reviews, but it's not really cumulative because it's more like just like a vomit of feedback all at once. So it doesn't really give us the opportunity to look at patterns and whether changes
06:25
have happened. Did you get feedback? Did you respond to it? Are you moving forward? So we don't really do that very well. So like most of you, I suspect that you like protocols and so I think it's useful to have frameworks for giving feedback, requesting feedback and receiving it so that if you're
06:45
in a little bit of an emotionally charged situation or you're upset, it's just easier to sort of communicate and you have something to kind of write down. So giving feedback, the goal is really to have a better relationship with someone. So if you work with someone, you have a relationship with them, you don't have to like
07:01
them, you don't have to be best friends, totally fine, but it would be swell if that relationship was better, right, and you could work together even better. So that's the main goal and the second goal with giving feedback is not creating defensiveness because once that sort of shield of defensiveness is up, you're not
07:20
going to get through to them and if anything, they may do the opposite of what you're asking because they feel like they have to justify themselves or they're not really listening. The best way to not get people to be defensive is to talk about actions and not the person. So you're a terrible developer and your code sucks is about the person.
07:41
Saying, I think this method is really long and overly complicated, maybe it would make sense for you to break it up into smaller methods is about the action that they took and giving them an action for them to perform and move forward. The other thing is, as engineers, we like to be efficient, but in these sorts of situations,
08:01
I think it's really important to remember the niceties. So hi, how are you? Like starting with a base level of we're two people and we're talking. I don't love small talk, don't go crazy with it, but that sort of basic, just touching base, how's everything going, I think sets a good tone for having these conversations.
08:21
So the framework that I like for giving feedback is called situation behavior impact. So you want to set the situation. So last week when there was a serious bug in production and the site went down, we were all working really hard to get things back up. Talk about the behavior that person did.
08:41
You force push to master and deployed production to production without telling anybody. And then it's important to state the impact. So quantifiable impact is great, like the site was down for X amount of time or we had X amount of bugs as a result of this is great, but I also think it's important to talk about the impact it had on you as a person. So I felt apprehensive that we might have introduced new bugs because our code didn't
09:05
go through the normal channels and I felt irritated that I worked on something that you'd already fixed. Kind of humanizes the conversation. And if you can, provide a recommendation. So I know it was a stressful situation, but I think it'd be best if you check in
09:20
with the team before going outside our normal protocols, right? And that can also be used for positive feedback. And again, I think positive feedback is really important and often something that gets overlooked. Using situation behavior impact helps you give genuine positive feedback. So just being like, you're awesome is great, but it doesn't really tell me what I
09:44
should keep doing that I'm doing well, right? I had a birthday a couple weeks ago and a good friend of mine who's a teacher gave me a card and it said you are awesome, but then she like wrote a list of the ways that she thinks I'm awesome, which felt really good. So it does work.
10:03
And the other thing to think about is that if you think about a scale, negative feedback weighs more than positive feedback. So if you're only giving someone negative feedback, the impression that you're giving them is like they're just terrible and negative a thousand, right? But maybe they're really only like negative 50. And going from negative 50 to zero feels a lot easier than negative a thousand to zero,
10:25
right? So studies have shown that it's like three positive statements to counteract one negative. For some people or situations, it's up to 10, but something to consider. And then I do think you can combine positive feedback and negative feedback, but they need
10:40
to have the same context. Saying like your hair is really awesome, but that Cody wrote sucks, not the same context. But so I had an employee who got a request from a client, told the project manager, just went ahead and did it because there was all this back and forth. We work at a consulting company. We got to make sure we get paid, right?
11:01
And he just went ahead and made the change because it was simple. And so when we talked about it, I said, look, I totally know that you care a lot about this client, that it was in a lot of ways more efficient for you just to make this change than to have all this back and forth outside it. But as a consulting company, we have to get paid and we need to make sure that's happening.
11:20
So that's sort of the same context. Here's like the good part of what you did, and then here are the things that could be improved. So receiving feedback, again, the goal is to have a better relationship, but this time it's sort of how can you change and improve? And the biggest aspect of receiving feedback is to listen.
11:42
And I don't say that to be patronizing, it's because listening is really hard. Our brain is basically wired to look for novel stimuli and actually paying attention and listening is difficult and requires practice and effort. The other thing is to ask questions to understand. So make sure that you fully understand what someone is saying before you kind of think
12:02
about responding to it. And the last thing is to say thank you and follow up. We all know that it's hard to give feedback and I think it can be easy when you're getting feedback and maybe it's not great and you feel a little uncomfortable or attacked to want to respond right away, but in some ways just thanking that person for taking that time can change the tone of the conversation and also it's
12:23
acknowledging that they did something that was maybe a little difficult. So I have a friend who's a couples therapist and I was asking her what the difference between individual therapy and couples therapy was. And she said that with individual therapy it's all about one person's inner experience and with couples therapy it's about how do we get that externalized, how do we
12:45
translate and communicate the connection between those two people. And this is a technique that she uses with her patients to get them to do that and it's called mirror empathy validation. So mirror is listening to what someone says and then repeat what they say.
13:00
You want to confirm that you really do understand what they're saying. Empathy, show that you understand what they feel and why. And validation, ask questions to follow up that show you're listening. So mirroring, I hear you say, blah, is that correct? Am I correct in understanding that when I force pushed a master and deployed to
13:23
production you were upset that you had to do extra work and worried that it would cause more problems. Just summarizing and confirming, are we on the same page? I really think that at the end of the day people want to feel heard and that's actually more important than you doing what they want.
13:43
They want to feel like you heard them and understood their point of view. And summarizing is a way to show them that. So empathy, there's lots of talk about empathy, there's lots of research and things about empathy, but I think fundamentally empathy is about a curiosity about people.
14:01
And hopefully we're all curious, that's why we're developers. So how does this person think and feel and work and using that curiosity to try to understand that before we kind of pass judgment on it. And it's also an opportunity to make a connection between your own experience and their experience. So we're not all going to have the same experience, but we've all felt
14:22
angry or sad or frustrated. And so we can say, oh, I know it sucks to feel that way. Basically this is the crux of empathy. A person's reasoning and emotions are valid even if you don't agree with them. You don't have to agree with the premise, you don't have to agree with the actions that they took as a result of it, but there was like an if-then.
14:43
If I feel sad, then I want to not feel sad. And outside that you may or may not agree with what they did, but we can sort of connect with that inner logic. And the other thing is that empathy is a skill, and it's a skill that we're not taught very well in general.
15:01
But because it's a skill, it's something that we can learn and practice and get better at. So a couple things you can do to improve your empathy skills. So one is to listen and summarize what people are saying. Really try to focus on listening and hearing what they're saying. Summarize it even if it's in your head or you write it down if you feel weird saying it out loud.
15:20
The second thing is to recognize and name your own emotions. We really don't do this well. We say I feel followed by words that are not emotions. So just starting to think about and reflect on your own feelings and how you felt in a situation is helpful to be able to connect and see that in others. And the other thing is that we all sort of have this like movie monologue going in our heads,
15:42
whether it's like, what am I going to make for dinner? What am I doing this weekend? Do I have to pick up the kids? And trying to sort of shut that out and really focus on the person that you're speaking with. So requesting feedback. The goal of requesting feedback is to get honest and actionable feedback.
16:01
And regular requests for feedback are more likely to elicit honest and comprehensive feedback. So you might get silly requests first. So Rebecca, please don't write with a yellow pen because I can't read it, said my fifth grade teacher. Kind of silly, but then if I stop writing with the yellow pen, I'm showing her that I heard what she said,
16:23
and I'm building a sense of trust. So then the next time the person will ask you something more substantial. So I use this with my team. Probably annoys them a little bit, but I'm fine with it, which is that I make them give me one thing that I should start doing, one thing I should stop doing, and one thing I should continue doing.
16:41
And if you think about it, this is really what you want to know. What am I doing well that I should keep doing? What am I doing badly that I should not do? What am I not doing that I should be doing? And really getting people into the mindset of giving you this feedback by asking it over and over again on a regular basis. In the beginning it's kind of like, you should not stop being great, or whatever,
17:01
but then they start to think about it over the next month or whatever, and you start to get more comprehensive and actionable feedback. So if you remember nothing else from this talk, I hope you'll remember to listen and ask questions. So how to give good feedback. We've all gotten crappy feedback before, probably, I hope.
17:22
Well, I don't hope, but I hope it's not just me. So good feedback is actionable, specific, and kind. So saying you're always an inconsiderate, irresponsible jerk, and don't listen to anything anyone says, not actionable, specific, or kind,
17:42
it's not contextual, it's not about a specific event, even though that might be true, but in general, using words like always, not the best in giving feedback, it's better to cite specific examples. So, you know, not you always do whatever you want without talking to the team,
18:01
instead that one time when you deployed to production without telling anybody, you didn't talk to the team. And the other thing that good feedback is, is that it encourages the team, and it's within the recipient's scope of skill. So you may have to ask them to do something or make a recommendation that isn't really the full thing that you want them to do.
18:22
Because they might not just be ready for that, maybe they need to take a baby step, so if you have a manual QA person, and then you're mad that they can't debug something in the JavaScript console, it's not really encouraging, because it's not really within their scope of skill. If you want someone to do something that's a little bit above what they can do, pair with them, work with them about it,
18:41
but make sure that what you're asking is something that's a little bit of a stretch, but not so wide of a stretch that it just makes them feel helpless. And the last thing is to speak from your own experience. It's easy to sort of say, hey, I'm pretty sure that person was pissed or whatever, but that's sort of debatable in some ways,
19:01
so talking from your own experience and how you experience the situation. So if I'm in a client meeting and someone interrupted someone, I could say, man, that client seemed really mad that you interrupted them. Or I could say, it made me really uncomfortable when you interrupted the client, and I'm really worried now that they're not happy with us.
19:23
The second part of good feedback is actually about receiving feedback, and that's accountability. So you know in retros we review previous actions and see what's been done. This is really important because it also gives you an opportunity to say, hey, I totally forgot to do that thing you asked, but I'm really going to try to do it this next time.
19:41
The other thing is to explain why you did what you did, especially if it was against their recommendation. So I know that half of the team really, really believe that we should use Ember for our new feature, and the other team thinks that we should just do it all server-side and return HTML fragments.
20:05
And while I totally understand the value of having structured code on the front end, I think right now performance is more important. So I'm explaining why I made a decision. I'm acknowledging the other ideas and opinions and where they're valid.
20:21
And then the last part of this that I think is really important and people often miss is to review the results. So set a meeting for one month, three months. Talk about what it looks like to have this be successful because it makes people feel like they're being heard, but also their voice will still be heard in the future and nothing sort of set in stone.
20:41
The key thing to remember about accountability is that without a response, people are going to stop talking. So it's really like a back and forth. If you want people to give feedback, you need to respond to it in some way. Okay, let's talk about hard stuff. So we live in a society that has oppression, right?
21:04
Racism, sexism, homophobia, transphobia, all of those things. And really oppression is about the unequal distribution of resources, whether that's money or education or influence or people. And that's really what power is. It's about access to resources.
21:21
And power can be formal and informal. So your boss has power over you, but so does the CEO's best friend's son, who might be an intern, but he has dinner every Sunday with the CEO. There's a level of power there, even if it's not formal. And the thing to remember about feedback is that words from a person with power have exponential impact.
21:40
So it's worth considering the power dynamics between you and someone else when you're giving or requesting feedback. Power dynamics exist whether we acknowledge them or not. They exist all the time. And that's okay, but in some ways not acknowledging them makes them more insidious because we can't talk about them.
22:02
So I've been a woman in tech for a long time, and early on I got asked a lot, not as much lately, you know, what's it like to be a woman in tech? And the way that I would describe it is that there's sort of patterns of behavior that come up over and over again, getting interrupted in a meeting, having my ideas ignored, things like that.
22:22
So it turns out some smart academics came up with a word for this, and it's called microaggressions. And the idea is that they're unintentional daily acts that reinforce stereotypes and oppression. So for the person doing the action, it's totally unconscious, relatively insignificant, it's a small thing. For the person experiencing it, it's part of a larger pattern
22:42
that builds up to be very obvious that it's a pattern and a problem, which makes it very difficult to talk about, right? Because for one person it's relatively insignificant, for another person it's actually kind of a big deal. So some simple examples, tone policing, calling women aggressive,
23:01
telling people of color that they're so articulate, because that's shocking, asking people where they're from if they don't look like a white American. The other thing is othering, the idea of making someone feel like they're not part of the group. So everything I know about football I learned from The Blind Side with Sandra Bullock. So if fantasy football or something like that was a part of your main team bonding activity,
23:22
I would not feel super a part of the group, because I basically don't know anything about it. So thinking about how you can have inclusive group activities or a variety so that people are always feeling included. So one of the biggest challenges about experiencing these things is that it's really hard to call someone out.
23:42
And often people don't, because they're afraid of how someone will react. I think that during emotionally charged situations it's not the best time to have a deep discussion about oppression and whether you feel offended and why. And in fact, thinking about having that discussion
24:00
often prevents people from saying anything. So I think it's actually more helpful in a situation like this to just say, that makes me uncomfortable, please stop talking about that, please stop doing it, period. But then how do you respond to that? Say thank you. Again, it sounds weird.
24:21
I think it humanizes the conversation. It took a lot of courage for them to call you out, whether you kind of see that or not. And then if you really genuinely want to know how to improve, ask if you can follow up with them. Can I follow up with you? I'd like to better understand what I did wrong. So again, that moment is probably not the time
24:42
to have that intense discussion. But I do think that someone took the courage to call you out and tell you that your behavior hurt them. You can then meet them halfway by having the courage to say, okay, can we talk about this in two days? And then actually do it.
25:01
So if you're at a stoplight and you rear-end somebody, there's lots of scenarios, right? Like could have been totally you weren't paying attention, could have been they braked really fast, a variety of things could have happened. But either way, you stop your car and you get out and you give them your insurance information, right? You deal with the impact of your actions
25:21
before you talk about the intention. And I think that's really important to think about in this, especially with microaggressions when we know that they're unintentional, like they're by definition unintentional. And so it's not that your intentions don't matter, it's that we have to acknowledge and deal with the impact of our actions before we can talk about the intention.
25:43
So a framework that I really like for difficult conversations is facts, feelings, needs, requests, and this is called nonviolent communication. So similar to the situation behavior impact, state the facts. When we were pairing the other day, you move the keyboard over to your side of the table
26:02
and I couldn't reach it, right? Not when we were pairing you grab the keyboard and totally cut me out of the whole conversation. One of those is with commentary, it doesn't really start us off on the same foot. Let's like understand what we did with basic facts. And then talk about the feelings that it made you feel.
26:21
Now, as I mentioned, we say I feel followed by words that are not feelings a lot. I feel judged is not a feeling, it's an accusation. I feel inadequate is not a feeling because a toaster can be inadequate, but a toaster can't be angry or anguished or hurt or sad, unless it's like a Disney movie or something.
26:43
But we're gonna put that to the side. So, you know, I felt irritated and insecure when you move the keyboard to the other side of the desk. And then we all have human needs, right? Food, water, shelter, et cetera. And we also have higher needs. And often conflict stems from one person having a need
27:02
that isn't being met. So think about what you needed in that situation that you didn't get. So I needed to feel respect from my colleagues and to feel open to communication and a sense of safety to not know everything when I'm working with you. Those were the needs that weren't being met.
27:21
And then I think with difficult conversations especially, it's really important to make a request. You know, you're not gonna sort of magically totally change somebody, but making a baby step is always some level of progress. So in the future, could I type while you drive when we're working on something
27:40
that I don't fully understand, or could you at least ask me before moving the keyboard? So I think that what's really hard about these conversations is that we immediately are like, here, get defensive. It's much easier to get defensive. We all feel uncomfortable. Every time I bring this up, section up, like, the whole room gets a little uncomfortable,
28:00
and I feel it. But if we sort of switch our mindset that thinking about diversity and empathy is really a learning opportunity, it's an opportunity for us to understand and learn about other people's life experiences and how we can better support them and how our actions affect them that we may not even think about.
28:22
So, thank you. Go forth, give feedback. Don't forget your frameworks. Thanks. Does anyone have any questions?