A while back, Peter Bell had me onto The CTO Podcast to do an interview about giving and receiving feedback. You can listen to that right over here, but in case you prefer reading to listening, I did manage to procure the transcript for my portion of the conversation.
I have done a small amount of cleanup on this transcript, and I inserted the approximate question that Peter asked me at each point in the conversation. See below!
Chelsea, do you mind telling us about what you do?
My pleasure. Sure. So I as an engineering consultant, I’m doing a couple of things. My career, uh, probably probably the longest individual stint that I have done in my career was at a company called pivotal labs, which is a consulting shop where they pair with the client pair program with the clients and um, imbue practices into the technical process such as test driven development and continuous integration, continuous deployment and so forth.
So I wanted to take that idea and apply it to kind of my ideal client profile. So I looked specifically for clients who are in a couple of areas. They’re saving the planet or they’re advancing basic scientific research or they’re providing resources to underserved communities. So I’ll reach out to or look for clients who are doing one of those things. And then my technical experience ranges from mobile development to web development to developments to machine learning.
And I will work in any of those areas. But then what I’m doing at the company is kind of to, what I’m doing at the organization rather is twofold. So firstly I’m making technical contributions. I’ll be in sort of a lead or or a staff role as a technical contributor. I’m also helping to imbue collaborative practices into the teams. So similar to the way that a technical consultant might introduce something like test driven development or continuous integration. I’m trying to introduce collaboration strategies for the teams so that engineers can communicate better, can transfer context better, can be in a better position to give and receive feedback from each other and to perform retrospectives so that they can continuously improve their processes and hopefully get more done with less stress.
How do you introduce those collaboration strategies on teams?
Right. So one of the first things that I do is uh, attempt to get a sense the current state of communication at the organization. So some of the big things that I’m looking for are, for example, whether they’re individual people who are responsible for individual projects and how the context is being transferred between team members about those projects. So that if somebody needed to share responsibility for a project or somebody needed to take over a project, would that be possible?
Another thing that I’m looking for is sharing of general knowledge and experience throughout the team. So if somebody runs into an issue and they need some help solving it, what strategies do they have in place to be able to get help from their teammates? And in what ways when, say they learned something at a conference or they learn something new for a new project, in what ways is that, is that knowledge being transferred to the remainder of the team?
And finally, to what degree are engineers able to go and seek that information? Because tech is such a fast changing field that a static education on a specific tool or library ends up being out of date in about eight months. And so our expertise isn’t necessarily in writing code or writing in a specific language. I consider our expertise really to be in. I’m learning continuously learning how to do things that we don’t know how to do. We spend about 80% of our time really on the margin of what we know how to do and have done before. Because if it had been done before, we wouldn’t be in B. We wouldn’t, uh, if it had been done before, we wouldn’t be getting paid these exorbitant amounts of money to do them again in a custom software capacity. We are almost always creating something new and we have to know how to do that in a way that is robust and that is sustainable and that will work for other engineers and will also work for our clients or our end users or the people we’re trying to serve.
How should an engineer balance their time between writing new code and helping other people understand the code they already wrote?
That’s a good question. And I think that uh, there are, depending on where we are in the process, the answer is a little bit different. So at the point at which the technical decisions are being made and the code is being written, I, uh, fall pretty far on the side of valuing the time spent to make it easier for future engineers who will need to read and maintain this code. And that’s true for a couple of reasons.
The first reason is that the code will be written once, but it could be read many, many, many times more than that depending on the audience of this piece of code. You’re talking about eight or nine times floor to thousands or tens of thousands of times ceiling. And so I think it’s valuable for the engineer to spend that time at that point because the amount of time and energy that they are saving all those other engineers is valuable.
I think it’s also the case that when engineers take time to stop and reflect on and explain their decisions, the technical decisions end up being better and that ends up saving the original engineer time on the backend when something they hadn’t considered ends up biting them. Those types of things happen a little less often when they’re spending that time?
Where/how should (software) engineers be documenting their work?
That’s a great question. I think it lives in a number of places and I think you did mention a lot of them. I think that uh, within the, I like to keep documentation when I can within the code base itself because it can be easier for other engineers to find that way. So there are four places in the code where I will tend to keep that information.
1. Naming
So the first one as you mentioned is in naming. Some of the most insidious bugs that I have seen happened because something was named in such a way that somebody assumed the wrong thing about what it was or it was named in such a that somebody misunderstood what the scope of that variable was. And in particular that name and scope thing, like the amount of gray hairs that I have just from that, like it’s a variable that lives inside of a loop, but it’s named the same as a variable that’s outside of the loop. But the scopes don’t cross, but it looks like they do. It’s ridiculous how often that ends up being the problem.
And so I think that that is, uh, a key place where context can end up not getting transferred. And I think that it is not only the cause of insidious bugs, I think that that insidiousness as a characteristic of bugs comes from making it look like the truth is one thing when it’s a different thing. So often when I’m going into a legacy code base for the first time and I’m trying to understand what it does, one of the first things that I do is I use print statements. I use error messages, various debugging tactics to find out what everything is. And then as I figure out what things are I go in and sometimes temporarily, sometimes less temporarily rename things to what makes the most sense for me to understand.
So an example of a temporary one might be if there’s something that I haven’t figured out what it does yet and it’s called block, I will rename it to originally blocked. Don’t know what this does yet and that will remind me because if I, if I start to commit it like that, I’m going to realize, wait, I still have a to do here, which is to figure out what this block thing is. So I think naming is super, super valuable as a way to transfer context. I think that, uh, so that’s helpful for figuring out what things are when it comes to figuring out what things do.
2. Automated Testing
Second, I’m a big fan of tests. I’m a big fan of using unit tests for uh, for documenting an individual class. And also I’m a fan of using integration test to figure out how the whole system works. I also happen to think that there’s a place in the middle for what I call risk oriented tests. So automated tests, they’re quick, but they don’t tell you about the whole system integration test tell you about the whole system, but they tend to be slower to run and they also can flake for reasons related to environmental variables and things that aren’t actually problems. And so there’s lower signal there. And the practical truth is developers trust them less for that reason.
So what I’ll do when I’m building a system sometimes is I’ll go in and I’ll try to figure out which parts of these systems are either the most likely to fail, the most likely to be a huge catastrophe if they fail or, and this one’s important, this one’s the most important one, maybe the most likely to fail without anyone noticing for a long time. And if there’s a place where that’s going to happen, I figure out a way to say it’s three different classes tied together. I’ll test those three classes, interactions in isolation from the remainder of the system.
So we talked about what things are and how they work. There’s also why they work and you can’t always infuse that into the code that is written.
3. Comments
So in those cases, if it’s important for someone to understand, for example, an arcane element of a third party API we’re forced to use, I’ll include a comment in the code to that effect to explain why that is. Now that works great for situations where you have this sort of potentially permanent thing and a reason for it. Sometimes we also have to answer the question of why, which includes a temporal component. For example, this module needs to be this way until X change happens. Or based on the information I have now I’m designing it this way and once I get this question answered, that might change.
4. Commit Messages
So, uh, one critique I often hear of comments is that as those temporal things change, if the comments don’t get changed, then they’re out of date, which is true. And so I’ll tend to put that information instead into a commit message. So I’ll begin with a relatively short descriptor of what I did. And then I’ll also include below that information about design decisions so that someone can go back and look at the commit history for this specific file or the specific set of lines. And they can understand from my commit messages how this piece of code changed and why over time.
Let’s switch gears to one of the team skills you teach—giving and receiving feedback.
Absolutely. So the way that we give and receive feedback is I think a critical component of team collaboration because our team’s skills impact our individual career trajectories and they also impact the overall productivity of our team. But the thing about giving feedback is, and receiving feedback as well, is that it can be really scary. And because of that, we have a tendency to work around that scariness in the way that we give feedback. And I’ll talk a little bit about why that is, but uh, let me back up for a second and talk about what, what, what we mean by feedback, right?
So feedback is, uh, it’s a signal. So there’s a useful tidbit of information from external sources. So it’s not our self-assessment, which can be biased and have blind spots. It’s supplementary signal from somewhere else. Maybe test output or system logs, but usually another person. And it’s about past decisions. So it’s not about us as people, it’s about something that happened and it informs future decisions. So feedback helps us make better future decisions based on what’s happened in the past.
Now, the tricky thing about feedback is that it is designed to help a person or organization improve. And so theoretically we should look forward to it, but we end up being so afraid of it because we have a tendency to set it up as an adversarial interaction. So even if we sort of nominally say that feedback is supposed to be this helpful thing, what we’re usually picturing when we think about feedback is criticism. And that happens because we focus more on negative feedback than positive feedback. It also happens because we don’t really have options for expressing anger or frustration in the workplace because we don’t consider it professional, which is a whole separate issue.
But, but the result ends up being that we, we see feedback as you over on this side of the table and your goal over on the other side of the table and in between you. And that goal is a person who’s giving the feedback, blocking the way between you and your goal of getting your perfect score or your praise or promotion or your bonus money or what have you. And so when we think about feedback in that way, we try to come up with these like ways to still make it work. So we’ll call the feedback constructive as though that actually changes the way we think about it, which it doesn’t. We just back translate the word constructive to negative.
What strategies have you seen people use to give feedback?
Can I cuss on this podcast? Okay. So we’ll do the shit sandwich where you give like a good piece of feedback and then what we think of as a negative piece of feedback and then a good piece of feedback, which doesn’t really end up working because one of two things will happen. Either the person knows it’s a shit sandwich and so they just strip off the bread and only focus on the negative thing or they don’t know it’s a shit sandwich and they think they’re doing great because they got more positive pieces of feedback than the negative piece. Even if the negative piece is really serious. So it doesn’t end up conveying the urgency the way that it should. I have heard one adaptation of this where folks will say feedback should be actionable and specific and kind. A-S-K. That’s getting closer to a paradigm for how to deliver feedback.
But A-S-K assumes that the feedback giver has control over whether their feedback is perceived as kind and the feedback giver does not have control over that. So why might the feedback not have control over that? Well, even if we give our feedback kindly, if the recipient didn’t consent to this feedback, then it might be unwelcome. Or if the recipient doesn’t prioritize the skill that the feedback is about, then the receipt of the feedback feels like a request that they change their priorities. Or if the recipient wasn’t expecting negative feedback and this was a surprise, then it can end up creating this feeling of defensiveness. Even if people asked for the feedback. Because often people will say, Oh, do you have any feedback for me? Um, but, but they’re not necessarily actually thinking about “what am I going to do if somebody delivers me the surprising news that I need to change something about what I’m doing?”
If giving feedback is, is dangerous and scary, why should we give it?
I think there are a few reasons it so, so the first one is, you know, to improve the work and the team because that affects our day to day experience at work. Right? And that’s generally the one that we think about as well when we talk about the ideal circumstance for giving feedback. Yeah. We also do it too. We, so when we give feedback that helps someone, we build a positive working relationship with that person, which is great for our network and it’s great for our work experience too. If we give feedback that somebody sees is helpful, then we get to be seen as a mentor and an advisor, which is helpful if we’re looking to assume a leadership or an expert role. And it’s also, uh, when we get feedback that helps someone, then those people will be more likely to reciprocate with feedback when we want to improve. So there are a lot of reasons to give feedback even even though we see it as this risky, scary thing.
How do we mitigate the risk of giving feedback?
Good question. So to mitigate the risk of giving feedback. I’ll do two things first. The first one is I don’t, I don’t give feedback unless I’m explicitly asked for it. Typically. And second I determined before I answer. If the person is looking for feedback or if they are looking for validation. So if somebody is, people sometimes they’ll ask for feedback with a really looking for is validation. If they want validation and I tell them something’s wrong, then my feedback could be seen as unwelcome or unkind even if I think that they explicitly asked for that feedback. So the way that I determine whether somebody is looking for feedback or validation is I’ll ask them for two or three goals that they have and that helps me understand what they’re trying to get better at and in what areas my feedback for them might be welcome.
That way I’m not providing feedback about something that they don’t want feedback on that they really just want validated. So a good example of when people really just want validation might be they come up and they say, you know, I wrote this piece of code. It’s really fast. I think it’s cool, isn’t it awesome? In that case, they’re really just asking you to look at it and say it’s awesome. You know, so and that’s fine, and I’ll praise it in the highest terms I authentically can. And that helps build the relationship. There’s value in providing people with validation, but sometimes it is disguised and you know, somebody will show you a, a program that they want to implement and they want your feedback on it. But really they kind of want your sign off.
And so how do you figure it out? Well, like I said, asking about about these goals. So then someone might give two or three goals. I want my code to be fast, I want my program to be inclusive depending on what, what thing we’re being asked to give feedback about.
And then after I asked for the goals, I get the person’s self assessment of the work that they have so far. Now this is key because if assessment of the work they have done is purely positive, they’re probably looking for validation, which like I said is fine and I can provide it to build a relationship with this person. But I’ve noted for myself that I might not be safe to express any reservations in the feedback that I’m providing. So that’s, that’s, that’s if their self assessment is purely positive. Now if their self assessment includes some concerns, that tells me that it’s safer for me to provide something other than congratulatory comments alone.
So now I have their goals and I have their self assessment for each goal. Now I’m ready to start preparing my feedback. And so for each goal I’ll make two lists. First list is things they’re doing already that max out their opportunity to be good at this thing. So these are things I think they should keep doing the way they’re already doing to get closer to their goals. So that’s the first list. Second list is things where they still have additional opportunity to improve. So this is things I think that they can change to get closer to their goals.
So now I have these two lists, but if we back out for a second to our analogy, here’s what we’re doing now. Instead of having you on one side of the table and me on the other side of the table and your goal behind me, I’m now moving my chair in the feedback conversation around the table so that both of us are on the same side. We’re looking at the goals on the opposite wall and we’re conspiring to help you get there. So we take away that adversarial idea and we’re trying to create a model of feedback that is more collaborative and cooperative than that adversarial model.
So we’ve covered receiving feedback. Do you have any advice for folks about receiving feedback?
Absolutely. So, uh, what’s interesting about this question is that we need feedback to get better, right? So to accelerate our careers, we want to absorb the knowledge and perspectives of other people, including about us specifically. And we often worry, Oh, you know, what are we going to do if we receive negative feedback? But in the working world, my, my experience isn’t of receiving a ton of negative feedback. The main failure mode that I see is people receiving no feedback at all or not enough feedback. And you know what I see that become more severe as people move up the org chart. And I think the reason for that is that as you move up the org chart and you’re amassing power, essentially there is a smaller and smaller percentage of the organization that I can give you that that you would not even be able to retaliate against without, without consequence.
You know, the more power you have, really the more the, the more people you can fire. And so anybody who you can fire or who you can influence the firing of is, is going to have to make that safety judgment when they determine whether to give you feedback and determine whether it’s, whether it’s worth it for them, particularly if they don’t know how you’re going to react to feedback. And in the absence of other information, people will generally assume that folks don’t respond that positively to negative feedback. Because the truth is most people just don’t respond that positively to negative feedback.
So, so, so what do you, as you, as you move up the org chart, how do you not fall victim to this absence of feedback? Right. Okay. So there are a few things we can do. And I think the first and the most important one to talk about is to expressly solicit feedback and we’ll talk about how to do that. But rather than just sort of hope that people provide feedback, we do need to ask for it. And, uh, not, not, not in the general sense of just saying, you know, does anybody have any feedback for me? But rather to ask people specifically by name, I find that if I gave someone thoughtful feedback in the past, they are more eager to reciprocate when I’m looking for feedback. And so often those are the first people that I will go to in that scenario.
Now, there’s a hack here that I do want to mention, which is what if I want feedback from somebody who, uh, responds negatively to feedback. And so I’m afraid to give them negative feedback, but I want the reciprocation aspect. So it turns out if you just provide validating feedback to someone, they’ll still reciprocate when you ask for, for potentially critical feedback. So, so that’s a good thing to know. So that’s great.
And then so how do we ask for that feedback? Generally the way we hear this is, do you have any feedback for me? If we want really good feedback, we do need to be more specific than this. So I like to give people my goals when I’m asking for feedback. I’d love your feedback on the way that I’m communicating about this specific project, the way that I have architected this specific system for its legibility and overall a maintainability, something like that.
And there are a few reasons for this. First of all, uh, providing goals makes us safer to give feedback to because it’s signals that we wanted enough to have thought about what kind of feedback we want rather than saying, Oh, do you have any feedback for me? I might be surprised if you actually do, but I feel like I need to ask this question because it’s what good leaders do, you know, which it happens a lot. So, so there’s that. Then, uh, I also like the fact that providing goals controls coworkers focus. So if I, if I provide two or three technical goals, the likelihood goes way down that the feedback is like you should smile more or some something completely irrelevant to me. You know, I don’t, I don’t want that personality feedback. So I provide these technical goals or something to that effect.
Also providing specific goals makes it easier for people to think of examples. Suppose I’ve been working for somebody for 15 years. I’ve been working with them for 15 years and I said, do you have any feedback for me? That’s like a lot of stuff, for them to sift, they might not even remember, you know? And so if I provide specific goals that makes it easier for people to think, Oh yeah, you know, you’re looking for feedback on your communication about this specific project. I do remember one time I needed to know something about that project to implement my project and it would have saved me some time if you had said whatever and it wouldn’t have been that much work for you actually. And so, so it’s helpful for getting people to think of examples.
And um, finally, even if folks haven’t listened to a podcast like this one and learned all these techniques for how to give feedback, when I provide goals, uh, when I’m soliciting feedback that makes it easier for other people to frame their feedback as an attempt to help. I say, my goal is to do this. And they’re like, Oh, you want to do this? Okay, well let me help you do this. Because I think that if you were to change X aspect of how you work, it’s going to make it easier for you to do that. And that way they have sort of an on ramp to delivering their feedback to me in a way that’s going to be there in a way that they think will, is likely to be perceived as friendly.
So that’s so I, so I asked specific people I provide specific goals and that’s before I get the feedback, right? Then there’s, okay, so I get my feedback. What do I do after I receive the feedback? Positive, negative, what have you.
So I have constructed a set of steps that I follow and this is why; I find that having steps to follow in stressful situations makes the situations less stressful for me because I’ll end up with this kind of derivative stress where I’m like stressed about my negative feedback. Right? And, but I’m also stressed about the fact that I am stressed now and that just makes it worse cause you know, I don’t know what to do and I’m freaking out. So I have these steps that I follow.
So the first thing that I do, regardless of the nature of the feedback, I thank the person for the feedback. And this the, what we are doing when we do this is we’re establishing that it is safe to give us feedback. When I thank somebody for feedback that signals to them that I’m probably not going to retaliate even if it’s negative feedback. So yeah, I thank them.
Then I explain how I’m going to act on their feedback. This is always important but I find especially helpful when the feedback is something that is going to take us a long time to change because it’s not going to be clear that we’re changing it until a while down the road when we explain how we’re going to act, then we kind of get credit for responding to the feedback even before we’ve done anything. So they get an earlier return on their investment of trust in us.
So then after I’ve explained how I’m going to act, I act, I, I follow through on the feedback that they’ve provided me because when I use the feedback, I demonstrate to the giver that I value what they have to say and improve our working relationship, improve my personal work, et cetera.
And then finally I will, if, if, if possible, I will publicly praise the feedback giver for their help. And the reason that I do this is that this person took time out of their day that they could have spent eating chocolate cake and watching movies to take a professional risk to give me information that I might not have wanted to hear. You know, that really in most cases is going to either have no impact on their career or have a negative impact on their career if I retaliate and I want to change that paradigm. So I’m trying to give them a professional reward for providing me with that feedback. So that’ll make it more likely that they provide feedback to me and to other coworkers in the future.
What do you do if the feedback hurts?
Yeah, it’s a good question. Um, so prior to my engineering career, I was a coxswain, which is the person on a rowing team who sits in the back and yells at the rowers and, uh, steers the boat. So when I was a coxswain, sometimes the rowers would, the coach would ask the rowers to fill out anonymous evaluation forms about my performance. And I hated it. I felt nervous every time because what if they say something bad about me and it’s, it’s terrifying. So a few years into doing this, I started finding it helpful to remind myself that people think what they think about me. And so I might as well know what it is you know by cause if I don’t ask them what they think, then I’m not making them think more highly of me. I’m just cutting myself off from the opportunity to fix whatever’s wrong.
Right? So, uh, if it hurts, what do we do? Good question. If the feedback hurts, that’s when it’s most important for me to follow those steps that I mentioned before because having those steps to follow makes the feedback a little easier to receive on account of. It reduces the panic of not knowing what to do or what to say. So that’s the first thing. The next thing I do is I sleep on it because, uh, a night of sleep has prevented me from making many rash decision. And I find that distancing myself to think about things a little more clearly often helps me. So that’s the second thing. [inaudible] then I’ll do some research. So when I get feedback, I’ll look it up just to find out, you know, have other people receive this feedback before? How common is it? How rare is it? Who tends to get this feedback?
Why do they tend to get this feedback? How do I go about fixing this thing, you know, and the re, so the research, uh, the research part can be a little bit stressful and then then I needed to take that research and figure out an action plan. How am I going to respond to this feedback? And, uh, I don’t necessarily have to do that step alone. So a lot of times I’ll get what I call a processing partner to help me with coming up with an action plan. I’ll find someone who has more institutional power than me so they can feel safe saying no to me. Or when I asked them to do this work for me, or who can correct me if I’ve got something wrong in my research or in my understanding of this feedback that I got and I find out if they are willing to help me work through this feedback and I talk to them about it and the goal of the conversation is to get from, “I got this feedback, I did this research, I’m upset,” to an action plan. Here’s what I’m going to do to act on this feedback. And then once I have that action plan, I can execute on that action plan to get to a better place where I’m not receiving that feedback anymore. Or even better. I’m getting feedback from the original person who, who says that they have noticed a change in the way that I do things in response to this feedback that they provided me.
Chelsea, thanks for talking with us!
Yeah, absolutely. Anytime.
If you like listening to this kind of thing, you might also like:
This podcast with Todd—AKA this ToddCast (Sorry, Todd; I couldn’t help myself)
The other podcast interview (mentioned above)
This half-recorded talk about refactoring (the audio from the whole technology section is intact)